Confirm your subledger meets the bank-hostable standard by cloning Formance Ledger from GitHub under the MIT license and running it in an environment you control. Then, post the FBO deposit transaction from the modeling section against your own account tree.
In a common FBO (short for "For Benefit Of") structure, customer funds are pooled in one custodial account at a sponsor bank, while beneficial-owner records may be maintained by the fintech or BaaS (Banking-as-a-Service) provider in an external subledger. The bank sees one balance, but you have thousands of customers behind it.
When the bank's end-of-day position arrives, your subledger sums every customer balance, and the two statements disagree by a five-figure amount.
Neither the on-call engineer, the finance ops lead, nor the compliance officer on the incident call can say which is correct. Then compliance wants to know whether the records would be approved as a pass-through insurance claim if the bank or the fintech failed.
The problem is that most FBO subledgers cannot prove customer ownership on demand. They record balances, but they don't enforce the equality between customer liabilities and bank cash at write time. They don't tie every posting to a bank statement line, and they don't stay readable when a fintech or BaaS provider goes down.
An FBO structure works only when the subledger is a double-entry accounting core ledger whose customer liabilities sum to bank cash by construction. Start with the structure itself.
What an FBO account is and how it holds customer funds
An FBO account is a single deposit account at a sponsor bank, titled for the benefit of your end customers.
The bank holds the deposit, while your fintech, BaaS provider, or another fiduciary may be the named account holder. Your customers are the beneficial owners because they own the money, regardless of whose name is on the account. The per-customer view lives in your subledger.
An FBO account works by routing money in through a rail (ACH, wire, or card) into the sponsor bank's FBO account, and out the same way in reverse.
The bank sees one FBO balance and one statement line per deposit, withdrawal, fee, and return. Your subledger holds one balance per customer, split into pending and available, with the full posting history behind each.
At every cutoff, the sum of every customer's pending plus available must equal the FBO balance at the bank.
How FBO accounts work under the three FDIC pass-through conditions
An FBO account works by satisfying three Federal Deposit Insurance Corporation (FDIC) conditions from 12 CFR § 330.5: fiduciary disclosure at the bank, ascertainable ownership records, and actual ownership by the beneficial owners.
Each maps to a subledger requirement: the bank must disclose the fiduciary relationship in its records, ownership must be available from the bank's or depositor's records, and the named beneficial owners must own the funds.
Condition 1 requires fiduciary disclosure in the bank's account title
Disclosure happens when the account title on the bank's core system names your entity as the depositor acting for its customers (for example, "XYZ FBO Customers").
The FDIC's compliant titling examples read "Jane Doe as Custodian for Susie Doe" and "First Real Estate Title Company, Client Escrow Account."
Before the first customer dollar arrives, pull the account agreement and the bank's account record, and confirm that the title carries the FBO designation.
If a BaaS provider sits between you and the bank, it should show up as a second fiduciary layer in the title. A plain corporate title on its own does not meet the disclosure requirement.
Condition 2 requires beneficial-owner identities ascertainable from your subledger
Your ledger meets this condition when it stores a stable ID and a point-in-time balance for every customer. § 330.5 lets the depositor or its agent keep that record, as long as it is "maintained, in good faith and in the regular course of business."
In practice, every customer account needs a stable, never-reused ID and a balance you can produce for any date, past or present.
Large banks already follow a similar shape under 12 CFR Part 370, which applies to institutions with two million or more deposit accounts. Part 370 requires a unique ID for each account holder and each beneficial owner where the two differ.
Its data format uses DP__PT__Account__Flag to mark pass-through accounts and DP__PT__Trans__Flag to mark accounts with transactional sub-accounts.
Condition 3 requires postings tied to source transactions and daily bank reconciliation
Every posting must include metadata linking it to a source transaction, so anyone can trace a customer's share of the pooled balance back to the bank line that created it.
The FDIC's proposed recordkeeping rule for custodial deposit accounts with transactional features would require a daily reconciliation process for FBO accounts whose beneficial owners can send payments to third parties.
The proposal acknowledges that variances from unposted or late transactions "should be addressed based on standard banking practices," without defining those practices.
Apply the checks against the bank position at a fixed daily time:
1Bank cash equals the sum of every customer's available plus pending balance at the cutoff. A posting made at 00:02 with yesterday's effective date lands on yesterday's side of the line.
2Every bank statement line has a matching ledger posting. Any line without one posts to @platform:exceptions:unmatched, never to a customer account. A fee the bank debited or a return you have not processed becomes a visible balance instead of silent drift.
3Every inbound file carries an idempotency key, so a file the bank re-sends cannot credit a customer twice.
These three checks cover cash conservation, no-double-post, and correct dating, ensuring ledger integrity.
In production, we run the first check with Formance Reconciliation, which raises a drift alert when the aggregate ledger position and the bank's FBO balance diverge at the cutoff.
How to model an FBO subledger in a double-entry core ledger
Model the FBO account as a named bank boundary and every customer balance in the subledger as a liability. After every posting, the boundary's negative balance offsets customer balances by construction.
Formance Ledger is the programmable core ledger that implements this model for the FBO subledger and enforces balanced, atomic postings.
The subledger account tree has four branches:
•@platform:banks:sponsor:fbo is the named boundary for cash entering through the sponsor account.
•@customers:<id>:pending holds credited money the customer cannot yet spend.
•@customers:<id>:available holds what the customer can move.
•@platform:exceptions:unmatched holds any bank line the ledger cannot attribute.
One incoming ACH deposit of $1,250,000.00 for Acme Logistics posts as a single atomic Numscript transaction:
// FBO_ACH_DEPOSIT// Event: Acme Logistics receives a pending ACH deposit through the sponsor FBO accountset_tx_meta("event_type", "fbo_ach_deposit")set_tx_meta("ach_trace", "091000010004521")set_tx_meta("bank_line_id", "2026-09-08:0417")set_tx_meta("idempotency_key", "ach:091000010004521")send [USD/2 125000000] ( source = @platform:banks:sponsor:fbo allowing unbounded overdraft destination = @customers:acme_logistics:pending)
USD/2 125000000 is $1,250,000.00 in integer minor units. The send moves cash from the sponsor-bank boundary into Acme Logistics's pending balance.
The boundary account tracks the total FBO cash as a negative balance, and each customer account holds the matching positive balance. The metadata links the posting to the ACH trace and the bank statement line, and the idempotency key stops the system from writing the same file twice.
When the hold period ends, a second transaction moves the $1,250,000.00 from Acme Logistics's pending balance to its available balance.
The totals do not change; only the amount Acme Logistics can spend does. If the deposit is returned, a reversing transaction sends the money back to the sponsor FBO account, and Acme Logistics never had access to funds that did not settle.
Whichever attribution scheme you use, the subledger must remain readable to the bank when the fintech or BaaS provider is unavailable.
What your bank needs from the subledger when the fintech or BaaS provider fails
The bank must be able to reconstruct every customer position directly from your subledger when a fintech or BaaS provider fails. This requires four properties: direct record access, immutable history with exports and point-in-time queries, third-party risk controls, and a self-hostable ledger.
1. Direct record access that survives the provider's bankruptcy
The bank must be able to reach the subledger on its own credentials and schedule, and that access must continue through the fintech or BaaS provider's insolvency or bankruptcy.
The subledger delivers a direct record when the bank holds its own read credentials against the ledger, independent of the fintech's operating stack, and when those credentials remain valid if the fintech is offline.
In practice, the bank should be able to query balances, postings, and exports at any hour, from an interface that does not route through the fintech's application layer.
2. Immutable history with beneficial-owner exports and point-in-time queries
The bank needs a posting history it can trust, an export it can consume without help, and the ability to reconstruct any past position. Without these, a pass-through claim reduces to whatever the fintech's application layer chose to write down.
Three properties get you there:
1A hash-chained transaction history, so any rewrite is detectable rather than plausible.
2A daily beneficial-owner export keyed by the identifiers from Condition 2.
3Point-in-time queries that return the position for any past cutoff, including the day before the fintech or BaaS provider went dark.
When several rails feed one omnibus balance, per-rail timing and format differences produce drift that the aggregate check will not catch on its own.
3. Third-party risk controls that go beyond record access
Sponsor banks carry supervisory obligations that apply whether or not a fintech partner fails. Banking agencies have issued third-party risk guidance covering AML, risk management, and consumer compliance programs at the bank level. Sponsor banks pass that scrutiny through to their fintech partners on the schedule the guidance sets.
The same posting history and beneficial-owner export that support a pass-through claim also cover routine third-party oversight. A sponsor bank asks for three things during a review:
1An examinable posting log
2An on-demand beneficial-owner export
3Controls the bank can inspect on its own schedule
The bank should be able to pull all three without opening a ticket with your on-call engineer.
4. A ledger the bank can host itself
The bank must be able to inspect the ledger code and hold a copy in an environment it controls, with permissions, data availability, replication, and operating procedures. It must be configured to meet the FDIC's requirements.
A ledger the bank cannot host is a ledger the bank cannot depend on when the fintech is unavailable. In practice, this means only open-source, self-hostable code on terms compatible with a bank's operating requirements will hold up under review.
Run the FBO subledger in your own environment
Formance Ledger is available under the MIT license, so the bank can inspect the same code you run, keep a copy in its own environment, and set the operating parameters the FDIC's proposal contemplates.
