Explainers

Virtual IBANs Explained: How They Work and the 2027 Rules

Dmytro Medvid, Founder · 26 October 2026 · 13 min read

Virtual IBAN payment routing to a master account, illustrated as linked infrastructure nodes

Key takeaways

A virtual IBAN is an identifier that redirects payments to a master account with a different IBAN; the balance lives in the provider's ledger, not behind the vIBAN itself.
From 10 July 2027, AMLR Article 22(3) requires vIBAN issuers to identify and verify their users, and the bank servicing the master account must be able to obtain that data within 5 working days.
AMLA's final draft CDD standard (Article 9) adds the data to hold per vIBAN: user identity, the vIBAN assigned, and the associated account number with opening and closing dates.
EU supervisors still disagree on country codes and whether a vIBAN user has a payment account; the agreed PSR text drops a country-code matching rule but orders a Commission review.
For Verification of Payee on accounts an EMI holds for multiple payees, the Commission's Q&A lets the EMI and its bank agree who answers, so real-time name data must sit with whoever responds.

A virtual IBAN is an identifier that looks and works like an IBAN but has no account of its own behind it: every payment sent to it lands in a different "master" account, and the provider's ledger decides whose money it is. Until now that has lived in a legal grey zone. From 10 July 2027 much of it stops being grey: the EU Anti-Money Laundering Regulation defines virtual IBANs, makes whoever issues them identify the people using them, and requires the bank behind the master account to make sure it can obtain that information within five working days. If you are an EMI or payment institution that issues virtual IBANs, or relies on a bank or partner that does, your data model, your partner contracts and your answer to every Verification of Payee request need to be ready for that date.

This guide explains how the money actually moves, where EU supervisors still disagree, and what changes between now and 2027. It covers the EU (and the EEA states as the rules are incorporated there); UK-only set-ups follow different rules.

What a virtual IBAN is, and what it is not

There was no legal definition until the AML package. In its May 2024 report on virtual IBANs (EBA/Rep/2024/08), the European Banking Authority described the common pattern it found across member states: a vIBAN has the same format and functionality as a regular IBAN, it is linked to a master account that has its own, different IBAN, and incoming payments are credited to that master account. In some set-ups the vIBAN can also be used to send payments, debited from the master account.

The Anti-Money Laundering Regulation (Regulation (EU) 2024/1624, the AMLR) now gives it a name in law. Article 2(1), point (26): a virtual IBAN is "an identifier causing payments to be redirected to a payment account identified by an IBAN different from that identifier".

Three consequences follow, and most practical problems trace back to one of them:

Nobody outside can tell. The EBA notes that to third parties a vIBAN is typically indistinguishable from a regular IBAN, and the payer's bank does not know which master account the money really goes to.
The master account may not be in the end user's name. It can be held in the name of the end user, or in the name of the firm that hands out the vIBANs. In the second case, the EBA observed, it may also be that firm's safeguarding account.
"Account" is still disputed. Some national authorities treat a vIBAN as just another identifier of the master account; others treat it as identifying a separate payment account. That matters for consumer rights, reporting and deposit protection.

What a vIBAN is not: a balance. The balance lives in a ledger. A vIBAN is a routing and matching key, which is exactly why businesses like it: one unique number per customer or per invoice makes incoming payments self-reconciling.

How money moves through a virtual IBAN

Take a common EMI model: the EMI gives its customers vIBANs that redirect to a master account the EMI holds at a partner bank, and the EMI's own ledger credits the right customer. Depending on the set-up, the vIBANs are issued by the EMI itself or, as in the EBA's use cases 2 and 3, by the partner bank, which matters for who carries which AMLR duty. Step through the diagram to see who knows what at each stage.

A euro payment to a virtual IBAN issued by an EMI

The payer types the payee's name and the vIBAN. To the payer's bank it is just an IBAN.
Before authorisation, the payer's PSP asks for a payee check. For an account held on behalf of multiple payees, either the bank or the EMI can answer, as they agree (Commission IPR Q&A 108-110).
The transfer settles into the master account at the bank. The bank sees the vIBAN in the credit, not necessarily who uses it.
The EMI's ledger reads the vIBAN and credits the right customer balance. This mapping is the product.
From 10 July 2027 the issuer must hold verified identity data for every vIBAN user, and the bank must be able to get it within 5 working days of asking (AMLR Art. 22(3)).
Under AMLD6 Art. 16, national account registers must also cover virtual IBANs: the vIBAN number, the master account it redirects to, and opening and closing dates, so FIUs can trace a vIBAN back to the account behind it.

Simplified. Real set-ups can add more PSPs between the master account and the end user.

The weak point is visible in the diagram: the party that receives the money (the bank) and the party that knows the customer (the EMI) are different firms. Every rule coming in 2027 is about closing that gap.

The six set-ups regulators have seen

The EBA mapped six use cases. The first three are the ones most EMIs and PIs use:

Branch in the host country (UC1). A PSP with a branch in another member state issues vIBANs with that country's code, while the master account sits in the home state.
Partner PSP's country code (UC2). A PSP offers its customers vIBANs issued by a partner PSP, carrying the partner's bank identifier and the code of a country where the partner is authorised or has a branch. The first PSP has no branch there.
Same-country partner bank (UC3). A PI or EMI offers vIBANs issued by a credit institution in its own member state; the vIBANs carry that bank's identifier and country code.
Non-EU firm, non-EU customers (UC4) through an EU partner PSP.
Non-EU firm, customers worldwide including the EU (UC5).
Group treasury (UC6) allocating vIBANs to group companies.

The EBA takes no position on whether any of these is legitimate. It does record where national authorities split, and those splits are the reason a structure that is fine in one member state draws questions in another.

Three common EMI and PI set-ups compared

Criteria
Country code on the vIBAN	Same as the master account	Host state, master account at home	Partner's state, no own presence
Main supervisory disagreement	Whether the end user has a payment account of their own	Whether the account must be serviced from the host state	Whether a PSP may use a partner's country code at all
Commission or EBA signal	EBA asks for Level 1 clarity on payee verification and on whether users have a payment account	Commission's preliminary view: acceptable if the PSP has an establishment in the host state	No common view; some NCAs object
Who must identify vIBAN users from 2027	Unclear: the bank issues the vIBANs, but only the EMI knows the user (the issue the EMA raised)	You, as issuer and account-servicing PSP	Unclear: the partner issues the vIBANs and services the account; you hold the user data
Exposure if the partner exits	High: every vIBAN carries the bank's identifier	Lower: the identifiers are your own, via your branch	High: identifiers belong to the partner

The more the vIBAN's country code and bank identifier belong to someone else, the more of your product that partner controls.

Based on the EBA's May 2024 report (EBA/Rep/2024/08). Supervisory views differ by member state; check yours.

The last row is our reading rather than the EBA's, but it is the one founders feel. A vIBAN carries the bank identifier of the institution behind it, so customers' "account numbers" usually cannot move with you when a banking partner leaves. If that risk applies to you, our banking partner exit plan covers it in detail.

Why "local IBANs" are popular, and why IBAN discrimination is the wrong reason

A large share of demand for vIBANs with a particular country code comes from IBAN discrimination: employers, utilities or tax offices refusing a euro account because it starts with "LT" or "MT" instead of "FR" or "ES". That refusal is unlawful. Article 9 of the SEPA Regulation (Regulation (EU) No 260/2012) forbids payers and payees to specify the member state in which the other party's payment account must be located, provided it is reachable. The Court of Justice confirmed the principle in Verein für Konsumenteninformation v Deutsche Bahn (C-28/18), and the European Commission asks people to complain to the competent authority where it happens.

The EBA's report notes the practice persists, suggesting the SEPA Regulation is under-enforced. A February 2026 study published by the Bank of Italy's financial intelligence unit, UIF Quaderno 33/2026, goes further. Its author argues that issuing an IBAN with an altered country code addresses none of the underlying concerns, and that institutions asked for additional IBANs to get around discrimination should report the case to the competent authorities rather than fulfil the request. That is one author's view, not binding guidance. Still, if your sales deck sells local IBANs mainly as a fix for discrimination, expect supervisors to ask what the product is really for.

What the AMLR changes on 10 July 2027

The AMLR applies from 10 July 2027 (Article 90). For virtual IBANs, Article 22(3) does two things:

The issuer identifies the users. Credit and financial institutions "shall obtain information to identify and verify the identity of the natural or legal persons using any virtual IBAN they issue, and the associated bank or payment account."
The bank behind it must be able to get that data fast. The institution servicing the account to which a vIBAN issued by another institution redirects payments "shall ensure that it can obtain from the institution issuing the virtual IBAN the information identifying and verifying the identity of the natural person using that virtual IBAN without delay and in any case within 5 working days of it requesting that information."

Two points worth noticing. First, the second subparagraph speaks of the natural person using the vIBAN. Whatever the drafting intent, plan to hand over data on legal-entity users as well: a partner bank is unlikely to accept "the law only says natural persons" as a reason to hold back data on a corporate user. Second, the obligation lands on the account-servicing institution, so your bank will push it down to you by contract. Expect new information-request clauses, service levels well inside five working days, and audit rights.

The Electronic Money Association's response to AMLA's consultation argued that the second subparagraph of Article 22(3) confuses the roles of issuer and account-servicing institution, and that Article 9's "obtain and verify" goes further than the AMLR's wording. That is a fair point for models where the bank issues the vIBANs and the EMI is the one that knows the customer. Until the Commission or AMLA clarifies it (AMLA's final text keeps "obtain and verify" and does not resolve the point), map each of your structures against the wording rather than assuming the obligation sits where it is most convenient.

What AMLA's standards add

On 1 October 2026 AMLA submitted its final draft RTS on customer due diligence to the Commission. Article 9 of the final report's draft RTS turns Article 22(3) into data fields:

the standard Article 22(1) identification data on each person using the vIBAN;
the vIBAN assigned to that person;
for the associated bank or payment account, its number and the dates it was opened and, where applicable, closed.

The RTS is proposed to apply six months after it enters into force, and it is not law until the Commission adopts it and it is published. The data model, though, is unlikely to change much. We covered the rest of the CDD standard in AMLA's final CDD standards for EMIs and PIs.

Account registers: AMLD6

The Sixth AML Directive (Directive (EU) 2024/1640) requires member states to run centralised automated mechanisms that identify anyone "holding or controlling payment accounts, or bank accounts identified by IBAN, including virtual IBANs" (Article 16(1)). The general transposition deadline is 10 July 2027, and the national mechanisms must be interconnected through the Commission's BARIS system by 10 July 2029. For each vIBAN the register must show the vIBAN number, the identifier of the master account it redirects to, and opening and closing dates (Article 16(3)(d)); the account holder recorded is the master account holder. Who reports is set by national law, but the dates have to come from somewhere reliable, usually your ledger. A vIBAN reassigned without a closing date produces a wrong register entry.

Supervisors are not waiting for 2027

Germany shows the direction of travel. On 27 July 2026 BaFin announced Supervisory Communication 06/2026 (A) on the risks of virtual IBANs in connection with underground banking, applying immediately until the AMLR takes over on 10 July 2027. As summarised by Hogan Lovells, BaFin's core message is that due diligence, control and monitoring "must not end with the holder of the Master Account": institutions must, on a risk basis, get transparency over vIBAN users and their beneficial owners, record them in the account information file, check the economic plausibility of transactions and business models, and monitor flows. The communication also lists risk indicators. The measures bite where a vIBAN is actually used with third parties, not where it serves only for internal booking. The communication interprets current German law rather than adding new legislation, but it tells you what an inspection will look for.

The UIF paper points the same way, singling out chains with several intermediaries, links to non-EU SEPA countries where the AMLR does not apply, and the speed at which new vIBANs can be created and funds moved. If your model has more than two firms between the payer and the end user, assume it will be read as higher risk.

Verification of Payee: who answers for a vIBAN?

Since 9 October 2025, euro-area PSPs have had to offer Verification of Payee under Article 5c of the SEPA Regulation, as amended by the Instant Payments Regulation, and to answer verification requests as the payee's PSP. (How that date applies to EMIs and PIs has been debated; our instant-payments playbook below explains why.) With vIBANs, the awkward question is simple: when a payer types "Anna Kowalska" and a vIBAN, who confirms the name? The bank holds the master account, but in the EMI's name.

The EBA flagged this as unclear in 2024 (paragraphs 77 to 82 of its report). The Commission's IPR implementation Q&A answers the closely related case of a PI or EMI holding an account at a bank on behalf of multiple payees. Questions 108 to 110 say that Article 5c(1)(c) covers it, that three PSPs are involved, and that the EMI and the bank may agree between themselves which of them responds. The Q&A is the Commission services' reading, not a binding interpretation, and it does not mention vIBANs by name.

The practical consequence is the same either way. Whoever answers must hold the vIBAN-to-user name mapping in real time. If it is the bank, you are shipping customer names to your partner on every new vIBAN. If it is you, you are running a VoP responder. "Verification not possible" on your customers' IBANs is a fast way to lose inbound payments. For the wider instant-payments picture see our SEPA Instant playbook for EMIs and PIs.

What PSD3 and the PSR add later

The PSR final compromise text (April 2026, not yet adopted) inserts a definition of virtual IBAN into the SEPA Regulation and a new Article 2a under which a vIBAN "shall be considered to be a valid payment account identifier where the use of an IBAN is required" (Article 110c of Council document 8221/26, 17 April 2026). A January 2025 Council Presidency note proposed deleting a rule that would have forced the vIBAN's country code to match the master account's, calling it disproportionate without proper analysis, and the final compromise text leaves it out. In its place, Article 108(1b) asks the Commission, within three years of entry into force, to report on vIBANs, weighing anti-money-laundering risks against benefits, and decide whether more EU rules are needed.

That is good news for UC1-type structures, but only for now: the country-code debate was postponed, not settled, and the Commission's review could still propose a matching rule. Timing follows the PSR's application date, 21 months after entry into force; as of October 2026 the text had not yet been formally adopted or published. Our PSD3 and PSR guide covers how that clock works.

A readiness checklist for July 2027

Virtual IBAN readiness for 10 July 2027

Inventory every vIBAN structure you run
Who issues, who holds the master account, which country code and bank identifier, how many PSPs sit in the chain.
Map each structure to AMLR Article 22(3)
Name the issuer and the account-servicing institution for each one; do not assume the obligation sits with your partner.
Store the Article 9 RTS data per vIBAN
User identity, the vIBAN assigned, the associated account number, and opening and closing dates.
Never recycle a vIBAN without closing it on the record
Reassignment must leave a closed record for the old user and a new opening date for the new one.
Agree a data-request process with your bank
A target well inside 5 working days, a named contact, and a test request run before July 2027.
Decide who answers Verification of Payee
Bank or EMI, agreed in writing, with real-time name data available to whoever responds.
Monitor at user level, not master-account level
Transaction monitoring and screening should see the vIBAN user and their beneficial owners.
Confirm your NCA's view on your country codes
Especially for vIBANs carrying another member state's code or a partner's identifier.
Reconcile vIBAN ledger balances to the master account daily
Where the master account is also a safeguarding account, the two must tie out.
Tell customers what they actually hold
Pre-contract information should say whose account sits behind the vIBAN and how funds are protected.

A working list for EMIs and PIs that issue or rely on vIBANs. Saved on this device.

The reconciliation item deserves a sentence of its own. If the master account doubles as your safeguarding account, every vIBAN balance in your ledger is a claim against money in that account. A gap between the two is a safeguarding problem, not just an accounting one. The Central Bank of Ireland's October 2026 fine on Coinbase Ireland shows how regulators treat a safeguarding account that does not reconcile.

This article explains the rules as we read them and is not legal advice. Several points are still open at EU level, so confirm your structure with counsel and your national competent authority.

Our view

Virtual IBANs are not going away. The EU has chosen to regulate them rather than restrict them: the AMLR defines them, the PSR is set to make them valid payment account identifiers, and the agreed text drops the country-code matching rule. The price of that legitimacy is transparency. From July 2027 a vIBAN programme is only as good as the issuer's ability to say, within days and with evidence, who used a given number, from when to when, and on whose behalf.

That is a data and ledger problem far more than a legal one. Firms that already treat each vIBAN as a record in its own right in the ledger, with its own owner, lifecycle and audit trail, will find the AMLR mostly a documentation exercise. Firms that treat vIBANs as a reference field on an omnibus account will be rebuilding under deadline, with their banking partner watching.

The second lesson: be honest about why you issue a particular country code. A local IBAN that improves reconciliation or fits an established branch is a product. One that exists mainly to dodge unlawful IBAN discrimination, routed through a partner's identifier in a country where you have no presence, is the structure supervisors keep writing about.

If you are designing or re-plumbing a vIBAN product, the core pieces are a double-entry ledger with real-time balances and a full audit trail, back-office KYC tied to each user, and clean integrations with your payment-rail providers. That is how the Fyora platform is built, and our custom development team handles the bank-specific parts. Tell us what you're building.

FAQ

What is a virtual IBAN?

An identifier, usually in IBAN format, that redirects incoming payments to a payment account identified by a different IBAN, the master account. The AMLR defines it in Article 2(1), point (26). The provider's ledger then credits the right customer.

Is a virtual IBAN a separate bank account?

Not necessarily. EU authorities disagree: some treat a vIBAN as another identifier of the master account, others as a separate payment account. The master account may be in the end user's name or in the name of the firm issuing the vIBANs.

What changes for virtual IBANs on 10 July 2027?

The AMLR applies. Issuers must identify and verify the people using their vIBANs, and the institution servicing the master account must be able to obtain that information within 5 working days of a request. Member states must also include virtual IBANs in national account registers under AMLD6.

Can a company refuse my IBAN because it has a different country code?

In the EU and EEA, generally no. Article 9 of the SEPA Regulation stops payers and payees from specifying the member state where the other party's euro account is located, provided it is reachable. Complaints go to the competent authority where it happened.

Who answers Verification of Payee for a virtual IBAN?

For accounts a PI or EMI holds at a bank on behalf of multiple payees, the Commission's IPR Q&A (questions 108 to 110) says the EMI and the bank may agree which of them responds. Whoever does needs the vIBAN-to-name mapping in real time.