Preserving the FBO account model with better governance

For more than a decade, the “for benefit of” (FBO) account served as the quiet but critical foundation of the bank-fintech economy with its straightforward appeal. A single bank account could support thousands or even millions of end users while balances were maintained outside the bank core in a separate ledger. Banks gained deposits and expanded market reach without having to update legacy infrastructure. Fintechs gained speed, scale, and the ability to launch regulated products without needing to secure banking licenses. 

Then the system was stress-tested in real-world conditions. When critical middleware and ledger providers like Synapse Financial Technologies collapsed, they exposed deep weaknesses across the ecosystem. Customers lost access to funds. Banks struggled to reconcile balances. Regulators intervened, and headlines quickly followed. In the aftermath, a narrative formed: the FBO model is broken. That conclusion is understandable but inaccurate. The construct didn’t fail; governance, control, and recordkeeping did. 

The questions that matter most 

Today, the FBO structure remains a widely used and fundamentally sound mechanism for holding customer funds. What has changed is regulatory and operational tolerance for opaque ledgers, fragmented ownership of critical controls, and unclear accountability when failure occurs. The post-Synapse environment hasn’t outlawed omnibus accounts. Instead, it’s forced banks and fintechs to confront a more fundamental design conundrum, with every bank-fintech arrangement reduced to two foundational questions: 

1. Who legally holds customer funds? 
2. Who maintains the system of record that can provide real-time or near real-time visibility into balances, fund location, and proof of ownership? 

These questions are often conflated, but they shouldn’t be. Holding funds is a legal and balance sheet requirement that determines custody, regulatory jurisdiction, deposit insurance mechanics, and ultimate responsibility. Keeping the ledger is an operational function that governs how balances are tracked, how transactions are authorized and posted, and how disputes are resolved. 

Recent failures didn’t occur because funds were held at the wrong institution. They occurred because banks lost control over the ledger, lacked full visibility into balances, or couldn’t independently reconstruct customer records when an intermediary failed. That’s why a viable FBO model must ensure banks can independently reconstruct customer fund balances at all times, reconciled to the penny, and intervene without relying on a single third party. 

The traditional FBO account model 

In its classic form, the FBO model is built around a simple but scalable structure. A bank opens a single omnibus deposit account in the name of the fintech that’s designated for the benefit of the fintech’s end customers. Funds belonging to all end customers are pooled within that account, while individual ownership and balances are tracked separately in a subledger that’s historically maintained by the fintech itself or by a specialized middleware provider operating outside the bank’s core systems. 

The model became dominant for good reason. Banks avoided the operational burden of opening millions of retail accounts on legacy cores, fintechs gained speed to market, and customers benefited from bank custody of funds. When properly designed, FBO structures can support FDIC passthrough insurance, consumer payments, and complex money movement. But “properly designed” is no longer a vague aspiration; it’s now a regulatory expectation. 

FBO model variations 

The traditional model’s appeal lies in speed and flexibility, but those advantages come at a cost. The ledger becomes a single point of failure, constraining bank visibility and allowing reconciliation errors to compound. Regulators now tolerate this arrangement only where banks can demonstrate hard controls, including independent reconciliation, data replication or escrow, enforceable step-in rights, and credible wind-down plans.  

These plans must address fintech capability freezing, fund segregation and reconciliation, orderly fund porting, and viable contingency options that allow other fintechs to step in. Absent these guardrails, too much operational truth sits beyond the bank’s reach. Practically speaking, this approach is risky and difficult to operationalize because it effectively externalizes a bank’s core ledgering function to an entity that’s neither regulated nor subject to equivalent supervisory standards. 

An alternative variant to this structure is a hybrid model, in which the ledger operates outside the core but remains controlled or approved by the bank, with fintechs integrating via APIs while the bank retains authoritative system of record status. This approach preserves much of the fintech’s agility while restoring auditability and supervisory comfort, provided it’s treated as a critical system subject to formal governance and resilience testing.  

At the opposite end of the spectrum is another model variant that has the bank placing each customer directly on its core, either in its main ledger or subledger. This approach trades speed and scale for regulatory simplicity, clearer insurance mechanics, and greater transparency. While there’s no universally correct architecture, this final option is gaining ground with banks because it guarantees strong controls, reduced risk, and enhanced compliance.  

This variation is often preferred in cases where fintech partners aren’t subject to direct regulation, and accountability rests with the bank. Ultimately, the right choice for financial institutions depends on transaction volume, customer risk, product complexity, bank risk appetite, and regulatory maturity. Which model is selected matters less than whether the chosen model can be operated with discipline. 

Accountability can’t be outsourced 

The consequences of poor FBO design aren’t theoretical; they surface when regulators test accountability in practice. In banking-as-a-service models, supervisors evaluate whether the bank retains control over compliance decisions, disclosures, and customer protections regardless of who operates the interface. Where that control is unclear, accountability failures follow quickly. 

For BSA, AML, and sanctions purposes, banks are required to treat underlying beneficial owners as their customers. Screening and monitoring must apply to individual customers and their transactions, not merely to the fintech counterparty. While alert generation and investigative support may be delegated to a third party, authority over suspicious activity reporting can’t be outsourced. A bank must be able to explain why a report was filed or not filed, consistent with its risk appetite and policies. 

Consumer protection risk is often amplified in these arrangements because disclosures, not balance sheets, shape customer understanding. Compliance with Regulation E, including error resolution rights, investigation timelines, and provisional credit, remains the bank’s responsibility regardless of who manages customer support. Disclosures must be clear, accurate, and consistent, particularly around fees, funds availability, transaction reversibility, and distinct bank and fintech roles. Where product mechanics or limitations are poorly explained, the risk of being subject to Dodd-Frank’s unfair, deceptive, or abusive acts or practices regulatory standards increases sharply. 

Deposit insurance disclosures warrant particular care. Passthrough FDIC insurance depends on clear reflection of beneficial ownership in the bank’s records, unambiguous FBO designation, and accurate, accessible account records. Customers mustn’t be misled about the nature or extent of that coverage. Inconsistent or imprecise statements included in account agreements, marketing materials, in-app messaging, or other communications can undermine passthrough eligibility and expose customers to loss. Regulators increasingly expect banks to actively govern fintech-authored disclosures rather than merely approve them at onboarding. 

From a safety and soundness perspective, the test is simple: if the bank can’t independently establish customer balances and rights at any given point, the program is no longer defensible. 

Bringing compliance to the front-end UI 

In BaaS partnerships, the customer interface has become the effective front line for customer and consumer regulation. Where a non-regulated fintech controls the user experience, compliance is no longer secured primarily through policies or contracts but through design choices embedded in screens, workflows, and data flows. Regulators increasingly assess whether banks influenced those choices or were treated as an afterthought, and whether fintechs can deploy changes without bank validation.

Authoritative data flows must be defined by bank-approved technology, even when executed through a fintech’s interface. The bank determines what constitutes the system of record for customer identity, balances, transactions, and disclosures. A well-governed user interface ensures that customer actions trigger bank-controlled processes and populate bank-reconciled records. Where the interface presents information that diverges from the bank’s books, governance weakens. Reconciliation stops being a control and becomes a repair exercise. 

The onboarding process illustrates this point. Fintechs often treat account opening as a branding exercise, whereas bank supervisors treat it as the execution of CIP, CDD, sanctions screening, and eligibility rules. A compliant interface doesn’t merely collect data; it enforces bank-defined procedures through sequencing, validation, and escalation logic. If the interface allows customers to proceed despite unresolved requirements, the failure is structural, and the bank absorbs the regulatory consequence. 

Disclosure obligations further underscore the importance of design discipline. Compliance isn’t achieved by the existence of disclosures but by their placement, timing, and coherence with the product’s actual mechanics. Fee structures, fund availability terms, Regulation E rights, and deposit insurance statements must appear at the moment when they shape customer decisions instead of being buried in static terms and conditions. Where the interface implies protections or features that the disclosures quietly contradict, customer risk rises sharply. 

For this reason, banks can no longer rely on fintech attestations as evidence of compliance. Active testing of the live customer journey, from onboarding and transactions to disputes and reviewing disclosures in context, is an essential required step. Examiners now ask not only whether controls exist but whether they’re visible, enforceable, and consistently executed on the screen. 

The aim of such discipline isn’t to slow innovation; it’s designed to ensure that innovation remains governable. In BaaS models, the interface is where regulatory obligations meet customer expectations. If governance is embedded there, scale is sustainable. If it’s not, growth merely accelerates the accumulation of risk. 

Where control ultimately lies 

Innovation rarely fails because of structure. It fails when control, recordkeeping, and accountability fall behind product design. The future of bank-fintech partnerships won’t be determined by whether programs rely on FBO accounts or direct-to-bank structures. What matters is whether banks can always identify and articulate who owns the funds, where they are at any given moment, and whether that information can be proven independently without dependency or delay. When that’s clear, account architecture becomes a design choice rather than a regulatory vulnerability.  

Banks and fintechs that treat ledger and account architecture as a core element of their regulatory and operational strategy rather than a purely technical decision will be able to scale with confidence as partnerships proliferate. Those that don’t will find that growth only amplifies risk, not value.