What Matters When You Hold Customer Money

A lending platform waiting to disburse a loan, a marketplace holding funds between buyer and seller, and a software company paying out on behalf of its users all have the same obligation: they need to know whose money they hold and how much belongs to each customer. Holding the money for only a day doesn't change that obligation that is embedded in all banking.

Most teams begin by opening an FBO account. Banks open these accounts every day. The more involved engineering work is building the systems that track what happens inside these accounts

We hear this often from teams building payments into their products. They want a dedicated account for every customer, layered onto an FBO account. It's a reasonable request, but the details can make the implementation fiendishly tricky. Where the balances live, how incoming payments get attributed, and who reconciles the records (and when) all determine whether the setup works.

An FBO Account Depends on Your Records

An FBO ("for benefit of") account is a bank account your company opens and controls to hold money belonging to someone else. The title reflects that relationship, usually with language like "[Bank] FBO Customers of [Your Company]." Your company can move money in and out, but the money belongs to your customers.

By default an FBO account is pooled. One account can hold funds for hundreds or thousands of customers, while the bank sees a single balance. Your company's operating funds, including revenue and money used for payroll, belong in a separate account. Mixing company and customer funds is called commingling, and is a major no-no. Teams must separate those from the get go to avoid issues later.

The records behind the FBO account matter for its protections, too. For deposits to qualify for pass-through FDIC insurance, meaning coverage that passes through to each underlying owner, the account has to be titled as custodial. Someone also has to maintain accurate records of each customer's ownership.

Opening the account establishes where the money is held. Maintaining the records establishes who owns it.

The Question Synapse Made Unavoidable

In 2024, the banking-as-a-service middleware provider Synapse went bankrupt, and end users couldn't access their money for months. The bank accounts still existed. The records of which person owned which dollars, however, no longer lined up with the balances that the banks held.

Understanding how that can happen starts with a basic question: where does the record of each customer's balance live?

There are generally three possibilities: in the bank's own sub-accounts, in a ledger you operate, or in a ledger operated by an intermediary. Any of these arrangements can work. Each requires clarity about who maintains the records and who checks them against the bank.

For an engineer, this is a consistency problem between two systems. The bank is the source of truth for the total amount held. The ledger is the source of truth for how that amount is allocated. At the end of each day, the following invariant should hold:

\sum \text{customer balances} + \text{platform balances} + \text{suspense} = \text{FBO bank balance} - \text{in-flight items}

You should be able to demonstrate this with actual numbers from yesterday. Any inability to do so deserves attention before adding more complexity.

We often see teams maintain customer balances as mutable columns in an application database, updating them as payments arrive. The difficulty comes when a balance is wrong and there is no transaction history to explain the difference. Balances should be computed from an immutable log of double-entry transactions, for the reasons we described in Accounting for Developers.

Two Kinds of Sub-Accounts

The request for "a sub-account for every customer" usually combines two separate requirements. Most platforms eventually need both.

The first is a ledger account, which records how much money a customer has. Every deposit, payout, fee, and return posts to that account. It answers the question: "How much does this customer have?"

The second is a virtual account number, a real routing and account number assigned to a customer that points into the shared FBO account. It answers: "Whose money just arrived?"

An email alias is a useful analogy. Messages arrive in a shared inbox, but the address identifies the intended recipient. Virtual account numbers provide that identification for incoming payments.

For a platform whose customers only receive money from the platform itself, ledger accounts can be sufficient for a long time. Once customers or third parties begin sending money in, virtual account numbers become necessary. Without them, someone has to determine which customer an incoming wire with "INV 2231" in the memo belongs to. At a few hundred customers, this becomes a recurring operational task. We'll cover that in the next post, on reconciliation.

Where Your Money and Theirs Get Tangled

Even when the FBO account is designated for customer funds, running the business creates situations that require careful accounting.

Consider fees. A platform charges a percentage of each payment. The fee is company revenue, but the money is still in the FBO account. The platform needs to post the fee to a platform revenue ledger account as it is earned, then sweep it to the operating account on a defined schedule. Each sweep should be traceable to the entries it covers. Leaving earned revenue in the FBO account creates a commingling problem.

Negative balances are another common source of difficulty. A customer's ACH debit is returned two days after the platform has paid that customer out. The customer's balance is now negative. That shortfall cannot be covered quietly with other customers' funds. Hold periods, reserves, or a funded loss account can address the exposure, but the approach needs to be established before the return occurs.

The accounting should let you answer three questions at any time: how much belongs to customers, how much belongs to the platform, and how much has yet to be identified.

What We'd Ask Before Signing

Whether you're evaluating a bank, a BaaS provider, or a payments platform like Modern Treasury, understanding the operating model requires more than a feature list.

• Where does each customer's balance live?
• Can a new customer account be created by API, or does it require a ticket?
• Who reconciles the ledger against the bank, how frequently, and can you inspect the results?
• How can reporting be made available for export or to a data warehouse, and how immediate is it?
• Which payment rails are available, including ACH, wire, RTP, and FedNow, and what are their cutoffs?
• What happens when you leave? Can you take your account numbers, counterparties, and transaction history with you?

"We handle that" is a starting point for a conversation. Ask to see how it works.

There is also a question for your own counsel: does your funds flow require a money transmitter license, or does it qualify for an exemption? Addressing this early helps establish which arrangements are available to you.

The choice of arrangement affects timing as well. Working directly with a sponsor bank often requires six to nine months of diligence, contracting, and integration. Launching through an existing program can take days or weeks.

The Short Version

Opening a bank account takes an afternoon. Operating it responsibly requires accurate customer records and daily reconciliation against the bank. Those capabilities need to be in place for the rest of your money movement to work reliably.

Modern Treasury gives platforms an account for every customer, kept separate from their own money. Internal Accounts and Virtual Accounts provide per-customer account numbers. Ledgers keep an immutable record of every balance. Expected Payments and Reconciliation match the bank to the ledger daily. Payment Orders move money across ACH, wire, RTP, and FedNow.

Thinking through an FBO setup? Talk to our team.