If you are building embedded finance into a vertical SaaS platform, at some point someone — your legal counsel, your bank partner's compliance team, a prospective enterprise customer — will ask how you hold customer funds. The correct answer involves a structure called a For-Benefit-Of account, commonly abbreviated FBO. Understanding exactly how this works is not optional. It is foundational to every financial product your platform can offer.
What an FBO Account Actually Is
An FBO account is a bank account held in the name of one entity "for the benefit of" a defined group of beneficiaries. In the embedded finance context, the structure works like this: your platform opens a single pooled deposit account at a chartered bank partner, titled something like "Fieldwork SaaS, Inc. FBO Its Customers." Inside that account, the actual dollars belong to your individual customers — each HVAC contractor, each salon owner, each gym operator — not to your platform. Your platform is the custodian. The bank is the account holder of record. The beneficial owners are the SMBs on your platform.
This is not a novel structure. It has been used in securities brokerage for decades under SEC Rule 15c3-3 (the broker-dealer customer protection rule), in law firm client trust accounting under state bar regulations, and in the prepaid card industry under FinCEN's prepaid access rules. Embedded finance BaaS providers have adapted the same architecture for platform-held SMB funds.
Why the Structure Exists — and Why It Matters
The FBO structure serves two distinct purposes that are easy to conflate but important to understand separately.
The first is legal segregation of funds. When a platform holds customer money in its own operating account, those funds are commingled with company assets. If the platform becomes insolvent, customer balances are unsecured creditor claims against the estate — meaning they can be frozen, delayed, or reduced through bankruptcy proceedings. Under a proper FBO structure, the beneficial ownership of those funds remains with the customers, not the platform. In most jurisdictions and most bank charter regimes, this provides meaningful protection to customer balances in a platform wind-down scenario. We say "meaningful" rather than "guaranteed" because specific outcomes depend on jurisdiction, how the FBO agreement is drafted, and the nature of any proceedings — but the distinction matters greatly relative to commingled operating accounts.
The second purpose is regulatory compliance. Most states have money transmission laws that prohibit non-bank entities from holding customer funds in transit without a money transmitter license (MTL) — a license that requires significant capital reserves, state-by-state application, and ongoing examination. The FBO structure, when properly executed under the umbrella of a bank partner with a federal charter, allows platforms to hold and move customer funds under the bank's regulatory authority rather than obtaining their own MTL. This is the legal basis on which virtually all BaaS platforms operate today.
How the Ledger Maps to the FBO Pool
Here is where the operational complexity lives. If one FBO master account at a bank holds the pooled deposits of, say, 1,200 small businesses on your platform, how do you know whose money is whose? The answer is a sub-ledger — a real-time, double-entry accounting system that your platform maintains, mapping every credit and debit to an individual beneficial account holder.
Consider a concrete example. A home services platform operates an FBO pool account with $847,000 in aggregate deposits across 340 HVAC and plumbing contractors. Each contractor has a virtual account number — acct_9f2c81, acct_3b7e44 — that appears in the sub-ledger with its own running balance, transaction history, and pending items. When a homeowner pays contractor acct_9f2c81 $320 for a service call, the sub-ledger credits that virtual account $320, and the FBO master account's aggregate balance increases by $320. When that contractor initiates a payout to their personal bank account, the sub-ledger debits the virtual account, and an ACH debit originates from the FBO master. The bank sees one net account; the platform's sub-ledger maintains 340 individual views.
Reconciliation between the sub-ledger and the bank's FBO master statement is a daily operational requirement. The aggregate of all sub-ledger balances must equal the bank balance to the penny, every business day. Discrepancies — caused by failed returns that hit the bank but not the sub-ledger, timing differences on pending ACH items, or data integrity issues in the posting logic — need to be identified and resolved before the next business day's opening. This is not aspirational; it is a condition of the bank's ongoing willingness to host the FBO relationship.
The Bank Partner's Role and Requirements
The bank partner in an FBO arrangement is not a passive holder of deposits. They are an active compliance participant, and their requirements shape almost everything about how the platform operates its treasury function.
Before extending an FBO arrangement, the bank's operational risk and BSA/AML teams will review the platform's compliance program. They want to know: How does the platform verify the identity of businesses holding sub-account balances? What is the KYB process? How does the platform screen for OFAC-sanctioned entities? What is the dispute resolution process when a business claims an unauthorized transfer? What is the incident response plan for potential fraud on the sub-ledger?
We are not saying that every bank partner requires the same level of documentation — the depth of review varies considerably by bank size, charter type, and their appetite for BaaS relationships. What we are saying is that the platform's compliance posture needs to be real and documented before the bank conversation happens. A platform that goes into an FBO negotiation with a spreadsheet of customer names and a vague description of "we check them out before onboarding" will not get to term sheet.
The bank also sets limits and conditions on the FBO arrangement: maximum aggregate balance, maximum individual sub-account size, prohibited business types, required reporting cadence. These limits are part of the operating agreement and need to be reflected in the platform's product constraints.
Customer KYB versus the FBO Master Account
A point that confuses many platform teams early on: the FBO master account is the platform's account with the bank, not the individual customers'. The bank's direct KYC/KYB due diligence applies to the platform as the account holder. But the FinCEN Customer Due Diligence rule (31 CFR 1020.220) requires the bank's program to extend through to beneficial account holders when the relationship involves a custodial structure holding funds for third parties.
In practice, this means the platform must collect and maintain CDD data on every business with a sub-account balance, and must make that data available to the bank upon request. The platform is running a CDD program on behalf of the bank, as part of the contractual FBO arrangement. If a particular sub-account holder cannot be verified — their EIN doesn't match IRS records, their beneficial ownership disclosure is incomplete, their business name doesn't match state registration — the platform needs a defined process for restricting that account until the issue is resolved. Having a broken KYB flow and a live FBO pool is a compliance violation waiting to happen.
Practical Implications for Platform Architecture
Understanding the FBO structure shapes several non-obvious architectural decisions for the platform product. Virtual account numbers need to be stable identifiers — contractors and business owners will use them for receiving ACH direct deposits, so they cannot change when a customer upgrades a plan tier or changes their contact information. The sub-ledger posting logic needs to handle the full lifecycle of an ACH transaction: initiated, pending, settled, returned — and each state needs the right balance treatment. A returned ACH item that is debited from the sub-ledger before the return hits the bank creates a reconciliation gap that requires manual intervention.
The platform also needs a clear funds-available policy: when does a deposited item count as available for outbound transfer? Banks impose availability holds on deposited items, and the platform needs to pass through the right hold logic to prevent sub-ledger balances from going negative when a deposit item is returned after a withdrawal has already been processed.
None of this is insurmountable. The FBO structure is the right architecture for this use case, and getting it right creates the legal and operational foundation for every financial product the platform can build on top. The key is going in with an accurate picture of what the structure requires — both from the bank partner and from the platform's own infrastructure.