Pooled Accounts vs Virtual Ledger Accounts: Which Setup Fits Your UK Business?

What are pooled accounts and virtual ledger accounts?

A pooled account is an underlying account holding funds attributable to several customers or business units. A virtual ledger account is usually an internal record showing a particular customer's or unit's balance and transactions. They describe different layers of the same arrangement: money can be held in a pooled account while a ledger tracks the separate entitlements within it.

The account agreement determines who is the account holder and on what terms the funds are held. The ledger records the allocation under that arrangement. Creating separate balance records does not, on its own, create separate bank accounts, trusts or insolvency protection.

Consider a simplified GBP collection. The pooled bank account initially holds GBP 2,000, allocated as GBP 1,200 to Customer A and GBP 800 to Customer B. Customer A then sends GBP 100 using an assigned payment identifier. Once receipt is confirmed, the bank total becomes GBP 2,100 and the ledger credits Customer A's entitlement to GBP 1,300; Customer B remains at GBP 800. No additional bank account needs to be opened for that allocation.

The records must explain the same economic position. In this simplified example, the customer balances total the pooled cash balance. In production, fees, unsettled receipts, reserves and payouts in transit can create legitimate differences that require separately identified entries and reconciliation. A payment notification should not automatically be treated as evidence of settled cash.

Virtual identifiers and ledger records are complementary. An identifier can tell the system which customer a receipt belongs to, while the ledger records its amount, currency, status and effect on that customer's balance. A missing or incorrect reference can still require investigation.

The phrase ledger banking is a commercial description, not a separate UK regulatory category. The actual account provider, regulated activity and customer-funds arrangement matter. The FCA's safeguarding guidance illustrates why customer-funds protection depends on legal and operational arrangements, rather than ledger-level separation alone.

The meaningful comparison is therefore between complete account structures: individually opened accounts, pooled accounts with internal records, and any supported virtual payment identifiers. A proposal should specify all three layers instead of presenting pooled accounts and virtual ledgers as incompatible alternatives.

How do the available setups compare operationally?

A pooled account and a virtual ledger are often parts of the same arrangement. The underlying account holds the funds, while the ledger records the amounts attributable to customers, business units or purposes. The operational comparison is therefore between different ways of combining bank accounts, payment identifiers and internal records, rather than a simple choice between pooling and ledgers.

Bank-provided virtual-account products can combine a physical account with subledger reporting, as illustrated by this virtual-account product explanation. However, a virtual account number used to identify an incoming payment is not necessarily the same thing as a ledger balance. Some identifiers only route or label receipts; the application must still determine the customer's entitlement.

For example, GBP 500 received for Customer A may increase cash in the pooled account by GBP 500 and increase A's recorded balance by the same amount. Customer B's balance remains unchanged. If the receipt lacks a usable identifier, it should remain an identifiable allocation exception until evidence establishes the correct customer. It should not be credited solely because its amount resembles an expected payment.

Within a permitted arrangement, reallocating value between ledger accounts may require only internal entries, without a corresponding transfer between bank accounts. An external payout still depends on the underlying account, available liquidity, supported payment rail and provider controls. Each payout must also stay within the relevant customer's available balance, after allowing for holds, reserves and pending payouts. Sufficient cash in the pooled account does not justify using funds attributable to other customers. A quickly updated ledger does not prove that a bank payment has settled.

• Reconciliation: Reconcile the account's opening balance and movements to its closing balance, then explain how the ledger's customer and control accounts map to that position. Pending items, fees and funds in transit can create legitimate differences.
• Liquidity: A central cash view can improve forecasting, but balances attributable to others must not be treated as unrestricted corporate cash.
• Administration: Virtual records can reduce physical-account management while increasing dependence on accurate account mappings, API events and access controls.
• Reporting: Ensure the accounting system receives entity, customer, currency and transaction references, rather than an unexplained pooled total.

Operational convenience does not establish ownership or insolvency protection. Those depend on the legal account arrangement and applicable protections, not the number of balance records displayed in the interface.

How are funds protected in the UK?

Protection depends on the legal account arrangement, the institution holding the funds and the customer's status. A separate virtual ledger balance is evidence of an allocation; it does not by itself create a separate bank deposit, trust or insolvency protection. Equally, pooling funds does not automatically remove protection where the required legal arrangements and records are in place.

Distinguish the failure of a bank from the failure of a payment or e-money institution. For eligible deposits with a UK-authorised bank, building society or credit union, the standard FSCS deposit limit is GBP 120,000 per eligible depositor per authorised institution, effective from 1 December 2025. Multiple accounts or brands sharing the same banking licence do not multiply that limit. See the FSCS deposit-limit guidance. Business eligibility must be checked for the actual legal entity and deposit.

For money held on behalf of others in a pooled or client account, FSCS treatment depends on the arrangement and underlying beneficiaries. A qualifying structure may allow protection to look through the named account holder to eligible beneficiaries; a virtual account label alone does not establish this. The FSCS guidance on client and pooled accounts explains the distinctions. An eligible beneficiary's share may also aggregate with deposits they hold directly at the same institution. For example, GBP 80,000 held directly plus a qualifying GBP 60,000 share of pooled deposits would total GBP 140,000 against the standard GBP 120,000 limit, assuming no additional protection applies.

Payment and e-money institutions use a different protection mechanism for relevant customer funds. Where safeguarding applies, funds are protected under the applicable segregation or insurance/guarantee arrangements. Safeguarding is not FSCS cover against the payment or e-money firm's own insolvency. The FCA's explanation of payment-provider protections also makes clear that returning safeguarded money can take time and may involve deductions or shortfalls.

The supplementary safeguarding rules effective from 7 May 2026 strengthen requirements around records, reconciliations, reporting and related controls. Check how the responsible institution meets the current FCA requirements. Do not assume every small payment institution safeguards: its obligations and any voluntary election need to be established.

• Identify the account holder, e-money issuer or other debtor, and the legal basis of each customer's entitlement.
• Confirm whether the arrangement is a bank deposit, safeguarded payment/e-money funds or another structure.
• Request a clear explanation of what happens if the provider fails and, separately, if the underlying bank fails.
• Check that beneficiary records, account acknowledgements where applicable and reconciliations support the stated protection.

The contractual and regulatory analysis should follow the funds through the whole arrangement. A well-maintained ledger supports that evidence, but cannot repair an unsuitable legal structure simply by displaying separate customer balances.

Which setup should your business choose?

Choose the account structure around ownership, payment flows and reporting needs. Pooled accounts and virtual ledger accounts can work together: the first determines where funds sit, while the second attributes balances and activity. The useful question is how many underlying accounts you need and what level of virtual allocation should sit above them.

Before choosing a setup, establish whether your proposed activities require FCA authorisation or registration, or fall within an applicable exclusion. Receiving and transferring customer money may constitute regulated payment services. A pooled account and ledger do not themselves authorise your business to provide those services. See the FCA's guidance on providing payment services.

For a marketplace, customer-level attribution and payout controls may be more important than issuing a separate physical account for every seller. For a trading group, legal-entity separation and intercompany accounting may drive the structure even when central treasury wants a consolidated view. The same virtual ledger can support either model, provided its account mappings reflect the actual arrangements.

Bank documentation shows how virtual subledgers can reduce reliance on physical accounts while preserving detailed cash reporting; see this virtual-account overview. Treat the operational fit described here as a selection framework, not a claim that every provider supports the same account types, payment rails or customer categories.

• Choose on control capability: A pooled model requires dependable allocation, reconciliation and exception handling. If your team cannot operate these controls, include a managed operational service in the assessment rather than assuming the ledger will maintain itself.
• Choose on total cost: Compare account fees, payment charges, implementation, support, reconciliation effort and the cost of manual exceptions at your expected volumes.
• Choose on liquidity visibility: Separate unrestricted business funds from customer entitlements, reserves and pending commitments. A consolidated dashboard should not make restricted balances appear spendable.
• Choose on resilience: Consider concentration in one institution or provider and whether the business can continue operating during an outage or account restriction.

Record the preferred structure and the reasons for it in a short decision document. It should name the account holders, expected payment flows, ledger responsibilities and conditions that would trigger a different setup as the business grows.

What should you verify before implementation?

Require evidence that the proposed account and ledger arrangement works for your actual funds flow. Product labels, an API demonstration and a successful test payment are not enough. Before moving live funds, finance, operations, compliance and engineering should agree the account model, responsibilities and acceptance criteria.

1. Verify the legal and contractual structure. Identify the contracting entity, account holder, institution holding the funds and the party responsible for the customer balance. Check the relevant regulatory permissions and whether your business acts as a customer, agent, distributor or service provider. Confirm beneficial entitlements, withdrawal rights, restrictions and insolvency treatment in the actual agreements.
2. Verify payment capabilities. Obtain written confirmation of the required GBP rails, receiving details, supported payer and beneficiary types, limits, cut-offs and settlement behaviour. Check what name recipients see and how returned, rejected or incorrectly referenced payments are handled. Do not assume a virtual receiving identifier supports every function of a separately opened bank account.
3. Verify the ledger model. Map each customer or business-unit record to the correct underlying account and legal entity. Define posted, pending and available balances, fee allocation, reserves and permitted internal transfers. Ensure currencies cannot be mixed accidentally and corrections retain a traceable history.
4. Verify reconciliation. Demonstrate that opening balances plus movements explain closing balances in the ledger and external records. Identify who supplies reports, how incomplete feeds are detected and who resolves unmatched receipts or payouts. Include the data needed for applicable safeguarding reconciliations, as described in the FCA's safeguarding guidance.
5. Verify operational control. Test user and administrator permissions, payment approvals, balance limits and recovery after service interruption. A retry after a timeout must not create a duplicate payment, and delayed notifications must not overwrite a valid later state. Document which party is responsible for applicable customer identity checks, sanctions screening, transaction monitoring and fraud handling, including how concerns are escalated and resolved.
6. Verify commercial and exit terms. Price account administration, transactions, rejected payments, reporting, support and minimum commitments. Establish access to transaction history, beneficiary data and reconciliation exports on termination, together with the process for moving or returning funds.

Use a small GBP test scenario with expected results agreed in advance. Receive GBP 100 for Customer A and GBP 60 for Customer B, then pay GBP 30 to A's authorised external beneficiary. Assuming no fees or other movements, the settled external balance should be GBP 130, attributable as GBP 70 to A and GBP 60 to B. Check intermediate pending states as well as the final result. Replaying the same payment instruction must not reduce either balance again.

Next, attempt a GBP 80 payout for Customer A. With only GBP 70 available to A, the payout must be rejected even though the pooled account holds GBP 130. Confirm that no payment is sent and both customers' balances remain unchanged.

Add an unidentified receipt, a rejected payout and an interrupted report import. The system should produce visible exceptions with source references and an accountable owner, rather than silently forcing totals to agree. Test both the application view and the records available to finance and customer support.

Approve production only when these checks have documented outcomes and all issues affecting fund protection, payment accuracy or legal readiness have been resolved. Any remaining non-critical issues must have named owners, agreed resolution dates and explicit acceptance by the responsible decision-makers. Retain the evidence and account mappings so subsequent provider changes, new currencies or additional legal entities can be assessed against the same control framework.