Embedded Finance and Banking-as-a-Service

Every core banking system you've worked on had exactly one client that mattered: your own front end, built by people who sat two desks away and could be pulled into a Slack thread when something looked wrong. Banking-as-a-Service inverts that. Now the client is a fintech program manager you've never met, integrating against your API on their own timeline, and the thing standing between their bug and your bank's balance sheet is whatever isolation you actually built — not whatever you assumed. This one's for the backend engineer being asked to open the core up. 

Embedded finance sounds like a product decision — a bank licenses its charter and infrastructure so a non-bank brand can offer cards, accounts, or payments under its own name. What it actually is, underneath the partnership deck, is a systems design problem: your ledger, your KYC pipeline, and your reconciliation process all need to serve multiple tenants who don't work for you, don't share your incident channel, and in some architectures don't even have direct visibility into whether their own numbers are correct. Get that architecture right and BaaS is a genuinely good distribution model. Get it wrong and you've built the exact shape of failure that took down one of the industry's largest middleware providers in 2024. 

The failure mode is a ledger problem before it's ever an API problem 

Synapse's collapse is worth understanding in technical terms, not just as a cautionary headline, because the root cause was architectural. Synapse operated as middleware between fintech apps and several partner banks, using "for benefit of" (FBO) omnibus accounts — one pooled account at the bank, holding funds for potentially thousands of end users, with Synapse's own systems tracking who owned what share of the pool. That per-user detail is what's sometimes called a shadow ledger: a secondary set of balances, held outside the bank's core, that the bank itself never directly reconciled against on any meaningful cadence. When Synapse failed, its partner banks lost access to Synapse's records and, with them, the only detailed account of which end user owned which slice of the pooled funds. The result was a reported $65–95 million shortfall between what the banks held and what was actually owed to end users, money that wasn't provably missing so much as unprovable, because no single system of record had ever been required to agree with the others in real time. 

The lesson isn't "don't use middleware". It's that a sub-ledger only deserves the name if it can reconcile back to the core ledger on demand. One assessment of multi-product ledger design puts it bluntly: a sub-ledger that can't reconcile back to the core on demand isn't a sub-ledger, it's a second source of truth, and a second source of truth is exactly what a regulated bank can't afford to discover it has, especially under stress, especially during a partner's bankruptcy, when "on demand" becomes "immediately, under a court's questioning." Any BaaS architecture where the bank's core isn't verifiably the reconciled system of record for every tenant's end-user balance is running the same risk Synapse's partner banks were running, just at whatever scale hasn't failed yet. 

Regulators have already drawn this conclusion. The OCC, Federal Reserve, and FDIC jointly issued a request for information in mid-2024 on bank-fintech arrangements specifically, following a wave of enforcement actions against banks whose fintech partnerships had outrun their risk management — the direction of travel is toward expecting banks to maintain their own verifiable records and direct oversight of end-user funds, not to rely on a partner's assurances that its books are correct. Building the ledger architecture to satisfy that expectation isn't a compliance checkbox layered on afterward. It's the schema design decision you make in week one. 

Tenant isolation: pick the failure mode you can live with 

Multi-tenant architecture has three broad shapes, and the tradeoff between them is really a tradeoff in blast radius. A standalone, single-tenant deployment per program gives the strongest isolation — one tenant's bug, load spike, or breach genuinely cannot touch another's data, because there's no shared infrastructure to leak across — at the highest operational and infrastructure cost. A database-per-tenant model keeps a single application layer but gives each tenant its own database, which is the pattern most SaaS platforms converge on as the practical balance: strong isolation, and a single-tenant restore or migration that can't accidentally touch anyone else's data. A pooled, shared-schema model with a tenant-discriminator column scales to the most tenants most cheaply, and it's also the pattern with the lowest isolation — a missing WHERE tenant_id = ? clause, a bug in the row-level filter, or a noisy tenant's query load is now everyone's problem. 

For anything touching customer funds — which, in a BaaS platform, is the entire point — the pooled discriminator model shouldn't be the default, and it's worth being explicit about why: the cost of the isolation failure is categorically different from a typical SaaS data leak. A cross-tenant bug in a project management tool shows the wrong task list to the wrong customer. A cross-tenant bug in a ledger shows the wrong balance, or worse, lets one program's transaction post against another program's funds. Schema-per-tenant or database-per-tenant should be the floor for ledger and account data specifically, even if lighter-weight shared infrastructure is acceptable for genuinely tenant-agnostic services like a public rates API. 

Hibernate ships native support for exactly this decision, through its MultiTenancyStrategy options — SCHEMA and DATABASE give you a real, separately-connected schema or database per tenant, resolved per request through a CurrentTenantIdentifierResolver; DISCRIMINATOR is the shared-schema, tenant-ID-column approach, and it's the one that depends entirely on every query, every JPA repository method, and every raw SQL statement correctly applying the tenant filter with no exceptions, forever, across every engineer who ever touches the codebase. That's not a criticism of the discriminator pattern in general — it's a real, legitimate architecture for the right workload — but for a ledger table, the failure mode of "someone shipped a query without the filter" is the kind of bug you want architecturally impossible, not merely code-reviewed against: 

 1 public class TenantIdentifierResolver implements CurrentTenantIdentifierResolver { 
 2     @Override 
 3     public String resolveCurrentTenantIdentifier() { 
 4         String tenantId = TenantContext.getCurrentTenant(); 
 5         if (tenantId == null) { 
 6             throw new IllegalStateException( 
 7                 "No tenant context set — refusing to resolve a default schema"); 
 8         } 
 9         return tenantId; 
10     } 
11 } 

The line that matters most in that snippet isn't the resolver logic — it's the refusal to fall back to a default. A multi-tenant system that silently defaults to some tenant when the context is missing is a system that will eventually post one program's transaction into another program's schema during exactly the kind of request-scoped bug that's otherwise harmless in a single-tenant app. 

API design: the confused-deputy problem, again, with real money attached 

A BaaS API's tenants aren't just data boundaries, they're credential boundaries, and the same failure pattern that shows up in tool-server design shows up here: a shared, broadly-scoped service credential used across every partner integration means a bug or a compromised partner integration can act with the platform's full privilege instead of that one tenant's. Every program-level API key needs to be scoped narrowly to that program's own accounts and actions, validated on every request against the tenant context resolved from the credential itself — not from a parameter the caller supplies and the server trusts. If a request can specify which tenant's ledger to post against, rather than that being derived entirely from the authenticated caller's identity, you've built a confused deputy into the API surface, and it's only a matter of time before a client's bug or a malicious actor discovers it. 

Idempotency deserves the same weight it gets in any payment API, for the same reason: a partner integration retrying a failed account-opening or transfer call after a timeout has to be safe to retry, which means every mutating endpoint needs to accept and honor a client-supplied idempotency key, returning the original result on a repeat rather than executing the operation twice. And because BaaS partners build their own products against your webhooks — a card authorization, a KYC status change, a settlement completing — those webhooks need per-tenant signing secrets and replay protection, exactly because a fintech partner's own security posture isn't something you control, and a leaked webhook secret for one tenant shouldn't let anyone forge events for another. 

Rate limiting is the last piece, and it's worth framing the same way a bulkhead is framed in any resilience design: without a per-tenant cap, one partner's traffic spike — a marketing campaign that goes better than they expected, or a bug in their retry logic — degrades the API for every other partner sharing the same infrastructure. Isolating rate limits per program, not just globally, is what keeps one tenant's bad day from becoming every tenant's incident. 

Reconciliation is the product, not the afterthought 

Everything above is what keeps the ledger correct in the steady state. What actually would have caught Synapse-shaped drift early is treating reconciliation between the core ledger and any tenant-facing balance as a monitored, alerting system in its own right — not a nightly batch job whose failures get triaged whenever someone notices the report didn't run. Daily reconciliation is the documented minimum in most guidance on this; event-driven reconciliation, checking that every tenant-facing balance change has a matching, correctly-attributed core ledger entry within minutes rather than hours, is what actually catches drift while it's still a rounding error instead of a court filing. A reconciliation break should page someone the same way a failed payment does, because functionally, it's an early warning for the exact failure that turned a single middleware provider's mistake into a multi-bank, tens-of-millions-of-dollars mess that regulators are still writing guidance in response to. 

We've built ledger and account infrastructure for banks long before "embedded finance" was the term for it, and the discipline underneath a good BaaS platform isn't new — it's the same core-banking rigor around reconciliation, audit trails, and system-of-record integrity that regulated banking has always required, applied now to an API surface with tenants you don't manage instead of a front end your own team built. The architecture question was never really "how do we expose our infrastructure to partners." It was "how do we expose our infrastructure to partners without ever losing the ability to prove, on demand, whose money is whose."