--- title: "IBAN Architecture for Crypto Exchanges: Native, BaaS, or Sponsor — A Decision Framework (2026)" slug: iban-architecture-crypto-exchange publishedAt: 2026-05-03T12:00:00Z author: Finconduit Editorial Team tags: PSD2, EMD2, AMLR, DORA canonicalUrl: https://finconduit.com/resources/iban-architecture-crypto-exchange --- # IBAN Architecture for Crypto Exchanges: Native, BaaS, or Sponsor — A Decision Framework (2026) Three IBAN issuance models for a crypto exchange in 2026: native (own bank/EMI), BaaS-named (sponsor bank with named IBANs), pooled-virtual (aggregator-held). Each has a structural risk profile, a customer-experience profile, and a regulatory-resilience profile. The decision framework that surfaces which to use when, with explicit pros and cons and a five-criteria scoring matrix. 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 three architectures ### Architecture 1 — Native IBAN issuance The exchange holds its own EMI authorisation under [EMD2](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0110)¹[^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. ### Architecture 2 — BaaS\-named IBANs \(sponsor\-bank model\) The exchange contracts with a BaaS aggregator that fronts a regulated sponsor bank under [PSD2](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L2366)²[^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. ### Architecture 3 — Pooled virtual IBANs 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. *Table: The three IBAN architectures — at a glance.* | Dimension | Native | BaaS\-named | Pooled virtual | | --- | --- | --- | --- | | Time to launch | 12–18 months | 8–14 weeks | 4–8 weeks | | Upfront cost | €1.0M–€2.2M | €50k–€200k | €10k–€50k | | Customer relationship | Exchange = AHOR | Sponsor bank = AHOR | Aggregator = AHOR \(pool\) | | Wind\-down behaviour | Customer\-fund segregation under EMD2 | Direct relationship survives aggregator failure | Sub\-accounts entangled in aggregator wind\-down | | Regulatory resilience | Highest | High | Lowest | | Product flexibility | Highest | Medium | Lowest | | Revenue\-share / margin | No external take | Aggregator \+ sponsor margin | Aggregator margin | ## The five evaluation criteria ### Criterion 1 — Customer\-experience profile 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. ### Criterion 2 — Regulatory\-resilience profile 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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1624)³[^3] tightens the bar further — supervisors now expect named IBANs for higher\-risk verticals. ### Criterion 3 — Operational complexity 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\). ### Criterion 4 — Migration path optionality 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. ### Criterion 5 — Cost 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. *Table: Five\-criteria evaluation matrix — practitioner view \(1=weak, 5=strong\).* | Criterion | Native | BaaS\-named | Pooled virtual | | --- | --- | --- | --- | | Customer\-experience profile | 5 | 5 | 2 | | Regulatory resilience | 5 | 3 | 1 | | Operational complexity \(lower = better\) | 2 | 4 | 5 at launch / 2 at scale | | Migration path optionality | 5 | 3 | 1 | | Cost at year 1 | 1 | 3 | 5 | | Cost at year 3\+ \(mid\-cohort\) | 4 | 2 | 2 | ## When each architecture is the right fit ### Native is the right architecture when… - 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. ### BaaS\-named is the right architecture when… - 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. ### Pooled virtual is the right architecture when… - 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. > **Warning:** The most expensive IBAN architecture mistake is choosing pooled\-virtual at the founding stage and discovering 18 months later that the supervisor expects named IBANs for the firm's vertical. The migration to BaaS\-named or Native takes 4–8 months and forces customer reissuance — typically 10–25% customer churn. Plan the architecture for the supervisor's 2027–2028 expectations, not for 2026's start\-up economics. ## Migration paths between architectures Architecture is not a one\-time decision. Most firms migrate between models as they mature: ### Pooled virtual → BaaS\-named \(typical year 1–2\) 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. ### BaaS\-named → Native \(typical year 2–3\) 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. ### Native ↔ Native \(changing safeguarding bank\) 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 implications by architecture AMLR application from 10 July 2027 affects each architecture differently. The [DORA](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554)⁴[^4] ICT\-third\-party concentration overlay further compounds the analysis. *Table: AMLR / DORA delta on each architecture from 2027.* | Architecture | AMLR delta | DORA delta | | --- | --- | --- | | Native | Direct AMLR application; AMLA selected\-entity if scale crosses threshold | Direct DORA application; ICT register required | | BaaS\-named | Sponsor bank's AMLR posture inherited; firm responsible for AMLR\-aligned customer flows | Sponsor's DORA programme inherited; concentration risk surfaces | | Pooled virtual | Aggregator's AMLR posture inherited; supervisor pressure on named IBANs intensifies | Concentration risk highest; aggregator\-as\-critical\-vendor scrutiny | ## Frequently Asked Questions ### Can I run multiple architectures in parallel? 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. ### How does this interact with multi\-currency operations? 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. ### What's the right architecture for a CASP under MiCA? 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. ### How do I assess a candidate BaaS provider's IBAN architecture? 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. ### Will pooled\-virtual disappear by 2027? 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. > **Call to action:** Book a free regulatory bankability assessment. We respond within 24 hours. ## Related Guides - [Sponsor Bank Profile for Fintech BaaS](/resources/sponsor-bank-profile-fintech) — the deeper diligence framework for BaaS\-named architectures. - [BaaS Due Diligence Checklist](/resources/baas-due-diligence-checklist) — the 30\-question framework for evaluating any BaaS architecture. - [The Three\-Bank Resilience Standard](/resources/three-bank-resilience-standard) — the architecture underpinning Native IBAN issuance. - [Bank Account for an EMI: 2026 Buyer's Playbook](/resources/bank-account-for-emi) — the build\-out path for native architecture. - [Banking Access for Regulated Fintechs](/services/banking) — 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. - [The Crypto Card Program Stack: BIN Sponsorship](/resources/crypto-card-program-bin-sponsorship) — how BIN sponsorship, program management and settlement accounts fit together to issue crypto\-linked cards. ## Footnotes [^1]: Directive 2009/110/EC \(EMD2\) — Article 7 customer\-fund safeguarding requirements for electronic money institutions. [^2]: Directive \(EU\) 2015/2366 \(PSD2\) — payment\-services framework underpinning BaaS sponsor\-bank arrangements. [^3]: Regulation \(EU\) 2024/1624 \(AMLR\) — single rulebook on AML/CTF for financial entities including CASPs, OJ L, 19.6.2024. [^4]: Regulation \(EU\) 2022/2554 \(DORA\) — digital operational resilience for the financial sector, OJ L 333, 27.12.2022. --- Source: https://finconduit.com/resources/iban-architecture-crypto-exchange