A named virtual account gives each customer its own account number, which can carry the customer's name. A payment is matched by the account it lands in. A pooled collection account is one account in the provider's or platform's name. Each payment is matched by a reference the payer types. Pooled accounts need a correct reference every time.
General information, not legal advice. Check current rules with your regulator and your providers.
What is the difference between named and pooled collection accounts?
A virtual account is a sub-ledger with its own account number. It sits on top of one physical account at a bank. The money is in that physical account. The account number tells you whose money it is.
A pooled collection account has no sub-ledger at the bank. Every customer's payers send to the same account number. The holder splits the money in its own ledger, by reference.
| Pooled account with a reference | Named virtual account | |
|---|---|---|
| Account number | One for all customers | One per customer, or per payment |
| Name the payer sees | The provider or the platform | The customer, if the provider registers it so |
| How a payment is matched | By the reference the payer types | By the account it lands in |
| Missing or wrong reference | Unmatched money to investigate | Still matched to the customer |
| Where the money sits | One account at the bank | One master account at the bank |
| Proof of whose money it is | The holder's ledger | The account number, plus the ledger |
Both models usually pool the money at the bank. A named label does not make a separate bank account. It changes how a payment is identified, and what the payer sees.
The question comes up early, sometimes on the first call with a provider. Will the collection account be in the client's name, or pooled?
How is each payment matched?
In a pooled model, the reference does all the work. The payer has to type it, and type it right.
Kenya's M-Pesa Paybill shows the pattern. A business receives payments on a Paybill number. Each payer types an account number of up to 20 characters. The business gets that value back as BillRefNumber in a confirmation message.
Paybill can check that account number before the payment completes. That check calls the business's validation URL. It is off by default, and the business must ask Safaricom to switch it on. With the check off, M-Pesa completes the payment and sends the confirmation, right reference or not.
In a named model, the account number does the work. One collection API in Nigeria offers two variants:
- Static accounts. One permanent account number per customer. A wallet app gives each user a fixed number to top up from.
- Dynamic accounts. One account number per payment. By default, they expire one hour after creation.
A dynamic account matches a single checkout. A static account matches a customer over time. For more on how this works country by country, see virtual accounts for African businesses.
Pooled matching breaks in four ways:
- No reference. The payer leaves the field empty.
- Wrong reference. A typo, or another customer's code.
- One transfer, two invoices. The payer combines payments under one reference.
- Third-party payer. Someone other than the expected payer sends the money.
A named account solves the first two, because no reference is needed to find the customer. It does not solve the last two. You still match invoices and screen the payer. To test how a provider reports each case, see how to choose a collections API for Africa.
What does the payer see before paying?
In the euro area, the payer's bank now checks the name before the payment.
Regulation (EU) 2024/886, the Instant Payments Regulation, added Article 5c on verification of the payee. Banks and payment firms then in the euro area had to comply by 9 October 2025. The other EU countries have until 9 July 2027 at the latest. The check covers euro credit transfers, instant or not.
The payer enters an IBAN and a name. The payee's provider says whether they match. On a mismatch, the payer is warned. The money might go to an account the named payee does not hold. On an almost-match, the payer sees the name on the account. A mismatch warning can make a payer stop and ask your client why.
Accounts a payment firm holds for several payees get their own path, in point 1(c). The payer can add details that identify the payee. The firm holding the account confirms whether that payee is among those it holds the account for. If not, the payer is told.
So a pooled account held by a payment firm can pass. In the euro area, that firm must answer the request. Ask your provider two things in writing:
- Which name does a payer's bank see for this IBAN?
- How does the account holder answer "is this payee on this account" requests?
Business payers can opt out when they send payments as one package. That is Article 5c(6).
A named account shows your client's name, if the provider registers it that way. For the US dollar side of this, see how to offer named USD accounts to your merchants.
Who can prove whose money it is?
Two rule sets show what a pooled ledger must prove.
UK: a next-business-day clock. The FCA's new client-funds chapter, CASS 15, came into force on 7 May 2026. It came from policy statement PS25/12 of August 2025. It covers authorised payment institutions and e-money institutions, among others.
CASS 15.2.5R sets the clock. A firm must allocate each receipt to an individual client by the end of the next business day. Until it does, it records the money as "unallocated relevant funds". The FCA's own example is money that arrives without the correct identifier. A pooled account with missing references feeds straight into that record. With a named account, the account number already identifies the client.
US: the ledger behind an FBO account. Some US programmes collect into one bank account held for their customers. It is often called an FBO account. Federal deposit insurance can pass through to each customer. Under 12 CFR 330.5(b), last amended in 1999, the bank's records must show the account is held for others. Each customer's interest must also be clear from records. Those can be the bank's own, or kept in good faith in the normal course of business.
In practice, that record is your ledger. One US bank described this set-up on a 2026 call. The programme gets one omnibus account at the bank. Account numbers for each merchant sit on top of it. The programme runs the ledger and reconciles balances every day. The bank relies on the programme's KYB and monitors activity.
That last point matters for sub-merchants. If a bank relies on your onboarding, read what it takes to rely on your KYC for sub-merchants.
Which model fits which flow?
| Flow | Payer | Better fit | Why |
|---|---|---|---|
| Wallet top-up | The account holder | Pooled, or static named | The payer knows the platform, and one static number per user ends reference errors |
| B2B invoices from many buyers | Your client's customers | Named | In the euro area, the buyer's bank checks the payee name before payment |
| Marketplace sales | Buyers of each seller | Named, per seller | Each seller's money is told apart by account |
| One-off checkout | A new payer each time | Dynamic account | One account number per payment, expired after use |
| Market with only a shared account | Any | Pooled, with strict reference rules | Validate references before you accept, where the rail allows it |
Some African rails are pooled by design. M-Pesa Paybill is one. On those rails, references and validation carry the load.
What should you ask a provider before you choose?
- Is each account named, pooled, or a full account in my client's own name?
- Which name does a payer's bank see, on each rail?
- In the EU, how does the account holder answer verification-of-payee requests for pooled accounts?
- What happens to a payment with no reference, or a wrong one?
- Can you check references before you accept a payment?
- How fast do you match a receipt to a client, and how do you report unmatched money?
- Who holds the money at the bank, and under which licence?
- Who keeps the ledger that proves each client's balance, and how often is it reconciled?
- Do you accept payments from third parties, or return them?
- When a payment is refunded, who receives it?
Named vs pooled accounts FAQ
What is a pooled collection account?
It is one account that receives money for many customers. The holder tells the payments apart in its own ledger, usually by a reference the payer adds.
Is a virtual account a real bank account?
No. It is a sub-ledger with its own account number, linked to one physical account at a bank. The money sits in that physical account.
Does a pooled account fail the EU's Verification of Payee check?
Not always. Under the 2024 Instant Payments Regulation, the payer's bank can query the payment firm holding a pooled account. That firm must confirm whether the payee is among those the account is held for.
How fast must a UK e-money or authorised payment institution match a pooled receipt?
By the end of the next business day, at the latest. CASS 15.2.5R has required this since 7 May 2026. Until a receipt is matched, it is recorded as unallocated relevant funds.
Can a payer pay a named account without a reference?
Yes. The account number identifies the customer, so the payment can be matched without a reference. A reference still helps to match it to one invoice.
For PSPs and platforms
If you collect for your clients, talk to our team about accounts in your client's name. Nilos offers accounts in your client's name in USD, EUR, GBP, AED, KES and XOF, with segregated client accounts. See virtual accounts, or how Nilos works for PSPs and fintechs.