> ## Documentation Index
> Fetch the complete documentation index at: https://developer.tazapay.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Using Payout Capability Fields

> What the capability fields in Payout Bank Metadata tell you about a corridor, and how to read them.

The [Payout Bank Metadata](/api-reference/tazapay-api/payout-bank) response describes what each corridor can do, not just which fields a payout request needs. Five capability fields — `delivery_time`, `on_behalf_of_supported`, `supported_modes`, `restricted_purpose_codes` and `cutoff_schedule` — tell you the shape of payouts a corridor supports and when they will settle.

These are informational. A payout that falls inside what a corridor advertises will pass through; you do not need to reproduce these rules as checks of your own.

## Where to read them

Placement depends on `payout_type`:

| `payout_type` | Read from                           | The other level                     |
| :------------ | :---------------------------------- | :---------------------------------- |
| `local`       | each `fund_transfer_networks` entry | corridor top level is `null` / `[]` |
| `swift`       | corridor top level                  | `fund_transfer_networks` is `[]`    |

The two levels are mutually exclusive — whichever one applies carries the values and the other is empty, so there is never anything to reconcile.

<Warning>
  For `local` corridors the top-level capability fields are intentionally empty. Read the per-network values, otherwise every network looks unrestricted.
</Warning>

## What each field tells you

### `supported_modes`

The remitter-to-beneficiary combinations the corridor carries: `B2B`, `B2C`, `C2B`, `C2C`. The first letter is the remitter and the second the beneficiary, where `B` is a business and `C` is a consumer.

A corridor listing only `B2B` and `B2C` carries payouts sent by a business. One that also lists `C2B` and `C2C` carries consumer-funded payouts as well.

### `restricted_purpose_codes`

[Purpose codes](/payouts/local-guides/supported-purpose-codes) the corridor does **not** carry. An empty array — the common case — means every purpose code is accepted.

### `on_behalf_of_supported`

Whether the corridor carries [Payouts On Behalf Of](/payouts/capabilities/payouts-on-behalf-of).

`true` means supported, `false` means it is not, and `null` means not stated at that level. A `null` on a `local` corridor means you are reading the top level instead of the network.

### `delivery_time`

A settlement speed label, not a duration. Values are drawn from `instant`, `same_day`, `next_day`, `t_plus_2` and `t_plus_3`, and one value may carry several labels separated by commas, e.g. `"next_day, t_plus_2, t_plus_3"`.

Treat it as an open set — match on substrings rather than a fixed enum, since new labels can be introduced without a breaking change. `null` means no estimate is published.

### `cutoff_schedule`

The corridor's weekly operating window, useful for knowing when funds will actually move.

**`null` means available 24/7.** When a schedule is present:

* `timezone` is an IANA identifier (e.g. `Asia/Kolkata`). An **empty `timezone` means the times are UTC**.
* Keys in `days` are ISO 8601 day numbers — `"1"` is Monday through `"7"` is Sunday.
* A day key that is **absent means closed** on that day.
* `open` and `close` are `"HH:MM"` in 24-hour form, and the **close minute is inclusive**.
* A window whose `close` is earlier than its `open` (e.g. `"22:00"`–`"06:00"`) **rolls over into the next day**.

```json theme={null}
"cutoff_schedule": {
  "timezone": "Asia/Kolkata",
  "days": {
    "1": { "open": "09:00", "close": "17:00" },
    "2": { "open": "09:00", "close": "17:00" },
    "3": { "open": "09:00", "close": "17:00" },
    "4": { "open": "09:00", "close": "17:00" },
    "5": { "open": "09:00", "close": "15:00" }
  }
}
```

A payout created outside the window is not rejected — the funds move when the window next opens.

## Worked example — IMPS and NEFT

For `IN` / `INR` the corridor returns `payout_type: local` with two networks:

|                            | `imps`                     | `neft`                         |
| :------------------------- | :------------------------- | :----------------------------- |
| `delivery_time`            | `instant`                  | `next_day, t_plus_2, t_plus_3` |
| `on_behalf_of_supported`   | `true`                     | `false`                        |
| `supported_modes`          | `B2B`, `B2C`, `C2B`, `C2C` | `B2B`, `B2C`                   |
| `restricted_purpose_codes` | `[]`                       | `["P0102"]`                    |
| `cutoff_schedule`          | `null` (24/7)              | Mon–Fri, `Asia/Kolkata`        |

Read together, that tells you:

* `imps` carries consumer-funded payouts and OBO payouts; `neft` carries neither.
* `neft` does not carry purpose code `P0102`; `imps` carries every code.
* `imps` settles instantly and is open 24/7, while `neft` settles next day or later and only moves funds during Indian banking hours.

So a consumer-funded OBO payout, or one carrying `P0102`, is served by `imps` on this corridor.

## Choosing the network

Where a network reports `remitter_preference_support: true`, you can name it on the payout request rather than leaving the choice to Tazapay:

```json theme={null}
{
  "local": {
    "fund_transfer_network": "imps"
  }
}
```

See [Fund Transfer Networks](/payouts/payout-network/fund-transfer-networks) for the full payout-object contract.

## Relevant Links

1. [Payout Bank Metadata API](/api-reference/tazapay-api/payout-bank)
2. [Payout Bank Metadata Fields](/api-reference/tazapay-api/payout-bank-fields)
3. [Fund Transfer Networks](/payouts/payout-network/fund-transfer-networks)
4. [Supported Purpose Codes](/payouts/local-guides/supported-purpose-codes)
5. [Payouts On Behalf Of](/payouts/capabilities/payouts-on-behalf-of)
6. [Create Payout](/api-reference/tazapay-api/create-payout)