Using a named virtual account for B2B collections means giving each paying counterparty a local account number that carries your customer's own name, in the currency the invoice is issued in, so the payer pays a domestic transfer and the money arrives already identified. The account is the collection instrument; what happens to the balance afterwards, whether it stays in local currency or converts to a stablecoin, is a separate decision that the account does not force.
This guide is about the collection side only. The basics of what the account is and how it differs from a payment instruction are in what a named virtual account is, and the Brazil-specific case of receiving dollars is in receiving USD as a Brazilian company. Here the question is operational: how a finance team runs collections through these accounts every day without adding a matching problem to the one they already have.
Why the payer's experience decides whether collections work
A B2B collection succeeds or fails at the payer's accounts-payable desk, not at yours. The person paying an invoice has a vendor record, an approval flow and a bank portal, and every field on your invoice that does not fit one of those three things is a reason for the payment to be late. A foreign account number is the most common misfit. A wire to another country needs an approval that a domestic transfer does not, and in many companies that approval is the treasurer's, who has better things to do with a mid-sized invoice.
A named account removes the misfit by matching the payer's own rails. A Mexican buyer sees an 18-digit CLABE (the 18-digit Mexican bank account number) and pays over SPEI (Mexico's interbank transfer system, run by Banxico), the same way it pays any local supplier. A German buyer sees an IBAN and pays over SEPA. A US buyer sees a routing and account number and pays over ACH or FEDWIRE (the Federal Reserve's same-day wire system). In each case the vendor record holds a domestic account, the approval is the routine one, and the payment lands in the currency of the invoice. Which currencies are covered and over which rails is on the coverage page, and it changes as rails are added, so read it rather than this paragraph for the current list.
The account being in your customer's name matters for the same reason. Accounts-payable teams check that the beneficiary name matches the vendor on the invoice, and some banks reject or hold transfers where it does not. A collection account that displays the provider's name, or a partner bank's name, fails that check on the payer's side and generates a support ticket on yours.
Two ways to run a collection, and when each one fits
There are two operating modes for collecting into a named account, and the choice depends on whether you know the amount in advance.
The first is a collection created per expected payment. You register the invoice amount before the payer pays, the provider returns the payment details for that specific collection (a code for Pix (Brazil's instant payment system, run by the Central Bank), a CLABE with a reference, wire instructions), and the incoming deposit is matched to the invoice by amount and reference. This is the right mode for invoicing, because the match is exact and reconciliation is done the moment the money lands. The price of the exactness is that the deposit has to match: a payer who pays two invoices in one transfer, or short-pays, produces an exception that somebody has to handle.
The second is a standing rule on the account. Every deposit that lands is accepted and processed the same way, with no per-invoice registration. This fits recurring flows where the counterparty pays whatever is due and the amounts vary, such as a marketplace paying out to a seller or a distributor settling a running balance. The match is looser, because the account, not the invoice, identifies the money, so reconciliation moves from the payment layer to your ledger.
Most B2B collection programs run both. Invoiced sales go through per-payment collections; settlement flows from a known counterparty go through a standing rule. What you should not do is run invoicing through a standing rule and reconstruct the invoice match afterwards from bank statements, which is the spreadsheet problem the account was supposed to remove.
What "in the customer's name" means legally and what it does not
The name on the account is the name of your customer, meaning the business that onboarded with the provider and passed KYB (know your business, the verification of a company and its owners). The account is issued by a banking partner in the country of the currency, and that partner holds the funds and executes the rail. The provider orchestrates provisioning and verification; it does not become the bank.
Two consequences follow. The account is not a deposit account with your provider, and it should not be described to your own customers as one; it is a local account at a regulated institution, in their name, that the provider operates on their behalf. And the account can carry its own verification status, separate from the customer's. A customer can be approved while an account in one currency is still being provisioned, or while the partner bank has asked for a document specific to that currency. Treat the account as its own object in your operations, with its own status, and do not assume that an approved customer has every account active.
The regulatory perimeter is the customer's own, not the provider's. A Brazilian company collecting euros into an IBAN in its name is still a Brazilian company with foreign-currency receivables, and the treatment of that balance when it is converted to reais follows Law 14.286 of December 29, 2021, the foreign exchange framework, regardless of what the account is called. The account changes where the money lands; it does not change who owes what to whom.
Matching and reconciliation, which is where collections actually break
Reconciliation is the reason to adopt named accounts and the place where most implementations lose the benefit they paid for.
The matching key differs by rail, and your ledger has to store it. In Brazil a collection over Pix carries an identifier inside the payment code, so a payer who scans or pastes the code cannot lose the reference. In Mexico the CLABE is paired with a reference that the payer types into the memo field of the SPEI transfer, and payers do drop it. For dollar and euro collections the account itself identifies the customer, so with a standing rule there is no per-payment reference at all and the invoice match has to come from the amount, the date and the payer's name.
The practical rule is to reconcile at the event, not at the statement. A provider that emits a status event when a deposit lands, when it is matched, and when it is credited gives your ledger a record per payment with the rail's own reference attached. Reconciling from a monthly bank statement instead recreates the manual process with extra steps. Ask for the event feed before you ask for the account.
Three exceptions will happen every month and the design should name their handling in advance. A deposit that arrives after the collection window has expired is not processed; the provider refunds the sender on the same rail, and the customer has to be told to create a new collection rather than assume the money is sitting somewhere. A deposit below the minimum for a standing rule is not converted and needs a manual path. And a deposit from an account whose holder name does not match the expected payer, which is common when a buyer pays through a group treasury entity, can be held for a compliance question. In every one of these cases the money is safe and the problem is communication: who tells the payer what happened, and how fast.
Compliance holds and the RFI you should expect
An RFI (request for information, a compliance hold that asks for a document before a transaction clears) is not a failure mode of named accounts. It is a regular part of B2B collections above small amounts, because the receiving institution has to know what the money is for, and a business invoice is a document that can answer that.
The best preparation is to make the purpose of the funds explicit at collection time. A collection carries a purpose category, such as trade or professional services, that the banking partner uses for screening and reporting, and a mismatch between the stated purpose and what the documents show is the single most common reason a hold turns into a longer conversation. Getting the purpose right on the first collection for a new payer, with the invoice attached to the customer's record, tends to make the next ones quiet.
Limits are the other predictable source of friction. A business customer on standard verification operates under caps per transaction, per day and per month, and enhanced verification raises them against financial documents. A collection program should know the customer's remaining limit before it issues an invoice that would breach it, because the deposit will arrive regardless of the limit and will then need handling. A provider that exposes used and remaining limits per customer through the API makes that a query; one that does not makes it a surprise.
What happens to the balance after it lands
The account collects in local currency; what happens next is a policy choice with three options, and it is worth deciding it per customer rather than per payment.
The balance can stay in the local currency, which is the right answer when the customer spends in that currency and has no reason to convert. It can convert to a stablecoin on every deposit, under a standing rule, which is the right answer for a customer that collects in several currencies and wants one treasury asset; on Lumx a standing rule is available for BRL, MXN and USD deposits, and the USD to USDC corridor page describes what that conversion looks like per rail. Or it can convert on demand, when the finance team decides, which trades the operational simplicity of the rule for control over timing and is the path for euro balances, described on the EUR to USDC page.
The choice interacts with reconciliation. A rule that converts every deposit produces a stablecoin credit per payment, with the rate and the fee in the receipt, so the accounting entry has everything it needs. A balance that sits in local currency and is converted in bulk later produces one conversion for many collections, and the cost of moving money that month is then spread across invoices by whatever allocation the ledger applies. Neither is wrong; the second needs a rule written down before the first month-end close.
When a named virtual account is the wrong tool for collections
A named account solves the problem of being paid by companies in another country as if you were local. It does not solve, and should not be used for, three other problems.
Consumer collections at scale are the first. If your customer sells to thousands of individuals who pay small amounts, the per-payment collection model creates thousands of expected deposits, and the standing-rule model creates a matching problem at the ledger level. A checkout or a payment link with a payment processor is the better instrument; the named account fits after the money has been collected, for the treasury leg.
The second is a single-country business that collects only in its home currency. A Brazilian company invoicing Brazilian customers in reais already has a bank account for that, and adding a named account through a provider adds a counterparty without adding a rail. The account earns its place when the invoice is in a currency the customer cannot otherwise receive domestically.
The third is a customer whose payers cannot pay a domestic transfer at all, because they are individuals abroad without local bank access, or because the flow is card-based. Card acceptance and named accounts are different products, and forcing one to do the other's job produces a worse version of both.
What a collection program 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, 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 the account is requested at customer creation: the integrator lists the currencies each customer should have, and each one enters provisioning once the customer is approved. Brazilian and Mexican accounts activate immediately after approval; dollar and euro accounts wait for the partner bank's review, which targets one business day per the accounts documentation. Each account carries its own status and emits its own events, and the one to build against is the event that says the account is active, because that is the moment the payment details can go onto an invoice. The named virtual accounts page lists the account formats per currency.
Both collection modes exist. A per-invoice collection is an on-ramp created with the expected amount, which returns rail-specific details and expires if the deposit does not arrive in time; a late deposit is refunded to the sender on the same rail. A standing rule is an autoconversion rule on the account, available today for BRL, MXN and USD accounts, with a minimum of 50 dollars per deposit and a receipt per conversion that carries the rate and the fee. A customer can hold one active dollar rule at a time, because dollar deposits are matched to the account rather than to a per-rule reference. The purpose of the funds is a required field on every collection, and the limits a customer operates under are readable through the API with the used and remaining amounts, so the invoice can be checked against them before it goes out.
I am asked, more than about any other feature, whether the account can show the platform's name instead of the end customer's, usually by a marketplace that wants its brand on the invoice. The answer is no, and it is a position rather than a limitation we are working around. The account is in the name of the business that was verified, because that is what makes the payer's bank accept the transfer and what keeps the funds attributable to the customer they belong to if anything is ever questioned. A platform that wants its brand on the collection should put it on the invoice, where it belongs, and leave the account in the name of the company that is actually being paid.
Verified on September 25, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Frantisek Duris on Unsplash.
Can one customer have named accounts in several currencies?
Yes. A business customer can hold one account per currency it needs, each issued by the banking partner for that currency and each with its own verification status. The currencies are requested when the customer is created, and additional ones can be added later.
How does a payment get matched to an invoice?
For a per-invoice collection, the deposit is matched by amount and by the reference embedded in the payment details, such as the identifier inside a Pix code or the memo on a SPEI transfer. For a standing rule, the account itself identifies the customer and every deposit is processed, so the invoice match happens in your ledger from the amount, the date and the payer.
What happens if a payer sends the money late or in the wrong amount?
A deposit that arrives after the collection has expired is not processed and is refunded to the sender over the same rail it came in on. A deposit that does not match the expected amount becomes an exception for your team to resolve with the payer. In both cases the funds are not lost, and the design question is how quickly the payer is told.
Does collecting into a named account convert the money to a stablecoin?
Only if you configure it to. The account collects in local currency, and the balance can stay there, convert on every deposit under a standing rule, or convert on demand when your finance team decides. The choice is made per customer and affects how the conversion cost shows up in reconciliation.
