Virtual IBAN Explained: What EMIs, PSPs, and Other PayTechs Need to Know About IBAN Issuance and Ledger Design

The term virtual IBAN appears throughout the marketing of payment platforms, embedded finance providers, banking-as-a-service (BaaS) providers, and core banking vendors. It is used to describe account identifiers issued to end customers, sub-accounts within a multi-client structure, and intermediary routing references used to receive inbound SEPA payments, in some instances, SWIFT and other types of payments. In many cases, the same label describes meaningfully different instruments with different legal, ledger, and compliance implications. For an electronic money institution (EMI) or payment service provider (PSP) building or scaling payment infrastructure, that ambiguity is not harmless.

A virtual IBAN, in the strictest regulatory sense, is an International Bank Account Number that is functionally real. It routes inbound payments correctly via the relevant payment scheme and is associated with a customer or sub-account in a defined ledger structure, but does not correspond to a dedicated settlement account held directly in the firm’s name at a central bank or correspondent bank acting as a CSM (clearing and settlement mechanism).

The settlement account behind the virtual IBAN belongs to the IBAN-issuing institution, and the customer’s virtual IBAN is a routing reference layered above it. This architecture creates capabilities and risks that PayTechs need to understand explicitly before building a product on top of it.

Virtual IBAN issuance is now standard practice across EMIs, neobanks, and banking-as-a-service providers serving business clients, marketplaces, and payment aggregators. The ability to assign a dedicated virtual IBAN to each end client has become a baseline product expectation for platforms handling third-party payments at volume, so that inbound funds are automatically attributed to the right customer account without manual matching. But the ledger architecture, safeguarding obligations, AML/CTF requirements, and regulatory risks that come with virtual IBAN issuance are not always understood at the depth they deserve when a firm is designing its initial product stack.

This article examines virtual IBAN issuance from an infrastructure and compliance perspective: what virtual IBANs actually are in a regulated context, what issuing them correctly requires from your core platform, and what regulatory and operational risks arise when the ledger design and compliance framework are not built to support virtual IBAN operations at scale.

What Is a Virtual IBAN and How Does It Differ From a Standard IBAN?

What is a virtual IBAN in the context of regulated payment operations?

An IBAN or International Bank Account Number is a standardised format defined by ISO 13616 for uniquely identifying a bank account across borders. In its traditional form, an IBAN corresponds to a single, uniquely held account at a named financial institution. That account has a direct relationship with the settlement infrastructure of the country in question: it can send and receive payments on the local and international scheme, and it is held in the name of the account owner on the books of the financial institution that issued it.

A virtual IBAN is structurally different. It is a valid IBAN that routes inbound payments to a shared settlement or pooled account held by the issuing institution, with the virtual IBAN itself functioning as a routing key rather than a direct account identifier. When funds arrive at the shared settlement or pooled account carrying a virtual IBAN reference in the beneficiary field, the receiving platform matches that reference to the correct sub-account or client ledger entry and posts the credit accordingly.

For the sender, the virtual IBAN looks and functions exactly like a standard IBAN. Payments can be sent to it from any SEPA-compliant or SWIFT-connected bank. Similar arrangements are also seen in the UK, with dedicated sort codes and virtual account numbers issued by the bank to its PayTech clients, effectively acting in the same manner as virtual IBANs for SEPA. For the receiving institution, the virtual IBAN is an internal routing reference that must be matched, validated, and posted against the correct ledger position. The distinction is invisible to the payer and consequential to the PayTech operating the platform.

Virtual IBANs are now widely used by EMIs and PSPs to provide dedicated e-wallet/payment account identifiers to business clients, marketplace sellers, and payment aggregators who need to receive funds in their own name without holding a dedicated bank account at a traditional financial institution. The virtual IBAN model makes this possible at scale and at lower cost than for the PayTech becoming SEPA or Faster Payments adherent and arranging a CSM relationship and developing all required IT components and integrations.

How does a virtual IBAN differ from a standard IBAN in practice?

The practical difference between a virtual IBAN and a standard IBAN becomes visible at the point of settlement and reconciliation. When a payment is sent to a standard IBAN, the credit posts directly to the named account. When a payment is sent to a virtual IBAN, it arrives at the pooled settlement account of the EMI or PSP, carrying the virtual IBAN in the payment message, and the receiving platform must then match that reference to allocate the funds to the correct customer position within its internal ledger.

This matching and posting step is where virtual IBAN operations either work cleanly or accumulate exceptions. If the virtual IBAN reference is structured correctly, the matching is automated and immediate.

If the payer omits or truncates the virtual IBAN in the beneficiary account field, which happens regularly in cross-border and SWIFT-originated payments (but not in SEPA or FPS), the credit arrives at the settlement account without a usable routing key. That credit must then be investigated manually: the operations team must identify which client it belongs to, often by cross-referencing the payer name, the amount, and the expected payment schedule.

At low volume, unmatched virtual IBAN credits are an operational nuisance. At the transaction volumes typical of a growing EMI or payments platform, they become a measurable reconciliation liability. A virtual IBAN architecture that does not include robust exception handling, automated matching logic, and a clear workflow for unmatched credits will generate a growing queue of unresolved items that affects both the client experience and the regulatory reporting position.

The second practical difference is accountability. A standard IBAN is typically held in the name of the account owner and corresponds to an account held directly in the name of the customer within the books of the financial institution. The EMI or PSP maintains the customer relationship and is responsible for ensuring that all transactions routed through such identifiers are subject to appropriate controls, including AML/CTF monitoring, sanctions screening, and regulatory reporting.

While the end customer remains responsible for their own activities, the institution is accountable for maintaining effective systems and controls to detect, prevent, and report financial crime in accordance with applicable regulatory requirements.

Why is the term “virtual IBAN” sometimes misleading in a regulatory context?

The word “virtual” implies something lightweight or informal, which is precisely the wrong framing from a regulatory perspective. A virtual IBAN issued by a licensed EMI or PSP is a payment identifier that is linked to an omnibus account held with a financial institution. Payments received through a virtual IBAN must be screened, attributed, reconciled, safeguarded, and reported in exactly the same way as payments received through any other account structure. The “virtual” qualifier describes the technical architecture, not the compliance weight.

Notably, depending on the operating model, virtual IBANs may be generated by the banking partner from its own IBAN range and mapped to a pooled account, or assigned through a BaaS infrastructure. In all cases, the IBAN structure remains within the bank’s namespace, and the EMI or PSP relies on the underlying credit institution to enable IBAN-based payment functionality.

The regulatory framing was made explicit by the European Banking Authority (EBA) in its 2022 Opinion on virtual IBANs, which clarified that virtual IBAN issuance does not create a new regulatory category and does not reduce the obligations of the issuing institution under PSD2, AMLD, and applicable national frameworks.

The EBA further noted that competent authorities had identified inconsistencies in how virtual IBANs were being supervised across member states, with some jurisdictions applying lighter-touch oversight on the assumption that virtual IBAN products were lower risk than standard accounts, a framing that the EBA explicitly rejected.

The implication for PayTechs building virtual IBAN products is direct: a virtual IBAN arrangement does not reduce your compliance obligations. It may, in certain sponsored arrangements, distribute them between the issuing institution and an underlying bank, but it does not eliminate them. Understanding who holds which obligation is a prerequisite for any virtual IBAN product design.

Virtual IBAN Issuance And What It Requires From Your Infrastructure

Who can issue virtual IBANs, and what does the regulatory framework require?

The ability to issue virtual IBANs is not a technical capability that any platform can offer; it is a regulated activity tied to the licensing, payment scheme rules adherence, and CSM or correspondent banking arrangements of the issuing institution. In practice, virtual IBAN issuance takes three main forms in the European market, each with distinct infrastructure and compliance implications.

The first is direct virtual IBAN issuance by a licensed EMI or PSP. A firm that holds its own EMI licence and has direct access to payment schemes through either direct participation or a CSM, can issue direct virtual IBANs to its own clients from its IBAN generation mechanism based on MOD-97, which takes into account institution’s BIC, bank number, allocated by the relevant national numbering authority, and national IBAN composition rules. In this model, the issuing EMI is directly accountable for all compliance, safeguarding, and reporting obligations associated with those virtual IBANs.

The second is sponsored virtual IBAN issuance, where a PayTech that has not yet obtained direct scheme access, uses a bank or licensed EMI as an upstream sponsor to issue virtual IBANs on its behalf. The sponsor holds the settlement/pooled account; the PayTech’s virtual IBANs route inbound payments to that account. This is a common model for earlier-stage fintechs and smaller PayTechs platforms, but it introduces a dependency risk and a contractual compliance split that must be explicitly understood and managed.

The third is sub-IBAN issuance to end clients, where a licensed EMI issues virtual IBANs to its own platform clients (typically businesses or marketplace operators) so that those clients can receive payments in their own reference without holding an account directly at a bank. This is the model used by most BaaS-enabled PayTechs and neobanks that offer business accounts. Each sub-virtual IBAN carries the same compliance obligations as a primary IBAN from the issuing institution’s perspective.

The regulatory framework applicable to virtual IBAN issuance in the EU rests primarily on PSD2 (payment account obligations, execution standards, and safeguarding), the Second Electronic Money Directive (EMD2) (issuance and redemption of electronic money), and the Sixth Anti-Money Laundering Directive (6AMLD) and its national transpositions. In the UK, the FCA’s Payment Services Regulations 2017 and Electronic Money Regulations 2011 apply, alongside the updated safeguarding requirements under PS25/12.

What ledger architecture does virtual IBAN issuance require at scale?

Virtual IBAN issuance at scale creates a specific ledger design challenge: how do you maintain a clean, reconcilable mapping between thousands of virtual IBANs, their corresponding client ledger positions, and the underlying settlement account at the correspondent bank, while ensuring that every credit, debit, fee, and adjustment is attributed to the correct virtual IBAN and correct settlement/pooled account without manual intervention?

The answer lies in the relationship between the virtual IBAN registry, the internal ledger, and the settlement account reconciliation process. A virtual IBAN registry is the platform’s internal database that maps each virtual IBAN to a specific account or client profile. When an inbound payment arrives at the settlement account, the platform queries the registry using the virtual IBAN reference in the transaction data, identifies the correct internal account, and posts the credit. If the matching is clean, the process is automated and real-time. If the registry is incomplete, stale, or inconsistently maintained, the matching fails and the credit lands in an exceptions queue.

The ledger design must also account for the lifecycle of a virtual IBAN: creation, activation, assignment to a client or sub-account, any changes in routing instructions, suspension, and eventual decommissioning. Each state change must be logged with a timestamp and a responsible user or system action. Regulators and auditors reviewing a virtual IBAN operation expect to be able to reconstruct, for any given virtual IBAN at any point in time, which client it was assigned to, what credits and debits passed through it, and what its current status is.

A ledger that cannot support that reconstruction creates an audit liability that becomes increasingly expensive to resolve as the virtual IBAN book grows, because virtual IBAN assignments are held separately from transaction records, or because lifecycle changes are not logged.

How does virtual IBAN issuance interact with safeguarding obligations?

For a licensed EMI or PSP, safeguarding obligations require that customer funds received through any account structure (including virtual IBANs) are held in a designated safeguarding account, clearly segregated from the firm’s own operational funds, and reconciled daily against the ledger balances attributable to each client. Virtual IBAN issuance creates a specific safeguarding complexity: because all virtual IBANs route inbound payments to a shared settlement account, the pooled balance at the correspondent is not, by itself, attributable to any individual client. The attribution happens in the ledger, not at the settlement layer.

This means that safeguarding compliance for a virtual IBAN operation depends entirely on the accuracy and timeliness of ledger attribution. If a payment received through a virtual IBAN is not correctly attributed to the right client account before the end-of-day safeguarding calculation, the safeguarding position is inaccurate. If that inaccuracy is not detected and corrected through daily reconciliation, the firm is in breach of its safeguarding obligations, not because it misappropriated funds, but because its attribution process failed.

The FCA’s updated safeguarding regime under PS25/12, which comes  into force in May 2026, reinforces this point directly. Firms are required to demonstrate that their reconciliation processes can identify and resolve discrepancies in the attribution of client funds on a daily basis, and to maintain documented evidence of how discrepancies were identified, investigated, and corrected. A virtual IBAN operation that relies on batch reconciliation on the following business day, or that treats unmatched credits as acceptable exceptions to be cleared over time, will not meet this standard.

Another issue related to the safeguarding arises in the situation where the virtual IBANs are issued by an EMI A (instead of the safeguarding bank) to another regulated EMI B. The implication is critical, as EMI B keeps the clients’ funds (for which virtual IBANs are issued by EMI A) with another electronic money institution, which can’t be used for the safeguarding of clients’ funds, as it is not a credit institution.

Therefore, the EMI B needs to move in and out funds between their settlement/pooled funds account and the safeguarding bank account. Unless the EMI B has significant own capital funds and can prefund the settlement/pooled funds account for the execution of the e-money redemption, it becomes a significant operational challenge. 

Baseella’s Approach: Virtual IBAN Issuance With Native Ledger and Compliance Integration

The infrastructure requirements described throughout this article: clean virtual IBAN registry management, automated credit attribution, real-time safeguarding reconciliation, integrated AML/CTF screening, and a complete virtual IBAN lifecycle audit trail are not features that can be bolted onto a generic core banking platform or managed through a collection of spreadsheets and manual processes. They are platform capabilities that must be designed in from the start.

Baseella supports virtual IBAN issuance as a native capability within its core platform. Each virtual IBAN is maintained in the platform’s account registry with a full lifecycle record: creation timestamp, client assignment, status history, and a complete transaction ledger of every credit and debit that has passed through that virtual IBAN reference. The ledger entry for an inbound payment is posted automatically on receipt of the settlement notification, with the virtual IBAN matching logic running internally against the registry held within the platform, without an external API call or a manual intervention step.

Safeguarding reconciliation is performed natively within Baseella, with daily reconciliation of the aggregate virtual IBAN ledger against the settlement account balance and a documented exception workflow for unmatched credits. Compliance screening for inbound payments (sanctions screening, PEP, adverse media checks) runs through Baseella’s internal Block lists module, which holds a continuously updated local copy of applicable sanctions lists and screens inbound transactions at the point of posting rather than via an external API call per transaction.

Transaction monitoring rules configured by the client’s compliance team apply to virtual IBAN credits and debits in the same workflow as all other transactions, with alerts flowing directly into the case management queue without a system switch.

For licensed EMIs and PSPs building or scaling a virtual IBAN product, the diagnostic questions are the same regardless of the platform in question: how is the virtual IBAN-to-account mapping maintained and audited, how are unmatched credits identified and resolved, how does AML screening apply to inbound virtual IBAN payments in real time, how is the daily safeguarding reconciliation produced and reviewed, and what does the virtual IBAN lifecycle audit trail look like in the event of a regulatory review. The answers to those questions determine whether a virtual IBAN capability is a scalable product or an operational liability waiting to surface.

Baseella is a core banking and payments platform built for electronic money institutions, payment institutions, neobanks, money service businesses, and crypto-asset service providers. To see how Baseella supports virtual IBAN issuance with integrated ledger management, safeguarding reconciliation, and compliance screening, visit Baseella online or schedule a demo.