A named virtual account is a real, routable bank account number issued in the name of a specific customer, provisioned by a payments provider on top of its own banking relationship rather than by the customer opening an account at a bank. Money sent to it settles like any ordinary transfer, and the provider knows immediately whose money it is, because the account itself carries the identity.
The alternative is the pooled account: one account in the provider's name that receives everybody's money, with a reference code to say who sent what. That difference sounds administrative and is not. It decides how collections reconcile, how fast a deposit converts, and what a compliance team can prove afterwards. This post covers what the account actually is, what changes when identity moves into the rail, what a named account does not solve, and how it shows up in a stablecoin flow. The on-ramp explainer covers the conversion step that usually follows.
What "named" means, and what "virtual" means
Named means the account resolves to the customer, not to the provider. When a payer looks it up before sending, the name they see is the customer's. When the receiving institution reports the credit, the beneficiary is the customer.
Virtual means no bank opened an account for that customer. The provider holds an account at a bank, and the account numbers it issues are addresses inside that relationship, each mapped to one customer in the provider's ledger. The money is real, the routing is real, and the customer never signed a bank contract.
Both halves matter. An account number that is routable but registered to the provider is a pooled account wearing a label. An account that is nominally named but cannot receive a transfer from an arbitrary third-party bank is a reference code.
How the account number looks, country by country
In Brazil the identifier is a Pix (Brazil's instant payment system, run by the Central Bank) key tied to a CNPJ (the Brazilian company taxpayer ID) or a CPF (the Brazilian individual taxpayer ID), or an account and branch pair for TED. The identity layer here is unusually strong, because the Central Bank operates the directory that maps a key to its holder. As of August 31, 2026, that directory held 186.3 million registered users, of which 18.6 million were companies, according to the Bank's open data service. A payer can confirm who they are about to pay before the money leaves, which is the same check that protects a stablecoin payout on the way out.
In Mexico it is a CLABE (the 18-digit Mexican bank account number), which routes over SPEI (Mexico's interbank transfer system, run by Banxico) and is tied to a named holder at a named institution.
In the United States it is a routing and account number pair reachable by ACH and wire. In the Eurozone and the United Kingdom it is an IBAN or a sort code and account number.
The mechanics differ by country. The property that matters is the same everywhere: an inbound transfer arrives already attributed.
What changes when identity moves into the rail
Reconciliation stops being a matching problem. With a pooled account, a credit is an amount, a timestamp and whatever the payer typed in a free-text field. Somebody or something has to guess which invoice it pays. With named accounts, the account is the invoice.
Conversion can be automatic. A deposit that is identified on arrival can hit an auto-conversion rule and become USDC or USDT in seconds, because there is no human step between the credit and the decision. An unattributed deposit cannot be converted at all, since the provider does not yet know whose balance to credit.
Refunds have somewhere to go. Returning money to the account that sent it is straightforward when the sending account was verified. It is guesswork when the deposit landed in a pooled account under a code.
Payer mismatches become a rule instead of a discovery. A provider can compare the payer of an inbound transfer against the customer that was onboarded, and reject a deposit from an unrelated third party at arrival, rather than clawing it back a week later.
Named accounts and the compliance file
Identity in the rail is not the same as identity in the file, and regulators care about the second one. In the United States, 31 CFR 1010.230 requires a covered institution to identify the beneficial owners of a legal entity customer: each individual holding 25 percent or more of the equity, plus one individual with significant responsibility to control or manage the company. The European Union sets the same ownership threshold in Regulation (EU) 2024/1624, which applies from July 10, 2027, where 25 percent or more of shares or voting rights generally establishes beneficial ownership.
This is why a named virtual account is issued after onboarding, never before. The account number is the visible end of a KYB (know your business, the verification of a company and its owners) file that already exists, and the KYB explainer covers what goes into it. A provider that hands out named accounts without that file is issuing the appearance of compliance.
I lost an argument about this once, and losing it is most of the reason I write about it now. We were collecting for a marketplace client with a reference code per seller, and the codes worked, mostly. Every month a handful of transfers arrived with a truncated code, a typo or nothing at all, and somebody reconciled them by hand against a spreadsheet, on the last two days of the month, every month. My position was that the failure rate was low enough to live with. The argument against me was that a low failure rate on a growing volume is a growing amount of manual work, and that the sellers whose money sat unallocated did not experience it as a low rate. We moved that client to named accounts per seller, and the monthly reconciliation went from two days to a report nobody reads because nothing is in it.
What a named virtual account does not do
It does not make the provider a bank. The account exists inside the provider's banking relationship, and the protections that apply depend on that relationship and on the jurisdiction, not on the label. This is worth reading carefully in any provider's terms.
It does not remove onboarding. Issuing an account to a customer requires verifying that customer first.
It does not create local presence. A company collecting through named accounts in Mexico is not established in Mexico, and tax and contractual questions follow the real structure. The coverage page lists which countries have local accounts and which are reached by SWIFT.
It does not promise same-day conversion. Identity removes one delay. Compliance review and rail timing are still there.
What named virtual accounts 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.
A client provisions a named virtual account for itself or for each of its end customers once that customer clears onboarding. Deposits arrive attributed, an optional rule converts them to USDC or USDT on arrival, and the client receives an event carrying the payer, the amount and the resulting balance. Where the payer does not match the onboarded customer, the deposit is refused at arrival with a reason the client can pass on, rather than reversed later.
Verified on September 25, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Guilherme Braga on Unsplash.
Is a named virtual account a real bank account?
The account number is real and routable, so any bank can send money to it. It is issued by the provider inside its own banking relationship rather than opened by the customer at a bank, so the customer has no direct contract with that bank. What protections apply depends on the provider's structure and jurisdiction.
How is it different from a pooled account with reference codes?
A pooled account puts every customer's money in one account and relies on a code to attribute each credit. A named account attributes the credit through the account it landed in. The first fails whenever a payer mistypes or omits the code, and the second does not have that failure mode.
Can a named virtual account receive money from anyone?
Technically yes, since it is routable. Operationally the provider will normally only accept money from a payer matching the onboarded customer, and return transfers from unrelated third parties. That rule comes from customer due diligence obligations, not from the account technology.
What is needed to get one?
Onboarding of the business or the end customer first, including beneficial ownership information where the rules require it. The account is issued after that file is complete, which is why providers cannot offer an account number before verification.
