What is a Virtual Account?

A virtual account is a sub-account linked to a physical bank account, often referred to as the Header Account, Physical Account or Master Account, that carries its own externally addressable payment details: a unique sort code, account number, and IBAN. Payers can send money to it and receive money from it exactly as they would with any physical bank account. The difference is structural: funds settle in the underlying Header Account, while the virtual account acts as a uniquely trackable address, recording its own opening and closing balances and all debit and credit transactions against it.

That single idea, that many externally addressable account numbers sitting over one Header Account, is what makes virtual accounts powerful. A Bank of London client can give every customer, counterparty, or purpose its own payment details without opening, managing, and reconciling hundreds of physical accounts.

A virtual account is not a holding account. It is an addressing and ledgering layer that routes payments and provides per-account visibility of activity, while all funds sit in the Header Account.

What is a vIBAN?

The terms "virtual account" and "vIBAN" are often used interchangeably, and at Bank of London they refer to the same thing. A vIBAN is not a separate product layered on top of a virtual account; it simply describes the payment addressability that every virtual account carries. When someone says vIBAN, they are referring to the fact that the virtual account has real, externally addressable payment details that work across payment schemes.

What those details look like depends on the payment scheme. In the UK, domestic payments are identified using a Sort Code and Account Number. For international payments, the IBAN (International Bank Account Number) is the standardised format. In the UK, an IBAN is derived from the sort code and account number, with a country code, check digits, and bank identifier added to produce the internationally recognised string. The same underlying account has both a Sort Code and Account Number for domestic rails and an IBAN for international ones; they are two expressions of the same account identity.

Every Bank of London virtual account carries both: its own sort code and account number for domestic payments, and a corresponding IBAN for international payment schemes. That full payment addressability across both domestic and international rails is what the term vIBAN captures.

It is important to be precise here: having an IBAN does not determine which currencies an account can receive. Currency capability depends on how the virtual account is configured. A virtual account may be denominated in a specific currency, or Bank of London may convert an incoming currency into the account's denominated currency (subject to applicable conversion fees). The IBAN is an identifier, not a currency instruction. All Bank of London virtual accounts whether they are used domestically or for cross-border payments are issued with externally addressable details that include an IBAN. There is no meaningful distinction between a "virtual account" and a "vIBAN" in this sense; the IBAN is simply part of the account's standard externally addressable details.

From a payer's perspective, a vIBAN is a real, valid IBAN. It passes validation and routes through payment systems as expected. "Virtual" describes the receiving structure, where it maps to an underlying Header Account rather than holding funds itself.

How do virtual accounts work?

Every virtual account structure has two layers:

1. The Header Account is a physical bank account held in the Bank's ledger, sometimes called the Master, Settlement, or Physical Account. This is where funds actually sit. The Header Account is held by the Bank's client and typically carries all the usual protections and regulatory treatment that a bank account with Bank of London implies.
2. The virtual layer sits below the Header Account. An unlimited number of virtual accounts can be provisioned against it, each with its own externally addressable details: a unique sort code, account number, and IBAN. Payers and payees interact with a virtual account exactly as they would with any standard account, the account details are real and fully functional. Payments arriving at a virtual account are automatically credited to the Header Account and tagged to the specific virtual account they came through. Payments made out follow the same logic in reverse: debited from the Header Account and recorded against the virtual account from which the instruction was made.

Each virtual account maintains its own opening and closing balance and records account-specific debit and credit transactions. Any payments that cannot be automatically reconciled to a virtual account are held in a suspense account, ensuring the Header Account's total balance always equals the sum of all virtual account balances. This keeps unreconciled items to a manageable, remittance-supported set rather than losing them in a single pool.

Because provisioning a virtual account is a data operation rather than a new account opening, Bank of London can create virtual accounts rapidly via API or online platform (subject to the client's own onboarding process for the customers or entities to which those accounts will be assigned). Clients can organise virtual accounts in a hierarchy: a top-level Header Account, with virtual accounts nested per customer, per currency, per entity, or per purpose, structured to mirror how the business actually operates.

Virtual aggregation nodes are a Bank of London-specific feature that takes this hierarchy further. A virtual aggregation node is a configurable, non-transactional layer that sits above virtual accounts in the hierarchy, similar to a branch in a tree, grouping accounts logically without itself holding funds or processing payments. Clients can create as many nodes as they need, named and arranged to reflect their own business structure: by business unit, product line, customer segment, or any other dimension. Each node and account can be given a custom name, replacing generic bank-issued labels with terminology that maps to how the business actually operates. Critically, the entire hierarchy, every node and every account within it, is exposed via Bank of London's API, allowing clients to programmatically manage structures, assign granular permissions, and control precisely which users or systems can view or act on each part of the hierarchy. This means a single Header Account can serve an entire organisation while maintaining full segmentation, visibility, and access control across teams, entities, and products - without the need for multiple physical accounts.

What are virtual accounts used for?

Bank of London provisions virtual accounts on Header Accounts configured for two primary use cases.

Use case 1: Corporate cash management

In corporate treasury and in-house banking, virtual accounts replace networks of physical subsidiary accounts. Each entity, region, business line, cost centre, or operating account gets its own externally addressable account details under a centralised Header Account structure. Treasury gains real-time visibility of each account's position, natural cash concentration, and clean intercompany tracking, without the cost and overhead of maintaining dozens of physical accounts across banks.

Virtual accounts also solve payment reconciliation at scale. When all incoming payments arrive into one account, finance teams reconcile by payment reference, a process prone to errors, omissions, and manual matching. When every payer or purpose has its own virtual account number, each inbound payment arrives pre-labelled by its account. Reconciliation becomes automatic: the account number itself identifies the source. Any unmatched items go to the suspense account rather than a pooled unallocated balance, giving the Header Account owner a clearly bounded set to resolve.

Use case 2: Client and customer externally addressable accounts

When a regulated financial institution creates a wallet for their customer, that wallet is a virtual account. The virtual account is what gives the wallet its externally addressable payment details: a sort code, account number, and IBAN allocated to that customer's wallet. Those details are real. The customer can share them with their own payers, receive payments directly, and access UK payment schemes exactly as they would with a standard bank account.

The end customer interacts entirely through the wallet interface their provider (the Bank’s client) has built, seeing their transaction history, live balance, and pending payments within that experience. They have no direct interaction with Bank of London. The bank's role is invisible to them; what they see is their provider's product, powered by the virtual account infrastructure underneath it.

A worked example

An e-money institution serves 3,000 business customers, each receiving funds from their own payers. With a single collection account, every inbound payment requires matching by reference which is a full-time reconciliation problem at that scale, and one that breaks whenever a payer omits or mistypes a reference.

Instead, the platform provisions each customer a virtual account with their own externally addressable details: a sort code, account number, and IBAN allocated to that customer. Payers pay (for example) "Customer Ltd" directly, at those details. Funds settle in the platform's Header Account, pre-tagged to each virtual account. The platform's ledger shows each customer's real-time position. Unmatched items are captured in the suspense account, where they can be resolved with full remittance data, rather than sitting unidentified in a pooled balance.

When a customer needs to receive payments from overseas payers, the platform configures an additional virtual account denominated in the relevant currency against the same Header Account structure. No new bank account is opened anywhere in the process.

Things to consider with virtual accounts

The Header Account is what counts. Where funds actually sit (which institution, what account type, what regulatory treatment) is determined by the Header Account. Virtual accounts inherit these properties; they do not create new ones. Depositor protection such as the FSCS applies, where eligible, at the level of the Header Account.

Client and customer onboarding still applies. Virtual accounts can be provisioned rapidly as a technical matter. Where they are being issued to end customers, those customers must be appropriately onboarded by the client. The speed of technical provisioning reflects the data operation behind account creation, not a bypass of onboarding obligations.

Naming and Confirmation of Payee. How a virtual account presents to payers, including through Confirmation of Payee in the UK, depends on implementation. Understanding this is important for payer experience and payment fraud prevention.

Data structure is a design decision. The value of virtual accounts comes from mapping them thoughtfully to your business: per client, per currency, per entity, per purpose. Hierarchy depth, API capability, and reporting tools differ between providers.

They are not a compliance shortcut. For regulated firms, virtual accounts support segregation and record-keeping but do not by themselves discharge client money, safeguarding, or other regulatory obligations. The underlying account arrangements and the firm's own controls do that work.

Frequently asked questions

What is a virtual account?

A virtual account is a sub-account linked to a physical bank account, the Header Account, held in Bank of London's ledger. It carries its own externally addressable payment details (sort code, account number, and IBAN), so payers can send and receive money to it exactly as they would with any standard bank account. Funds settle in the Header Account, while the virtual account records its own transaction history and balance.

What is a vIBAN?

A vIBAN is the IBAN associated with a virtual account. Every Bank of London virtual account carries an IBAN as part of its externally addressable details. The term "vIBAN" simply describes the IBAN belonging to a virtual account structure - the IBAN itself is real, valid, and routes normally through domestic and international payment systems.

Can a virtual account hold money?

No. Funds sent to a virtual account settle in the underlying Header Account. The virtual account provides the externally addressable payment details and a per-account view of all activity, but does not hold funds itself.

Is a virtual account a real bank account?

Not in its own right; the bank account is the Header Account. The virtual account's payment details are real and externally addressable, and payers can pay to and receive from them as they would any standard account. The account itself is a routing and ledgering layer over the Header Account, which is where the funds and the banking relationship sit.

How quickly can virtual accounts be created?

Provisioning a virtual account is a data operation against an existing Header Account, so it can be done rapidly via API or online platform. How quickly an account can be made available to an end customer depends on the client's own onboarding process for that customer.

Is a vIBAN a real IBAN?

Yes. From a payer's perspective, a vIBAN is a valid IBAN that passes validation and routes normally through domestic and international payment systems. "Virtual" refers to the receiving structure (where the IBAN maps to an underlying Header Account) not to the IBAN identifier itself.

Are virtual accounts safe?

Funds sit in the underlying Header Account, so safety depends on the institution holding it and the account arrangements behind the virtual layer. The same considerations apply as for any bank account, including eligibility for depositor protection at the level of the Header Account. The virtual layer is an addressing and reporting structure; it does not change where the funds are held or who holds them.

What is the relationship between a virtual account and a digital wallet?

A virtual account is the technical infrastructure that makes a digital wallet's payment details real and externally addressable. When a platform issues a wallet to an end user, the wallet's sort code, account number, and IBAN are the externally addressable details of the underlying virtual account. The virtual account is what gives the wallet its bank-grade payment identity - they are not inherently separate things.

Important information

This page is provided for general information only. It describes products, services and industry concepts in general terms and does not describe the products, features or terms available to any particular client. Availability of anything described here depends on the arrangements agreed with Bank of London and on the applicable product terms and contractual documentation, which prevail over the content of this page.

Nothing on this page constitutes an offer, commitment, invitation or recommendation to provide any product or service, or legal, regulatory, tax or accounting advice. Where regulatory requirements are referred to, responsibility for identifying and meeting them rests with the firm concerned and depends on its own permissions and circumstances. Recipients should take their own professional advice and should not rely on this page in making any decision.

This page reflects our understanding at the date of publication and may not reflect subsequent changes in law, regulation or our products.

‍