Banking-as-a-Service in Europe: A Framework for Choosing a Sponsor Stack (2026)

A fintech founder evaluating Banking-as-a-Service in Europe in 2026 typically begins with the wrong question: "which BaaS provider should I use?" The vendor list is long and the marketing material is interchangeable. Pricing decks converge. Reference customers overlap. After three months of provider calls the founder has a spreadsheet of fees, integration timelines, and feature matrices — and no clearer view of which architecture actually fits the business.

The right question is upstream of the vendor list. Choosing BaaS in Europe is an architectural decision, not a vendor selection. There are exactly three patterns in production use across the EEA — call it the BaaS sponsor-stack framework. Each pattern places the regulated perimeter in a different counterparty, distributes redundancy differently, exposes the fintech to different supervisory expectations, and produces a different unit-economic profile.

Pattern 1 is sponsor-bank-direct issuance, with the sponsor bank as the regulated issuer and the fintech as agent. Pattern 2 is BaaS aggregator middleware, with a licensed EMI/PI sitting between the fintech and a panel of sponsor banks. Pattern 3 is the hybrid model — the fintech holds its own EMI or PI and uses BaaS only for transaction-banking primitives. This article codifies the framework, compares the three patterns on the four dimensions that actually matter, and lays out the migration paths a fintech follows as it scales from launch through €50M+ revenue.

BaaS providers are not interchangeable, but the differences that matter operationally are not the differences that show up on a feature matrix. Fee per IBAN, FX spread, and webhook latency are real — but they are second-order. The first-order question is who holds the licence, who carries the safeguarding obligation, and who the supervisor walks into when there is a problem.

Under EMD2¹^[1] and PSD2, the regulated activity sits with the licence holder — issuance of electronic money, execution of payment transactions, IBAN issuance, safeguarding of customer funds. Whoever holds the licence carries the customer-facing perimeter and the supervisory exposure that goes with it. The fintech's structural choice is which counterparty in the stack owns that perimeter.

Vendor selection within an architecture is straightforward — due diligence on capital, governance, sponsor-bank panel, integration quality. But choosing the wrong architecture is not solvable by switching vendors. A fintech that picked a BaaS aggregator when it should have built on its own EMI does not fix the problem by moving to a different aggregator; it has to re-architect.

This is why the framework comes before the shortlist. Pin the architectural pattern first; then run a vendor selection inside that pattern.

In Pattern 1 the sponsor bank is the direct issuer of the customer-facing product — IBAN, card, payment account — and the fintech operates as an agent or technical service provider on top. The fintech holds no payments licence in its own right. The bank holds the regulated function and the customer-facing perimeter. End-customers contract with the bank; the fintech provides the user interface, onboarding flow, and product wrapping.

This is the cleanest regulatory perimeter available — and the thinnest fintech control. The bank approves the product, the marketing, the customer terms, the AML calibration, and any change to the user journey. Speed-to-market depends on a single counterparty's release cadence. Brand strategy is constrained: most Pattern 1 deployments are co-branded or white-labelled with bank disclosures prominent on the customer-facing surface.

The trade-off: Pattern 1 minimises the fintech's licensing burden, prudential capital, and supervisory contact, at the cost of product velocity, brand control, and concentration risk on a single sponsor. Right for early-stage fintechs (pre-Series A), embedded-finance plays where the bank's brand is acceptable, and verticals where regulatory burden would otherwise dominate.

In Pattern 2 a licensed BaaS aggregator — itself an EU EMI or PI — sits between the fintech and a panel of sponsor banks. The aggregator holds the customer-facing licence, performs the safeguarding, runs the AML core, and orchestrates rail selection across multiple bank back-ends. The fintech contracts with the aggregator only and is exposed to the bank panel through the aggregator's contracts.

Pattern 2 is the most common architecture in the EEA in 2026 and the default for fintechs in the €5M–€50M revenue band. It offers faster time-to-market than direct issuance because the aggregator's product is pre-built, the customer terms are reusable, and the integration is one API rather than one per bank. It offers better redundancy than Pattern 1 because rail failures inside the aggregator's panel can be re-routed without breaking the fintech's customer experience.

The dominant risk in Pattern 2 is concentration at the aggregator itself. The fintech has diversified its sponsor-bank exposure but introduced a new single point of failure — the aggregator's licence, governance, capital, and continuity. When the aggregator wobbles (regulatory action, capital event, ownership change, sponsor-bank exit) the fintech's entire customer-facing rail wobbles with it. The mature mitigation is a two-aggregator architecture with active-active or active-warm posture across two distinct providers — expensive, but increasingly required by sophisticated investors and risk committees.

In Pattern 3 the fintech holds its own EMI or PI licence — the customer-facing perimeter sits inside the fintech itself — and uses a BaaS layer only for the transaction-banking primitives the fintech does not want to build directly: card-issuing infrastructure, IBAN range procurement, FX execution, scheme connectivity, sometimes specific sponsor-bank correspondent relationships.

This is the highest regulatory burden and the highest control. The fintech runs its own AML programme, holds its own safeguarding accounts, files its own regulatory returns, carries its own prudential capital (€350,000 minimum for an EMI under EMD2; tiered scales for PIs), and is the supervised entity in its own right. The BaaS provider is a vendor under outsourcing rules, not the licence-holder.

The EBA outsourcing guidelines²^[2] govern the relationship: documented exit plan, substitutability assessment, audit rights, sub-outsourcing chain disclosure, BCP testing. In Pattern 3 the fintech itself owns these obligations rather than relying on the aggregator's posture. Right for fintechs at scale (typically €50M+ revenue) where licence cost amortises, brand independence is strategic, and the cost of aggregator concentration exceeds the cost of running a regulated entity.

The framework reduces the choice to four dimensions. Score the business honestly on each one and the right pattern usually falls out.

The most consequential dimension. Whoever holds the customer-facing licence holds the regulator's attention. In Pattern 1 the sponsor bank is the regulated entity for the customer-facing product; in Pattern 2 the aggregator is; in Pattern 3 the fintech itself is. Each shifts where the supervisory inspection lands, where AML governance ultimately sits, and which entity carries reputational risk in a public incident.

Founders should not pick a pattern primarily to avoid supervision — Patterns 1 and 2 do not exempt the fintech from oversight, they relocate the primary point of contact. EBA outsourcing guidelines and DORA both ensure that the fintech remains accountable for the customer outcome regardless of where the licence sits.

Pattern 1 is single-sponsor by construction; Pattern 2 distributes across a panel inside one aggregator; Pattern 3 supports own-licence-plus-BaaS-backup as a deliberate multi-rail architecture. The right answer depends on the cost of an outage in customer-facing rails — for a B2C neobank with payroll inflows on day-of-month, single-sponsor concentration is not survivable. For a niche B2B treasury product with low transaction frequency, it may be tolerable.

Under DORA³^[3], regulated entities must demonstrate ICT third-party-risk management with documented exit and substitution plans. A Pattern 2 fintech needs an answer for "what happens if your aggregator fails" — and that answer increasingly has to be a contracted second aggregator with at least quarterly failover testing.

Pattern 1 is white-label or co-brand; the bank's name is on the customer-facing disclosures. Pattern 2 supports co-brand ("powered by …") or near-full-brand depending on the aggregator's contractual flexibility. Pattern 3 is full brand — the fintech is the regulated counterparty and customer-facing terms reference no third party as the issuer. Brand strategy alone can force Pattern 3 for fintechs whose differentiation is built on customer trust and brand independence (digital-bank challengers, premium B2B propositions).

Three components dominate: per-transaction fees, sponsor-bank capital float, and licensing overhead. Pattern 1 minimises licensing overhead and shifts the economic margin to the sponsor bank; per-transaction fees are typically high. Pattern 2 introduces an aggregator margin but bundles the licensing infrastructure cost. Pattern 3 carries the highest fixed cost (own licence + capital + compliance team) but the lowest marginal cost per transaction at scale.

The cross-over is roughly €30M–€50M annual revenue — below that, Pattern 2's bundled licensing infrastructure is cheaper than running it in-house; above that, the fixed cost of Pattern 3 is amortised across enough volume to make the lower marginal cost dominate.

Decision rules in plain language. Pick Pattern 1 if you are pre-Series A, embedded-finance native (your end-customer never thinks about the bank), and your priority is launching in 90 days with no licensing burden. The single-sponsor concentration is acceptable because product-market fit is a higher-priority risk than rail redundancy at this stage.

Pick Pattern 2 if you are in the €5M–€50M revenue band, building a brand-led product but not yet at the scale that justifies own-licence economics, and you need flexibility across rails without the burden of negotiating multiple sponsor-bank contracts directly. Pattern 2 is the default for most growth-stage EU fintechs and the assumption from which other patterns are deviations.

Pick Pattern 3 if you are at €50M+ revenue, brand independence is strategic, you have a multi-product roadmap that benefits from holding the regulated rails in-house, and the fixed cost of an EMI/PI licence amortises across enough volume to lower your marginal economics. Pattern 3 is also right earlier than €50M when institutional customers require own-licence as a procurement criterion — increasingly common in B2B treasury, payroll, and platform-payments verticals.

The transition from PSD2⁴^[4] to PSD3 / PSR tightens several expectations that map directly to the framework. The merger of EMI and PI regimes under PSD3 reduces the gap between Patterns 2 and 3 — own-licence becomes structurally simpler. Mandatory diversification of safeguarding accounts above thresholds raises the cost of single-sponsor concentration. Strengthened outsourcing oversight raises the substance bar for any fintech relying on a BaaS provider for the customer-facing perimeter.

For Pattern 1: the sponsor bank's diversification expectations rise; the fintech-as-agent model remains viable but the sponsor bank's onboarding diligence sharpens. For Pattern 2: aggregator concentration becomes a more visible regulatory concern; expect supervisors to ask Pattern 2 fintechs about their second-aggregator posture during routine inspections. For Pattern 3: the regulatory burden converges with PSD3's higher own-licence substance expectations, but the lower aggregator dependency becomes a structural advantage.

The framework is not static. Most successful European fintechs migrate through the patterns as they scale — typically Pattern 1 → Pattern 2 → Pattern 3 — and the migration plan is part of the original architecture decision. Designing Pattern 1 with no consideration of the Pattern 2 migration path produces re-platforming pain at exactly the moment the business cannot afford it.

Trigger: the single-sponsor concentration becomes intolerable, or the brand-control limits constrain product velocity. Mechanics: select a Pattern 2 aggregator, contract in parallel, migrate customer cohorts in waves with explicit consent and IBAN re-issuance, decommission the Pattern 1 relationship after the last cohort migrates. Realistic duration: 6–12 months depending on customer base and the original sponsor's exit cooperation.

Trigger: revenue at the cross-over point, brand strategy demanding own-licence, or aggregator concentration risk no longer acceptable. Mechanics: file the EMI or PI authorisation in chosen home state (typically Lithuania, Ireland, or the Netherlands), build the compliance and risk function to inspection grade, run the aggregator and own-licence in parallel during the licensing process, and migrate the customer book to own-licence rails after authorisation. Realistic duration: 18–24 months end-to-end including licensing.

Rare but possible. Typically driven by an institutional customer cohort or M&A scenario that compresses the migration timeline. Operationally harder than the two-step path because the fintech does not gain Pattern 2's intermediate operational maturity before assuming Pattern 3's regulatory load. Not recommended unless external factors compel it.

It is the most common pattern but not the safe default in every case. For embedded-finance use cases where the end-customer never identifies the bank, Pattern 1 is structurally simpler and cheaper. For fintechs with institutional B2B buyers who require own-licence as a procurement criterion, Pattern 3 may be the only viable choice from launch. The safe default is whichever pattern matches the four-dimension profile honestly assessed.

All-in Year-1 cost in Lithuania, Ireland, or the Netherlands typically lands in the €600k–€1.5M range — covering minimum prudential capital (€350k for a small EMI), licensing legal and consulting fees (€150k–€350k), in-house compliance and risk hires (€200k–€500k), audit and external assurance (€50k–€100k), and infrastructure for safeguarding and reporting (€50k–€150k). Year 2 onwards drops to the recurring run-rate, but the licence is a permanent fixed cost regardless of volume.

Yes — and most Pattern 3 fintechs do. The own EMI/PI carries the principal customer-facing rails; a BaaS provider remains in place for specific functions (card issuing, particular currency rails, geographic redundancy). The architectural distinction is which counterparty holds the customer-facing licence; the operational reality is usually a hybrid even within Pattern 3.

Start the licence application 18–24 months before you need the live licence. The application is gated by regulator capacity, governance hire-in (Heads of Compliance, MLRO, Heads of Risk all required at substance), and a credible 3-year financial plan. Fintechs that wait until the aggregator concentration becomes painful are 18 months away from a solution; fintechs that begin in advance complete the migration on their own timeline.

DORA applies to the regulated financial entity. In Pattern 1 the sponsor bank is the DORA-regulated entity; the fintech is downstream as a service provider with contractual flow-down. In Pattern 2 the aggregator is the DORA-regulated entity. In Pattern 3 the fintech itself is the regulated entity and carries DORA obligations directly — including ICT third-party-risk management of the BaaS providers it uses for transaction-banking. The substance is identical; the locus of obligation differs.

• BaaS Due Diligence Checklist — the 30 questions to put to any aggregator or sponsor candidate inside the chosen pattern.

• Sponsor Bank Profile for Fintech BaaS — the diligence framework for evaluating sponsor bank candidates in Patterns 1 and 2.

• IBAN Architecture for a Crypto Exchange — sector-specific application of the framework where rail choice is constrained by counterparty filters.

• The Three-Bank Resilience Standard — the redundancy posture that informs Pattern 2 → Pattern 3 migration triggers.

• Banking Access for Regulated Fintechs — our service: pattern selection, aggregator and sponsor-bank introductions, migration planning.

The BaaS sponsor-stack framework is not a recommendation in favour of any one pattern. It is the discipline of forcing the architectural question before the vendor question — and of revisiting the answer as the business crosses the cohort thresholds where one pattern stops fitting and the next one starts. Founders who make the framework explicit in their original build decision migrate cleanly; founders who treat BaaS as a vendor selection re-architect under pressure. Choose the pattern; then choose the vendor.