IBAN Architecture for Crypto Exchanges: Native, BaaS, or Sponsor — A Decision Framework (2026)

The IBAN is the most-visible piece of infrastructure a crypto exchange exposes to its customers — and one of the least-debated architecture decisions at the founding stage. How the IBAN is issued — natively under the firm's own licence, named-IBAN through a BaaS sponsor bank, or pooled-virtual under an aggregator account — shapes regulatory resilience, customer-experience, operational complexity, and cost in different directions. The decision is structural and surprisingly hard to reverse.

This article codifies the three IBAN architectures, the five evaluation criteria that distinguish them, the cohort and use-case mapping, the AMLR implications by pattern, and the migration paths between them. The decision framework is not which is "best" — each architecture is the right answer for a particular firm at a particular stage. The question is which is the right answer for your firm in 2026.

This guide covers the three architectures in detail with explicit pros and cons, the five-criteria evaluation framework, when each architecture is the right fit, AMLR implications, and migration paths between models as the firm matures.

The exchange holds its own EMI authorisation under EMD2¹^[1] and issues IBANs from its own BIC range, with customer funds segregated at a separate safeguarding bank under Article 7. The exchange is the account-holder-of-record for the customer's IBAN; the safeguarding bank holds the segregated balance.

Pros: maximum control over customer experience, branding, and product roadmap; structural independence from any single sponsor; the strongest regulatory resilience of the three architectures; revenue-share with no aggregator margin. Cons: full EMI authorisation cost (€1.0M–€2.2M per our Banking Cost Benchmark); 12–18 months to operational launch; full Three-Bank Resilience Standard required from day one; substance-bar obligations apply directly.

The exchange contracts with a BaaS aggregator that fronts a regulated sponsor bank under PSD2²^[2]. IBANs are issued in each customer's name, with the sponsor bank as account-holder-of-record. The customer has a direct legal relationship with the sponsor bank — the BaaS aggregator handles the technology layer; the exchange handles the customer-facing brand.

Pros: faster time-to-market (8–14 weeks vs 12–18 months); materially lower upfront cost; named IBANs survive aggregator failure as direct customer-bank relationships; reasonable regulatory resilience. Cons: dependent on a single sponsor bank's ongoing willingness to host the relationship; subject to all Seven Patterns of Bank De-Risking; revenue-share with the BaaS aggregator; less control over product roadmap; sponsor-bank inspection risk inherited.

The exchange contracts with an aggregator that holds a single pooled IBAN at a sponsor bank. Each customer gets a virtual sub-account under that pooled IBAN — typically a unique reference number that routes funds within the aggregator's ledger to the right customer balance. The pooled IBAN is in the aggregator's name, not the customer's.

Pros: fastest time-to-market (4–8 weeks); lowest cost; minimal customer-onboarding friction (no per-customer IBAN provisioning at sponsor); attractive economics for high-velocity, low-balance customer bases. Cons: weakest regulatory resilience; on aggregator failure, customer sub-accounts become entangled in wind-down; supervisors increasingly require named IBANs for higher-risk verticals; the model has been at the centre of multiple US BaaS failures.

How the IBAN appears to the customer at deposit and withdrawal. Native and BaaS-named IBANs both deliver a personal IBAN in the customer's name — indistinguishable to the customer. Pooled virtual IBANs deliver a reference number that the customer's counterparty bank may flag as unfamiliar or low-trust — particularly an issue for B2B customers whose finance teams reject IBANs that don't match the named beneficiary.

What happens if the upstream institution exits or fails. Native is most resilient — the exchange is the licence-holder. BaaS-named is intermediate — the named IBAN survives aggregator failure but not sponsor-bank failure. Pooled virtual is weakest — sub-accounts can be frozen during aggregator wind-down. AMLR³^[3] tightens the bar further — supervisors now expect named IBANs for higher-risk verticals.

How much engineering and compliance lift the architecture demands. Native is heaviest — the exchange runs its own AML programme, safeguarding architecture, supervisor reporting, and DORA-aligned ICT register. BaaS-named is medium — the aggregator handles the technology, the sponsor handles the regulatory perimeter, the exchange focuses on customer experience and product. Pooled virtual is lightest at launch but accumulates complexity at scale (reconciliation across thousands of sub-accounts is non-trivial).

How easily the architecture can be replaced if the upstream relationship deteriorates. Native has full optionality — the exchange can change its safeguarding bank without changing customer IBANs. BaaS-named has medium optionality — the customer keeps their named IBAN if you change aggregator, but a sponsor-bank exit requires customer reissuance. Pooled virtual has the worst migration profile — every customer needs a new sub-account reference and the rebrand is operationally heavy.

Total cost over a 3-year horizon, including upfront authorisation, monthly fees, transaction-volume charges, and revenue-share with the upstream. Native is most expensive at year 1 but cheapest at year 3+ as scale amortises authorisation cost. BaaS-named compounds with revenue-share at scale — at €50M+ annual revenue the BaaS margin starts to dominate. Pooled virtual is cheapest at low volumes but unsustainable above mid-cohort.

• The exchange already operates at €50M+ annual revenue and the BaaS margin is materially expensive.

• Long-term independence from any single banking counterparty is a strategic priority.

• The customer base is institutional / B2B where named-IBAN trust is critical.

• The firm has the substance to satisfy the 2026 Substance Bar at authorisation.

• The 12–18 month time-to-launch is acceptable.

• The firm needs to launch in 8–14 weeks with regulated banking foundation.

• Customer base mixes B2C and B2B with material trust expectations on the IBAN.

• Year-1 / Year-2 economics matter; native authorisation cost is unjustified at current scale.

• The firm intends to migrate to native architecture at year 2–3 once scale justifies the authorisation cost.

• The firm is testing product-market fit with very low cost; the firm is prepared to absorb the higher regulatory-resilience risk.

• Customer base is exclusively retail B2C with high-velocity, low-balance flows.

• The firm has a documented migration plan to BaaS-named or Native at year 1–2.

• Lower-risk vertical that is unlikely to attract supervisory pressure on named-IBAN expectations.

Architecture is not a one-time decision. Most firms migrate between models as they mature:

Trigger: regulatory pressure on named IBANs, customer-trust friction, B2B customer base growth. Migration takes 4–8 months — every customer needs a new named IBAN, with reissuance comms and direct-debit re-mandate workflow. Plan for 10–25% customer churn during migration; mitigate with a structured customer-comms arc.

Trigger: scale economics overtake BaaS revenue-share; strategic independence from sponsor; supervisor pressure on cross-border BaaS arrangements. Migration runs in parallel — the firm pursues its own EMI authorisation while continuing to operate on BaaS, then migrates customers as the native infrastructure goes live. Realistic timeline: 18–24 months end-to-end.

The simplest migration — the customer's IBAN does not change because the exchange remains the account-holder-of-record. The change is internal: safeguarding-bank-A → safeguarding-bank-B. Critical for de-banking-event resilience under the Three-Bank Resilience Standard.

AMLR application from 10 July 2027 affects each architecture differently. The DORA⁴^[4] ICT-third-party concentration overlay further compounds the analysis.

Yes — large exchanges often run native architecture for institutional / B2B customers and BaaS-named for retail. The trade-off is operational complexity (two different reconciliation workflows, two different KYC/onboarding paths, two different supervisor reporting profiles). At mid-cohort and above, the parallel architecture is increasingly common.

Each architecture must be evaluated separately for each currency. Native EMI under EMD2 issues EUR / GBP IBANs; USD requires a separate USD correspondent under the Three-Bank Resilience Standard. BaaS-named typically supports multi-currency through the sponsor's banking network. Pooled virtual is multi-currency in principle but the wind-down behaviour is worse for currency that is not the aggregator's home currency.

MiCA itself does not mandate IBAN architecture; the choice depends on the CASP's customer-facing fiat services. A pure crypto-only CASP may not need IBAN issuance at all (deposits via SEPA bank transfer to the firm's safeguarding account). A CASP with on-platform fiat balances increasingly needs named IBANs to satisfy supervisor expectations and customer trust.

Run the BaaS Due Diligence Checklist — questions 11–15 specifically address the IBAN architecture, segregation, and audit rights. Named IBANs are a clear yes / no answer; if the provider hedges, it is operationally pooled-virtual regardless of marketing language.

Not entirely — there is a legitimate role for pooled-virtual in low-risk verticals at small scale. But supervisor pressure under AMLR plus customer trust expectations will materially shrink the addressable use case. Firms still on pooled-virtual at year 2 should have an explicit migration plan to BaaS-named or Native by year 3.

• Sponsor Bank Profile for Fintech BaaS — the deeper diligence framework for BaaS-named architectures.

• BaaS Due Diligence Checklist — the 30-question framework for evaluating any BaaS architecture.

• The Three-Bank Resilience Standard — the architecture underpinning Native IBAN issuance.

• Bank Account for an EMI: 2026 Buyer's Playbook — the build-out path for native architecture.

• Banking Access for Regulated Fintechs — our service: architecture decision, sponsor-bank diligence, migration planning.

IBAN architecture is one of the most consequential infrastructure choices a crypto exchange makes — and one of the easiest to get wrong by defaulting to whatever the BaaS aggregator markets at the founding stage. The framework is deliberate: pick the architecture that fits the firm's current cohort and customer base, document the migration plan to the next architecture before you need it. The exchanges that scale do not pick once and forget; they revisit the architecture annually as scale, customer mix, and regulatory expectations move.