Multi-currency accounts without a local entity are accounts in Brazilian reais, Mexican pesos or Colombian pesos that a provider's banking partners issue to a customer, so the customer needs no company registered in each country to receive local payments. The customer passes verification once, and deposits can convert to a dollar stablecoin balance.
The accounts do not remove the customer's own tax, employment or licensing duties in those countries. Those belong to the local entity decision and to local counsel. This guide is the how-to. A named virtual account (a local account number issued in the customer's own name) is the account type underneath, and a pooled account is the alternative.
What a foreign company needs instead of a local entity
A provider replaces the local bank relationship, not the company's legal existence. The account holder is the company itself, verified through KYB (know your business, the verification of a company and its owners) with its own country and tax ID. What KYB is covers the process in general. Three things follow:
The company needs no subsidiary or branch to receive local account details.
Verification takes the place of local paperwork: incorporation documents, owners and directors, and a proof of address.
Tax filings, employees, local invoices and any regulated activity stay with the company.
On Lumx, a foreign company holds BRL and MXN accounts without an entity in Brazil or Mexico, and a COP account is available to any customer. The customer of record is the company, with its own country and tax ID, and the supported countries page lists the tiers: Supported, High-Risk (EDD Required) and Restricted.
Which accounts can a foreign company hold in BRL, MXN and COP?
One account per currency, each on the rail of its country. Brazil runs on Pix (Brazil's instant payment system, run by the Central Bank). Mexico runs on SPEI (Mexico's interbank transfer system, run by Banxico), and the payer sends to a CLABE (the 18-digit Mexican bank account number). Colombia collects over Bre-B (Colombia's instant payment system) and PSE (Colombia's online bank-transfer network).
What each account gives the payer, and whose name it carries
Currency | The payer sends to | Rail | Name on the account | Ready after approval |
BRL | A static Pix QR code, or a Pix code for one amount | Pix | The customer | Right after the customer is approved |
MXN | A CLABE, with a memo carrying the reference | SPEI | The customer | Right after the customer is approved |
COP | The Bre-B key of the COP account, or a PSE payment | Bre-B, PSE | The customer if it is Colombian, the banking partner for every other customer | Right after the customer is approved |
BRL runs over Pix only. The same request can add USD, EUR or GBP accounts too.
The COP row is the one to explain to payers. A COP account is available to any customer, but only a Colombian customer gets a named one. For everyone else the holder the payer sees is the banking partner, so say so in your payment instructions before the first transfer. A payer who sees a bank's name instead of the customer's often stops the transfer and asks finance whether it is going to the right company, or sends it and cannot match the receipt to the invoice.
Collections have a ceiling too. The same 1,000 UVB cap that limits Bre-B payouts applies to a payer's Bre-B transfer into the account, so a larger invoice needs PSE, the other collection route, or a smaller transfer.
On Lumx, the currencies go in the accounts array of the customer request, each one enters verification alongside the customer, and the BRL and MXN accounts are active right after approval (per the Lumx docs, read November 1, 2026).
Step by step, from the customer request to the first deposit
The six steps and the signal behind each
Step | What happens | Call or event |
1. Create the customer | Send the company's details and the currencies it needs |
|
2. Accept the terms | The company opens a terms page, which expires after 24 hours |
|
3. Verify the business | Send company details, upload documents, add owners |
|
4. Wait for each account | Each account moves through requested and provisioning to active |
|
5. Share deposit details | A rule or an on-ramp returns the Pix code or the CLABE |
|
6. The deposit lands | Converted and credited to the company's wallet |
|
Verification asks for four documents: the articles of incorporation, the shareholder registry, the directors registry and a proof of address issued in the last 90 days. It also needs at least one associated party in each of three roles: a UBO (ultimate beneficial owner, always an individual, with 25 to 100% ownership), a shareholder and a representative. One person can hold several roles. The company also states its activity, expected volume and source of funds.
Lumx targets one business day for KYB once everything is in. That is a target, not a promise. When compliance needs more, the customer or the account moves to an RFI (request for information, a compliance hold that asks for a document before a transaction clears), and the clock restarts when the answer arrives. A company based in Colombia always goes through enhanced due diligence, so plan for extra documents there.
If you would rather not build the form, share the verification link returned on the customer, and do not mix it with API submission for the same customer.
On Lumx, this sequence runs in the sandbox first, where the last digit of the taxId drives the simulated verification result, and COP works there too.
One account per end customer, never one shared by many
A platform whose users each need local details does not share one account among them. Each user becomes its own customer, with its own verification and its own accounts. The rule behind it is simple: before any payment, ask whose money it is and whose business it pays for. If both answers are the onboarded customer, the flow fits. If either names someone the provider has not onboarded, it is a pass-through.
Launching a dollar account app follows the same rule.
I recommend asking for only the currencies a customer will collect in on day one, and adding the next one when the first payer in that country shows up. Each requested account carries its own status and can stop in an RFI on its own, so three accounts at sign-up are three things for support to explain, and an unused one is still a screen someone has to watch. I would start a customer with the currency of its largest payer, add the others on request, and keep COP for customers who really have Colombian payers, because that is the account where the name the payer sees can differ.
On Lumx, accounts are never pooled: Lumx's nested payments rules require every end customer to be onboarded as its own customer, and a marketplace's sellers each hold their own account, with the platform's cut collected as a partner fee.
Where does the conversion happen, and how does a deposit find its customer?
At the deposit. The local currency lands in the account, converts to a stablecoin, and the stablecoin is credited to the customer's wallet. The balance is USDC or USDT, not reais or pesos, so any local figure next to it is an estimate. For Pix and SPEI, every account belongs to one customer, so attribution is built in, and matching a deposit to an invoice or a payer can run two ways. The table covers those two rails. A COP account collects on the Bre-B key of the account or through PSE.
Two ways to take a deposit, as the Lumx docs describe them
Conversion per deposit | Standing rule | |
Set up | An on-ramp created for the exact amount | An autoconversion rule on the account |
What the payer gets | A Pix code or a CLABE for that amount | One static Pix code, or a CLABE with a memo, reused |
How it is matched | The deposit has to match the on-ramp | The Pix |
A late payment | Refunded to the sender on the same rail | Converts whenever it is paid through the rule |
Fits | A fixed invoice | Recurring or unknown amounts |
A floating on-ramp over Pix or SPEI expires after 1 day. A payment that arrives after that is not processed, and the money goes back to the sender on the same rail, so tell the payer that on the expired screen. Without that line, a payer sends the Pix a day late, watches it bounce back, and writes to your finance team asking why the invoice still shows as open. Key your own ledger on the customer ID and the transaction ID, and let the events move the status until onramp.success, with onramp.expired and onramp.failed as the exits.
On Lumx, every account converts its deposits the same way, COP included, and a BRL or MXN account can carry several autoconversion rules, one per payer. Each rule picks the target asset and one of Ethereum, Polygon, Base, Tron or Stellar, subject to the pairs on the coverage page.
Who holds the money while it sits in the account
Two layers. The fiat sits in an account at a banking partner until it converts, and afterwards the stablecoin sits in a wallet. Ask which entity holds each layer, because the customer's own counsel will.
On Lumx, the virtual account is issued by a banking partner in the customer's name, and the stablecoin sits in a custodial wallet segregated per customer. Lumx is not a bank. Lumx US OP LLC is a FinCEN-registered Money Services Business, and regulated money transmission runs through licensed financial-institution partners. In Brazil, services are provided by Lumx Sociedade Prestadora de Serviços de Ativos Virtuais Ltda, which is adapting to the SPSAV regime under Central Bank of Brazil Resolution 520/2025, under the Article 88 transition regime. If your own product looks like a bank, that is a separate question, covered in neobank licensing in Brazil.
Taking money out of the same accounts
The wallet that collects also pays, converting the stablecoin and sending local currency over the destination's rail. For a EUR account, see paying Latin American suppliers from Europe.
Withdraw by country
Country | Rail | What the destination needs | Corridor |
Brazil | Pix | The recipient's Pix key or bank details | |
Mexico | SPEI | The recipient's CLABE | |
Colombia | Bre-B or ACH Colombia | A Bre-B key, or the holder's details and bank account |
In Colombia the rail is fixed when the destination is registered. A Bre-B payout above 1,000 UVB per operation is refused and not split. The cap comes from section 3.2 of the Banco de la República's Circular Reglamentaria Externa DSP-465 of March 31, 2026, and applies to every provider. The Banco de la República's "Conozca Bre-B" page puts 1,000 UVB at COP 12,110,000 for 2026 (read November 1, 2026).
Default limits for a standard KYB customer are USD 50,000 per transaction and USD 100,000 per day and per month, and enhanced verification raises them.
On Lumx, a payout needs a destination, with a holder relationship such as SELF for the company's own account or SUPPLIER for a third party. No fee comes out of the amount that reaches the recipient on a Pix, SPEI or Bre-B payout, and on a Pix payout the recipient sees the customer as the payer. A company that wants the dollar side of the same wallet can read receiving USD as a Brazilian company.
When this setup is the wrong tool
The company has local employees, issues its own local tax invoices or carries out a regulated activity. Those push a company toward an entity, and an account changes none of them.
Local revenue is large and steady, and local costs are paid from it. Converting twice can cost more than an entity.
Users expect a bank deposit. A stablecoin balance is not one.
Money belongs to people the provider has not onboarded. That is a pass-through, which is refused.
What this looks like on Lumx
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
For this guide, the customer is the foreign company or one of its end customers. It is created once, with the currencies it needs, accepts Lumx's terms on a hosted page and passes Lumx's verification. Each account then reports its own status, and the account.active event is the moment to show deposit details. The named virtual accounts page describes the account type, and the coverage page lists the live rails.
What fails shows up as an event too. An RFI on a customer or an account names the missing information, and an expired on-ramp refunds a late payer on the same rail.
The next step is the sandbox. Run the six steps there first, where COP works too, and the verification result is driven by the last digit of the taxId. The sandbox quickstart takes an empty project to a converted deposit without a real bank transfer.
Methodology and sources
Every Lumx statement comes from the docs pages for accounts, customers, global accounts, business verification, identity verification, autoconversion rules, transactions, destinations, transaction limits, nested payments and coverage, read on November 1, 2026. The Bre-B cap comes from the Banco de la República circular linked above, and the peso figure from its "Conozca Bre-B" page.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Ahmet Yüksek ✪ on Unsplash.
Can a company get multi-currency accounts without a local entity?
Yes, for receiving local payments. A provider's banking partners issue the account details after the company passes verification, so no subsidiary is needed to collect. Tax, employment and licensing duties stay with the company. On Lumx, a foreign company holds BRL and MXN accounts without an entity in Brazil or Mexico, and a COP account is available to any customer.
Whose name does the payer see on a BRL, MXN or COP account?
On BRL and MXN accounts the account is in the customer's own name. A COP account carries the customer's name only when the customer is Colombian, and the banking partner's name for every other customer, so tell payers what to expect. On Lumx, the BRL and MXN accounts are named, and COP follows that rule.
How long does it take to get the accounts?
Two steps add up. Verification targets one business day once all documents are in, and an RFI restarts the clock. Then each account needs provisioning. On Lumx, the BRL, MXN and COP accounts are active right after the customer is approved, and an account.active event says when to show the details.
Is the money in these accounts a bank deposit?
No. The fiat sits in an account at a banking partner until it converts, and then the stablecoin sits in a wallet, so neither layer is a bank deposit. On Lumx, Lumx is not a bank, and the stablecoin is held in a custodial wallet segregated per customer.
What do multi-currency accounts without a local entity cost?
Expect a fee to issue each account, a recurring fee to keep it open, and a fee to verify the company, plus the conversion and payout fees on money that moves. Ask for all of them before comparing providers. On Lumx, virtual accounts have issuance and monthly maintenance fees, differentiated for individual vs business, and KYC (know your customer) and KYB verification is a one-time fee per entity. There is no setup fee, and for rates you contact sales.
