Named accounts, virtual IBANs and pooled accounts explained

“Named account”, “virtual IBAN” and “pooled account” describe different ways of holding and presenting customer funds. They are often used loosely in product marketing, which causes confusion, because the same label can hide very different arrangements underneath. The single most useful distinction is between the legal account where funds actually sit and the ledger account your platform uses to track who is owed what. Getting the model right shapes reconciliation, customer presentation, returns handling and safeguarding design — so it should be chosen against your use case, not against the label a provider prefers.

Legal account versus ledger account

A legal account is an account at a regulated institution that holds funds and is identified for payment purposes. A ledger account is an entry in a platform’s books recording an entitlement to part of those funds. These are not the same thing: a customer can have a ledger balance without having a separate legal account in their own name. Many account models are combinations of one or a few legal accounts with many ledger entries. Keeping this distinction explicit prevents most of the confusion in this area.

Named or dedicated account

A named account (or dedicated account) is a legal account presented in, and typically held for, an individual customer. Incoming payments arrive to that account, and it can usually be reconciled directly to one customer. Named accounts give the clearest customer presentation and the most direct reconciliation, but they can be more operationally involved to open and maintain at scale.

Virtual IBAN

A virtual IBAN (vIBAN) is an IBAN that can be assigned to a customer or purpose and used to route incoming payments, often to an underlying master account. A vIBAN is not necessarily a separate bank account — in many arrangements it is an identifier that maps to an entry on a ledger over a shared underlying account, while in others it may correspond more closely to a dedicated account. Because the term covers a range of setups, the key question is always: what does this vIBAN actually resolve to — a distinct legal account, or a routing identifier over a pooled account? IBANs and their use on euro rails are defined in the SEPA framework 3.

Pooled or omnibus account

A pooled (or omnibus) account is a single legal account that holds funds for many customers, with each customer’s entitlement tracked on a ledger. Pooled models scale well and simplify account opening, but they place more weight on the ledger and on reconciliation: the legal account alone does not tell you who owns what. Safeguarding and reconciliation design become especially important in pooled models.

Reference-based reconciliation

When many customers share an underlying account, incoming payments are often matched using a reference supplied by the payer. Reference-based reconciliation works well when references are present and correct, but it fails when they are missing, wrong or truncated, producing unallocated funds that must be investigated. A model that depends heavily on references needs a robust exception process.

Unique identifiers

Alternatively, each customer or purpose can be given a unique identifier — such as a dedicated vIBAN — so that incoming payments are attributed by the destination identifier rather than by a reference. Unique identifiers reduce reliance on payer behaviour and can make attribution more reliable, at the cost of managing a larger set of identifiers. The choice between reference-based and identifier-based attribution is central to reconciliation quality.

Ownership and account-holder presentation

Who the account “belongs to” for payment purposes, and whose name a customer sees, can differ across models. In a named model the customer may be the presented holder; in a pooled model the customer sees a ledger balance while the legal account is held by the provider or programme. Be precise and accurate about presentation, and avoid implying a customer has a separate bank account when they hold a ledger entitlement.

Customer-facing implications

The account model affects what customers can do and expect. It influences whether they can share an IBAN in their own name, how a payment appears to a counterparty, and how balances are shown in your product. Aligning the customer experience with the underlying reality avoids support issues and misleading impressions — a theme that also runs through embedded-finance architecture.

Incoming and outgoing payment handling

Incoming payments must be attributed to the right customer, whether by destination identifier or by reference. Outgoing payments must be funded from the correct entitlement and presented with appropriate originator details. In pooled models, both directions rely on the ledger being correct and reconciled; in named models, attribution is more direct. Map both flows for each model you consider.

Returns and investigations

Returns, recalls and investigations behave differently across models. In a named account, a return typically relates cleanly to one customer. In a pooled account, a return must be traced through the ledger to the right entitlement, and an unallocated or misreferenced payment can complicate the process. Ask how each model handles returns, recalls, and payment investigations before committing.

Safeguarding implications

The account model interacts with how customer funds are safeguarded. Whether funds sit in named accounts or a pooled account, EMIs and PIs must protect relevant customer funds through safeguarding 1 2. Pooled models place more emphasis on reconciliation to demonstrate what is owed to each customer. For the mechanics, see how safeguarding works.

Statement and reconciliation design

Statements and reconciliation reports must reflect the model accurately. In pooled models the statement of the legal account and the ledger of entitlements are different artefacts that must reconcile to each other. Design statements so that operations can reconcile daily and so that customers see an accurate view of their balance and transactions.

Country and rail restrictions

Not every model works identically in every country or on every rail. IBAN handling, acceptance of vIBANs by counterparties, and rail-specific rules can vary 3. Some counterparties or schemes may treat certain identifiers differently. Test the model against the specific countries, currencies and rails in your roadmap rather than assuming uniform behaviour.

Decision matrix by use case

Use case	Priority	Model often considered
Customer needs an IBAN presented in their own name	Clear ownership presentation	Named / dedicated account
High volume of many small balances	Scalable account opening	Pooled with ledger
Attribute incoming payments reliably at scale	Attribution without payer references	Unique vIBAN per customer
Collections where payers omit references	Reduce unallocated funds	Unique identifiers per payer/purpose
Simple treasury with few counterparties	Operational simplicity	Named account(s)

This is orientation only; the right model depends on your product, safeguarding design and operations. See the add accounts and IBANs stack for how these choices fit a build.

Account-model selection checklist

• Confirmed what each vIBAN actually resolves to (distinct account vs routing identifier)
• Legal account and ledger account roles documented for the chosen model
• Incoming attribution method chosen (reference-based vs unique identifier)
• Returns, recalls and investigations process reviewed for the model
• Safeguarding design aligned with the account model
• Statement and reconciliation artefacts defined and shown to reconcile
• Country and rail behaviour tested against the real roadmap
• Customer presentation checked to avoid implying a separate bank account

Questions to ask providers

• For each vIBAN, does it resolve to a separate legal account or to a routing identifier over a pooled account?
• Which funds sit in a legal account, and which entitlements are tracked only on a ledger?
• How are incoming payments attributed — by destination identifier, by reference, or both?
• How do returns, recalls and investigations work in this model?
• How is the account model reflected in safeguarding and reconciliation?
• Are there country, rail or counterparty restrictions on the identifiers used 3?
• What does the customer see, and does it accurately reflect what they legally hold?

Common failure modes

• Marketing a vIBAN as a “bank account” when it is a routing identifier over a pooled account.
• Relying on payer references for attribution without a robust unallocated-funds process.
• Weak reconciliation between the legal account and the ledger in pooled models.
• Customer presentation that implies a separate account the customer does not have.
• Ignoring how returns and investigations differ across models until an incident occurs.
• Assuming identical vIBAN behaviour across every country and rail 3.

What this does not cover

This guide explains how the account models differ; it does not tell you which model is right for your product, and it does not conclude that any arrangement is compliant or that any specific vIBAN setup meets a given requirement. It is general information, not legal, regulatory or tax advice, and it does not assess any provider.

FAQ

Is a virtual IBAN a separate bank account?

Not necessarily. A virtual IBAN can be a distinct legal account, but in many arrangements it is a routing identifier that maps to an entry on a ledger over a shared underlying account. Always confirm what a specific vIBAN resolves to.

What is the difference between a legal account and a ledger account?

A legal account at a regulated institution actually holds funds; a ledger account is a bookkeeping record of an entitlement to part of those funds. A customer can hold a ledger balance without having a separate legal account in their own name.

Why does the account model affect reconciliation?

Because in pooled models the legal account holds funds for many customers, and only the ledger records who owns what. The legal statement and the ledger must reconcile, and attribution of incoming payments depends on identifiers or references.

How does the account model interact with safeguarding?

EMIs and PIs must protect relevant customer funds regardless of model 1. Pooled models rely more heavily on reconciliation to evidence each customer’s entitlement, which is why safeguarding and reconciliation design go together.

Which model should I choose?

It depends on the use case — ownership presentation, attribution needs, volume and operations. Use the decision matrix as a starting point and validate the choice against your safeguarding design and the countries and rails you operate on.