A named virtual account is a routable bank account number issued in a specific customer's name, so a deposit arrives already attributed; a pooled account is one account in the provider's name that receives everyone's money, with a reference code to say who sent what. Both collect local currency that will become a stablecoin. They differ on where the identity of the payer lives: in the rail, or in a field somebody had to type.
That difference reads as administrative and is operational. It decides whether a deposit can convert on arrival or has to wait for a person, whether a refund has an obvious destination, whether a compliance team can prove whose money sat where, and whether the month-end close is a report or a spreadsheet. This post compares the two models on those questions, says where the pooled model is the right answer, and closes with a recommendation. The named virtual account explainer defines the object; this post is about choosing between the two.
Two ways to answer "whose money is this"
Every collection flow has to answer that question for every credit that lands. The pooled model answers it after the fact: the money is in one account, and a reference in the transfer's free-text field, matched against a table, says which customer it belongs to. The named model answers it before the fact: the account number the payer used belongs to one customer, and the credit is that customer's by construction.
The pooled model is older and cheaper to set up, because it needs one bank account and a lookup table. The named model needs a banking partner that can issue account numbers in the customer's name inside the provider's relationship, in each country, and it needs the customer to have been verified before the number exists. Neither of those is trivial, and that is why the pooled model persists.
The comparison on one table
Named virtual accounts and pooled accounts compared on the questions an operations lead asks about collections.
Question | Pooled account with reference codes | Named virtual accounts |
How a credit is attributed | By a code the payer typed | By the account it landed in |
What a mistyped or missing code means | An unallocated deposit and a manual match | No such case; the account is the attribution |
Can a deposit convert to stablecoin on arrival | Only after attribution | Yes, through a standing rule |
Where a refund goes | To whoever the operator decides sent it | To the verified payer of that account |
What a third-party deposit looks like | A credit with the wrong code, or the right one | A payer whose name does not match the account holder, detectable at arrival |
What the customer's own payer sees | The provider's name as beneficiary | The customer's name as beneficiary |
What compliance can prove | That money entered a pool | Which customer's money entered which account |
Month-end reconciliation | A matching job with exceptions | The account is the invoice |
Set-up cost | One bank account and a table | Onboarding per customer and a banking partner per country |
Read the middle rows twice. They are where a low failure rate on a growing volume turns into a growing operations team.
Reconciliation: a matching problem or none
With a pooled account, a credit is an amount, a timestamp and a string. The matching job compares the string to the expected codes and allocates the credit. Most of the time it works. The exceptions are the transfers whose code was truncated by the payer's bank, mistyped, replaced with an invoice number nobody registered, or left blank, and each exception is a person reading a bank statement. The exception rate is low. The exception count is the rate times the volume, and volume is the thing the business is trying to grow.
With named accounts, there is no matching job. The credit landed in customer A's account, so it is customer A's. The reconciliation report at month end lists deposits by account, and the exceptions are the deposits that were refused for a reason, not the ones nobody could place. The B2B collections guide walks through the flow end to end.
Speed: why the account decides when the token appears
A stablecoin on-ramp has four steps: quote, deposit, conversion, credit. The deposit step is where the two models diverge in time. A named-account deposit is identified the moment it lands, so a standing rule can convert it to USDC or USDT without a human between the credit and the decision. A pooled deposit cannot convert until someone or something has decided whose balance to credit, and when the code is wrong, that decision waits for a person.
On Pix (Brazil's instant payment system, run by the Central Bank) and SPEI (Mexico's interbank transfer system, run by Banxico), the bank leg settles in seconds at any hour. An on-ramp that takes hours on those rails is not slow because of the network. It is slow because the deposit is sitting in a pool waiting to be named.
Compliance: what each model lets a provider see
Customer due diligence rules require the provider to know whose money it is handling, and to keep that knowledge in the file. In the United States, 31 CFR 1010.230 requires a covered institution to identify the beneficial owners of a legal entity customer; the European Union sets the same ownership threshold in Regulation (EU) 2024/1624. That file exists before a named account is issued, which is why the account cannot be handed out first and verified later. A named account is the visible end of a KYB (know your business, the verification of a company and its owners) file, and the KYB explainer covers what goes into it.
The pooled model makes that file harder to connect to the money. A credit in a pool is a credit from somebody; the code says who the provider thinks sent it. If a customer's own client pays into the pool on the customer's behalf, the provider may be handling money for a party it never saw, which is the nesting problem that virtual asset rules and partner banks both prohibit. Named accounts make the payer visible per customer, and a payer whose name does not match the account holder is a rule at arrival rather than a discovery weeks later.
Brazil's framework points the same way. Law 14.478 of December 21, 2022 defines virtual asset service providers by the services they perform for third parties, and Central Bank Resolutions 519, 520 and 521 of 2025 set the conduct regime, including the obligation to know the parties to each transaction. An account structure that hides the party is a structure the regime is designed to reject.
I do not accept the argument that a reference code is good enough because the failure rate is low, and I used to make that argument myself. A low failure rate on a growing volume is a growing amount of manual work, and the customers whose money sits unallocated do not experience it as a low rate; they experience it as their money not arriving. The lesson I took from watching a reconciliation move from days of matching to a report with nothing in it is that the cost of the pooled model is paid at the worst time of the month, by the people least able to refuse it, and it never shows up in the pricing comparison that chose it.
Where the pooled model is the right answer
It is not always wrong, and a comparison that says so is selling.
When the payers are few and known. A business collecting from ten counterparties who each pay once a month, with a reference they will not mistype because their own finance team set it up, does not need an account per counterparty.
When the country's banking partners do not issue named accounts. Some markets have no partner that can provision account numbers in a customer's name, and the pooled model with strict reference validation is the only collection option there. The coverage page lists which markets have local named accounts and which are reached otherwise.
When the customer is the only payer. A company funding its own conversions from its own bank account has one payer, and a pooled account with the company's tax ID as the reference is attributable enough.
When the volume is too small to justify onboarding each payer. A named account requires the payer's customer to be onboarded first, and for a handful of transfers a year the onboarding is the whole cost.
When a named virtual account is the wrong tool
When the business wants to collect for people it has not onboarded. A named account is issued after verification, and a platform that wants account numbers for sellers it has not verified is asking for the appearance of attribution without the file behind it. Partner banks and virtual asset regimes both refuse that, and a provider that offers it is offering a pooled account with a label.
When the flow is a one-off. A single large transfer from a known counterparty needs a reference and a phone call, not an account.
When the account is being used as a bank. A named virtual account is a collection endpoint inside the provider's banking relationship, and the protections that apply depend on that relationship and the jurisdiction. A business that needs deposit protection, interest or a cheque book needs a bank.
What both models look 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, 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.
On Lumx there is one model: a named virtual account is issued by a partner bank in the customer's name once that customer is approved, one account per currency, and it supports every rail the partner offers for that currency. BRL and MXN accounts activate as soon as the customer is approved; USD and EUR accounts wait up to a business day for the partner bank's review, and the client learns the moment an account is active through a webhook. A standing autoconversion rule on a BRL, MXN or USD account turns each deposit into USDC or USDT on arrival, on the network the client chose, and the deposit details the client shares embed the reference that matches the deposit to the rule. What Lumx does not offer is a pooled account for third parties: a virtual account may not be used to pool or commingle funds that belong to parties Lumx has not onboarded, so a marketplace onboards each seller as its own customer and takes its platform fee through a partner fee rather than from a shared balance. That is a constraint, and it is the constraint that makes the attribution in the table above hold.
Methodology and sources
The account lifecycle, activation times and autoconversion behaviour are from the Accounts and Autoconversion Rules pages of the Lumx documentation, read on September 24, 2026; the prohibition on pooling for non-onboarded parties is quoted from the Nested Payments page of the same documentation, read on the same date. Beneficial ownership thresholds follow 31 CFR 1010.230 in the United States and Regulation (EU) 2024/1624 in the European Union, cited by number because the govinfo.gov page did not serve a readable body on the day of writing. Brazil's definitions follow Law 14.478/2022 and Central Bank Resolutions 519, 520 and 521 of 2025. Which markets have named accounts changes over time, and the coverage page is the live reference.
Verified on September 25, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Antoine Beauvillain on Unsplash.
Is a named virtual account the same as a for-benefit-of account?
They are close cousins. A for-benefit-of account is a pooled account at a bank with sub-ledgers the provider keeps, and the bank sees one holder. A named virtual account is an account number in the customer's own name that any bank can route to, so the beneficiary the payer sees and the beneficiary the receiving bank reports is the customer.
Can a pooled account convert deposits to stablecoin automatically?
Only after each deposit has been attributed to a customer, which depends on the reference code being correct. A named account is attributed on arrival, so a standing conversion rule can run without a person in the loop.
Why do providers refuse to issue named accounts before onboarding?
Because the account is the visible end of a verification file, and issuing it first would mean collecting money for a party the provider has not identified. Customer due diligence rules in the United States, the European Union and Brazil all require that file to exist before the money moves.
Which model should a marketplace use for seller collections?
Named accounts per seller, with each seller onboarded as a customer and the platform's commission taken as a fee on each transaction. A pooled account that receives buyer funds and distributes them to sellers the provider never saw is the structure partner banks and virtual asset regimes reject.
