Canonical payment-rail vocabulary, shared by named accounts and payout
destinations. The table below answers one question: can you open a named
account on this rail (machine-readable in x-ozav-rail-availability)?
Paying out is a different question, answered by the corridor table in
POST /payout-destinations. The two differ: fedwire, for example, is
live for payouts, while opening a USD account on it is sandbox only.
| Rail | Corridor | Availability |
|---|
| pix | BRL - Brazil instant payments | available |
| fedwire | USD - US wire | sandbox only |
| sepa | EUR - SEPA credit transfer | live (behind enablement) |
| spei | MXN - Mexico SPEI | sandbox only |
| swift | Cross-border SWIFT | live (behind enablement) |
| faster_payments | GBP - UK Faster Payments | live (behind enablement) |
ach and co_transfer are not offered. Requests for accounts, payout
destinations and quotes use RequestRail, which leaves both out, and a
fiat_payment source on ach is refused with 422 RAIL_NOT_AVAILABLE.
They stay in this enum only because older records carry them.
live (behind enablement) means the corridor is served in production,
but not to everyone: opening an account still requires that OZAV has
enabled the specific customer for foreign-currency named accounts. Until
then a live request is refused with a named error that says which step
is missing - not with ACCOUNT_RAIL_NOT_AVAILABLE, which would send you
looking at the corridor instead of the customer.
sandbox only is a real, usable state, and not a promise of later.
The corridor is fully exercisable with a test key: you can open the
account, read its receiving instructions and build against the exact
response shape production will return. What it does not have is a
settlement partner behind it, so a live key is refused with
ACCOUNT_RAIL_NOT_AVAILABLE rather than opening something that cannot
receive. Build against it in sandbox; the request you write does not
change when the corridor goes live.