A Banking-as-a-Service provider holds money that belongs to other people’s customers, and it has to hold that money somewhere. There are two structurally different answers. In the dedicated model the provider opens one bank-level FBO account for each enterprise program it serves. In the pooled model — an omnibus FBO account — every program’s money sits inside a single bank account, and the provider’s own ledger is the only thing that says who owns what.
FBO stands for “for benefit of”. The distinction between the two structures is not an administrative preference about how many accounts somebody has to open. It decides where segregation actually lives: in the banking architecture, or in a ledger. Everything else on this page follows from that one difference. If you need the underlying concept first, start with how an FBO account works.
Ten figures run through the sections below. Each one is drawn at a resolution the reading column cannot show in full, so click any figure to open it at its original size.
A terminology point before anything else. The pooled structure should not be called an “intermingled FBO account”. The industry terms are omnibus FBO account and pooled FBO account. Money from multiple programs is pooled in one bank account, but it stays separated from the provider’s own corporate and operating funds — and “commingled” implies something considerably more serious. That distinction is drawn out in the last section.
Model one: the dedicated FBO account
Enterprise A is separated from Enterprise B and Enterprise C at the actual bank-account level. There may be hundreds, thousands or millions of end-user balances underneath Enterprise A, but every one of them rolls up into Enterprise A’s own FBO account at the partner bank.
The BaaS provider still maintains the granular ledger, because the bank does not know that A1 holds $4,000 of Enterprise A’s $10,000 and A2 holds the other $6,000. However, the bank can also see the program-level position directly, because that position is a bank account balance rather than a figure someone has to assemble:
| Bank account | Titled for | Bank balance |
|---|---|---|
| #1001 | Enterprise A dedicated FBO account | $10,000 |
| #1002 | Enterprise B dedicated FBO account | $10,000 |
| #1003 | Enterprise C dedicated FBO account | $15,000 |
Since each program has its own deposit account, the reconciliation that matters is narrow: program account against program ledger, one program at a time.
Model two: the omnibus or pooled FBO account
Here there are not three bank accounts. There is one. The bank may simply see a single line — BaaS Provider FBO Customers, account #9000, $35,000 — and nothing more.
That balance does not tell you that Enterprise A owns $10,000, Enterprise B owns $10,000 and Enterprise C owns $15,000. Within an omnibus FBO account that information exists only in the provider’s subledger, which is precisely why the ledger becomes the critical system rather than a supporting one. There may be millions of ledger entries sitting behind one deposit account.
Therefore the whole structure rests on one equation: the omnibus bank balance must equal the master liability ledger, and each enterprise total must equal the sum of its own customer positions. If those two numbers disagree, nothing in the bank account tells you which program the discrepancy belongs to.
This is the operational consequence people underestimate. In a dedicated structure a broken reconciliation is a broken reconciliation on one program. In an omnibus FBO account the reconciliation is the master account against the entire master ledger, so an error anywhere is an error everywhere until it has been located.
One $1,000 ACH credit, followed through both models
Suppose customer A1 receives a $1,000 ACH payment. For example, follow that same dollar through both architectures and the difference stops being abstract.
Dedicated. The bank credits Enterprise A’s FBO account, taking it from $10,000 to $11,000. A webhook updates the ledger, taking A1 from $4,000 to $5,000. Nothing at all happens to the bank accounts belonging to Enterprise B or Enterprise C.
Pooled. The master account moves from $35,000 to $36,000. The subledger records Enterprise A going from $10,000 to $11,000 and A1 going from $4,000 to $5,000, while B and C are untouched. In contrast with the dedicated case, the physical account now holds $36,000 while economically A owns $11,000, B owns $10,000 and C owns $15,000 — and that gap between the physical balance and the economic one is the entire point of the architecture.
Bank account versus ledger account
This is where Banking-as-a-Service is most frequently misunderstood. A customer sees a routing number, an account number and an available balance. That does not necessarily mean the bank has opened a standalone traditional deposit account in that customer’s name.
The account number exposed to a user may be a virtual identifier used to route incoming funds to that user’s ledger position inside a master FBO account. Although the experience is indistinguishable from a bank account, the underlying legal and account structure has to be examined separately — and it is the structure, not the screen, that determines what happens in a dispute or an insolvency. The related idea of a segregated named account is worth reading alongside this.
Why each model is attractive
Dedicated: a cleaner boundary. If Enterprise B has a reconciliation problem, it is easier to isolate, because the problem is bounded by a bank account. When somebody asks how much of Enterprise A’s money is at the bank, the answer can be read off the account itself rather than reconstructed from a master ledger.
Omnibus: operational scale. A provider running 5,000 fintech programs would otherwise have to open and administer 5,000 separate bank accounts, each with its own opening process, statement, signatory list and treasury position. Pooling lets most of that segregation be performed logically instead. It is efficient — but the subledger becomes systemically important, which is a real cost rather than a free one. This is one reason Banking-as-a-Service programs concentrate so much engineering effort on ledger integrity.
Where segregation lives
Dedicated FBO. Segregation primarily through banking architecture, supplemented by a ledger.
Omnibus FBO account. Segregation primarily through ledger architecture, supported by one pooled bank account.
Nearly every practical difference between the two models — reconciliation scope, error containment, treasury, portability, what a bank can see without asking — is a consequence of that single sentence. The comparison below is the same distinction expanded.
Dedicated and omnibus FBO accounts, side by side
| Characteristic | Dedicated FBO | Omnibus / pooled FBO |
|---|---|---|
| Bank-level accounts | Separate FBO account per enterprise or program | One FBO account for many enterprises or programs |
| Enterprise A’s funds | Physically separated at bank-account level | Logically separated in the subledger |
| Enterprise B’s funds | A separate bank account | The same master FBO account as A |
| Customer-level accounting | Subledger still required | Subledger absolutely central |
| Bank sees program balances directly | Generally much easier | Not necessarily from the account balance alone |
| Reconciliation | Program account against program ledger | Master FBO against the entire master ledger |
| Operational complexity | Higher | Lower at the bank-account layer |
| Scalability | More account administration | Very scalable |
| Program isolation | Strong | Primarily ledger-based |
| Error containment | Easier to isolate by program | Ledger errors can have broader consequences |
| Cash movement | Each FBO has its own movements | All movements hit the master FBO |
| Bank statement | A separate statement and position per FBO | One consolidated bank statement |
| Treasury management | More fragmented | More centralised |
| Account opening burden | Higher | Lower |
| Dependence on the BaaS ledger | High | Extremely high |
| Reconciliation importance | Critical | Mission-critical |
| Identifying the beneficial owner | Ledger plus account structure | Primarily subledger records |
| Program portability | Often cleaner operationally | Potentially more complicated |
| Bank exposure | Can view each program separately | Bank sees the aggregate pool, supplemented by records |
| Best suited for | Higher-value programs needing strong isolation | High-scale platforms with many programs or users |
Neither column is the right answer on its own. A dedicated structure buys isolation at the price of administration; an omnibus FBO account buys scale at the price of making one ledger load-bearing for everybody on it. Which trade is correct depends on program values, program count, and how much operational maturity the provider actually has.
Pooling is not commingling
A properly structured arrangement keeps the provider’s corporate operating account entirely separate from the customer omnibus FBO account. Enterprise and customer funds may be pooled with each other inside the FBO structure while remaining separated from the provider’s own money. That is the difference between a legitimate pooled structure and improper commingling of corporate and customer funds, and the two are routinely confused in conversation.
The distinction also matters to deposit insurance. Pass-through FDIC coverage depends on genuine beneficial ownership, account records disclosing the custodial relationship, and records identifying each owner’s interest — conditions that sit squarely on the ledger in a pooled structure. The FDIC sets out the requirements in its guidance on pass-through deposit insurance coverage, and the federal banking agencies identify recordkeeping, reconciliation and third-party dependencies as principal risks in bank–fintech deposit arrangements.
Which model does your program need?
In summary, the question to answer before approaching a provider is not “dedicated or omnibus” in the abstract. It is narrower: whose money sits in each account, who has the authority to move it, and what has to be true of the ledger for the answer to hold up under examination. Programs with a small number of high-value enterprises usually want the bank-level boundary. Platforms with thousands of programs usually cannot have it.
Related reading: FBO, omnibus and OBO accounts compared, and the pooled and non-pooled account diagrams.
If you are deciding which structure a live program should use, or being offered one and want to understand what you are being offered, tell us how funds move and we will help identify the banking conversations it requires.
Faisal Khan LLC facilitates business introductions and provider relationships; it is not a bank and does not hold customer funds. The figures on this page are illustrative and simplified. Account structures and their legal treatment require assessment of the specific business model and confirmation by qualified counsel.