Banking as a Service Explained: Why the Compliance and Ledger Burden Doesn’t Sit Where Brands Expect
Banking as a service is an arrangement in which a licensed bank makes its regulated capabilities, deposit accounts, card issuing, and payments available to a non-bank brand through APIs, so the brand can offer financial products without holding a charter itself. The appeal is obvious on both sides. The brand gets a revenue line and a reason for customers to stay inside its product. The bank gets deposits and interchange without building a consumer acquisition function. What neither side tends to price correctly at the outset is who holds the ledger, who reconciles it, and who answers to a regulator when the two disagree. That question has moved from a contract detail to the center of the model.
Key Highlights:
- Brands treat banking as a service as a straightforward integration project, budgeting for APIs and card issuance rather than for what a sponsor bank actually requires.
- The gap surfaces late: ledger reconciliation, audit-trail requirements, and compliance obligations they had assumed sat with the bank turn out to be theirs to build and defend.
- Establish ledger ownership and reconciliation cadence before selecting a sponsor bank, and design the audit trail to answer a regulator’s question rather than an internal one — the result is a program that survives sponsor bank examination and can add a second bank later without rebuilding the ledger.
- Sigma engineers on both sides of this stack, from core and sponsor bank API integration through customer-facing onboarding, and treats reconciliation design as the first deliverable rather than a later phase..
What Is Banking as a Service?
Banking as a service separates the regulated function from the customer relationship. Three parties are involved, and confusion about which one carries which obligation is the source of most program failures.
Table 1: Who does what in a BaaS stack
| Layer | Responsible for | Its binding constraint |
| Sponsor bank | Holds the charter and the deposits; regulatory compliance, deposit insurance eligibility, oversight of partners | Its examiner holds it accountable for activity under its charter regardless of who performed it |
| Platform or program manager | APIs, the ledger, reconciliation processes, and often compliance tooling | Sits between two parties with different risk tolerances and no direct relationship with each other’s regulators |
| Brand | The customer, the interface, product design, and frequently KYC data collection at onboarding | Inherits obligations it did not write and cannot renegotiate mid-program |
The important line in that table is the sponsor bank’s constraint. An examiner does not distinguish between work the bank performed and work its partner performed under its charter. That single fact explains why sponsor bank diligence is heavier than brands expect, and why it has grown heavier since 2024.
How Is BaaS Different From Open Banking and Embedded Finance?
The three terms overlap and are not interchangeable. Banking as a service is about a brand using a bank’s license to offer regulated products. Open banking is about permissioned access to data held at a bank, so a third party can read account information or initiate a payment without offering a banking product of its own. Embedded finance is the commercial outcome rather than the mechanism: a financial product presented inside a non-financial experience, which may be delivered through banking as a service, through a lending partnership, or through open banking rails.
A practical way to separate them is to ask where the customer’s money sits. Under banking as a service, it sits at the sponsor bank, in an account structure the brand does not control. Under open banking, it stays where it already was. Under embedded finance, the answer depends entirely on which underlying mechanism was used, which is why the term is useful commercially and useless architecturally.
Where Does the Compliance Burden Actually Sit?
On paper, the sponsor bank owns this. In practice, the platform and the brand are the ones doing the work. That mismatch is exactly what regulators have spent the last couple of years trying to fix.
The wake-up call came from a real failure. A middleware provider that let fintechs plug banking services into their apps collapsed in 2024. Under that setup, the fintechs had built the interfaces and kept their own ledgers tracking what each customer was owed. When one of the partner banks froze the deposits sitting with it, customers couldn’t get to their money — because the records showing whose money it actually was lived outside the bank entirely.
Regulators took notice. A federal banking regulator proposed new rules requiring banks holding pooled custodial accounts to keep clear, accurate records of who owns what within those accounts, down to the individual balance. Under the proposal, a bank’s most senior leadership would have to personally certify, every year, that this recordkeeping actually works — and report on it. The rule is still working its way through the comment process.
Two things matter here for anyone building a program. First, the rule itself isn’t final, so don’t design around the exact paperwork — design around the principle. Second, that principle isn’t going away no matter what happens to this specific rule: sponsor banks are going to keep asking for the ability to verify ownership themselves, rather than trusting that a partner’s ledger is complete and correct.
The Assumption That Breaks BaaS Programs, and What Replaces It
The assumption is that the sponsor bank owns the ledger. It usually does not. In most program structures the bank holds a pooled custodial account and the platform or brand maintains the sub-ledger recording individual balances. Teams discover this late, typically during sponsor bank diligence, and by then the ledger has been built as an application feature rather than as a system of record.
The distinction is not academic. A ledger built as an application feature updates balances. A ledger built as a system of record writes immutable entries so that any balance at any past moment can be reconstructed and explained. The first is simpler and works until someone asks what a customer’s balance was on a specific date and why. The second is the only version that survives an examination or a bankruptcy.
Sigma’s engagements in this space therefore start with reconciliation design rather than with API integration, and the sequence is deliberate. The first question is what the source of truth is for each balance type and what happens when the bank’s position and the platform’s sub-ledger disagree. Every program has breaks. What distinguishes a working program is whether breaks surface automatically with an aging report attached or whether they are found during a monthly close by someone comparing spreadsheets. Designing that exception path first constrains everything built afterward, which is why it cannot be retrofitted cheaply.
Read our success story: Scaling Loan Processing and Empowering Growth through MicroServices Architecture
The second workstream is sponsor bank API integration, and the constraint here is rarely technical difficulty. It is that bank APIs are frequently batch-oriented, where the brand’s product is real time, so the platform layer has to hold a consistent view across two systems operating on different clocks. The work Sigma does in this area is closely related to integration orchestration it has delivered outside BaaS specifically. In one engagement for a United States customer financing provider serving a network of more than 7,500 dealers, Sigma built and enhanced a dealer application portal requiring integrations across Transunion, Experian, Spectrum, FSSI, Rubex, Lyons Commercial Data, and multiple payment vendors, while executing a phased migration from a monolithic architecture to microservices without interrupting operations. The transferable part is the phased migration under live traffic, since a BaaS program that has launched cannot pause to re-architect.
Read how a dealer financing platform was migrated to microservices without interrupting operations.
The third workstream is onboarding and identity. Sigma’s BaaS and neobank enablement work covers API-based issuance of debit, credit, and virtual cards with spend controls and PCI-compliant payment rails integration, alongside KYC and anti-money laundering integration with automated identity verification, global watchlist and sanctions screening, and risk scoring on transactions. These are the components a sponsor bank asks about directly, and the answers it wants are evidentiary rather than descriptive.
Servicing is the part most programs underestimate. Accounts that are opened must be serviced, and servicing generates the disputes, adjustments, and corrections that stress a ledger far more than account opening does.
What stays with the bank throughout is the compliance program itself: risk appetite, the decision to accept a partner, and the supervisory relationship. Sigma builds the systems that produce the evidence those decisions require. Confusing the two is the most common source of misaligned scope in this category.
Should You Build or Partner?
The determining factor is whether financial services will be a product line or a feature. A brand adding a single card product to increase retention should partner with an established platform and accept its constraints.
A company whose economics depend on the financial product, where interchange or net interest income is a primary revenue line, will eventually need control of the ledger and should plan for that from the outset rather than migrating later under duress.
Conclusion
Banking as a service works by separating the regulated function from the customer relationship, with a sponsor bank holding the charter and deposits, a platform layer providing APIs and the ledger, and a brand owning the customer and the interface. Confusion about which party carries which obligation is the most common cause of program failure, and the sponsor bank’s constraint is the one that governs everything else, because its examiner does not distinguish between work the bank performed and work performed under its charter by someone else.
Open banking and embedded finance are related but distinct, and the clearest way to separate them is to ask where the customer’s money sits. A high-profile collapse in 2024 showed what happens when the records identifying whose money it is sit outside the bank holding the funds. A proposed recordkeeping rule that followed would require insured institutions to independently determine beneficial ownership and balances for pooled accounts. That proposal isn’t final, but the principle behind it is unlikely to reverse.
The practical consequence is that a ledger has to be built as a system of record with immutable entries rather than as an application feature that updates balances. Reconciliation design, including how breaks surface and age, should be the first deliverable rather than a later phase, because the exception path constrains everything built after it. Sponsor bank API integration, onboarding and identity, and servicing follow from that foundation.
The build-versus-partner decision turns on whether financial services will be a product line or a feature. Programs that answer these questions before selecting a sponsor bank tend to pass diligence, and programs that answer them afterward tend to rebuild.
Build the ledger right the first time — Choose Sigma’s financial software development services to launch a BaaS program built to pass diligence, not rebuild after it.
FAQs
What is banking as a service?
Banking as a service is an arrangement where a licensed bank makes regulated capabilities available to a non-bank brand through APIs. The brand offers deposit accounts, cards, or payments under its own name while the bank holds the charter, the deposits, and the regulatory relationship.
How is BaaS different from open banking?
Banking as a service lets a brand offer a regulated product using a bank’s license. Open banking provides permissioned access to data already held at a bank, so a third party can read balances or initiate payments without offering a banking product itself.
Do you need a banking license for BaaS?
No. The absence of a license is the point of the model. The sponsor bank supplies the charter, and the brand operates under it. What the brand acquires instead are obligations flowing down through the bank’s contract, including recordkeeping, identity verification, and examination cooperation.
What does a BaaS provider do?
A provider sits between bank and brand, supplying APIs, the sub-ledger recording individual balances, reconciliation against the bank’s position, and usually compliance tooling. Its hardest technical work is maintaining a consistent view across systems that frequently operate on different processing clocks.
Who carries the compliance burden?
The sponsor bank carries it in the regulator’s view, since examiners hold the charter holder accountable for activity conducted under it. Operationally, much of the work sits with the platform and brand. That gap between formal and practical responsibility is what recent rulemaking addresses.
