What is a virtual IBAN?

A virtual IBAN (vIBAN) is a real, addressable International Bank Account Number issued from a dedicated range and routed into a single master account. It accepts payments like any other IBAN — a payer sends an ordinary SEPA credit transfer to it from their own bank — but it holds no balance of its own. Its job is identification: because each virtual IBAN is assigned to exactly one payer or purpose, a payment arriving on it already says who sent it and what it is for. The money concentrates in the master account automatically; the virtual IBAN is the label on the payment, not a second place the money lives.

That one property — one IBAN per payer — is the whole idea. To see why it is worth an article, start with the problem it removes.

The real problem: matching money to payers

Picture a business collecting by bank transfer into one account: rent, subscriptions, invoices. Every credit lands on the same IBAN, and the only clue to who paid is whatever the payer typed into the reference field. References get mistyped, truncated somewhere along the chain, or left blank entirely. A €49.00 transfer with a garbled reference is not €49.00 of recognized revenue yet — it is a ticket. Someone has to work out which customer and which invoice it belongs to before the books close.

At low volume this is an annoyance. At platform volume it is a department. Matching engines score candidate invoices on amount, date, and fuzzy reference text; whatever they cannot place goes to a human queue. And the failure mode is structural: when two subscribers pay the same amount on the same day with no reference, no engine can separate them — the information that would tell them apart was never in the payment to begin with.

One IBAN per payer: identity by construction

A virtual IBAN program flips the design. Instead of asking every payer to label their payment correctly, you give every payer their own address. Each tenant, subscriber, or marketplace seller pays into an IBAN that is theirs alone. The reference field can be wrong, empty, or in another alphabet — the credit still identifies itself, because identity is carried by the account number instead.

The account number is a much better carrier than the reference. An IBAN includes its own check digits, so a mistyped IBAN fails validation at the payer's bank before the transfer is ever sent. A mistyped reference sails through and becomes your problem. Moving identity out of the free-text field and into the address moves the error check from your back office to the sending bank.

For the payer, nothing changes: they pay an IBAN from their banking app, same as ever. All the novelty is on the receiving side — the payment arrives pre-labeled, and the reference field goes back to being what it should have been all along: a note, not an identification system.

When every payer pays into their own IBAN, an incoming payment can only mean one thing. The matching problem does not get solved — it stops existing.

— Protocore · Payments engineering

Where the money actually lives

Underneath, there is exactly one master account per currency. The virtual IBANs are issued from ranges dedicated to the program, and every credit sent to any of them settles into the master. There are no per-payer balances to manage and no end-of-day sweep jobs shuttling funds from thousands of small accounts into one — concentration happens by routing, not by extra transfers you would then have to reconcile in their own right.

This is also what makes a virtual IBAN real rather than a trick. It is addressable from any bank, it clears like any SEPA credit, and it shows up on the payer's own statement as the account they paid. What it lacks is exactly what a full account drags along: a balance of its own, and a lifecycle beyond assignment and retirement.

What a virtual IBAN is not

It is not a sub-account: a sub-account holds a balance, needs funding and defunding, and multiplies the ledgers you operate. It is not a virtual reference number: those still ride the reference field and still depend on payers copying strings correctly. And it is not a wallet: nothing is stored against the vIBAN itself. It is an address with routing behind it — the narrowest construct that makes an incoming payment self-identifying.

Returns come back with a reason attached

Payments do not only arrive. Accounts close, banks reject credits, payers recall transfers. In a single-collection-account world, a return is a small investigation: which payment came back, whose was it, and does the ledger entry it was matched to need unwinding?

In a vIBAN program, a return is data. It carries its reason code, lands as a payment.returned event against the same virtual IBAN the original credit used, and gets its own count on the statement. You know whose payment came back, and why, before anyone opens a ticket. Returns become rows to handle, not mysteries to chase.

An exception queue, not a matching team

No design reconciles one hundred percent of anything. Credits arrive on retired vIBANs. Duplicates happen. Someone, somehow, pays the master account directly. The goal is not to make exceptions impossible — it is to make them rare and countable. In the Protocore vIBAN demo, 99.6% of credits reconcile automatically; the remainder queues for review with the payer's full history attached, so working an exception starts from context, not from a bank statement and a spreadsheet.

That difference reshapes the team. A matching operation scales with payment volume: more credits, more unmatched credits, more people. An exception process scales with exception volume, which the design has already pushed toward zero. The people you keep work genuine anomalies, not retyped references. In our stack that queue lives in Protocore Center (/products/center), the operations console where every privileged action requires a reason and lands in an audit log.

Bulk issuing, purpose tags, platforms

One IBAN per payer only works if issuing one costs nothing. A landlord with a dozen tenants could mint vIBANs by hand; a marketplace onboarding thousands of sellers cannot. So issuing is a bulk operation. In the vIBAN demo, a CSV of 2,400 payers validates, previews an IBAN on every row, and issues in a single action — 2,400 payers, one operation, a review step in between.

Purpose tags keep flows apart at the address level: rent here, subscriptions there, marketplace payouts in their own lane. Reporting by purpose becomes a filter instead of a project, and each vIBAN gets its own statement — CSV or PDF — while the master account stays the single line of truth underneath. When a payer leaves, their vIBAN is retired: the history stays, the address stops accepting new credits.

Where this sits in a payment stack

Virtual IBANs are collection infrastructure. They give inbound bank transfers what card payments have always had — identity attached to the payment itself, not typed in alongside it. In the Protocore ecosystem, Gateway's pay-by-transfer orders carry vIBAN references, and Center works whatever exceptions the matching leaves behind. The product page at /products/viban walks the full loop — issue, share, match, except, report — on the same demo data used here.

And an honest boundary: if you take a handful of transfers a month, a reference convention and ten minutes of bookkeeping are fine. Virtual IBANs earn their keep where volume has turned matching into a process — rent rolls, subscription collections, marketplaces — anywhere the question of who paid you is asked thousands of times a month.