---
title: "Virtual IBAN & White-Label IBAN Providers: The Four Architectures and Selection Criteria (2026)"
slug: virtual-iban-architecture-selection
publishedAt: 2026-05-11T08:00:00Z
author: Finconduit Editorial Team
tags: EMD2, PSD2, PSD3
canonicalUrl: https://finconduit.com/resources/virtual-iban-architecture-selection
---
# Virtual IBAN & White-Label IBAN Providers: The Four Architectures and Selection Criteria (2026)

Virtual IBAN provision sits on a four-architecture spectrum — white-label issuer, pooled vIBAN, named vIBAN with sponsor BIC, and fully-branded vIBAN on own BIC. Each architecture differs in segregation, BIC routability, naming, jurisdictional reach, and chain of liability.

Almost every fintech, EMI, payment institution, and CASP eventually faces the same procurement question: how do we issue **IBANs to our end\-customers** without spending three years building our own banking licence and BIC infrastructure? The answer is the **virtual IBAN** market — but the term "virtual IBAN" hides a spectrum of very different architectures, each with materially different segregation guarantees, brand strength, supervisory exposure, and chain of liability.

This article codifies what we call **the virtual IBAN architecture spectrum** — four common architectures from white\-label issuer at one end to fully\-branded virtual IBAN on the buyer's own BIC at the other. The architectures are not interchangeable. Picking the wrong one for the use case produces predictable failures: end\-customers seeing the wrong account holder name on incoming SEPA credits, supervisors flagging concentration at a pooled aggregator, sponsor banks exiting the relationship because the chain of liability was misrepresented, or — in the worst case — customer funds frozen because segregation was structural fiction rather than legal reality.

This is the general architectural companion to our [virtual IBAN chain\-of\-liability article focused on non\-EU VASPs](/resources/virtual-iban-non-eu-vasp-chain-of-liability). Here we step back and frame the universal selection problem: which of the four architectures is right for your fintech, given your customer base, jurisdictional reach, brand strategy, and regulatory appetite. The framework applies whether you are an early\-stage neobroker testing payments, a Series\-B EMI scaling cross\-border, or an established CASP integrating fiat rails into a custody product.

## The virtual IBAN spectrum

A virtual IBAN — vIBAN — is any IBAN that does not sit directly inside a credit institution's core ledger as a standalone account. It is a routing identifier mapped via a sub\-ledger to a beneficiary, where the underlying funds may be pooled, segregated, or held under various legal constructs. The defining contrast is with a **physical IBAN** — a real account inside a credit institution holding a real balance against a single named holder. Both are governed by the same European architecture: [EMD2](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0110)¹[^1] for safeguarding obligations, and the BIC/IBAN standard for routability through SEPA and SWIFT.

What varies across architectures is who holds the **BIC**, who is the **account\-holder\-of\-record**, how end\-customer funds are segregated, and where the **chain of liability** terminates when something goes wrong. Both [PSD2](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L2366)²[^2] and EMD2 anchor the rules — but neither directive specifies a single "vIBAN" model, which is why the market has fragmented into the four architectures below.

The spectrum runs from **lowest fintech control \+ lowest regulatory burden \+ lowest brand strength** at one end \(Architecture 1\) to **highest fintech control \+ highest regulatory burden \+ full brand ownership** at the other \(Architecture 4\). Each architecture is the right answer for some fintechs and the wrong answer for others. The selection question is not "which is best?" but "which fits the use case, customer\-base composition, and regulatory appetite?"

## The four architectures

### Architecture 1 — White\-label issuer

The IBAN BIC belongs entirely to the issuer \(an EMI, PI, or sponsor bank\). The fintech is a **sub\-account holder** inside the issuer's master account; end\-customers, in turn, sit one further level down as sub\-sub\-accounts. There is no chain\-of\-liability extension to the fintech itself — the issuer holds the regulatory perimeter and the customer\-protection obligations end\-to\-end.

Brand strength: **low**. The IBAN visibly belongs to the white\-label issuer; incoming SEPA credits show the issuer's name as account\-holder. The fintech is invisible at the payment\-rail layer. Regulatory burden: **lowest**. The fintech does not need its own EMI/PI authorisation to use the architecture. Cost: **lowest**. Setup is typically commercial onboarding rather than supervisory authorisation. Time\-to\-live: **weeks** rather than months.

Right answer for: very early\-stage fintechs validating a payments use case, sub\-vertical use cases where brand at the rail layer doesn't matter \(e.g. embedded payouts inside a marketplace\), or any fintech that wants to test demand before committing to architectural depth.

### Architecture 2 — Pooled virtual IBAN

Multiple fintechs share an aggregator\-held pooled IBAN, with sub\-ledger attribution allocating incoming credits to the right fintech and ultimately to the right end\-customer. The aggregator is typically an EMI or BaaS provider sitting on top of one \(or more\) sponsor\-bank relationships. The chain of liability flows **end\-customer → aggregator → sponsor bank** — with the fintech as a contractual middle party but not a direct holder of the BIC.

Brand strength: **low to medium** — the IBAN range is the aggregator's, but the fintech may be able to apply its own naming on outgoing payments. Regulatory burden: **low**. Concentration risk: **high**. Pooled architectures concentrate hundreds of fintechs at one aggregator and one sponsor bank — meaning a single sponsor exit cascades across the whole pool, simultaneously.

Right answer for: early\-stage fintechs that need a quick path to fiat rails, fintechs whose customer base is tolerant of seeing the aggregator's name on incoming credits, and use cases where pooled\-account economics are acceptable. **Wrong answer for** any fintech serving institutional or treasury clients who require legally\-segregated, named accounts in their own customer's name.

### Architecture 3 — Named virtual IBAN with sponsor BIC

The IBAN is issued in the **end\-customer's name** — meaning the customer's legal name appears as account\-holder on incoming and outgoing SEPA flows — but the BIC remains that of a sponsor bank. The sponsor bank is the account\-holder\-of\-record from a regulatory perspective; the fintech sits in the chain as a referrer or programme manager. Funds are typically held in segregated safeguarding accounts under EMD2 Article 7 \(or the equivalent PSD2 Article 10 construct\) at the sponsor bank.

Brand strength: **high** — end\-customers see their own name on the IBAN. Regulatory burden: **medium** — the fintech typically requires its own EMI or PI authorisation, or operates as a tightly\-bound agent under a sponsor's licence. Cost: **materially higher** than Architectures 1 and 2 — both setup and per\-IBAN ongoing fees. Chain of liability: flows back through the sponsor bank, with the fintech holding intermediate exposure on KYC and ongoing monitoring.

Right answer for: scaled fintechs with regulated authorisation, payment institutions serving SME or institutional clients, neobanks where end\-customer naming is a brand and trust requirement, and any operator whose customers need to receive credits from third parties \(suppliers, employers, treasuries\) under their own legal name.

### Architecture 4 — Fully\-branded virtual IBAN \(own BIC\)

The BIC belongs to the fintech itself — via its own EMI authorisation, PI authorisation, MPI, or in some cases a credit\-institution licence. The fintech is the account\-holder\-of\-record and runs its own sub\-ledger to allocate vIBAN ranges to end\-customers. There is no aggregator and no sponsor BIC sitting between the fintech and the SEPA scheme. The fintech is, for routing and naming purposes, indistinguishable from a bank.

Brand strength: **highest** — the fintech's BIC and brand are present at every payment\-rail interaction. Regulatory burden: **highest** — full EMI/PI authorisation is a multi\-month process with own\-funds requirements, governance bar, BCP and DORA scope, and the full safeguarding obligation under EMD2/PSD2. Cost: **highest** — but unit\-economics flip past a certain volume threshold, since per\-IBAN aggregator fees disappear. Chain of liability: **fully owned by the fintech**.

Right answer for: scaled fintechs operating at material monthly volume where aggregator economics no longer pencil, neobanks treating IBAN issuance as a core product \(not an embedded feature\), and operators with the regulatory ambition to hold their own EU passport across all 30 EEA states.


*Table: The four virtual IBAN architectures compared.*

| Architecture | Segregation | BIC routability | End\-customer naming | Jurisdictional reach | Cost | Fintech control |
| --- | --- | --- | --- | --- | --- | --- |
| 1. White\-label issuer | Pooled at issuer | Issuer's BIC | Issuer's name shown | Issuer's licence footprint | Lowest | Lowest |
| 2. Pooled vIBAN | Pooled across many fintechs | Aggregator's BIC | Aggregator's name shown | Aggregator's licence footprint | Low | Low |
| 3. Named vIBAN, sponsor BIC | Per\-customer segregation under EMD2 Art. 7 | Sponsor bank's BIC | End\-customer's legal name | Sponsor bank's footprint, often EEA\-wide | Medium\-high | Medium\-high |
| 4. Fully\-branded, own BIC | Per\-customer, own safeguarding | Fintech's own BIC | End\-customer's legal name | Full EEA passport via own EMI/PI | Highest | Full |

## Selection criteria

### Segregation guarantees

The first selection question is whether segregation is **per\-fintech and per\-customer** or whether it is pooled with sub\-ledger attribution. Pooled segregation is operationally efficient but legally weaker: in the failure of the aggregator or sponsor bank, the recovery process for sub\-ledger entries is harder, slower, and more contested than for legally\-segregated named accounts. The [EBA](https://www.eba.europa.eu/)³[^3] has flagged sub\-ledger fragility in multiple supervisory communications, particularly post\-Wirecard.

For institutional clients with treasury exposure, named segregation under EMD2 Article 7 is increasingly a procurement requirement — not a nice\-to\-have. Architecture 1 and Architecture 2 both fail this test by definition; only Architectures 3 and 4 satisfy it cleanly.

### BIC routability and incoming\-transfer attribution

The BIC determines routability — which scheme operators, correspondent banks, and counterparty banks accept the IBAN, and how cleanly the IBAN survives screening and rejection rules at the receiving institution. Sponsor BICs \(Architecture 3\) typically route well because the sponsor is a recognised EU credit institution. Aggregator BICs \(Architecture 2\) route well within mainstream SEPA but occasionally produce friction at correspondent banks unfamiliar with the aggregator's profile.

Incoming\-transfer attribution — whether the receiving fintech can match a credit to the right end\-customer — is a function of the sub\-ledger logic, not the architecture per se. But pooled architectures introduce more failure modes: misattributed credits, manual reconciliation queues, and disputes when a remitter places the wrong reference field. Named architectures simplify attribution because the IBAN itself is the customer identifier.

### End\-customer naming

This is often the most consequential selection input. End\-customer naming determines whether incoming SEPA credits show:

- the issuer's name \(Architecture 1\)

- the aggregator's name \(Architecture 2\)

- the end\-customer's own legal name \(Architecture 3 or 4\)

Where the customer's counterparty \(an employer, a supplier, a tax authority\) screens incoming or outgoing credits against the customer's legal name, only Architectures 3 and 4 work. **Confirmation of Payee** and similar name\-matching schemes are tightening this constraint year by year — making Architectures 1 and 2 progressively less viable for any customer base where the IBAN holder receives third\-party credits routinely.

### Jurisdictional reach

In Architectures 1, 2, and 3 the jurisdictional reach is the issuer's, aggregator's, or sponsor's licence footprint. A vIBAN built on a Lithuanian EMI passporting into 30 EEA states inherits 30\-state reach. A vIBAN built on a single\-country PI is correspondingly narrower. The [European Commission's](https://finance.ec.europa.eu/)⁴[^4] pending PSD3/PSR package is expected to harmonise vIBAN treatment further but will not change the underlying single\-NCA vs multi\-NCA distinction.

Architecture 4 puts reach inside the fintech's own control: the EMI/PI authorisation is the passport, and the fintech can extend it as the business requires. This is the strategic logic for ambitious neobanks and EMIs where pan\-European reach is structural to the product.


*Table: Selection criteria scorecard — weighting by use case.*

| Use case | Segregation | BIC routability | Naming | Reach | Cost sensitivity | Best fit |
| --- | --- | --- | --- | --- | --- | --- |
| Embedded payouts in a marketplace | Low | Medium | Low | Medium | High | Architecture 1 |
| Early\-stage neobroker | Medium | Medium | Medium | Medium | High | Architecture 2 |
| SME\-focused payment institution | High | High | High | High | Medium | Architecture 3 |
| Treasury / institutional banking | Highest | Highest | Highest | High | Low | Architecture 3 or 4 |
| Pan\-EEA neobank at scale | Highest | Highest | Highest | Highest | Low | Architecture 4 |
| CASP integrating fiat rails | High | High | High | Medium | Medium | Architecture 3 |

## PSD3 implications — mandatory diversification

The pending PSD3/PSR framework introduces an explicit **diversification expectation** on safeguarded customer funds: above a threshold, customer funds must be spread across at least two credit institutions to prevent single\-institution failure cascading into customer\-fund loss. This maps directly onto the four\-architecture spectrum.

Architectures 1 and 2 — pooled at one issuer or one aggregator — are most exposed to the diversification requirement. Architectures 3 and 4 are more naturally compatible because they allow the fintech \(or its sponsor\) to spread safeguarded balances across multiple credit institutions deliberately. Buyers selecting an architecture in 2026 should anticipate that PSD3 will materially increase the cost of pooled architectures and reduce the cost differential against named architectures.

In other words: Architecture 2 is cheaper today than Architecture 3 partly because the safeguarding diversification cost is socialised across the aggregator's pool. PSD3 forces that cost back onto the architecture explicitly, narrowing the gap.

> **Warning:** PSD3 is expected to apply by 2027. Fintechs procuring vIBAN architecture in 2026 should explicitly ask vendors how they intend to comply with the diversification requirement, and what the pricing impact will be. Vendors that cannot answer concretely are signalling architectural fragility.

## When to upgrade between architectures

The four architectures are not just options — they form a natural **upgrade path** as a fintech matures. Most successful fintechs traverse the spectrum left\-to\-right over their lifecycle. The trigger points are predictable.

1. Architecture 1 → 2: when the fintech's customer base outgrows the white\-label issuer's pricing or feature set, but is not yet ready for own\-branded IBAN issuance.

1. Architecture 2 → 3: when end\-customers begin demanding named IBANs \(typically when the customer base shifts from consumer to SME or institutional\), or when a Confirmation\-of\-Payee mismatch becomes a recurring complaint.

1. Architecture 3 → 4: when monthly transaction volume crosses the breakeven threshold where own\-EMI economics beat per\-IBAN sponsor fees \(typically several hundred million euros of monthly throughput\), or when the strategic plan requires pan\-EEA passporting under the fintech's own brand.

Each upgrade is a 6–18 month project. Plan it before you need it. The most damaging pattern is staying on Architecture 1 or 2 long after the customer base has outgrown it — because the migration project lands on top of a customer\-experience crisis rather than ahead of one.

## Frequently Asked Questions

### What is the difference between a virtual IBAN and a physical IBAN?

A physical IBAN sits directly inside a credit institution's core ledger as a standalone account against a single named holder. A virtual IBAN is a routing identifier mapped via a sub\-ledger to a beneficiary, where the underlying funds may be pooled, segregated, or held under different legal constructs. The four architectures in this article all sit inside the virtual\-IBAN family.

### Can I run more than one architecture in parallel?

Yes — and many scaled fintechs do. A common pattern is Architecture 3 for institutional and SME customers \(where named IBANs are required\) plus Architecture 1 or 2 for consumer or low\-touch use cases \(where pricing matters more than naming\). The complexity cost of running two architectures is real but manageable; the strategic benefit is that you serve segments at the right unit\-economic point.

### How does PSD3 change the architecture choice?

PSD3 introduces a mandatory diversification expectation: customer funds spread across at least two credit institutions above a volume threshold. This raises the relative cost of pooled architectures \(1 and 2\) and narrows the gap to named architectures \(3 and 4\). Buyers in 2026 should procure with PSD3 in mind, not just current\-state economics.

### At what volume does Architecture 4 start to make economic sense?

The breakeven is sensitive to the per\-IBAN fee structure of the underlying Architecture 3 sponsor. Rough rule\-of\-thumb: when monthly throughput exceeds several hundred million euros and the customer base exceeds tens of thousands of named IBAN holders, the fixed cost of own\-EMI authorisation amortises against per\-IBAN fees and Architecture 4 begins to win. Below that, Architecture 3 is typically the better unit economics.

### How does the architecture interact with the chain of liability for non\-EU VASPs?

Non\-EU VASPs face a particularly constrained set of options because of MiCA Article 61 and ESMA's reverse\-solicitation guidelines. Our companion [IBAN architecture for crypto exchanges](/resources/iban-architecture-crypto-exchange) article walks through the specific intersection of vIBAN architecture and CASP/VASP supervisory boundaries.

> **Call to action:** Book a free regulatory bankability assessment. We respond within 24 hours.

## Related Guides

- [Virtual IBAN & Non\-EU VASP Chain of Liability](/resources/virtual-iban-non-eu-vasp-chain-of-liability) — the chain\-of\-liability deep dive for third\-country VASPs using EU\-issued vIBANs.

- [IBAN Architecture for Crypto Exchanges](/resources/iban-architecture-crypto-exchange) — vIBAN architecture as it applies specifically to CASP and VASP fiat\-rail design.

- [BaaS Due Diligence Checklist](/resources/baas-due-diligence-checklist) — the 30 questions to put to any candidate Architecture 2 or 3 provider.

- [EMI Safeguarding Architecture](/resources/emi-safeguarding-architecture) — how the EMD2 Article 7 safeguarding obligation maps onto each vIBAN architecture.

- [Banking Access for Regulated Fintechs](/services/banking) — our service: vIBAN architecture selection, sponsor introductions, supervisor\-readiness.

The four virtual IBAN architectures are not interchangeable, and the right answer is rarely the cheapest. The procurement question for any fintech in 2026 is not "which vIBAN provider is best?" but "which architecture matches our customer base, our regulatory appetite, and our 24\-month roadmap?" Get the architecture right and the provider question becomes secondary. Get the architecture wrong and no provider can save you from the customer\-experience and supervisory consequences that follow. **Choose the architecture before the vendor** — and revisit the choice annually as your volume, customer mix, and the PSD3 timetable evolve.

## Footnotes

[^1]: Directive 2009/110/EC of the European Parliament and of the Council on the taking up, pursuit and prudential supervision of the business of electronic money institutions \(EMD2\), OJ L 267, 10.10.2009. <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0110>
[^2]: Directive \(EU\) 2015/2366 of the European Parliament and of the Council on payment services in the internal market \(PSD2\), OJ L 337, 23.12.2015. <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L2366>
[^3]: European Banking Authority — Guidelines on safeguarding requirements under EMD2/PSD2 and consultation work feeding into PSD3. <https://www.eba.europa.eu/>
[^4]: European Commission — Financial services policy hub, including PSD3 and PSR consultation materials. <https://finance.ec.europa.eu/>


---
Source: https://finconduit.com/resources/virtual-iban-architecture-selection