Embedded Finance and Banking-as-a-Service Architecture: Spon

When a fintech app shows you a balance, three different systems may disagree about what that number means, and only one of them is legally a bank. That gap is the central design problem of banking as a service architecture: a company with no charter offers deposit accounts, cards and payments by stitching together a chartered sponsor bank, a platform that exposes banking APIs, and its own product front end. When the three ledgers agree, it is invisible. When they drift, customers can lose access to money for months, which is what happened when Synapse Financial Technologies entered Chapter 11 in April 2024.

This matters in 2026 because regulators have shifted from tolerating thin oversight of bank-fintech programs to asking who holds the records, who reconciles them and who answers to examiners. Engineers building embedded finance products now inherit obligations that used to live inside a bank.

You will leave with a working mental model of the roles, the ledger layering (FBO accounts, virtual accounts, reconciliation), the card issuing flow, the KYC/AML responsibility split and the failure modes seen industry-wide. This is a systems analysis, not legal or financial advice.

What this covers: the actors and contracts, the three-layer ledger model, daily reconciliation design, card issuing and settlement, compliance boundaries, failure modes, and a practical checklist.

Non-advisory note: this article describes system architecture and publicly reported events. It is not legal, regulatory, compliance or investment advice. Requirements differ by jurisdiction, charter and program; consult qualified counsel and your sponsor bank.

Context and Background

Embedded finance is the practice of offering financial products inside a non-financial product: a ride-hailing app with a driver debit card, an accounting tool with business accounts, a payroll platform with earned-wage access. Banking-as-a-Service (BaaS) is one way to deliver it. In the US model, the fintech does not hold a bank charter and cannot take deposits itself. A chartered bank, the sponsor bank, holds the deposits and issues the products. The fintech brand owns the customer relationship. A BaaS platform, sometimes called a middleware or program manager, supplies the APIs, ledger, orchestration and operational tooling that let the two cooperate.

The model grew because the alternatives are expensive. Obtaining a bank charter is slow and capital intensive, and building core banking, card processing and compliance operations from scratch is a multi-year effort. Renting a regulated stack lets a small team launch in months. The cost shows up in layered accountability: three or more companies share one customer relationship, and regulators hold the chartered bank responsible for all of it.

Two regulatory facts frame everything below. First, the Interagency Guidance on Third-Party Relationships: Risk Management, issued in June 2023 by the Federal Reserve, FDIC and OCC, states that a bank’s use of a third party does not diminish its responsibility to operate safely and in compliance with laws. You can read the text on the Federal Reserve site. Second, the 2024 collapse of Synapse showed that the records problem is real: the CFPB later alleged in its August 2025 complaint that Synapse failed to keep accurate records of consumer funds and did not reconcile them with partner bank records, with an estimated shortfall of $60 million to $90 million among more than 100,000 affected accounts, according to reporting on the CFPB filing. Those figures are allegations and estimates from the agency, not adjudicated findings.

Several posts on this site cover the building blocks. For ledger internals see event sourcing and bitemporal data for a financial audit trail and the double-entry ledger database architecture guide. This article takes a different angle: not how to build a ledger, but how to decide which ledger is the source of truth when there are three, and who is accountable for each.

The Reference Architecture: Roles, Contracts and Ledger Layers

A BaaS program is a stack of four parties linked by contracts, and the architecture follows the contracts. The sponsor bank holds the charter, the FBO (for benefit of) accounts and the regulatory accountability. The BaaS platform runs the technology and often operational services. The fintech brand designs the product and acquires customers. Vendors (KYC providers, card processors, fraud tools) plug in beneath the platform or the bank.

Figure 1: Banking as a service architecture, the four roles and where regulatory attention flows. Dashed lines show that examiners reach through the bank to the platform and brand.

Figure 1 shows the shape. Solid arrows are the product and money path from customer to rails. Dashed arrows are supervisory reach: the regulator examines the bank, and the bank’s third-party risk obligations extend that examination to the platform and the brand. The diagram is deliberately flat because the legal truth is flat too: there is exactly one regulated deposit-taking entity in the picture.

The sponsor bank is the issuer of record. Its name appears on the account agreement, the card BIN registration and the regulatory filings. It holds customer money in deposit accounts at the bank, owes the deposit insurance assessments, and carries the Bank Secrecy Act (BSA) program obligation. Its core system, often a traditional core from a large vendor, is the book of record for the bank’s own balance sheet.

The BaaS platform (also called a program manager or middleware provider) builds the layer that fintechs actually integrate with. It typically supplies account opening APIs, a customer-facing ledger, card program management, ACH and wire initiation, and compliance workflow tooling. Some platforms are very thin routers; others are effectively outsourced operations departments. This difference matters because the thicker the platform, the more records the bank depends on but does not directly control.

The fintech brand owns product, marketing and customer support. It decides who the target customer is, which usually determines the risk profile the bank must underwrite. Contractually it agrees to follow the bank’s policies, to submit to oversight and to share data.

A fourth pattern is increasingly common: the brand contracts directly with the sponsor bank and uses a platform only as a technology vendor, sometimes called a direct or “bank-direct” program. This shortens the chain, but the architecture questions below are the same.

Program Management: What the Bank Actually Approves

Bank program management is the governance wrapper around the technical stack. At a minimum a sponsor bank expects a program to be approved before launch, with documented products, target customers, expected volumes, marketing materials, complaint handling, and a compliance management system. After launch it expects periodic reporting: transaction volumes, returns and chargebacks, complaints, fraud losses, suspicious activity referrals and reconciliation status.

For engineers, the useful translation is that program management turns policy into interfaces. A rule such as “no accounts for customers in a prohibited category” becomes an onboarding gate. A rule such as “reconcile daily” becomes a scheduled job with an attestation record. A rule such as “the bank may audit at any time” becomes a requirement for read access to underlying data. The better programs expose bank-facing dashboards and data feeds rather than relying on monthly spreadsheets.

The Three-Layer Ledger Model

Most confusion in BaaS comes from calling three different things “the ledger.” A clearer model separates them.

Layer 1: the bank’s record. At the sponsor bank, customer funds typically sit in one or a small number of pooled accounts titled as custodial or “for benefit of” accounts, commonly shortened to FBO accounts. The bank’s general ledger sees the pooled balance, not the individuals behind it. From the bank’s balance sheet perspective this is a single deposit liability.

Layer 2: the platform or program ledger. Here each end customer has an account representation, often called a virtual account, wallet or sub-ledger entry. It records who is owed what: balances, holds, pending transactions, fees and interest. It is the only place where the per-customer view exists in real time.

Layer 3: the fintech’s product view. The brand’s own application database keeps profiles, display balances, rewards and categorizations. It is a cache and presentation layer; if it disagrees with Layer 2, Layer 2 should win.

The invariant that keeps the stack honest is simple to state: at every close of business, the sum of customer balances in Layer 2 must equal the bank’s pooled balance in Layer 1, after accounting for in-flight items. Anything else is a break, and breaks are where programs fail.

Figure 2: Ledger layering. Per-customer balances roll up into an aggregate that is compared with the FBO account balance in a daily reconciliation, with breaks routed to an exception queue.

Figure 2 shows the flow. The platform ledger aggregates its virtual accounts, the bank reports the balance of the FBO account, and a reconciliation step compares them. A match is attested and the day closes. A break goes to an exception queue where an operator must explain it before the next cycle.

FBO Accounts and Pass-Through Deposit Insurance

FBO accounts matter beyond bookkeeping because of deposit insurance. FDIC deposit insurance covers up to $250,000 per depositor, per insured bank, per ownership category. For pooled custodial accounts, the FDIC’s pass-through rules can treat each underlying owner as the insured depositor, but only if the records identify those owners and their interests. The FDIC states the concept in its deposit insurance resources, and the condition is the operational crux: coverage depends on the ability to reconstruct per-customer ownership from records. Notably, insurance protects against failure of the insured bank. It does not protect customers against a failed fintech or platform, and it does not cover a shortfall caused by bad bookkeeping upstream. That distinction was lost on many consumers during the Synapse episode, and it is worth stating plainly in product disclosures.

Why the Records Question Drives the Design

The FDIC’s September 2024 proposal on custodial deposit accounts with transactional features, published in the Federal Register in October 2024, reflects this concern. As proposed, it would require covered banks to keep records identifying each beneficial owner and balance in a standardized electronic format and to reconcile those records at least daily at close of business. It would also require direct, continuous, unrestricted access to records held by a third party, written procedures, independent validation of third-party records and annual executive certification. The FDIC estimated that 600 to 1,100 banks could be affected. See the Federal Register text. I am describing a proposal; check the current status of any final rule before relying on specifics. Regardless of its final form, the direction is clear, and it is a useful design target: build as though the bank must be able to rebuild every customer balance without your cooperation.

Deeper Analysis: Reconciliation, Card Issuing and the Compliance Split

The reference model is easy to draw and hard to operate. Three mechanisms carry most of the weight: reconciliation, the card authorization and settlement loop, and the division of compliance duties.

Designing Daily Reconciliation

Reconciliation in a BaaS program compares independent views of the same money. The bank statement and core report (Layer 1) arrive as files or API pulls. The platform ledger (Layer 2) emits a trial balance. Network and rail files (card clearing, ACH, wire confirmations) provide the third leg. A robust design reconciles at three levels rather than one.

The first level is aggregate: the sum of virtual account balances plus platform-owned accounts (fee income, reserves, suspense) must equal the FBO balance. This is the headline check and the one a regulator would ask for first. The second is transaction-level: every credit or debit on the FBO account must map to a platform ledger entry, and vice versa, using a stable reference such as a trace number, wire reference or network transaction identifier. The third is per-customer: no virtual account should hold a negative balance that is not covered by an explicit, approved overdraft or credit arrangement.

Timing differences are the main source of false alarms. A card purchase reduces the customer’s available balance at authorization, but cash moves between the network and the bank at settlement, typically a day or more later. An ACH credit may be shown as pending while the bank’s ledger already includes it, or the reverse. Good reconciliation models these as named in-flight categories, each with an expected age. An item that exceeds its expected age moves from “in flight” to “break.”

Here is a compact sketch of the aggregate and transaction-level checks. It is illustrative, not production code: it ignores multi-currency, partial matches and ledger sign conventions beyond the basics.

from collections import defaultdict
from dataclasses import dataclass
from datetime import date

@dataclass(frozen=True)
class Entry:
    ref: str          # stable cross-system reference
    amount_cents: int # positive = credit to customers
    value_date: date

def reconcile(bank_entries, ledger_entries, bank_close_cents,
              customer_balances_cents, platform_own_cents, in_flight_cents):
    """Return (aggregate_diff, unmatched_bank, unmatched_ledger)."""
    # Aggregate check: customers + platform-owned + in-flight == bank FBO balance
    expected = sum(customer_balances_cents.values()) + platform_own_cents + in_flight_cents
    aggregate_diff = bank_close_cents - expected

    # Transaction check: match by ref and amount
    bank_by_ref = defaultdict(list)
    for e in bank_entries:
        bank_by_ref[e.ref].append(e)
    ledger_by_ref = defaultdict(list)
    for e in ledger_entries:
        ledger_by_ref[e.ref].append(e)

    unmatched_bank, unmatched_ledger = [], []
    for ref in set(bank_by_ref) | set(ledger_by_ref):
        b = sum(x.amount_cents for x in bank_by_ref.get(ref, []))
        l = sum(x.amount_cents for x in ledger_by_ref.get(ref, []))
        if b != l:
            (unmatched_bank if ref in bank_by_ref else unmatched_ledger).append((ref, b, l))
    return aggregate_diff, unmatched_bank, unmatched_ledger

Three design rules make this useful in practice. Keep money in integer minor units to avoid rounding drift. Make the reconciliation job idempotent and re-runnable for any historical date, so an auditor can reproduce the result. And persist the output, including the inputs’ checksums, as an append-only record. This is where the event-sourcing pattern in the financial audit trail article pays off: a bitemporal record lets you answer both “what did we believe on Tuesday” and “what was actually true on Tuesday.” For broader reconciliation engine patterns, see the reconciliation engine architecture post.

A Worked Illustration

The numbers below are illustrative, not from any real program. Suppose a program has 40,000 virtual accounts. At close of business the platform reports ledger balances (cash actually owed, before pending card holds) of $18,420,000.00 across customers and $61,000.00 of platform-owned fee income. It also has $212,500.00 of card purchases authorized but not yet settled. The sponsor bank reports an FBO balance of $18,481,000.00.

Using ledger balances, 18,420,000 plus 61,000 equals 18,481,000, so the aggregate difference is zero: the authorized purchases have not moved cash, so they correctly do not appear in the bank balance. Now suppose the reconciliation job accidentally sums available balances, which are net of the holds. Customers would total 18,207,500, the expected FBO figure would be 18,268,500, and the job would report a false break of 212,500. The reverse mistake is worse: a job that uses ledger balances to decide whether a customer can spend would let customers spend money that is already committed.

The lesson is that both systems must agree on what “balance” means before reconciliation can succeed. A shared data dictionary with named balance types (ledger, available, pending, held) is a compliance artifact, not documentation fluff. It is also what lets an examiner or a successor platform read your data without guessing.

Card Issuing: BIN Sponsorship and the Authorization Loop

Card programs add a fast path that cannot wait for a nightly job. A card network (Visa, Mastercard and others) assigns BIN ranges to a member issuer. In a BaaS setup the sponsor bank is that member, and the platform or its processor operates the program under the bank’s sponsorship. When a customer taps the card, the merchant’s acquirer sends an authorization request through the network to the issuer processor, which must answer within a tight window. Networks publish their own timeout rules; treat any specific millisecond figure as network-specific and confirm in the processor’s documentation.

Figure 3: Card authorization and settlement. The processor decides in real time against the platform ledger; cash settles later against the sponsor bank’s FBO funds.

As Figure 3 shows, the real-time decision happens against Layer 2. The processor checks the virtual account balance, applies limits and fraud rules, and places a hold. Money does not move at authorization. At clearing and settlement, the network debits the issuer’s settlement account, and the bank funds that from the FBO balance. The platform then converts the hold into a posted debit. If the settlement amount differs (a tip added to a restaurant bill, a fuel pre-authorization), the platform must release or adjust the hold.

Two architectural details deserve emphasis. First, just-in-time (JIT) funding is a pattern where the program does not pre-fund a card balance; instead the processor requests approval from the program’s ledger per transaction and the settlement account is funded afterwards. It shifts risk from a pre-funded pool to a real-time decision and requires that the ledger be highly available, because a ledger outage means every card declines. Second, the card-level ledger events (authorization, incremental authorization, reversal, clearing, chargeback) must be idempotent and ordered, or holds leak. For the processor side of this flow see the card issuing processor architecture article and the issuer authorization switch post.

There is also an economic boundary worth knowing. In the US, the Durbin Amendment’s debit interchange cap (Regulation II) applies to issuers with $10 billion or more in assets, while smaller issuers are exempt. Many sponsor banks are below that threshold, which is a reason card-heavy BaaS programs have clustered at smaller banks. This is a regulatory fact that shapes who sponsors programs; it is not a recommendation on partner selection, and thresholds and rules change, so verify current Federal Reserve guidance.

The KYC and AML Responsibility Split

The most dangerous misunderstanding in BaaS compliance is that responsibility can be outsourced along with the work. The bank must maintain a BSA/AML program, including a Customer Identification Program (CIP) under its rules, customer due diligence, suspicious activity monitoring and reporting, and sanctions compliance with the Office of Foreign Assets Control (OFAC). The regulatory duty sits with the bank, but the day-to-day work is often delegated to the fintech or platform, and to vendors beneath them.

Figure 4: The compliance pipeline. Tasks like identity verification and monitoring can be delegated, but filing and accountability remain with the bank.

The practical consequence is that the architecture must give the bank visibility and control rather than a trust relationship. That means the bank can see the CIP evidence (what was checked, with which vendor, with what result), can see screening decisions and tuning, can see monitoring alerts and their dispositions, and can override or halt a program. A pattern that works is a shared case-management system in which the bank has its own role, rather than periodic reports sent from the fintech. For detail on the underlying controls, see the posts on perpetual KYC architecture, sanctions screening and watchlist filtering and AML transaction monitoring.

One subtle point is tuning ownership. Monitoring thresholds directly determine how many alerts are generated and how many suspicious patterns are missed. If the fintech owns tuning to keep its alert volume low, an incentive conflict exists. Strong programs put threshold changes under a change-control process with bank approval and keep a record of model and rule versions in effect on each date, so any past decision can be reconstructed.

Money Movement Beyond Cards

Cards are only one rail. ACH, wires, and instant payments pass through the sponsor bank’s own connections or through a third-party sender. ACH introduces returns that can arrive days after the original entry, and the NACHA rules define return windows by reason code. Your ledger must be able to reverse a credit that already funded a card purchase, which creates negative balance exposure. Programs commonly handle this with delayed availability, risk-tiered holds, and reserve accounts, each of which is a policy knob agreed with the bank. See the ACH and NACHA rails architecture post for return mechanics.

Trade-offs, Gotchas, and What Goes Wrong

Failure in BaaS is usually not a dramatic hack. It is a slow divergence between ledgers that nobody has the authority or tooling to resolve. The following modes are drawn from public reporting and regulatory actions; where I describe a mechanism beyond what is documented, I label it as inference.

Reconciliation drift and the missing source of truth. In the Synapse case, as described in the CFPB’s complaint, the company allegedly failed to keep accurate records and to reconcile them with partner banks. After the April 2024 bankruptcy filing, more than $265 million in deposits was reported frozen, and the estimated unrecovered shortfall was $60 million to $90 million, per the CFPB filing coverage. The architectural lesson, which is my inference rather than a finding, is that when the only per-customer ledger lives at the platform and the bank holds only an aggregate, the platform’s failure removes the bank’s ability to say who owns what. The control that addresses this is bank-side access to a continuously updated copy of the per-customer records.

Multiple banks, multiple ledgers. Platforms that spread customer funds across several partner banks multiply the reconciliation surface. Each bank holds an FBO balance, and the platform must track which customer’s dollars sit where. Movement between banks (sweeps for deposit insurance limits or liquidity) creates additional in-flight categories. Complexity grows faster than the number of banks, and mapping errors are hard to detect from a single bank’s perspective.

Regulatory enforcement on the bank side. Banks that sponsored fintech programs have faced supervisory action over risk management. Evolve Bank & Trust, a Synapse partner, was subject to a Federal Reserve enforcement action in 2024 relating to risk management and AML compliance in its fintech partnerships; consult the Federal Reserve enforcement actions database for the primary documents rather than relying on summaries. The pattern across such actions, in general terms, is that banks onboarded fintech volume faster than their compliance operations could scale.

Key-person and vendor concentration. A platform may rely on one processor, one KYC vendor and one core integration. If any fails, the entire program stalls. Contractual step-in rights, data escrow and tested migration plans reduce this risk, but they cost money and slow launches, so they are often skipped until needed.

Negative balances and fraud losses. Returned ACH, disputed card transactions and account takeover create negative balances. Who absorbs the loss, the brand, the platform or the bank, must be defined in the contract and mirrored in the ledger as explicit accounts, not buried in a suspense bucket. Suspense accounts that grow without aging reports are an early warning sign.

Dormant data and orphaned customers. If a program is terminated or a fintech shuts down, customers must be offboarded or transferred. Without a clean export of balances, transaction history and KYC records, the process takes months. Designing for exit, including a documented export format, is cheap before launch and very expensive afterward.

Gotchas for engineers. Do not reuse the platform’s internal customer ID as the only key shared with the bank; use a stable external identifier you control. Do not mutate ledger history; correct with reversing entries. Do not treat “pending” as a single state; model its origins. And do not assume your sponsor bank’s core reports intraday, since many produce files once per day, which constrains how fast you can detect breaks.

Practical Recommendations

Treat the sponsor bank as a first-class stakeholder in your architecture, not a legal formality at the end of the stack. The goal is that the bank, at any time and without your cooperation, can answer: who owns this money, where is it, and what compliance decisions were made on its behalf.

A concrete way to apply this is to write down, before launch, a record-of-truth map: for each entity (customer, account, balance, transaction, KYC decision, alert, SAR referral), name the system that owns it, the system that holds replicas, the sync mechanism and the recovery procedure. Then test the map by simulating the loss of each party, starting with the platform.

Checklist for builders (a planning aid, not advice):

Define balance types in a shared data dictionary and publish it to the bank.
Reconcile daily at aggregate, transaction and per-customer levels; store results immutably.
Give the bank read access to per-customer records through an independent replica, tested for restoration.
Use integer minor units, idempotency keys and append-only ledger entries with reversing corrections.
Put KYC, screening and monitoring configuration under bank-approved change control with versioned history.
Model in-flight items with expected ages and automatic escalation.
Define loss allocation in the contract and in the chart of accounts.
Document an exit plan, including data export format, customer notification and fund transfer path.
Track the FDIC custodial account proposal and your bank’s examiners’ expectations, and design to the stricter standard now.
Disclose clearly to customers that deposit insurance covers bank failure, not fintech or platform failure.

Frequently Asked Questions

What is banking as a service architecture?

Banking as a service architecture is the technical and contractual arrangement through which a non-bank company offers regulated banking products using a chartered bank’s license. A sponsor bank holds deposits and issues cards, a BaaS platform provides APIs, ledgers and operations, and the fintech brand owns the customer experience. The defining design question is how three ledgers stay consistent and who is accountable when they diverge.

The sponsor bank ledger is the bank’s own record, typically showing pooled balances in FBO accounts as single deposit liabilities. The platform ledger records each customer’s balance, holds and transactions in virtual accounts. The bank ledger is legally authoritative for the bank’s balance sheet, while the platform ledger holds per-customer detail. Daily reconciliation proves that the two agree, and deposit insurance pass-through depends on the per-customer records being accurate.

What is an FBO account and are funds in it FDIC insured?

An FBO (for benefit of) account is a pooled custodial account at a bank holding funds for multiple underlying customers. FDIC pass-through coverage can apply to each underlying owner, up to the standard limit, if the bank’s or its agent’s records identify the owners and their interests. Insurance covers the failure of the insured bank only. It does not cover losses from a failed fintech, platform or record-keeping errors upstream.

Who is responsible for KYC and AML in a BaaS program?

The sponsor bank carries the regulatory responsibility, including its BSA/AML program, customer identification, suspicious activity reporting and sanctions compliance. Day-to-day tasks may be delegated by contract to the fintech, the platform or vendors, but delegation does not transfer accountability. The 2023 interagency third-party guidance says a bank’s use of a third party does not diminish its responsibility. In practice banks should see evidence, control tuning and be able to halt the program.

What does the FDIC custodial deposit account proposal require?

As proposed in 2024, covered banks would maintain records of each beneficial owner and balance in a standardized format, reconcile at least daily, ensure direct and continuous access to records held by third parties, have independent validation, and provide annual executive certification. It followed the Synapse failure. It was a proposal, so confirm whether and how it was finalized before treating any requirement as binding.

Why do BaaS programs fail?

Most public failures trace to weak controls rather than technology limits: unreconciled ledgers, unclear record ownership, compliance programs that did not scale with volume, and vendor concentration. Banks and platforms that grew quickly sometimes lacked the operational capacity to resolve breaks. The mitigations are well understood, such as independent record replicas, daily attestations, bank-visible case management and tested exit plans, but they cost speed and margin.

Embedded Finance and Banking-as-a-Service Architecture: Sponsor Bank Ledgers, Program Management and Compliance Boundaries (2026)

Context and Background

The Reference Architecture: Roles, Contracts and Ledger Layers