An FBO ("For Benefit Of") account is the legal construct that allows a fintech to hold user funds without being a bank. Legally, the account belongs to the users, not the company. Architecturally, this creates a "One-to-Many" mapping problem. There is one physical bank account (The Pool) and millions of virtual user balances (The Sub-Ledger).
The Sub-Ledger Sync Requirement
The cardinal rule of FBO architecture is: Sum(User_Sub_Ledgers) <= FBO_Bank_Balance.
If the internal sub-ledgers sum to $1,000,001 and the bank account holds $1,000,000, the platform is insolvent.
The Sweep: Platforms often sweep revenue (fees) out of the FBO into an Operating Account daily. This logic must be precise; sweeping user funds by mistake is a regulatory violation.
Attribution: Every cent entering the FBO must be tagged with a User ID immediately. Unallocated funds ("Suspense Account") are a major compliance red flag.
Handling Interest and FDIC Pass-Through
If the FBO earns interest, that interest legally belongs to the users (unless T&Cs state otherwise).
The Interest Engine: The system must calculate daily accruals for every user based on their specific balance history and credit it to their sub-ledger.
Pass-Through Insurance: For users to be FDIC insured, the ledger must clearly identify the owner of every dollar. "Pooled" anonymity breaks insurance; the system must maintain a "System of Record" that can be handed to regulators in a failure event.
