Banking as a Service (BaaS)

Banking as a Service is the model in which a chartered bank makes its regulated capabilities available to non-bank companies, so a fintech can offer accounts, cards or payments without holding a charter itself. The bank supplies the license, the deposit insurance and the rail access. It also keeps the regulatory obligations — and the last three years have been a demonstration of what that means in practice.

Why the model strains

The appeal is real on both sides. A charter is slow and expensive to obtain, so a fintech reaches market far faster by renting access to one; the bank gains deposits and fee income it could not originate through its own branches.

The strain is structural. The obligation and the operation sit in different places. The bank is accountable for a Customer Identification Program that the fintech actually runs, for transaction monitoring on activity the fintech sees first, and for records the fintech holds.

Where a middleware platform sits between them, a third party holds the ledger reconciling which end customer owns what — and the bank may not hold that view independently at all.

That arrangement works when the bank has genuine visibility. It fails when the bank has a contract instead, and supervisory attention has landed precisely on the difference.

What the last three years established

Two things reset expectations for this model, and the specifics are worth stating rather than gesturing at.

The enforcement wave. Consent orders ran through 2024 and 2025 across the FDIC, OCC and Federal Reserve, with BSA/AML program deficiencies and third-party oversight the recurring themes. Evolve Bank & Trust received a Federal Reserve cease-and-desist in June 2024 citing weak AML and BSA programs, OFAC-related deficiencies and ineffective oversight of fintech partnerships.

The Synapse collapse. The middleware provider filed for bankruptcy in April 2024, and when access to its systems was cut the following month roughly $265 million of end-customer deposits became inaccessible across several partner banks — because the records reconciling ownership sat with the intermediary rather than with the institutions holding the money.

The expectation that emerged from both is concrete: a sponsoring bank should have current visibility into each partner’s compliance performance, and should be able to produce a complete, accurate customer file on request. Not eventually, and not by asking the fintech.

Why this matters for identity verification

Every one of those expectations resolves to what was captured at onboarding, by the fintech, on the bank’s behalf.

A bank asked to evidence how a customer’s identity was established needs a better answer than “our partner ran a check.” It needs to know which document was presented, whether it was authenticated rather than merely read, whether a biometric bound it to the person, and where that evidence is held. Where the partner accepted a photograph and a database name match, the bank inherits that weakness and answers for it.

Two consequences follow for anyone operating this model. Verification standards have to be consistent across every partner program, because the bank’s examination covers all of them and the weakest sets the finding. And the evidence has to be retrievable by the bank, not merely retained by the fintech — which is the lesson of the reconciliation failure applied to identity records.

That makes identity document verification a third-party risk control here rather than only a fraud control, and KYC and AML obligations sit with the charter wherever the work happens. Command Center visibility across programs is what turns a contractual assurance into an observable one.

What the model can’t do

It cannot transfer regulatory accountability. Contracts allocate commercial responsibility between the parties; they do not move the supervisory obligation off the charter.

It does not make the fintech supervised. Regulators examine the bank, so a partner’s weaknesses appear as the bank’s findings.

Indemnities are not controls. A promise to cover losses does not prevent a consent order and is worth only what the counterparty is worth.

Deposit insurance does not guarantee access. Where reconciliation records sit with an intermediary, a failure upstream can strand funds regardless of insurance.

Frequently asked questions

What is Banking as a Service?

A model in which a chartered bank makes its regulated capabilities available to non-bank companies, so a fintech can offer accounts, cards or payments without holding a charter. The bank supplies the license, deposit insurance and payment rail access, and retains the regulatory obligations.

Who is responsible for compliance in a BaaS arrangement?

The chartered bank, regardless of how the partnership agreement allocates the work. Execution of customer identification, monitoring and screening can be delegated to the fintech, but supervisory accountability stays with the charter holder, who is the party regulators examine.

What is the difference between BaaS and a sponsor bank?

Banking as a Service is the model; the sponsor bank is the institution playing the chartered role in a specific partnership. The terms are often used interchangeably, but one describes the arrangement and the other a party to it.

Why did BaaS attract so much supervisory attention?

Because the model separates obligation from operation. Banks were accountable for programs their fintech partners actually ran, and where oversight amounted to contractual assurance rather than genuine visibility, examiners found BSA/AML deficiencies. The Synapse collapse then showed the same weakness in reconciliation records.

Related reading

• Sponsor bank — the institution playing the chartered role
• Customer Identification Program — the obligation the bank answers for and the fintech performs
• AML audit — the independent testing that examines whether oversight is real
• Compliance — why an unevidenced control is treated as an absent one