Add Bank Account

Use this endpoint to maintain a fiat account that will be used as either a payer (debit/outgoing) account or a beneficiary (credit/incoming) account.

Important: this API is for fiat rails only (e.g., PIX, local bank, SEPA, SWIFT). It is not for crypto addresses or on-chain wallets.

What it’s for

Transfer flow

• Add your payer account so we can validate ownership and accept funds from you.
• Add your beneficiary account so we can off-ramp and deliver the converted fiat to the right destination.

Sell flow

• Add your beneficiary account to receive the fiat proceeds after the sale.

Please note: The beneficiary account for these two flows can be the same, meaning you only need to maintain one account to use it in multiple places.

Scope & variability

We support multiple payment networks and corridors (e.g., PIX/BR, SEPA/EU, SWIFT/global, and other local rails). The required fields change dynamically by networkType and country:
• Example:

BRL(PIX)

USD(SWIFT)

EUR(SEPA)

CNPJ or CPF: A unique identifier for users or merchants in Brazil.

PIX Key: Used for receiving and making payments, supporting information such as email, phone number, or CNPJ.

Account Holder Name: Client KYB/KYC name.

Validation & compliance

BPN verifies:

Ownership / name match (payer side) to reduce third-party risk.

Format & network consistency (e.g., IBAN structure, bank code validity, currency–country alignment).

Eligibility of the rail for incoming/outgoing payments on the specified corridor.

Depending on corridor, we may require additional data to support Travel Rule / payer information capture and internal compliance checks.

Rules & best practices

You can store multiple payer and beneficiary accounts per merchant.

Use accountType to indicate whether you are adding a PAYER or BENEFICIARY account.

Use networkType (e.g., PIX, SEPA, SWIFT, LOCAL) and country / currency to select the rail; the API will enforce the correct field set for accountInfo.

Add accounts before you request a transfer/sell; downstream transactions reference accountId only.

For payer accounts, ensure the legal name and document ID match your onboarding/KYB/KYC records; mismatches may be rejected.

Typical flow

First Step

Merchant calls Add Account to register payer/beneficiary details for a given rail.

Second Step

BPN validates the data and returns a unique accountId with status.

Third Step

Merchant reuses accountId when calling Transfer Estimation / Confirm Transfer (payer & beneficiary) or Sell (beneficiary).

application/json

Body

Example

{
    "status": 200,
    "data": {
        "accountId": "13",
        "externalAccountId": "EX1231",
        "bindStatus": "ad aliqua"
    },
    "traceId": "35"
}

What it’s for

Scope & variability

Validation & compliance

Rules & best practices

Typical flow

Request

Request Code Samples

Responses

Add Bank Account

What it’s for#

Scope & variability#

Validation & compliance#

Rules & best practices#

Typical flow#

Request

Request Code Samples

Responses

What it’s for

Scope & variability

Validation & compliance

Rules & best practices

Typical flow