What Is Banking-as-a-Service (BaaS)? Platforms, Players, and Risks Explained

The pitch was elegant: any software company could become a bank in weeks, not decades. No charter, no regulator knocking on the door, no core banking system to procure. Just call an API, pass some KYC checks, and you were issuing cards and holding deposits. Banking-as-a-Service turned the most heavily regulated industry in finance into something that, from the outside, looked like a developer integration. The irony arrived in April 2024 when Synapse Financial Technologies, one of the most prominent middleware providers in the American BaaS stack, filed for Chapter 11. The CFPB later described a shortfall estimated at between $60 million and $90 million, while customers of apps built on Synapse's infrastructure lost access to money for weeks or months. Building a bank turned out to be easy. Making it safe was something else entirely.

What BaaS Actually Is: The Three-Layer Stack

Banking-as-a-Service is not a product. It is an architecture: a set of contractual and technical relationships that allow a non-bank business to offer bank-grade financial products to its own customers.

The stack has three layers, and conflating them is where most confusion begins.

The chartered bank sits at the regulated deposit-taking layer. In the United States, eligible deposits at an FDIC-insured bank may qualify for deposit insurance, including pass-through coverage only where the legal and recordkeeping conditions are satisfied. The UK has a different framework under the FSCS. The bank accepts deposits, provides regulated account infrastructure and retains responsibility for complying with the laws that apply to the bank; contracts with technology providers do not transfer that responsibility.

The middleware platform sits above the bank. This is what most people mean when they say "BaaS provider." Platforms like Stripe Treasury, Unit, Synctera, Treasury Prime, and Marqeta (for card issuance specifically) provide the developer-facing APIs, the compliance tooling, the KYC and KYB orchestration workflows, and, critically, the reconciliation infrastructure that keeps track of who holds what across every customer account. The middleware layer is the translation layer: it abstracts the bank's legacy systems and regulatory complexity into something a software team can integrate in a sprint cycle.

The software business (the BaaS customer, fintech or brand) builds the customer-facing product. It may be unregulated, separately licensed for some activities, or acting under contractual arrangements with regulated entities; there is no universal status. It depends on the lower layers for account and payment capabilities while retaining its own contractual, consumer-protection, data and operational responsibilities.

The critical thing to understand is which legal entity provides each service. A technology platform is not made a bank by marketing itself as BaaS, but some groups include licensed entities and some platforms themselves hold payment or e-money permissions. The contract, licence registers and account terms, not the brand label, determine the regulated provider and protections.

For a deeper look at what software companies are building on this infrastructure, see our coverage of B2B embedded finance and where the revenue is actually accruing.

What Each Layer Does in Practice

The chartered bank does more than hold a licence. It maintains deposit and settlement records, handles payment-network relationships where applicable, and files regulatory reports. It remains responsible for its Bank Secrecy Act and anti-money-laundering compliance even when service providers perform operational tasks. The federal banking agencies' interagency third-party risk guidance^[1] explicitly says using a third party does not diminish or remove a bank's responsibility to comply with law.

The middleware platform's job is operationally dense. It handles API design and versioning; webhook infrastructure so fintechs can react to real-time events like card authorisations and ACH settlements; KYC and KYB orchestration (typically aggregating identity verification providers like Alloy, Persona, or Socure behind a single interface); compliance rule configuration; and reconciliation. That last item, reconciliation, proved to be the fault line. In a well-functioning BaaS stack, every dollar that passes through the middleware platform is tracked at the sub-account level, with the middleware maintaining a shadow ledger that matches the chartered bank's master ledger. When that matching breaks down, the consequences are severe.

Card-specific infrastructure sits partly in this layer. Marqeta, for instance, is a card issuing platform rather than a full BaaS suite: it connects to Mastercard and Visa's networks, issues virtual and physical cards, and processes authorisations in real time, but it pairs with bank partners and sometimes other BaaS layers for deposit accounts. The card economics are distinct from the deposit economics, and understanding which providers operate in which part of the stack matters when building a product.

The software business at the top layer is responsible for its own user experience, its own customer support, and increasingly, following regulatory guidance, for understanding the full chain of its banking relationships. A fintech cannot simply outsource awareness of its underlying bank to its middleware provider. If the middleware fails, the fintech's customers are the ones who cannot access their funds.

Why Small Banks Dominate the US BaaS Market

The most striking feature of the American BaaS ecosystem is who the chartered bank partners tend to be. The BaaS market is not built on JPMorgan Chase or Bank of America. It is built on Evolve Bank & Trust (West Memphis, Arkansas-chartered, with total assets of about $1.81 billion at 31 December 2024^[2], the peak in the cited FDIC Call Report series), Cross River Bank (Fort Lee, New Jersey), Coastal Community Bank (Everett, Washington), and a collection of similarly sized community banks that most consumers have never encountered.

The Durbin Amendment is one economic factor. Regulation II's debit-interchange standards apply to covered issuers, while qualifying smaller issuers are exempt from the cap. Exemption does not guarantee a particular interchange rate, and BaaS partnerships are also shaped by sponsor-bank strategy, risk appetite, technology and customer-acquisition economics. It is therefore too strong to describe the market structure as the direct consequence of one rule.

Interchange revenue is the economic engine that makes BaaS unit economics work. A neobank issuing debit cards through a large bank earns capped interchange, which at consumer spend volumes rarely covers the cost of customer acquisition, customer support, and platform fees. The same neobank issuing through a sub-$10 billion community bank earns uncapped interchange, which can be meaningful at scale. The business model depends on the regulatory carve-out. This is why the BaaS ecosystem in the United States is structurally dependent on small banks that most of their customers' customers have never heard of, and why the risk is concentrated in institutions with less capacity to absorb operational or compliance failures.

The Synapse Collapse and What It Revealed

Synapse Financial Technologies was, for several years, one of the more prominent middleware providers in the US BaaS market. It connected a collection of partner banks, including Evolve Bank & Trust, American Bank, AMG National Trust, and Lineage Bank, to dozens of fintech apps including Yotta (a savings product with lottery-style prizes), Juno (a crypto-linked neobank), and others. At its peak, Synapse processed billions of dollars in transaction volume across millions of accounts.

In April 2024, Synapse filed for Chapter 11 bankruptcy protection. What followed exposed the structural fragility at the centre of the three-layer stack.

The core problem was reconciliation. Synapse maintained the sub-account ledger: the record of which customer's money was held at which partner bank in what amount. When Synapse collapsed, the reconciliation records became disputed. The partner banks each had records of total deposits held against Synapse, but not necessarily the granular customer-level allocation. Synapse had that granular allocation, and its records were inaccessible or unreliable. The CFPB later put the estimated aggregate shortfall between the banks' records and Synapse's records at $60 million to $90 million, with the gap proving impossible to close quickly.

Customers of apps built on Synapse lost access to funds, in some cases for months. FDIC deposit insurance is triggered by the failure of an insured depository institution, and the partner banks had not failed, so the Synapse bankruptcy was not itself an insured-bank failure. Separately, pass-through coverage depends on satisfying ownership and recordkeeping requirements. The episode showed why clear account terms, accessible records and bank-controlled reconciliation matter even when a deposit may be eligible for insurance against a bank failure.

The Synapse case illustrated a risk that had been hypothetical until that point: the middleware layer could fail independently of the chartered bank, and that failure could strand customer funds even when the banks themselves remained solvent. Regulators took note. The OCC, FDIC, and Federal Reserve subsequently increased scrutiny of "pass-through" deposit arrangements and third-party risk management at the banks involved.

The EU and UK Parallel: EMI Licences

In Europe and the United Kingdom, the structural picture is similar but the regulatory framework differs. The equivalent of the BaaS chartered bank relationship is often built around an Electronic Money Institution (EMI) licence rather than a full banking licence.

In the UK, an EMI is authorised to issue electronic money and may provide payment services, but money received in exchange for electronic money is not a bank deposit and does not receive bank-deposit protection merely because it sits behind an account-like interface. The credit restriction is narrower than a general ban on balance-sheet lending: regulation 32 of the Electronic Money Regulations 2011^[3] permits credit in connection with specified payment services subject to conditions, including that it is not granted from funds received in exchange for electronic money and held under the safeguarding requirement. The exact permissions and funding therefore have to be checked for the entity and product.

Relevant customer funds are protected through safeguarding rather than deposit insurance. Depending on the applicable route, the framework includes segregation and secure low-risk assets or an insurance or comparable guarantee method. Since 7 May 2026, in-scope UK payment and e-money firms must also follow the FCA's Supplementary Regime, including applicable rules in CASS 15 and related reporting, audit, record and resolution-pack requirements^[4]. That scope follows the regulated entity and activity; a company is not subject to every requirement merely because it is described as a BaaS provider.

European and UK providers use a mix of bank, electronic-money and payment-institution permissions, sometimes across several group entities. The EU and UK frameworks should not be collapsed into one set of rules, and provider or product availability changes. Buyers should verify the exact contracting entity, permission, safeguarding method and customer terms in the relevant jurisdiction. Safeguarding is not deposit insurance and does not promise the same statutory payout process or limit as a deposit-guarantee scheme.

This matters for businesses building on BaaS in Europe: the question is not just "is this provider regulated?" but "what is the precise nature of the regulatory protection it offers, and how does that translate into customer-level risk in a failure scenario?"

How to Choose a BaaS Provider

Four questions cut through the marketing and go to the actual risk structure of any BaaS relationship.

Does the provider own the bank relationship, or is it a chain of intermediaries? Some middleware platforms have direct, exclusive relationships with one or two partner banks. Others aggregate access across multiple banks or sub-contract through other middleware providers, creating a chain of four or five entities between the software business and the chartered bank. Every additional link in that chain is an additional point of failure, and another entity that needs to be assessed for operational and financial resilience.

How does reconciliation work, and who owns it? This is the Synapse question. Ask any prospective BaaS provider how sub-account balances are maintained, how frequently they are reconciled against the bank's master ledger, and what happens to those records in the event of the provider's insolvency. If the answer is vague or deferred to the bank, that is a structural warning sign. The reconciliation architecture is not a technical detail: it is the core safety property of the entire arrangement.

What is the provider's regulatory track record? Evolve Bank & Trust, one of the major BaaS-aligned community banks in the US, received a cease-and-desist order from the Federal Reserve in June 2024 relating to its fintech partnership risk management and BSA/AML programme. The order was contemporaneous with the Synapse collapse but addressed broader weaknesses in how the bank oversaw its fintech relationships, not solely the Synapse situation. Regulatory actions against partner banks or middleware providers are public and searchable. Check the OCC enforcement actions database, the FDIC's enforcement decisions, and equivalent FCA and PRA registers in the UK before committing.

Do the unit economics work at your projected volume? BaaS providers typically charge a platform fee (monthly or per-account), pass-through transaction fees from the partner bank, and in some cases take a share of interchange. The interchange split (how much of the uncapped debit interchange actually flows to the software business versus the middleware and the bank) varies significantly. Modelling the unit economics at low, medium, and high volume scenarios before signing is not optional; the margin difference between providers at scale can be several basis points per transaction, which at millions of transactions per month is the difference between a profitable product and a loss-making one.

BaaS is distinct from building on cloud-native core banking infrastructure: BaaS abstracts the bank relationship entirely, whereas core banking migration involves the bank itself modernising its own systems. The two paths serve different builders.

For software businesses evaluating BaaS, the compliance layer, specifically KYC, KYB, and AML, deserves particular scrutiny. BaaS providers vary in how much of this they genuinely handle versus how much they configure and delegate back to the fintech. Understand exactly where your compliance obligations begin.

Where BaaS Is Heading

The regulatory direction is clear: fewer intermediaries, stronger contracts, and explicit audit rights at every layer of the stack.

The Federal Reserve, FDIC and OCC issued joint third-party risk-management guidance in June 2023. It sets a risk-based lifecycle covering planning, due diligence, contract negotiation, ongoing monitoring and termination. The agencies later issued a joint statement on third-party deposit arrangements^[5], highlighting operational, compliance, funding and consumer risks. These publications do not ban BaaS; they make clear that the bank must understand and control the arrangement.

In the UK, the FCA's Supplementary Regime has added rules and reporting around safeguarding audits, reconciliations, records, third parties, resolution packs and monthly returns for firms within scope. That is a concrete change rather than a general statement that every layer of a BaaS chain is regulated in the same way. Buyers still need to map which entity performs each activity and which rules attach to it.

For builders, this means BaaS is not getting simpler. The abstraction layer is becoming more contractually complex even as the APIs remain developer-friendly. Providers that can demonstrate genuine control over their reconciliation infrastructure, thorough audit trails, and regulatory relationships built on transparency, rather than structural opacity, will be better positioned than those whose model depended on light-touch oversight of the middleware layer.

BaaS worked. It built an enormous amount of fintech infrastructure that would not otherwise exist. The question going forward is not whether the model survives (it will) but which providers have built the middle layer with sufficient rigour to survive the scrutiny that the Synapse collapse made inevitable.

Sources and methodology: The control framework was checked against the federal banking agencies' third-party guidance and deposit-arrangements statement, plus the FDIC third-party risk examination manual^[6]. Synapse figures and allegations were checked against the CFPB's public enforcement action^[7]. Provider names illustrate layers, not current availability or endorsement; licences and account protections must be verified for the contracting entity.