Provision Sub-Accounts for Every Customer With Modern Treasury Payments

A virtual account is a unique account number that sits under a platform’s master account and routes funds to a specific customer. Anything sent to that number is attributed to that customer on arrival, so the platform knows whose money is whose without matching after the fact. Modern Treasury’s sub-accounts go further: each is a named account with its own account number that can receive ACH, RTP, FedNow, and wire payments, hold its own balance, and send payments. They sit inside Modern Treasury’s FBO structure at our sponsor bank.

A virtual account is an alias account number linked to a standard bank account. Depending on the bank, it may only receive payments, with the balance and payouts staying on the linked account, or it may also hold its own balance and send payments. A Modern Treasury sub-account is a programmable account with its own account number that holds its own balance and can both receive and send payments. A ledger balance is a record in software. It tracks who owns what but has no account number, so it can’t receive a wire or an ACH by itself. When each customer needs to send and receive payments under their own account number, use sub-accounts.

An FBO (for benefit of) account is a bank account a platform holds on behalf of its customers, who remain the owners of the funds inside it. Sub-accounts sit under the FBO, one per customer, each with its own account number, so the bank, your platform, and your auditors can see whose money is whose. Modern Treasury holds the FBO at our sponsor bank, so you don’t negotiate an FBO program with a bank directly.

Your platform completes KYB with Modern Treasury once. Each customer that receives a sub-account is verified as part of provisioning, with Modern Treasury running the checks. Your customers’ recipients, the people they pay, don’t need an account to be paid.

Each customer’s funds sit in their own sub-account, with its own account number, under the platform’s FBO structure at the partner bank. Money in never lands in a shared pool that has to be split up later, and money out debits the specific customer it belongs to. Your operating funds stay in a separate account entirely. Provisioning is one API call per customer, so segregation is the default rather than a project.

The account number is the reconciliation key. Every ACH, RTP, FedNow, or wire that arrives is attributed to the right customer on arrival because it was sent to that customer’s number, and every payout over those rails or push-to-card debits the specific sub-account it came from. Balances are current in the API and the dashboard without a matching step, and exceptions such as a return or a payment to a closed sub-account surface for review instead of hiding in an omnibus total.