Multi-currency accounts without local entities: how a neobank collects in USD, MXN, COP, and BRL

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

  • "Multi-currency account" usually means three things: receive in several currencies, hold value, and pay out locally. Entities are the expensive way to do all three.
  • BlindPay issues permanent account details in USD (US virtual account), MXN (SPEI CLABE), and COP (Bre-B key), and one-time instructions for BRL, ARS, and COP.
  • Conversion happens at the deposit. The balance is held as USDC or USDT.
  • CLABE and Bre-B accounts show a pooled recipient name. US accounts carry the user's own name. Tell payers which one they're looking at.
  • KYC is per customer. Each account type has its own eligibility rules.

What do you normally need a local entity for?

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.

How do the three routes compare?

Open local entitiesPartner bank per countryOne API with virtual accounts and local rails
Time to first currencyLongest: incorporation, then a bank accountLong: one bank negotiation per countryShortest: one integration, then per-customer KYC
Fixed costEntity upkeep in every countryBank minimums and integration per countryPlatform plan plus per-account and per-transaction fees
Compliance workLocal AML program in each countryEach bank's onboarding and reviewsProvider runs KYC, KYB, and screening in the flow
IntegrationsOne per bank, per countryOne per bankOne
Accounts in user's own namePossible, per bankDepends on the bankUS accounts yes; CLABE and Bre-B use a pooled name
Best forVery large local volume, local lendingA few deep corridorsLaunching several currencies at once

Which currencies can your users receive through BlindPay?

Five currencies, two shapes. Permanent account details for repeat deposits, one-time instructions for top-ups.

CurrencyPermanent account detailsOne-time instructionPayer's rail
USDUS virtual account, routing and account number in the user's nameNot needed once the account existsACH, wire, SWIFT
MXNSPEI CLABE virtual account, 18 digits, unique to the userSPEI CLABE from a payin quoteSPEI
COPBre-B key, for customers with a Colombian documentPSE payment linkBre-B, PSE
BRLPer top-up, from a payin quotePix code (copy and paste or QR)Pix
ARSPer top-up, from a payin quoteCBU from a payin quoteTransfers 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.

Where does the exchange rate get fixed?

At the deposit. That one decision shapes your balance design.

  • Permanent CLABE or Bre-B deposits convert at the live rate when the money lands. Each deposit is a new payin.
  • One-time instructions come from a payin quote, which locks the rate for its window (5 minutes on BlindPay, 10 seconds for BRL OTC quotes). The payer must send within the payin's waiting period.
  • USD deposits settle to USDC or USDT without a currency conversion.

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.

What does this look like for a US startup serving Brazil and Mexico?

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.

  1. A user in Guadalajara passes KYC. The app issues a US virtual account for US clients and a SPEI CLABE for Mexican clients.
  2. A US client pays $2,000 by ACH to the US account. It settles as USDC in the user's wallet.
  3. A Mexican client pays MX$ 18,000 to the CLABE. It converts at the live rate and settles as USDC in the same wallet.
  4. A user in São Paulo tops up R$ 500 by Pix from a payin quote, then sends money to family over Pix.

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.

Common mistakes

  • Promising the user's name on every account. CLABE and Bre-B payers see a pooled name. Show it in the app before the user shares the details.
  • Issuing every account at sign-up. Issue at a moment of intent.
  • Showing a converted balance as exact. A peso view of a dollar balance moves with the rate.
  • Forgetting Bre-B's per-deposit limit. Point larger Colombian payers to PSE.
  • Treating a one-time instruction as permanent. A payin quote's CLABE or Pix code belongs to that payin.
  • Skipping the eligibility check. Bre-B needs a Colombian document. Check before you offer it.

What about sending money out in those 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.

How BlindPay fits

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.

What to do next

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.

FAQ