FBO account

An FBO account is how most fintech balances actually live at a bank. Rather than opening an account per customer, a platform opens one pooled account titled “for benefit of” its customers at a sponsor bank, then keeps its own ledger of who owns what inside the pool. The bank holds one balance; the platform holds the map.

The structure solves a real problem. It lets a non-bank offer account-like products without a charter, keeps customer funds off the platform’s own balance sheet, and, when documented properly, passes deposit insurance through the pool so each beneficiary is covered individually rather than the pool being treated as one depositor. It is the US cousin of European safeguarding: customer money segregated at a regulated institution, with the operator standing between customer and bank as agent rather than owner.

Its weakness is the same as its design: the pooled balance is only as good as the ledger that explains it. The bank cannot see individual entitlements; the platform’s records are the single source of truth. When the US banking-as-a-service middleware firm Synapse failed in 2024, funds sat at banks while customers spent months unable to prove their share of the pool, because the reconciling record was the failed company’s. The FDIC’s September 2024 proposed rule on custodial deposit accounts with transactional features is the direct response: banks holding such accounts would need beneficial-ownership records reconciled daily, held directly or with continuous, unrestricted access even if the third party fails.

Operationally, the map is usually kept with virtual account numbers: the platform or its banking-as-a-service provider assigns each customer a routing-addressable identifier that resolves into the single pooled account, while the ledger allocates every credit and debit to a beneficiary. Done well, the arrangement reconciles to the penny daily. Done badly, the pool and the ledger drift, and nobody notices until withdrawals are frozen.

For settlement, FBO structures are a reminder that “money in the bank” can be an indirect claim: customer, to platform ledger, to pooled account, to bank. Each layer adds operational dependency, and the moment of failure is when the layers are tested. The same discipline that governs omnibus accounts in market infrastructure applies here: pooling is efficient, and pooling without verifiable records is risk wearing efficiency’s clothes. Diligence on any program built this way starts with three questions: who keeps the ledger, who else can read it, and how fast could a stranger reconstruct it if the keeper disappeared.