How nested accounts work: one real account, many balances

A nested account is an account that lives inside another account: one real, safeguarded account at a regulated institution — the master account — and any number of sub-accounts created on top of it as ledger entries, each with its own balance, its own reference, and often its own account number. The money physically sits in one place; the nesting is the ledger that says whose is whose.

That one structure powers most of modern fintech. A marketplace holding 3,000 seller balances, an agency keeping client media budgets apart from its own fees, a business holding GBP, USD and EUR side by side — all of it is nested accounts. Here is how the mechanics actually work, what to use them for, and the two questions to ask before you trust one.

What a nested account actually is

Strip the branding and there are only two layers. At the bottom sits a real account — held at a bank or an e-money institution, in the regulated entity’s name, with actual money in it. On top sits a ledger: a database that divides that one balance into named sub-balances. Seller #4172 has £8,300. Client “Harlow & Co — media budget” has £45,000. The USD wallet has $12,900.

The industry names for this are nearly interchangeable — nested accounts, virtual accounts, sub-accounts, vIBANs. They all describe the same thing from different angles: “virtual account” stresses the inbound side (a unique number each payer can send to), “sub-account” stresses the ownership split. Nothing about a sub-account is a bank account in its own right. That is the point — and the risk, which we come back to below.

How the mechanics work

Money in. Each sub-account can be issued its own virtual account number or virtual IBAN. When a payment arrives on that number, it lands in the master account — but the number itself tells the ledger exactly which sub-balance to credit. No reference-matching, no “please quote invoice 4471 in the payment reference” and no guessing when the client doesn’t.

Money held. The master balance always equals the sum of the sub-balances. A platform holding seller funds sees one line at the bank and thousands of lines in the ledger, and the two must reconcile to the penny, continuously. This running proof — the real money matches the ledger — is the entire integrity of the structure.

Money out. A payout is drawn against a specific sub-balance, so seller #4172 can only spend seller #4172’s money. Splits work the same way: one inbound customer payment can be divided across sub-accounts — platform fee here, seller balance there — as a ledger operation, instantly, before anything moves over a payment rail at all.

Reconciliation. Because every movement is born tagged to a sub-account, reconciliation stops being an end-of-month archaeology project. The question “whose money is this?” was answered at the moment the payment arrived.

What businesses use them for

Marketplaces and platforms are the classic case: collect from buyers, hold each seller’s balance separately, pay out on schedule. Without nesting you are commingling seller money in one pot and rebuilding ownership in a spreadsheet — the exact pattern regulators dislike and sellers stop trusting.

Agencies use nesting to keep client money apart from agency money. A media agency holding a client’s ad budget, or a studio holding a project deposit against stage payments, can give each client or project its own pot — so “how much of this balance is actually ours?” has a live answer.

Multi-currency businesses are nesting without calling it that: a GBP wallet, a USD wallet and a EUR wallet under one relationship is the same master-plus-ledger structure, one sub-balance per currency.

Project businesses use sub-accounts as commitment pots — the deposit for job #4821 sits in its own balance until the materials order draws it down, so no phase of a project quietly finances another.

The two questions to ask before you trust one

The nesting layer is only as good as the account underneath it, so ask these before the demo dazzles you:

1. In whose name is the master account, and is it safeguarded? With an FCA-authorised e-money institution, client funds must be safeguarded — held separate from the company’s own operating money, so they are protected if the provider fails. With an unregulated wrapper, the prettiest sub-account dashboard can sit on one ordinary account in somebody else’s name, and in an insolvency your “balance” is an unsecured claim.

2. Is the ledger real-time and provable? The master balance must equal the sum of sub-balances continuously, not at month-end. The Synapse collapse in the US showed what happens when the ledger and the bank disagree: customers’ money vanished into the gap between an app, a middleman and a bank while reconciliation was rebuilt by hand. If a provider cannot show you live sub-balance reconciliation, the nesting is decorative.

One caveat on the word “nested”

In bank-compliance vocabulary, nesting also names something else entirely: a foreign bank quietly piggybacking on another bank’s correspondent account, so the upstream bank can’t see whose transactions it is really processing. That “nested correspondent banking” is a money-laundering red flag — and it is unrelated to the customer-facing sub-account structure this article describes, beyond the shared metaphor of accounts inside accounts. If you meet the word in an AML policy, it means the risky kind; in a product doc, it almost always means the useful kind.

How Fynex runs nested accounts

Fynex uses this structure as the foundation of its money layer, with the safeguarding question answered the right way up: Fynex is an FCA-authorised e-money institution and client funds are safeguarded by default. On top of that master layer, Fynex runs the sub-balances your operation needs — a balance per seller for marketplace payouts, multi-currency wallets to hold and pay in every currency you owe, per-client and per-project pots for agencies — and its agents do the part software should do: splits applied at the moment money arrives, payouts drawn against the right balance on the cheapest compliant rail, and every movement reconciled to Xero or QuickBooks automatically, because it was born knowing which account it belongs to.

One real account. Many true balances. A ledger that proves itself continuously — instead of a spreadsheet that hopes.