Capabilities

A capability lets an account do one thing in a payout: be paid in a currency, or be named as the sender. This page lists every capability, the identity details each one needs, and how they control payouts. For how a capability’s status changes, see Account model.

​

What a capability is

Each capability has an id: cap_ followed by a Base58 string. Treat it as opaque; don’t try to read meaning into it. An id stands for one fixed set of terms: what it covers, the identity it needs, and its legal basis. When any of those change, OpenFX issues a new id. To see what a capability covers, read its details (CapabilityDetails). It’s read-only and always matches the id:

• grants: what the capability lets the account do, as one or more CapabilityGrant values. A capability with several grants is still one capability, with one set of requirements and one status.
• currencies (optional): the currencies it covers.
• repatriability (optional): which kinds of account it covers, such as regular or NRE for INR.

Two rules apply. A missing field means no limit: no currencies means any currency, and no repatriability means the distinction doesn’t apply. Every combination applies: two grants and two currencies mean both grants for both currencies. Where that wouldn’t hold, OpenFX issues separate capabilities per currency instead. New fields can appear in details, so ignore ones you don’t recognize. Compare capabilities, check payouts, and match webhooks by id, never by details.

​

The capability catalog

These are the ids to use. They’re fixed and global: the same id works in SANDBOX and LIVE, and it’s both what you send in capabilities and what accounts report back. The names in the first column are labels for this page only; the API uses just the id. Identity requirements below lists what each one needs.

​

Request capabilities at create

Send capability ids in capabilities when you create the account. You can only add capabilities at creation, so request every one the account will need, along with the identity details they require. Each starts PENDING. If you send [] or leave it out, the account has no capabilities. Each capability comes back as an AccountCapability with its details, which you can use in your own product, for example to offer adding a EUR payout address once the account can receive EUR. An account can hold each capability only once, ever. Requesting the same one twice fails with 422 CAPABILITY_DUPLICATE. If a capability is rejected, you can’t request it again; you need a different one. Account model explains each status.

​

Identity requirements

Each capability is available to individuals, organizations, or both, and needs certain identity details before it can become ACTIVE. The sections below list them. Each table lists one required field per row, as a path into the account’s identity. An individual’s fields start with identity.individual and an organization’s with identity.organization. If a capability is open to both, each gets its own table. If you request several capabilities, you need the fields for all of them. Most identity fields are optional in the schema, so an account with no capabilities needs very little. These tables show what each capability adds. If anything is missing when you request it, the request fails with 422 IDENTITY_REQUIREMENT_UNMET, and error.details.issues lists every missing field. The capability isn’t created. The When required column gives any condition. “Always” means in every case. Conditions that depend on the account are explained below the table.

​

Receiving capabilities

Receiving capabilities grant RECEIVE_PAYOUTS: the account can be paid. See The coverage gate.

​

Be paid in euro over SEPA

cap_Ji86R1HUP9uUTtp9kdkqBw (RECEIVE_EUR). Covers RECEIVE_PAYOUTS for EUR. Offered to individuals and organizations. An individual needs: An organization needs:

​

Be paid in Mexican pesos

cap_4fdeGSFUm3ux2h2XxRc36m (RECEIVE_MXN). Covers RECEIVE_PAYOUTS for MXN. Offered to individuals and organizations. An individual needs: An individual is identified by an RFC or a CURP. If you send both, OpenFX uses the RFC. A passport isn’t accepted instead. An organization needs:

​

Be paid in Colombian pesos

cap_ErJidGbptNorgQQMFtt8q3 (RECEIVE_COP). Covers RECEIVE_PAYOUTS for COP, to a Colombian bank account or a Bre-B key. Offered to individuals and organizations. An individual needs: A Colombian citizen is identified by their cédula, sent as a NATIONAL_ID issued in CO. A foreign national uses a cédula de extranjería, sent as a RESIDENCE_PERMIT issued in CO, or a passport or national ID from another country. A driving license isn’t accepted. An organization needs:

​

Be paid in UAE dirhams

cap_JgahDHi18aKcx9riZS36wb (RECEIVE_AED). Covers RECEIVE_PAYOUTS for AED, to a bank account held in the United Arab Emirates. Offered to individuals and organizations. An individual needs: No identity document is needed. If you send a PASSPORT, or a NATIONAL_ID issued in AE (the Emirates ID), its number must be at most 50 characters, not counting spaces and separators. The address can be in any country. An organization needs: The name paid is checked on the payout address, not here. A UAE bank account takes a name of at most 75 bytes using letters A to Z, digits, spaces and / – ? : - ( ) . , ’ + &, with no digits for an individual. If the account’s own name doesn’t fit, send accountHolderName when you register the payout address.

​

Be paid into a regular Indian account

cap_R8mRkY9V6dXFFpFrff3mDw (RECEIVE_INR). Covers RECEIVE_PAYOUTS for INR, NON_REPATRIABLE: an NRO or resident account, registered with isNre: false. Offered to individuals only. Every INR capability, receiving and sending, needs a phoneNumber. OpenFX can waive this for your organization, in which case it’s no longer listed as required.

​

Be paid into an Indian NRE account

cap_GKm4sqq9YsRcJj9yMnHyLx (RECEIVE_INR_REPATRIABLE). Covers RECEIVE_PAYOUTS for INR, REPATRIABLE: an NRE account, registered with isNre: true. Offered to individuals only.

​

Sending capabilities

Sending capabilities grant SEND_PAYOUTS_TO_THIRD_PARTIES: the account can be named as the sender of a payout to someone else’s bank account. They exist only for INR today, so a payout in any other currency never names a sender.

​

Be named as the sender to a regular Indian account

cap_R2EcnNENdJX6suu2SWM2fs (SEND_INR). Covers SEND_PAYOUTS_TO_THIRD_PARTIES for INR, NON_REPATRIABLE. Offered to individuals only. A sender is identified by a PAN or an identity document, wherever they live. The document can be a passport, national ID, driving license, or residence permit; send an Aadhaar as a NATIONAL_ID issued in IN. A sender living in the US (residentialAddress.country is US) can use an SSN instead. A PAN is five letters, four digits, and a letter, such as ABCDE1234F; anything else doesn’t count. A document only counts if its issuingCountry is accepted. Both INR-sending capabilities accept every country except these: AF, AI, AO, AQ, AS, BA, BF, BG, BO, BV, BY, CC, CD, CF, CI, CM, CU, CX, EH, ER, GN, GQ, GS, GU, GW, HM, HT, IO, IQ, IR, KM, KP, LA, LB, LY, MC, MH, ML, MM, NE, NF, NI, NR, PA, PG, PN, PS, PW, RU, SD, SJ, SO, SS, ST, SY, TC, TF, TJ, TK, TM, UA, UM, VE, VI, VU, YE, ZW.

​

Be named as the sender to an Indian NRE account

cap_BTfPKkGd8ttTQjf3bxA22g (SEND_INR_REPATRIABLE). Covers SEND_PAYOUTS_TO_THIRD_PARTIES for INR, REPATRIABLE. Offered to individuals only. An NRE sender is identified the same way as a regular one: a PAN, or a passport, national ID, driving license, or residence permit from an accepted country. An SSN doesn’t count here. An NRE sender lives outside India, so residentialAddress.country can’t be IN or a sanctioned country.

​

The coverage gate

A payout checks what a capability covers, not its id. When you create a payout, OpenFX works out the coverage it needs from the receiveCurrency and, for INR, from the bank account’s isNre. The receiver, and the sender if there is one, must each hold an ACTIVE capability that covers it.

• RECEIVE_PAYOUTS lets the account be paid at the bank accounts its capability covers.
• SEND_PAYOUTS_TO_THIRD_PARTIES lets the account be named as a payout’s sender. It only grants permission: the money still comes from the payout’s financialAccountId, never from the sender. It exists only for INR today, so only INR payouts and quotes can name a sender. Naming one on a payout or quote in any other currency fails with 422 SENDER_NOT_SUPPORTED.

The payout has no field for the sender’s account type. For INR, the bank account’s isNre decides it for the whole payout. A payout address doesn’t name a capability, but its account must already hold one that can receive at it, in any status. See Payouts. OpenFX decides how the payout is delivered.

​

How the vocabulary evolves

Capabilities are only ever added. A published capability is never renamed or changed. To widen what a capability covers, OpenFX issues a new capability and grants it to accounts that already meet its requirements. You get common.account.capability_activated without doing anything. A change to requirements or legal basis always means a new capability. To retire one, OpenFX issues a replacement and moves holders of the old one to REJECTED; the old one can then no longer be requested. This means capabilities are versioned without version numbers, and one capability may be replaced by several ids over time. Because payouts check coverage across all your ACTIVE capabilities, you won’t notice this when paying, and your audit trail stays clear.

​

What’s next