Banking as a Service: How the Stack Works and the Cost

Banking as a service is the practice of a licensed bank exposing its regulated capabilities, accounts, payments, and card issuing, as APIs that a software product can consume without holding a charter of its own. You call an endpoint to open an account, another to issue a card, another to move money, and a stack of parties beneath you turns that call into a real transaction on the banking and card networks. The bank keeps the license. Your product keeps the customer. That split is the whole model, and it is why a payroll tool, a logistics platform, or a vertical SaaS product can suddenly hold balances and issue cards.

This guide is written from the builder's chair. Most explanations of BaaS are produced by the vendors selling it, so they stop at the layer where the sales pitch lives. We go a level down, into the stack an engineer actually integrates against: the sponsor bank, the BIN sponsor, the provider middleware, the ledger, and the boundary where the provider stops and your code starts. We also cover the part nobody enjoys writing about, which is what happens to your build when a provider fails, because one just did.

What banking as a service is, and where it sits in the stack

Banking as a service is a delivery model where a chartered bank packages its regulated functions, holding deposits, moving money across rails, issuing cards, as developer-facing APIs that non-bank software consumes. The defining property is the separation of license from product. The bank carries the regulatory weight: deposit insurance eligibility, the relationship with examiners, the obligations under banking law. The software product carries the experience: the screens, the onboarding, the support, the brand the customer trusts.

Place it in the stack and the picture sharpens. At the bottom is a licensed bank. Above it sits a BaaS provider, a technology company that translates the bank's slow, batch-oriented core into clean modern APIs and adds the ledger and compliance tooling that the bank requires. On top of the provider sits your application, which never touches the bank's core directly. When a user taps a button in your product, the request travels down through the provider to the bank to the network, and the confirmation travels back up. The user sees one screen. Three or four regulated and unregulated parties did the work, each owning a precise slice of it. Knowing which party owns which slice is the difference between a system that survives an audit and a provider failure, and one that does not.

Banking as a service vs embedded finance vs open banking, in one minute

Banking as a service, embedded finance, and open banking describe different layers, and treating them as synonyms produces bad architecture. The one-line version: BaaS is the infrastructure, embedded finance is the experience built on it, and open banking is a data-sharing framework that sits beside both.

The practical relationship is a stack, not a contest. You almost always sit on BaaS to ship embedded finance, and you might use open banking to read a customer's existing accounts inside that flow. We unpack the embedded-finance layer in depth in our embedded finance guide; here we go a level down, into the infrastructure that powers it.

How a BaaS stack is wired: sponsor bank, BIN sponsor, provider, and your app

A BaaS stack is wired as a chain of responsibilities, each connected by an API boundary: a sponsor bank holds the license at the base, a BIN sponsor enables card issuance, a provider or middleware exposes the API layer and runs the ledger and compliance tooling, and your app sits on top consuming it all. Money and instructions flow down the chain. Confirmations and webhooks flow back up. The art of building well here is respecting each boundary instead of reaching across it.

Start at the foundation. The sponsor bank is the chartered institution that legally holds customer deposits, settles on payment rails, and answers to regulators. It is the only party in the chain that can actually hold the money. Card issuance brings in a second role, the BIN sponsor, the entity that owns the bank identification number range under a card network like Visa or Mastercard and lets cards be issued against it. Sometimes the sponsor bank is also the BIN sponsor; sometimes they are separate, and that separation matters when you trace where a card program's risk really lives.

Above the bank sits the BaaS provider, the middleware that does the heavy lifting your team would otherwise build from scratch. It exposes the APIs you call, runs the ledger that records every balance and movement, and operates the compliance tooling, the KYC engine, the screening, the reporting, that the bank requires of every program on its rails. On top sits your app: the product, the user experience, and the integration code that speaks to the provider. The cleaner you keep that top boundary, the easier it is to swap providers later or absorb a function in-house. Figure 1 lays out the layers and the boundary between each.

What the provider gives you versus what you build on top

The split between provider and product is the most important architectural line in a BaaS build: the provider gives you the regulated core, and you build everything that makes the product yours. Almost nobody should write their own ledger, card-issuing platform, or KYC engine, and fewer still should chase their own banking license early. What you do build is the experience and the integration logic, and that turns out to be a substantial system in its own right.

On the provider side of the line sit the core ledger that tracks balances, the KYC and onboarding engine that verifies identity, card issuing that mints virtual and physical cards, and the connections to payment rails that actually settle money. On your side sit the user interface, a product sub-ledger that maps the provider's accounts to your own users and internal logic, reconciliation that proves your records and the provider's agree, idempotent payment calls so a retried request never moves money twice, webhook handling that absorbs the asynchronous truth of the financial world, and the fraud and limit rules specific to how your product is abused. Figure 2 draws the line capability by capability.

The ledger and reconciliation problem

The ledger problem is the question of who holds the authoritative record of every customer's balance, and reconciliation is the daily discipline of proving every record agrees. In a BaaS build there are at least two ledgers in play: the provider's, which the sponsor bank settles against, and your own product sub-ledger, which maps those balances onto your users and your features. They must agree to the cent, every day, or money is quietly going missing somewhere in the chain.

The structure underneath usually involves an FBO account, a "for benefit of" account the sponsor bank holds that pools customer funds, with the provider's ledger tracking each end user's share inside it. Your sub-ledger mirrors those shares. A reconciliation job compares the two and flags any drift the moment it appears, because drift that goes unnoticed is how a customer ends up unable to withdraw money that the system insists is there. Idempotency keys on every money movement keep a retried request from double-posting and corrupting the very records you are trying to reconcile.

This is exactly where the Synapse collapse turned abstract risk into a concrete disaster. When that provider failed in 2024, the records it kept and the records the partner banks kept did not line up, and reconstructing who was owed what became enormously difficult. End users of products built on the rails lost access to their funds while the ledgers were untangled. The lesson for anyone building now is blunt: your reconciliation is what protects your users when a layer beneath you breaks, so it deserves the same rigor as the money movement itself. The Federal regulators' response leaned directly on this point, pressing banks to keep accurate, independent records of the funds underlying these programs.

Choosing a BaaS provider as an engineering decision

Choosing a BaaS provider is an engineering decision before it is a commercial one, because the provider you pick becomes load-bearing infrastructure you cannot cheaply replace. A provider whose APIs are immature, whose webhooks drop events, or whose sponsor bank cannot support the product you need becomes a wall you hit a year in, after your money already flows through it. The evaluation that matters runs on technical and structural questions, not on the marketing site.

Work through these in discovery:

• API and sandbox quality. Are the APIs documented, versioned, and stable, with a sandbox that behaves like production and webhooks you can actually test against? You will live inside this integration for years.
• Webhook reliability. Does the provider deliver events durably, with retries, signatures, and a way to replay missed events? Your ledger correctness depends on never silently losing one.
• Which banks the provider sponsors. Which licensed bank or banks stand behind the provider, and what does each one's program permit? The bank is the real boundary on what you can offer, and single-bank dependence is a concentration risk.
• License type. Does the provider rely on a sponsor bank, or does it hold its own banking or electronic-money (EMI) license? An EMI can issue accounts and cards but cannot do everything a full bank can, and that distinction shapes your product ceiling.
• Data portability and exit risk. Can you export your ledger, customer, and transaction data in a usable form, and how hard is it to move to another provider or bring a function in-house? Plan the exit before you sign.

Provider archetypes are worth naming so the categories are concrete. In the US market, companies such as Unit, Treasury Prime, and Synctera operate as middleware that connects products to sponsor banks. In Europe, Solaris runs as a licensed institution itself, and ClearBank operates as a clearing bank with API access. These are archetypes of how providers are structured, not a ranking and not a recommendation; the right choice depends entirely on your product, your geography, and the licensed entity you are comfortable standing behind your money.

The 2023-2024 BaaS reckoning: what Synapse and the FDIC actions mean if you build now

The 2023 to 2024 period was a reckoning for banking as a service, when a high-profile provider failure and a coordinated regulatory response reset what "build on a provider" actually demands of you. The headline event was the collapse of the BaaS provider Synapse in 2024, which froze funds for end users of products built on its rails and exposed how fragile the model becomes when ledgers are not independently verifiable and responsibilities are not clearly owned.

US regulators answered directly. In July 2024, the Federal Reserve, the FDIC, and the OCC issued a joint statement on arrangements between banks and third parties that deliver bank products and services, the bank-fintech arrangements at the heart of BaaS. The agencies flagged risks in these partnerships and pointed to stronger expectations on oversight, record-keeping, and the management of funds held for end users. You can read the agencies' position through the FDIC, and the practical message for a builder is consistent across all three.

Three operational takeaways follow for anyone building now. First, provider due diligence is no longer optional polish; you need to understand the provider's financial health, its bank relationships, and how it keeps its ledger, because its failure is now a modeled risk in your own system. Second, be precise about who really owns compliance, since the regulators made clear that a bank cannot outsource its responsibility for the program even when a provider runs the tooling. Third, treat sponsor-bank concentration as a real exposure: a program riding on a single bank inherits that bank's regulatory troubles, and several banks pulled back from BaaS in this window. None of this kills the model. It raises the bar, and the products that clear it are the ones that built proper reconciliation and clear ownership from the first commit.

The teams that survive a provider failure are the ones that treated their own ledger and reconciliation as the product, not as plumbing. When a layer beneath you breaks, your records are the only thing standing between your users and their money.

Who owns compliance, and the parts you cannot outsource

Compliance ownership in banking as a service is layered, and the single most expensive mistake is assuming the provider absorbs all of it. The regulatory relationship belongs to the sponsor bank. The bank owns its obligations under the Bank Secrecy Act and anti-money-laundering law, and a 2024 interagency statement from US regulators made explicit that a bank stays responsible for those obligations even when a third party operates the controls. The provider runs much of the tooling. You, the product, feed the controls and own the parts that touch your users directly.

Map it to the concrete controls. BSA, AML, and sanctions screening are the bank's regulatory duty, operated through the provider's engine, but they only work if your product collects the right data and integrates the screening into your flows. KYC and KYB, verifying individual and business identity, gate who can hold an account or a card, and while the provider supplies the engine, the onboarding experience and the data quality are yours to get right. We cover that build in detail in our KYC software guide. The parts you genuinely cannot outsource are the ones bolted to your own product: accurate identity data at onboarding, correct surfacing of disclosures, your fraud and transaction-monitoring signals, and the reconciliation that proves the money is where your records say it is.

Operational resilience is the other half of compliance that builders underestimate, and in Europe it is now law. The EU's Digital Operational Resilience Act (DORA) sets requirements for how financial entities and their critical technology providers manage operational and cyber risk, including incident reporting and third-party risk management. The European Banking Authority is among the bodies shaping its technical standards. If your BaaS build touches the EU, your provider relationship falls squarely inside the kind of third-party dependency DORA expects you to manage deliberately. Messaging standards like ISO 20022 add structure to the payment data moving through these rails, which matters once you are reconciling and reporting at volume.

What banking as a service costs to build on

The cost of building on banking as a service has two distinct sides that teams routinely conflate: what the provider charges you to use the rails, and what it costs you to build and run the product on top. Both scale with how much of the stack you take on, so the only honest framing is drivers and scope tiers, not a single number. The provider side is a recurring bill tied to usage. The build side is engineering plus the standing cost of a compliance function, which is the line most teams underestimate by the widest margin.

On the provider side, expect a setup or platform fee to get a program live, per-account and per-transaction pricing as the recurring usage cost, often a monthly minimum that bites before you reach scale, and an interchange share, the cut of card-network fees a card program returns to you, which can offset cost as spend grows. Minimums and setup fees are what make the lightest tier still nontrivial for an early product. Figure 3 breaks the components down by who charges and what drives each one.

The market context tells you the model is mainstream rather than experimental. Market-research estimates put the global banking-as-a-service market at roughly $30 billion in 2025 and growing at a double-digit annual rate, though these figures vary widely by methodology and should be read as direction, not precision. The takeaway for a builder is not the number itself but what it implies: provider economics are competitive, and the durable cost is operational. Start at the lightest tier that delivers real value, prove the flow, and climb only when volume or strategy genuinely demands it. For the broader mechanics of pricing a build at this depth, a scoped discovery with the custom software development team is how an estimate gets made, and platforms shipping this as a SaaS product tend to start small and grow into more of the stack as volume justifies it. The fintech practice is where we scope these programs end to end.

Where BaaS fits: real build patterns and use cases

Banking as a service fits anywhere a software product wants to hold balances, move money, or issue cards without becoming a bank, and the patterns repeat across very different products. The common move is the same: a non-bank product adds a financial capability at the point where its users were already about to transact, and a licensed bank runs the money underneath through a provider. Four patterns cover most of what gets built.

Embedded accounts inside a SaaS product let a vertical platform give its business customers a real account to receive and hold funds, turning the software into the place money lives rather than just passes through. Marketplace payouts use the rails to pay thousands of independent sellers or contractors, often pairing a held balance with a debit card so recipients can spend earnings directly. Expense and corporate cards issue branded cards against a funded account, with spend controls and a sub-ledger tracking every authorization. And a neobank MVP stacks accounts, cards, and payments into a single consumer product, which is the most ambitious pattern because it leans on nearly every part of the stack at once.

We have built across this range. Fese is our clearest example of building on banking rails: a neobank that runs accounts, loan applications, and budgeting in one product, on banking infrastructure, with the licensed bank holding the charter while we built the product, the integration, and the controls. C-Bank is a mobile banking app we built, a focused consumer money product with instant payments, loans, and transaction reporting. In both, the division of labor was the one this whole guide describes. The sponsor bank held the license and the regulatory relationship. We built the experience, wired the integration, fed the controls, and owned the reconciliation. That is the realistic shape of a BaaS engagement, and it is worth being precise about it: Idealogic builds the product and the integration, never the bank. The closer you map that boundary before you start, whether through payment gateway integration or a full banking program, the cleaner the build.