Banking-as-a-Service (BaaS): Platform Selection and Due Diligence

Banking-as-a-Service has become the dominant infrastructure model for the embedded finance era, enabling non-bank businesses to offer current accounts, debit cards, lending products, and payment services to their own customers without obtaining banking licences. The model works by layering technology platforms on top of regulated banking infrastructure, distributing financial services through the channels of non-financial businesses. But the rapid growth of BaaS has exposed a set of structural risks that regulators and participants are now grappling with seriously.

The BaaS Model Explained

In a typical BaaS arrangement, a regulated bank or EMI — the sponsor institution — provides the regulatory licence, balance sheet, and core banking infrastructure. A technology platform — the BaaS provider — sits between the sponsor institution and the end distribution partner (the brand), providing APIs, developer tools, and operational processes that allow the distribution partner to build financial products without directly managing banking relationships. The distribution partner embeds these financial products into its own customer experience.

The three-layer structure (sponsor institution, BaaS platform, distribution partner) creates distributed accountability. Each layer has distinct responsibilities, but the regulatory accountability ultimately rests with the sponsor institution — it holds the licence, and the FCA holds it responsible for the conduct of the businesses it enables, regardless of how many intermediary layers exist between the bank and the end customer.

Licence Sponsorship Risks

The sponsor bank risk in BaaS has become a significant supervisory focus. The FCA's Dear CEO letter to non-bank lenders (2022) and subsequent Dear CEO correspondence to banks providing sponsor services (2023-2024) made clear that sponsor banks cannot outsource their regulatory responsibilities. A sponsor bank that enables a BaaS distribution partner to onboard customers without adequate AML/KYC checks, or to offer financial products that breach consumer protection standards, is accountable to the FCA for those failures — even though the underlying conduct was the distribution partner's.

This regulatory accountability creates a principal risk that has caused several US sponsor banks — including some notable failures linked to BaaS concentration — to withdraw from the BaaS market or impose significantly more stringent requirements on their distribution partners. The FCA has signalled similar expectations in the UK, creating pressure on sponsor institutions to implement robust oversight frameworks for their BaaS relationships.

API Connectivity and Technical Due Diligence

BaaS platforms are fundamentally API-first businesses. The quality, stability, and security of the API layer determines the operational resilience of every distribution partner building on the platform. Technical due diligence on a BaaS platform should include: assessment of API uptime SLAs and historical performance against those SLAs; review of the API security architecture including authentication, encryption, and penetration testing frequency; evaluation of the data architecture and data residency compliance; incident response procedures and communication protocols; and the roadmap for API development and versioning stability.

API versioning deserves particular attention. BaaS platforms that deprecate API versions without adequate notice or migration support create significant operational disruption for distribution partners whose products are built on those APIs. Understanding the platform's API governance policies — including deprecation timelines, migration support, and contractual commitments — is important before committing to a deep integration.

Sponsor Bank Accountability Framework

Distribution partners entering BaaS arrangements should understand exactly what their sponsor institution's accountability framework requires of them. Modern BaaS sponsor agreements typically include: mandatory AML/KYC standards that the distribution partner must implement for all end customers; transaction monitoring requirements and escalation procedures for suspicious activity; regular compliance reporting to the sponsor institution; audit rights allowing the sponsor to review the distribution partner's compliance infrastructure; and step-in rights that allow the sponsor to restrict or suspend operations if compliance obligations are not met.

Distribution partners who treat the sponsor institution's requirements as a contractual formality — implementing minimum compliance processes without genuine substance — create liability exposure for both themselves and the sponsor. The FCA has demonstrated through enforcement actions that it will pursue distribution partners who allow inadequate compliance frameworks to persist, particularly where AML failures have resulted in financial crime flows through the embedded product.

Due Diligence Checklist for BaaS Platform Selection

A practical due diligence checklist for selecting a BaaS platform should cover:

• Regulatory status of the sponsor institution — FCA authorisation, PRA oversight if a bank, regulatory history including past enforcement actions
• Financial stability of the BaaS platform provider — capital position, funding runway, investor backing
• Customer fund protection — where are customer funds held, what safeguarding or FSCS protection applies
• Operational resilience — disaster recovery capability, maximum RTO/RPO, business continuity testing frequency
• Data protection — GDPR compliance, data breach history, DPA agreements
• Exit provisions — what happens if the BaaS platform fails or terminates the relationship, how long does migration to an alternative provider take
• Pricing structure — pricing transparency, minimum volumes, volume tier structure

The exit provision question is often overlooked in BaaS due diligence but is critically important. Distribution partners that have built deeply integrated products on a single BaaS platform and have no migration plan are in an extremely vulnerable position if the platform experiences financial difficulty, is acquired by an unsympathetic buyer, or has its regulatory authorisation restricted. Designing for portability — including maintaining data in portable formats and understanding migration timelines — is as important as the initial platform selection.