Why sub-ledgers matter
Banks don't open one general-ledger account per customer; they pool customer funds into program-level accounts at the core and use sub-ledgers to track who owns what within the pool. A sub-ledger answers: "of the $50M in this FBO account, how much belongs to each of the 200,000 underlying customers, and what entries justify that?"
For a BaaS program, the fintech operates the sub-ledger; the sponsor bank operates the core; reconciliation between the two is the single most important compliance and operational process.
When sub-ledger design matters
- Architecture day one — pick double-entry, append-only, idempotent. Retrofitting is brutal.
- Reconciliation cadence — daily at minimum; intraday for active programs.
- Failure modes — design for partial reconciliation (some rows match, some don't) without halting the entire system.
Common pitfalls
- Treating the sub-ledger as the system of record. It is not. The core is. The 2024 middleware failures made this lesson expensive for thousands of customers.
- Mutable balances. Balances must be derived from entries, not stored mutably.
- No bank-side reconciliation. A sub-ledger that doesn't tie to the core is a database, not a sub-ledger.
A sub-ledger is the fintech's promise to itself and its customers; the core is the bank's promise to the regulator. Both have to balance.