Skip to main content
Release type: Enhancement (Backward-compatible) Applies to: Payout Bank Metadata The Payout Bank Metadata endpoint (GET /v3/metadata/payout/bank) now returns additional capability fields in its response. These fields help you understand the capabilities and restrictions of each payout method before initiating a payout.

Where the new fields live

The placement of the capability fields depends on payout_type: The two levels are mutually exclusive, not a precedence pair: whichever level applies carries the values and the other is returned empty, so you never have to reconcile the two. This split exists because for local, capabilities (operating hours, OBO support, purpose-code restrictions, etc.) are inherently network-specific (e.g. IMPS vs NEFT in India, FPS vs CHATS in Hong Kong). For swift there is no fund-transfer-network array, so the corridor top level is the only meaningful place.

New Fields

The five new capability fields appear either at the top level (swift) or inside each fund_transfer_networks entry (local): “Group” = the corridor for swift; the network within the corridor for each fund_transfer_networks entry on local.

Example Response

In the example above:
  • The first entry (payout_type: local, IN/INR) returns the capability fields empty at the top levelnull for delivery_time, on_behalf_of_supported and cutoff_schedule, [] for the two arrays. Each fund_transfer_networks entry carries the real values instead, and they differ per network: IMPS is instant and OBO-capable, NEFT is "next_day, t_plus_2, t_plus_3" and restricts purpose code P0102.
  • IMPS has cutoff_schedule: null, which means it is available 24/7. NEFT publishes a Mon–Fri window in Asia/Kolkata, closing early on Friday.
  • The second entry (payout_type: swift, IN/OMR) carries the capability fields at the top level, because fund_transfer_networks is an empty array for swift.
null is meaningful — it is not the same as false or "". These fields are always present in the response; an unset capability comes back as null (delivery_time, on_behalf_of_supported, cutoff_schedule) or [] (supported_modes, restricted_purpose_codes). In particular on_behalf_of_supported: null means “not stated at this level”, whereas false means “explicitly not supported”, and cutoff_schedule: null means 24/7, not “unknown”. For local corridors always read the per-network values so you do not miss network-specific behavior.