How a neobank gives users account details in USD, MXN, and COP and local top-ups in BRL and ARS without an entity per country, and where the FX happens.
A neobank can offer multi-currency accounts without opening a local entity in each country by issuing account details through a provider's partners. With BlindPay, users get US account details, a Mexican CLABE, or a Colombian Bre-B key, plus Pix and Transfers 3.0 instructions for BRL and ARS. Every deposit converts on arrival and lands in a dollar stablecoin balance.
That covers the money-in side: which currencies your users can receive, how each one reaches them, and where the exchange rate gets fixed. It's one layer of building a neobank. Sending money out in those currencies gets a short section at the end.
Key takeaways
To hold a local bank account in your company's name, and to sign up directly with the country's payment rails through a bank. That's the traditional route to collecting in a currency.
Each entity brings its own registration, tax filings, directors, local bank relationship, and accounting. Multiply by every country your users live in. For a neobank serving freelancers in Mexico and Colombia, or families in Brazil, that cost lands before the first user deposits a peso.
The alternative is to collect through a provider that already runs those bank and rail relationships, and to issue each of your users their own account details on top. Your licensing questions don't disappear. Do you need a banking license for a neobank walks through them. This is educational content, not legal advice.
| Open local entities | Partner bank per country | One API with virtual accounts and local rails | |
|---|---|---|---|
| Time to first currency | Longest: incorporation, then a bank account | Long: one bank negotiation per country | Shortest: one integration, then per-customer KYC |
| Fixed cost | Entity upkeep in every country | Bank minimums and integration per country | Platform plan plus per-account and per-transaction fees |
| Compliance work | Local AML program in each country | Each bank's onboarding and reviews | Provider runs KYC, KYB, and screening in the flow |
| Integrations | One per bank, per country | One per bank | One |
| Accounts in user's own name | Possible, per bank | Depends on the bank | US accounts yes; CLABE and Bre-B use a pooled name |
| Best for | Very large local volume, local lending | A few deep corridors | Launching several currencies at once |
Five currencies, two shapes. Permanent account details for repeat deposits, one-time instructions for top-ups.
| Currency | Permanent account details | One-time instruction | Payer's rail |
|---|---|---|---|
| USD | US virtual account, routing and account number in the user's name | Not needed once the account exists | ACH, wire, SWIFT |
| MXN | SPEI CLABE virtual account, 18 digits, unique to the user | SPEI CLABE from a payin quote | SPEI |
| COP | Bre-B key, for customers with a Colombian document | PSE payment link | Bre-B, PSE |
| BRL | Per top-up, from a payin quote | Pix code (copy and paste or QR) | Pix |
| ARS | Per top-up, from a payin quote | CBU from a payin quote | Transfers 3.0 |
Eligibility differs by account. A SPEI CLABE account is available to individuals and businesses from any country, one per customer, and never reassigned. A Bre-B key needs a Colombian ID card or a NIT, one key per document, and each deposit is limited to about COP 12,000,000 depending on the payer's bank. US virtual accounts need approved KYC plus account purpose and source of wealth, and go through a compliance review and a bank review.
For the US side in detail, see US account details for every customer. For a full Mexico flow, see the SPEI transfer feature.
At the deposit. That one decision shapes your balance design.
After conversion, the user's balance is a dollar stablecoin in their wallet. That's the "hold" part of multi-currency: one dollar balance, shown in your app in dollars, with the original currency kept on each deposit record. If you want to display a peso balance too, compute it from a live rate and label it as an estimate.
Illustrative example. The company and amounts are invented.
A US startup builds an app for freelancers in Brazil and Mexico who bill US clients and get paid locally too.
The startup holds no entity in Mexico or Brazil. It does hold a product decision for each step: which accounts to issue at sign-up, which only on request (each US account costs $1.50 a month), and how to show a balance that came in three currencies.
It runs on the same balance. A payout quote locks the rate and fees, and the payout lands over the local rail: Pix in Brazil, SPEI in Mexico, ACH Colombia, Transfers 3.0 in Argentina, ACH, RTP, and wire in the US, SEPA in Europe, Faster Payments in the UK, and SWIFT (POBO/COBO) for the rest. Multi-currency payouts from one USDC balance covers the treasury side, and which payout rails to launch first helps you pick.
BlindPay gives a neobank one integration for collecting in several currencies. US virtual accounts carry each customer's own name and accept ACH, wire, and SWIFT. SPEI CLABE accounts give any customer a permanent Mexican CLABE, and Bre-B accounts give Colombian customers a permanent key, both active as soon as they're created. Payin quotes add Pix in Brazil, Transfers 3.0 in Argentina, PSE in Colombia, and one-time SPEI.
Every deposit becomes a payin that converts at the live or quoted rate and settles as USDC or USDT in the customer's wallet, so the balance is one dollar stablecoin no matter where the money came from. KYC, KYB, and sanctions screening run per customer in the same API, and Svix-signed webhooks tell your ledger when each deposit completes.
The same balance funds payouts over local rails, with the rate and fees locked in the quote before execute.
List the currencies your first 100 users get paid in, then match each one to a row of the currency table above. Create a development instance and issue one account of each type from the virtual accounts docs.
Always cheaper? No intermediaries? Recipient needs a wallet? 10 common claims about cross-border stablecoin payments, checked against the Fed and the BIS.
Seven places blockchain payments beat bank rails: contractor payroll, remittances, B2B suppliers, marketplaces, 24/7 treasury, bill pay, and PSP payouts.
The dates that turned stablecoins from a trading tool into cross-border payment rails: USDC, Pix, MiCA, the GENIUS Act, ISO 20022, and Visa settlement.