Most product teams evaluating a virtual IBAN provider start with the wrong question. They ask which country codes are on offer, how many currencies are supported, and how quickly an account can be provisioned through the API. Those questions matter, but they miss the point that a virtual IBAN is only ever a label. What determines whether it will hold up operationally, legally and financially is the infrastructure sitting behind that label. Two providers can issue what looks like an identical EUR IBAN and mean two very different things by it.

The number is not the product

A virtual IBAN identifies a payment destination without being a standalone bank account in its own right. Behind every virtual IBAN a provider issues, there is a real account at a bank or e-money institution, and the provider's platform maps incoming payments from the virtual IBAN to a ledger entry for a specific customer or transaction. The quality of a virtual IBAN provider is really the quality of that mapping layer, the account structure underneath it, and the regulatory status of the entity actually holding the funds.

This is why comparing providers on IBAN coverage alone is misleading. The more useful comparison is structural: how funds are held, how the provider connects to payment schemes, and how much of that plumbing is visible to you as the integrating business.

Pooled accounts versus segregated accounts

Almost every virtual IBAN provider builds on one of two account structures, and the choice has practical consequences.

Pooled structure. Many virtual IBANs are mapped onto a small number of underlying bank accounts held by the provider, with the provider's ledger tracking who owns which slice of the pooled balance. This is efficient to run and is the model behind most marketplace payouts, where a platform needs thousands of collection references but does not need each one to be a separately protected account. It works well for routing and reconciliation. It is less suitable where funds need to be legally ring-fenced from the provider's own balance sheet.

Segregated or client money structure. Here, funds attributable to end customers are held apart from the provider's operating funds, typically under a client money or safeguarding arrangement governed by specific rules. This matters for regulated firms such as payment institutions or e-money issuers that must demonstrate customer funds are protected if the provider fails. A virtual IBAN sitting on top of a properly safeguarded account gives a different risk profile to one sitting on a pooled operational account, even though the IBAN itself looks the same on a payment instruction.

Neither structure is universally better. A high-volume, low-value payout use case rarely needs full segregation. A platform holding customer balances for any meaningful period usually does. The mistake is not asking which one you are getting.

Where the IBAN actually comes from

A related question, and one that is easy to skip past, is how the provider connects to the payment schemes that move the money. There are broadly two positions.

A provider with direct payment scheme membership holds its own settlement account with the scheme, whether that is a domestic clearing system, SEPA, or a card network, and clears transactions without an intermediary bank. A provider without direct membership routes transactions through a sponsor or correspondent bank that does hold that membership, adding a layer between the provider's platform and final settlement.

This distinction rarely shows up in a sales conversation, but it affects two things you will care about later: typical settlement timing, and what happens operationally if the sponsor relationship changes. Indirect access through a sponsor bank is a completely normal and common model in fintech banking infrastructure, and it is often the only realistic route for a newer BaaS provider. But it means your virtual IBAN provider is itself dependent on a third party's risk appetite and commercial terms, which is worth understanding rather than discovering later.

Currency coverage is a scheme question, not a feature toggle

EUR IBAN issuance and GBP collection accounts look similar from the API documentation, but they sit on different rails with different mechanics. A EUR virtual IBAN generally routes domestic and SEPA payments directly, giving a genuine IBAN-to-IBAN transfer. A GBP account in the UK is still commonly represented by a sort code and account number pairing under the hood, even where a provider surfaces an IBAN-style reference for consistency. Payments outside the SEPA and Faster Payments zones, or in currencies without a domestic equivalent, typically fall back to cross-border payments over SWIFT, with different timing and cost characteristics.

When a provider claims broad multi-currency virtual IBAN coverage, it is worth asking which currencies clear on a local scheme and which are, in effect, being processed via international wire behind a friendly interface. The difference will show up in your reconciliation timing even if it never shows up in the marketing.

Common integration mistakes

A handful of mistakes recur across integrations, regardless of provider.

  • Assuming portability. Virtual IBANs are usually tied to the issuing provider's underlying account. If you switch API banking platform providers later, existing IBANs generally cannot move with you, which means a migration plan for customer-facing account numbers, not just a technical cutover.
  • Treating settlement times as fixed. Scheme cut-offs, sponsor bank processing windows and cross-border cover for SWIFT payments all vary, and any timing quoted should be read as typical rather than contractual.
  • Under-specifying reconciliation data. Some providers pass through full remittance information on incoming payments; others truncate it. If your reconciliation logic depends on payment references, confirm exactly what data survives the journey from payer to your ledger.
  • Skipping the account structure question. As above, pooled versus segregated is not a technicality. It affects what you can accurately tell your own customers about how their funds are held.
  • Assuming one provider covers every currency equally well. A provider strong in EUR IBAN issuance may be weaker in GBP, or may handle both only through indirect scheme access. Coverage claims are worth testing against the scheme mechanics described above.

What to ask before signing

A short, practical checklist covers most of the ground: is the underlying account pooled or segregated; does the provider hold direct payment scheme membership or route through a sponsor bank; what remittance data survives on incoming payments; what happens to existing IBANs if you migrate; and which currencies clear on a local scheme versus SWIFT. Firms such as London Rails Ltd. that operate in this space expect these questions, because the answers determine whether a virtual IBAN is a convenience layer or a genuine piece of financial infrastructure. Getting clear answers before integration is far cheaper than discovering the gaps once real customer money is moving through the account.