Virtual IBANs (vIBAN) Explained: How Platforms Use Them
Venly Finance | Updated September 28, 2026
A virtual IBAN (vIBAN) is a bank account number that routes to a shared master account, letting platforms assign a unique IBAN per end-user, merchant, or invoice, without opening a real bank account for each one. Marketplaces and PSPs use vIBANs to attribute inbound SEPA/SWIFT payments automatically.
A virtual IBAN is a unique IBAN string mapped to a sub-ledger within a licensed institution's master account. It looks and behaves like a real IBAN for incoming payments (sender banks route to it normally), but the underlying deposit sits on the issuing institution's balance sheet, with the platform's ledger tracking per-user balances.
What a vIBAN actually is (vs a real IBAN)
A real IBAN is a bank account. Every real IBAN is opened for a named account holder who has passed KYC at the account-issuing bank, holds a direct claim on that bank, and is protected by the local deposit guarantee scheme.
A virtual IBAN is a routing key. The account of record is the licensed institution's master (or "collection") account. The vIBAN string tells the receiving bank's systems: "credit the master account, and attribute this deposit to sub-ledger X." The platform's systems (or the vIBAN provider's) then post the credit to the correct end-user or merchant balance.
For inbound SEPA and (usually) SWIFT payments, the sender cannot tell the difference. For legal, deposit-protection, and safeguarding purposes, the difference matters a great deal.
Why marketplaces and PSPs need them
Reconciling inbound bank transfers to the right seller, merchant, or invoice is the largest operational cost in a fiat platform. Without vIBANs, platforms rely on the sender putting a correct reference in the payment message, which fails often enough to require a manual ops team.
With vIBANs, each seller/merchant/invoice gets its own IBAN string. The sender pays "to that IBAN," and attribution is deterministic on receipt. Reconciliation errors drop to near-zero.
Issuer models
- Bank-issued vIBANs: a licensed credit institution issues vIBANs against its own master account. Strongest safeguarding position; typically the most restrictive on KYC and use-case approval.
- EMI-issued vIBANs: an Electronic Money Institution issues vIBANs against a safeguarded master account at a bank. Funds are safeguarded under the EMI regime, not covered by the deposit guarantee scheme.
- BaaS-issued vIBANs: a Banking-as-a-Service provider fronts a bank or EMI licence to the platform. Fastest to integrate; the platform must diligence the actual regulated entity behind the BaaS provider.
Who owns KYC on the end-user
Under EU rules (and the EBA's June 2024 opinion on vIBANs), the platform assigning a vIBAN to an end-user typically retains KYC responsibility on that user; the issuing institution retains oversight and can pull back accounts that fail its risk framework. This is a source of ongoing regulatory attention: expect vIBAN issuers to tighten their end-user KYC evidencing requirements over the next 24 months.
Reconciliation and safeguarding
For PSPs and marketplaces, the reconciliation win is the primary reason to use vIBANs. The safeguarding question ("is my end-user's money protected if the issuing institution fails?") depends on the issuer model. Bank-issued vIBANs are covered by the deposit guarantee scheme up to the local cap (€100k in most EU member states). EMI-issued vIBANs are safeguarded, not guaranteed. The platform should surface this to end-users if their balance exceeds material thresholds.
How vIBANs pair with stablecoin payouts
A common architecture: use vIBANs on the inbound side (collect from customers in local fiat with clean reconciliation), and use a stablecoin leg on the outbound side (settle cross-border to recipients over stablecoin rails, with timing that depends on the rail and the checks each payment needs). The same platform ledger tracks both.
How it works
- Platform requests EUR receiving details (a vIBAN) for a new customer via the Finance API.
- Issuer generates a valid IBAN string mapped to the master collection account with attribution metadata.
- Sender bank sees a normal IBAN and routes payment.
- Issuer credits the master account and posts an attributed webhook to the platform.
- Platform ledger updates the correct sub-balance; funds can then be paid out, converted, or held.
Sources (last verified 2026-07-02)
- European Banking Authority, "Opinion on virtual IBANs," June 2024.
- European Central Bank, SEPA Instant Credit Transfer rulebook, 2025 edition.
- National Competent Authority notices on vIBAN issuance (BaFin, DNB, ACPR, CBI).
Reader questions
Is a vIBAN a real bank account?
No. A vIBAN is a routing key into a shared master account held by a licensed institution. It behaves like a real IBAN for inbound payments, but the account of record is the master account, not the individual vIBAN.
Who's liable if the underlying institution fails?
It depends on the issuer model. Bank-issued vIBANs are typically covered by the deposit guarantee scheme up to the local cap (€100k in most EU states). EMI-issued vIBANs are safeguarded under the EMI regime: funds are ring-fenced from the EMI's own creditors, but not covered by the deposit guarantee scheme. Platforms should surface this to end-users where balances are material.
Can a vIBAN receive SWIFT?
Most vIBANs receive SEPA/SEPA Instant natively. SWIFT support depends on the issuing institution: some vIBANs receive SWIFT with an intermediary BIC; some do not. Confirm with the issuer per corridor.
Do end-users need KYC before an IBAN is assigned?
Yes, in practice. Under the EBA's 2024 opinion on vIBANs and applicable AML rules, the platform requesting the vIBAN typically owes KYC on the end-user, and the issuing institution can pull back accounts that fail its risk framework. Requirements are tightening across EU member states.
Can we issue vIBANs across EEA + UK from one integration?
For EUR, yes, from a single API surface. Venly's Finance API gives each customer named EUR (SEPA) and USD receiving details on licensed partner rails, with incoming payments attributed by reference. GBP receiving details for UK customers are being added to the same API, so the platform doesn't integrate each partner separately.