What is a virtual IBAN?
Give every customer their own account number without opening a single account. That is the trick, and it has consequences.
The sender sees an ordinary account number. The money lands in one place, labelled.
The problem it solves
Incoming bank transfers are notoriously hard to attribute. A payer types a reference wrongly, or omits it, or their bank truncates it, and a payment arrives in your account as an amount from a name that does not match any customer record. Someone then works out who it was from. At scale that someone is a team.
Give each customer their own account number and the problem disappears at the source. Money arriving on that number is from that customer, definitionally, with no reference to parse and nothing to mistype. Attribution happens on arrival rather than in a reconciliation process afterwards.
This is why virtual IBANs are standard in marketplaces, in business banking, in collections, and anywhere a business receives money from many payers and must credit it accurately and fast.
How it actually works
There is one real account, held by a bank or a licensed institution. Virtual identifiers are issued from a range associated with it, and the provider maintains a mapping from each identifier to a customer.
Incoming payments to any of those identifiers are routed to the real account, and the provider's own ledger records which virtual identifier received what. Each customer's balance is a ledger position rather than a bank account, which is precisely why the double-entry discipline in the article on ledgers is not optional here.
The part that gets glossed over
A virtual IBAN is not an account, and the distinction matters legally.
The customer does not have a banking relationship with the bank. They have a relationship with the provider, and the provider has one with the bank. If the provider fails, what protects the customer is how the underlying funds are held and safeguarded, not the existence of a number that looked like an account.
Two more issues that regularly cause real trouble.
Country mismatch. A virtual IBAN often carries a country code reflecting where the underlying account sits, not where the customer is. That produces refusals from payers whose systems flag a mismatch, complications in some direct debit schemes, and awkward questions from tax authorities and counterparties who read the country code as a statement about the customer.
Regulatory attention. Supervisors across the EU and UK have raised concerns that virtual IBANs obscure who is actually behind a payment, complicating sanctions screening and transaction monitoring, particularly where the identifier is issued across borders. Expect the requirements to keep tightening, and expect providers to ask more about your customers than they used to.
A hotel switchboard. Every room has its own extension and callers dial it directly, but there is one line into the building. The extension tells you which room the call is for. It does not mean the room has its own connection to the telephone network, and if the hotel closes, the extension is not a phone line you own.
Where you meet it
Every marketplace that gave you a unique account number to pay into. Every business account with a country code that does not match the business. Every reconciliation team that shrank after a migration nobody outside finance noticed.
Building this? A second pair of eyes on the architecture is what the advisory is for. →