What Banking as a Service Actually Means

Banking as a Service has been a buzzword for a few years now, but the mechanics of how it actually works are often misunderstood. People use "BaaS" and "embedded banking" interchangeably. They are not the same thing, and the distinction matters.

When I first tried to pin down how BaaS actually works, what helped was realizing it is a stack of three layers that are easy to conflate but carry very different weight.

The Three Layers

What took me a moment to absorb is that the actual bank sits at the bottom, mostly out of sight. It is a chartered, FDIC-insured institution that holds the licenses, files the regulatory reports, and carries the compliance responsibility. Without it there is no bank product, just a ledger entry dressed up as one. That bottom layer is where all the accountability lives, which turns out to be the whole story once something breaks.

The middle is where the cleverness is, and where my attention kept getting pulled. Companies like Synapse, Unit, and Treasury Prime sit between the bank and the fintech, building the APIs and handling the ledgering and payment processing so a fintech can launch without standing up the plumbing itself. It is genuinely useful infrastructure. It is also the layer that quietly holds the most, because the record of who owns what often lives here rather than at the bank.

The top is the only part anyone sees. The fintech, a Chime or a Mercury or a Current, builds the experience, acquires the clients, and defines the product. Most clients have no idea which bank is underneath, and do not need to. That invisibility is the point of the model, and also where the risk hides.

Put the three together and a fintech can offer banking products without a charter. It also gets complicated fast. Who owns the client relationship? Who answers when something goes wrong? Those questions get harder the more layers you stack between the bank and the client.

BaaS vs. Embedded Banking

The distinction I see people miss most is between BaaS and embedded banking. BaaS is the infrastructure that lets non-banks offer banking products. Embedded banking is what you get when financial services show up inside something that isn't a financial product at all.

A ride-sharing app offering its drivers a debit card is embedded banking. An e-commerce platform letting sellers tap their funds instantly is embedded banking. The banking lives inside a non-banking experience. BaaS is what makes that possible. It is the pipes, not the faucet. You can have BaaS without embedded banking, since a standalone neobank still runs on BaaS underneath, but you cannot have embedded banking without some form of BaaS beneath it.

Where the Responsibilities Sit

This is where it gets serious from a banking seat. The interagency guidance on third-party risk management is blunt that a bank cannot outsource accountability. Even when a middleware provider runs the APIs and a fintech owns the client, the bank is still answerable for BSA/AML compliance, consumer protection, and fair lending. The charter comes with obligations, and partnering with a technology company does not transfer them.

Regulators have been paying close attention here, and I read that attention as part of what keeps the system healthy. The pattern in the public record is consistent. When a bank's BaaS partnerships grow faster than its compliance discipline can scale, regulators step in to bring the program back into alignment. That is the system working as intended.

For a community bank, that reframes the whole math. The revenue is real, but so is the oversight burden, and the two do not scale at the same rate. You cannot just plug into a middleware provider and collect fees. You have to actively manage the relationship, watch the fintech's activity, and stay in close contact with examiners as the program grows.

What This Means

I think BaaS is here to stay. The model works, and client demand for better digital banking is not going away. But the easy phase is over. The boundaries are clearer than they were, and the banks that do well in this space will be the ones that treat these partnerships as serious operational commitments, not revenue lines.

For most community banks, the real question is whether the scale and infrastructure to carry that commitment is there yet. Often it is not, and that is not a failure. Deciding not to take on a substantial program is a perfectly reasonable strategic answer.