A bank account is opened by a bank for one holder and carries its own balance. A virtual account is a set of receiving details that routes deposits into a master account and records who each belongs to. A virtual IBAN is the same idea in IBAN format. They differ on who holds the money and which rails reach them.
Providers use "virtual account" for a ledger line, a routable account in a customer's name, or a collection reference that is not an account at all. The definition of the account type Lumx issues is in what a named virtual account is.
What is the difference between a virtual account, a virtual IBAN and a bank account?
The difference is who holds the funds and what the account number points at. A bank account points at a balance on the bank's books. A virtual account and a virtual IBAN point at a master account, and a ledger keeps the split.
Bank account, virtual account and virtual IBAN compared on nine properties.
Property | Bank account | Virtual account | Virtual IBAN |
Holds its own balance at the bank | Yes | No, routes into a master account | No, routes into a master account |
Who the payer sees as beneficiary | The account holder | The provider (pooled) or the end customer (named) | The provider (pooled) or the end customer (named) |
How it is issued | Bank application, one holder at a time | API call to a provider | API call to a bank or payment institution |
Identifier | Account number plus routing number, sort code or IBAN | Account number plus routing number, CLABE or a local reference | IBAN: country code, check digits and a bank-and-account identifier |
Typical rails | Everything the bank offers | ACH and wire in the US, local rails elsewhere | SEPA, domestic IBAN rails, SWIFT |
Setup time, typically | Days to weeks | Minutes to a business day | Minutes to a business day |
Reconciliation | By reference or amount | By the account the credit landed in | By the IBAN the credit landed in |
Payroll out, tax payments, credit | Yes | Receive and send depend on the provider | Receive and send depend on the provider |
Attributes each payer without a reference | By reference only | Yes | Yes |
A virtual account and a virtual IBAN are one concept in two address formats, so choosing between them depends on where your payers are. The choice that changes the risk is between named and pooled, covered in named virtual accounts vs pooled accounts.
On Lumx the account type is the named virtual account: issued by a banking partner in the customer's name, one account per currency, after the customer is approved. The MXN, EUR and GBP accounts are named too and collect from payers abroad. The customer must request each currency's account before it can collect or pay out in it. Per the Accounts page of the Lumx documentation, read on November 1, 2026, activation after approval is immediate for BRL, MXN, EUR and GBP and takes up to one business day for USD, where the partner bank reviews first.
What each one can receive
An account only receives what its rails can reach, and the identifier format decides who can pay it without friction. This is where a virtual IBAN and a US-style virtual account stop being interchangeable.
An IBAN (International Bank Account Number, ISO 13616) is the address format of SEPA and most of Europe, and a euro payer expects to type one. Regulation (EU) No 260/2012 of March 14, 2012 (Article 9) forbids a payee from specifying the member state of the payee's account, so a business collecting on an IBAN issued in another country should still be payable from inside the euro area. Some payers' systems reject foreign IBANs anyway.
A US account is a routing number plus an account number. It receives ACH (1 to 2 business days) and FEDWIRE (the Federal Reserve's same-day wire system). Pix (Brazil's instant payment system) pays to a key or a QR code that embeds a reference, and SPEI (Mexico's interbank transfer system) pays to a CLABE (the 18-digit Mexican bank account number).
Lumx follows the currency. Per the Autoconversion Rules guide, read on November 1, 2026, the deposit details a client shares are a Pix QR code for BRL, a CLABE plus a memo reference for MXN, account and routing numbers or a BIC for USD, an IBAN and BIC for EUR over SEPA, and a sort code and account number for GBP over Faster Payments (the UK's real-time bank transfer network). A USD account takes ACH, FEDWIRE and SWIFT on the same account. Pix, SPEI and Faster Payments settle instantly; SWIFT takes 1 to 5 business days. The coverage page lists rails by country.
Who holds the funds in each structure
In a bank account the bank holds the funds, in the holder's name, as a deposit. In a virtual account or virtual IBAN the master account holder holds them at a bank, and that holder is the provider unless the account is titled to your customer.
Where the money sits and what to ask, by structure.
Structure | Where the money sits | Whose name is on it | What to ask |
Bank account | At the bank, own balance | The account holder | Deposit protection limits in that jurisdiction |
Pooled virtual account or IBAN | One master (omnibus or for-benefit-of) account at a bank or payment institution | The provider | How the ledger proves each customer's share, and what happens if the provider fails |
Named virtual account or IBAN | At a bank, under the provider's banking relationship | Your customer | Who the bank partner is, and whether payouts go out under your customer's name |
Payment institutions in the European Union must safeguard the funds they receive from payment service users, in a segregated account or by insurance, under Article 10 of Directive (EU) 2015/2366 (PSD2) of November 25, 2015. That protects the money against the provider's other creditors, but it is not a bank deposit protection scheme.
The Accounts page says a virtual account is issued by a Lumx banking partner in the customer's name, and that Lumx orchestrates provisioning and verification with partners that hold the funds and execute the rails. With an autoconversion rule, each matched deposit is converted to USDC or USDT on arrival, so the fiat leg lasts from the credit to the conversion.
Why the name on the account matters
It matters for what the payer sees before sending and for what compliance can prove afterwards. A named account shows your customer as beneficiary; a pooled account shows the provider.
The payer-side reason is verification of payee, which compares the name with the data the beneficiary's bank holds. Regulation (EU) 2024/886 of March 13, 2024, which amended the SEPA rules, requires euro-area payment service providers to check that the beneficiary name matches the IBAN before a euro credit transfer goes out, and to warn the payer on a mismatch; the obligation applies in the euro area from October 9, 2025. A payer who types your customer's name against a pooled IBAN held in the provider's name can see a mismatch warning, and a warned payer often stops. A named IBAN should pass when the issuing bank holds your customer's name against it, but the regulation does not require that, so test with a real payer.
The compliance-side reason is attribution. A named account's title answers whose money it is; with a pooled one, the provider's ledger has to prove it deposit by deposit.
Lumx accounts are named in every currency except COP, where the payer sees the banking partner's name. A foreign company can hold a named BRL or MXN account without a local entity in Brazil or Mexico, and a BRL payout by Pix shows the receiver the client's name as payer, not Lumx. The Nested Payments page, read on November 1, 2026, sets the limit for platforms: a virtual account serves the customer's own commercial activity and may not pool several third parties' funds, so a platform onboards each end customer as its own customer and collects its fee as a partner fee.
What each one costs
Costs vary by provider and are rarely published. A bank account usually has a monthly fee; virtual accounts and virtual IBANs add per-account, per-deposit or conversion fees on top.
Lumx prices as a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans. By item, and paid by the platform, not the end customer: Identity verification is a fee per verification, charged once when the customer is onboarded. Opening a virtual account is a fee per account, charged once for each currency opened. Maintenance is a monthly fee per active account. Lumx does not charge for transaction monitoring.
What breaks with each option
Failure modes by structure, with the prevention for each.
Failure | Where it shows up | Hits | Prevention |
Payer's bank rejects a foreign IBAN | The payment bounces or never starts | Virtual IBAN | Test two or three payers; use an IBAN from the payer's country if that is the fix |
Name check mismatch warning | The payer pauses or abandons | Pooled account or IBAN | Use a named account and tell the payer the beneficiary name |
Reference code mistyped or truncated | An unallocated credit someone matches by hand | Pooled | One account per customer, so the account is the reference |
Account issued before verification | Funds arrive for a party nobody checked | Any structure issued first | Issue after verification, see what KYB covers |
On Lumx an account passes through states before it can move money: AWAITING_ONBOARDING, REQUESTED, PROVISIONING, then ACTIVE. It can pause in RFI (request for information, a hold that asks for a document), and the account.active webhook tells the client when it can receive. The Lumx target for the customer's KYB (know your business, the verification of a company and its owners) review is one business day, and the supported countries list shows where customers can be onboarded. Matching depends on currency: USD, EUR and GBP match by account, with one active autoconversion rule each, while BRL and MXN match by depositIdentifier or reference, embedded in the Pix code or passed as the SPEI memo.
Which structure fits which job
Choose by who pays you, in which country, over which rail, and whose name the payer must see.
Seven situations and the structure that fits each.
Situation | Fits best | Why |
Operating cash, payroll out, tax payments, credit | Bank account | Only a bank account carries the services a company runs on |
Collect from many US business payers on ACH or wire | Named virtual account in USD | Each credit is attributed by the account number |
Collect euros from payers in the euro area | Virtual IBAN, named where payers verify payee names | Payers expect an IBAN and the name check should pass |
Collect pounds from UK payers | Account with a sort code and account number | UK payers pay over Faster Payments, not by IBAN |
Collect reais from Brazilian payers | Pix-based account | A Brazilian payer pays by Pix, not by IBAN |
Collect pesos from Mexican payers | Account with a CLABE | Mexican payers pay over SPEI to a CLABE |
Few payers who pay rarely | Reference code on one account | Attribution by reference is enough at that volume |
I would start from the payers and not from the product name. List the top twenty payers with each one's country and rail, and the structure falls out of the list. I recommend putting the same three questions to every provider in writing before comparing features: where the money sits, in whose name, and what the payer sees as beneficiary. My position is that a provider who answers "it depends" to the second question is selling a pooled account with a nicer label, and I would not accept that for funds from customers I had not onboarded myself.
A company that collects from Brazil and settles in dollars can follow receiving USD as a Brazilian company; the BRL to USDC conversion page shows the pair. Once the structure is settled, see choosing a virtual account provider and the B2B collections guide.
The recommendation: for collections from many payers, use named accounts and match the rail to each payer's country. Keep a bank account for operating cash. Choose a virtual IBAN over a US-style account only when the payers are in the euro area. When all payers are in one country on one rail and you also need operating banking, a local bank account does both with fewer parts.
When a virtual account is the wrong tool
When the company needs a bank. A virtual account or virtual IBAN is a collection and settlement endpoint, not a place to run payroll, pay taxes, earn interest or draw credit. The stablecoin API vs banking API comparison covers where an API-issued account stops, and where neobanks hold customer funds explains the structure behind the apps.
When the account would collect for people you have not onboarded. A named account is the visible end of a verification file, and partner banks refuse one issued for a party that was never verified.
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.
The named virtual accounts product page lists the currencies. A standing autoconversion rule turns each matched deposit into USDC or USDT, so the client reconciles stablecoin transactions and not a fiat balance.
Methodology and sources
Lumx account behavior is from the Accounts, Autoconversion Rules, Payment rail cut-off times, Coverage and Nested Payments pages of the Lumx documentation, read on November 1, 2026. The SEPA scheme is described on the ECB SEPA page. EU rules are cited by number and date, with links to EUR-Lex: Regulation (EU) No 260/2012 of March 14, 2012, Article 9; Regulation (EU) 2024/886 of March 13, 2024; Directive (EU) 2015/2366 of November 25, 2015, Article 10. EUR-Lex blocked automated reading on the day of writing, so the citations follow the official numbers and dates. The IBAN format follows ISO 13616.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
What is the difference between a virtual account and a virtual IBAN?
A virtual IBAN is a virtual account in IBAN format. Both route deposits into a master account. The IBAN version receives SEPA and other IBAN-based transfers; a US-style one receives ACH, wire and sometimes SWIFT. On Lumx the EUR account's deposit details are an IBAN and BIC over SEPA, and the USD account's are account and routing numbers, each tied to one currency and issued in the customer's name.
Is a virtual IBAN a real bank account?
No. A virtual IBAN does not hold its own balance at the bank. It routes into a master account, and a ledger records the split, so safety depends on who holds that account. Lumx does not call its account a bank account: the funds sit with the banking partner that issues it and executes the rails.
Can a virtual account replace a business bank account?
Usually not. A virtual account collects and settles payments, while a bank account also runs payroll, taxes and credit. Per the Lumx Accounts page, a Lumx account is issued by a banking partner in the customer's name, holds one currency, and the partner holds the funds.
Does the name on a virtual account matter to the payer?
Yes. In the euro area, banks check that the beneficiary name matches the IBAN and warn the payer on a mismatch, under Regulation (EU) 2024/886. A named account shows your customer as beneficiary; a pooled one shows the provider and can trigger the warning. Lumx issues the EUR account in the customer's name, with an IBAN and BIC over SEPA.
Who holds the money in a virtual account?
The master account holder, at a bank or payment institution, with a ledger tracking each customer's share. That holder is the provider in a pooled structure and a bank partner in a named one. On Lumx, banking partners hold the funds and execute the rails, and Lumx orchestrates provisioning and verification.
