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 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.

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

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 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.

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.

"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:

{
  "local": {
    "fund_transfer_network": "imps"
  }
}

See Fund Transfer Networks for the full payout-object contract.

Relevant Links

1. Payout Bank Metadata API
2. Payout Bank Metadata Fields
3. Fund Transfer Networks
4. Supported Purpose Codes
5. Payouts On Behalf Of
6. Create Payout