Sponsor Bank Profile: What a Fintech Should Demand from BaaS (2026)

Most fintechs evaluating Banking-as-a-Service spend their diligence cycle on the BaaS aggregator: the platform's API, the IBAN issuance flow, the per-transaction pricing, the onboarding velocity. The deeper question — and the one that determines whether the relationship survives a regulatory cycle — is the sponsor bank standing behind the aggregator. The aggregator does not hold the licence. It does not own the BIN, the IBAN range, or the customer-fund safeguarding. The sponsor bank does.

When the sponsor de-risks, the aggregator inherits it within thirty days. You inherit it within ninety. We have watched this pattern play out three times in the last eighteen months — solvent, well-funded fintechs effectively deplatformed when their sponsor bank's risk committee reweighted crypto, MENA flows, or higher-risk merchant categories. In each case the failure was visible in the sponsor bank's profile six months earlier; the fintech had simply not done the diligence on it.

This is the seven-criteria evaluation framework we run on any sponsor bank before approving a BaaS engagement: capital adequacy, supervisory history, AML maturity, BaaS portfolio composition, exit terms, IBAN issuance mechanic, and customer-fund segregation. Get all seven right and the relationship is a five-year asset; get any one wrong and the de-platforming clock starts ticking.

The Banking-as-a-Service stack has three layers. The fintech sits at the top — the customer-facing brand, the wallet UX, the merchant relationships. The BaaS aggregator sits in the middle — the technology layer, the API, the orchestration. The sponsor bank sits at the bottom — the licence, the regulator, the BIN, the IBAN range, the safeguarding mechanic.

The fintech contracts with the aggregator. The aggregator contracts with the sponsor bank. There is no direct contractual line between the fintech and the sponsor bank — and yet the sponsor bank holds material control over the fintech's operations, often including unilateral termination rights at thirty days' notice. Every fintech that runs on BaaS lives inside someone else's regulated perimeter under the Payment Services Directive (PSD2)¹^[1] or EMD2. The question is whether that perimeter is solid.

A failing aggregator can be replaced. It is painful but the sponsor-bank licence underneath survives, and a substitution is technically possible — albeit at a six-to-nine-month cost. A failing sponsor bank, by contrast, terminates the entire stack. The aggregator has no licence to fall back on. The fintech has no banking relationship to migrate. Customer funds become trapped in a wind-down process that takes 12–24 months. This is what happened to the US BaaS market in 2023–2024 and it is what we now design around in EU sponsor evaluations.

The mistake fintechs make is treating the aggregator as the diligence target because the aggregator is the contractual counterparty. The substantive risk sits one layer down. The aggregator is selling you exposure to a sponsor bank you didn't pick.

Look at the sponsor bank's published capital position relative to its regulatory minimum. CET1 ratio, leverage ratio, liquidity coverage ratio — all published under EBA prudential disclosures²^[2]. A sponsor bank running at the regulatory minimum has no buffer when its risk committee tightens — the first thing cut is non-core relationships, and BaaS programmes are by definition non-core. We won't approve a sponsor running below 1.5x the regulatory CET1 floor.

Has the sponsor bank received any consent orders, public censures, supervisory letters, or s.166 reviews in the last three years? AML-related enforcement actions are particularly material — a sponsor bank that has just exited an AML consent order has just been told by its regulator to reduce non-core, higher-risk-profile programmes. BaaS programmes are first on that list. Check the FCA enforcement page³^[3] for UK sponsors and the equivalent NCA enforcement register for EU sponsors.

The sponsor bank's AML programme is the AML programme your customer flows are assessed against. If the sponsor's transaction monitoring is generic, your fintech's onboarding gets generic. If the MLRO is junior or under-resourced, every escalation in your customer base creates pressure. Evidence of maturity: depth of EDD methodology, sophistication of TM rules, MLRO seniority, training records, and full alignment to the new AMLR (Regulation 2024/1624)⁴^[4] single rulebook.

What other fintechs is this sponsor bank serving? If the portfolio is concentrated in higher-risk verticals (remittance, merchant acquiring for higher-risk MCC codes, crypto on-ramps), the sponsor is one regulator letter away from re-pricing or de-risking the entire book. If the portfolio is well-diversified across investment management, lending, and embedded payments for low-risk verticals, the sponsor is structurally more stable. Ask for an aggregate breakdown — names redacted, but composition disclosed.

What does the BaaS contract say about termination? In practice, every BaaS contract gives the sponsor bank the right to terminate at thirty to ninety days' notice for 'regulatory reasons' — this is non-negotiable. What is negotiable is the migration support: notice period, customer-data portability, fund-segregation runbook, and audit rights on the sponsor's safeguarding posture. Strong contracts include the right to inspect the sponsor's safeguarding bank annually.

There are two models. Named IBANs in the customer's name, with the sponsor bank as account-holder-of-record, are stronger — the customer has a direct relationship that survives an aggregator failure. Virtual IBANs that are sub-accounts under a single pooled IBAN held by the aggregator are weaker — when the aggregator fails or is de-risked, the underlying sub-accounts become entangled in the wind-down. EU supervisors increasingly require named IBANs for higher-risk verticals.

Same architecture as direct EMI safeguarding under EMD2 Article 7⁵^[5]: customer funds must be segregated from the sponsor bank's own funds and from the aggregator's own funds, ring-fenced in a properly-named safeguarding account, with daily reconciliation. The fintech should have audit rights on this segregation. Many BaaS programmes pool customer funds across multiple fintechs in the same operating account — a structural failure that creates contagion risk if any single fintech in the pool encounters fraud or collapse.

A sponsor bank exiting an AML consent order in the last 24 months is structurally compelled to reduce higher-risk programmes. BaaS is by default classified as higher-risk under most supervisory taxonomies. Avoid unless the sponsor can evidence a fundamentally rebuilt programme.

Sponsor banks where more than 40% of BaaS revenue comes from a single vertical (e.g. remittance) face concentrated regulatory exposure. One ESMA, EBA, or NCA letter on that vertical and the entire book gets re-priced.

If customer funds across multiple fintechs sit in a single pooled operating account at the sponsor bank, fraud at any one fintech contaminates the whole pool. This is the architecture pattern at the centre of multiple US BaaS failures and is now flagged by EU supervisors.

Names can stay confidential. Composition cannot. Any BaaS provider unwilling to share an aggregate vertical breakdown of its book is hiding portfolio concentration.

Mandatory DORA⁶^[6] compliance applies from 17 January 2025. A sponsor bank without a DORA-aligned ICT-third-party risk programme cannot credibly host BaaS into 2026 — expect supervisory pressure inside twelve months.

The single most predictive question: in the last 18 months, has the sponsor bank received any supervisory letters or directions concerning third-party programmes, BaaS partnerships, or AML controls? If yes, treat the relationship as already on a clock. If no, ask how the sponsor monitors for these signals across its peer set. The right sponsor invests in regulatory horizon scanning; the wrong one reacts after the fact.

• What is the sponsor bank's name and registered regulatory authorisation number?

• Has the sponsor received any public enforcement action in the last 36 months?

• What is the sponsor's current CET1 ratio and where is it published?

• What proportion of the sponsor's revenue is from BaaS / fintech partnerships?

• What is the BaaS book composition by vertical (aggregate, no names required)?

• Named IBANs or pooled virtual IBANs?

• Daily-reconciled segregation, and what audit rights does the fintech have?

• Termination notice period and documented migration runbook?

• DORA ICT-third-party risk programme — evidence of compliance and last attestation date?

Ask the BaaS provider directly under NDA. If they refuse to name the sponsor in writing during diligence, walk away. The sponsor's identity is also typically inferable from the BIC of the IBAN range issued, the BIN of any card products, and the BaaS provider's regulatory filings (e.g. partnership disclosures in their annual report).

Only if the BaaS provider itself holds a banking, EMI, or PI licence — in which case the BaaS provider is functionally the sponsor. Most pure-play BaaS aggregators do not hold their own licence and rely entirely on the sponsor relationship.

A named IBAN is registered in the customer's name with the sponsor bank as the account-holder-of-record — it has the legal status of a direct bank account and survives an aggregator failure. A virtual IBAN is a sub-ledger entry under a single pooled IBAN held by the aggregator. The customer-facing experience is identical; the wind-down behaviour is materially different.

Standard contracts give the sponsor 30–90 days' termination right for 'regulatory reasons.' In practice, when a sponsor de-risks under supervisory pressure, the migration window can compress to two to four weeks. Plan continuity around the worst-case rather than the contract.

It can be — but it is also faster and cheaper to launch. The right framing is: BaaS is the right answer for the first 18–36 months while you build the volumes and capital base needed for direct authorisation. Treat it as a stepping stone with a deliberate migration plan, not a permanent architecture.

• Bank Account for an EMI: 2026 Buyer's Playbook — the alternative to BaaS: direct three-bank treasury build.

• EMI Safeguarding Architecture — the segregation pattern your sponsor bank should match.

• EMI vs PSP vs VASP vs CASP — deciding whether to build on BaaS or pursue your own licence.

• Banking Access for Regulated Fintechs — our advisory service: BaaS evaluation, sponsor diligence, migration planning.

BaaS is not a shortcut around banking. It is a rented banking relationship with someone else's de-risking risk attached. Pick the sponsor with the same care you would pick a direct safeguarding bank, contract for migration runbook and audit rights from day one, and revisit the seven criteria every twelve months. The fintechs that survive de-risking cycles are the ones that did the diligence on the layer below.