Virtual IBANs: A Decision Framework by Platform Type

Most virtual IBAN comparison content treats the market as though every platform needs the same thing. They don’t. A payroll company distributing salaries across 30 countries has fundamentally different infrastructure requirements than a trading platform segregating client funds under FCA CASS rules, or a PSP whose Lithuanian IBANs keep getting rejected in France.

This guide maps five platform archetypes to the infrastructure requirements that should drive your provider decision. The question is not which provider is best. It is which provider is best for the way your platform actually moves money.

Payroll and EOR platforms: settlement predictability, payout reach, and named accounts

Payroll platforms collect from corporate clients in one currency and distribute salaries across multiple jurisdictions on strict monthly cycles. The core failure mode is straightforward: an employee does not get paid on time. That makes settlement predictability the first filter. Infrastructure providers need to offer settlement windows reliable enough to anchor payroll cycles around, not aspirational timelines that vary by corridor.

The second differentiator is geographic payout coverage. Most providers handle EUR, GBP, and USD collection well. The disbursement side separates them. Currencycloud offers deep FX liquidity across 35+ currencies. Lorum covers 30+ markets across Europe, the Middle East, and Africa through a single clearing integration, with strength in corridors that SEPA-focused providers don’t reach. Banking Circle provides direct access to 11 local clearing schemes, strong for high-volume SEPA payroll.

The third requirement is named client accounts. Corporate clients depositing large sums for salary distribution expect to see their company name on the receiving account. Named IBANs also eliminate the most common reconciliation failure in payroll: truncated or missing payment references on incoming wires. Pooled models, where attribution depends on references surviving every hop in the banking chain, create friction at scale.

Marketplaces and gig platforms: choosing between PSP orchestration and clearing infrastructure

The infrastructure decision for marketplaces is not really about providers. It is about which layer of the stack your platform needs. Consumer-facing e-commerce and gig marketplaces needing checkout, card acquiring, and split payments are best served by PSP-style providers. Stripe Connect dominates this segment. Mangopay and Adyen offer similar capabilities with different regional strengths and enterprise positioning.

Virtual IBAN infrastructure becomes relevant at a different layer: B2B marketplaces, regulated platforms holding funds on behalf of others, and operators building their own payment orchestration rather than using a PSP’s. Lorum and Banking Circle provide multi-currency clearing and custody infrastructure beneath a platform’s own orchestration layer. Airwallex brings strong marketplace capabilities with payouts in 150+ countries and like-for-like settlement.

The critical question: do you need a PSP with built-in marketplace logic, or raw clearing infrastructure because you are building your own? The answer determines the entire provider category, not just the shortlist.

__

Licensed PSPs and EMIs: safeguarding, IBAN discrimination, and why your provider’s compliance is yours

PSPs and EMIs occupy a unique position: they are themselves regulated entities building customer-facing products on top of virtual IBAN infrastructure. That means the provider’s compliance posture does not just affect the PSP. It becomes the PSP’s compliance posture. Three factors dominate this decision.

EMIs must hold client funds in segregated accounts at credit institutions. Named custody account structures make this straightforward. Pooled models with ledger-only segregation create audit complexity and regulatory risk. The EBA’s 2024 report on virtual IBANs flagged ten risk categories. The new EU AML Regulation goes further: it formally defines virtual IBANs for the first time in EU law and requires issuers to identify end users and register their details in member state bank account registers. Lorum’s custody account model, where each client account is named and segregated, aligns with this regulatory direction. Clear Junction, FCA-regulated, serves PSPs and EMIs in UK and EU corridors with compliance-first onboarding.

IBAN discrimination compounds the challenge. A PSP licensed in Lithuania issuing IBANs with an LT country code faces systematic rejection by payers and their banks in France, Germany, and Spain, despite SEPA rules requiring equal treatment. Banking Circle can issue across multiple SEPA country codes from its Luxembourg banking licence. Providers with multi-currency issuance outside SEPA reduce this risk further. The onboarding model matters too: providers built for SMEs have KYB processes that don’t accommodate nested compliance structures. Providers purpose-built for regulated entities (Banking Circle, Lorum, Clear Junction) design institutional onboarding from the start.

Trading and investment platforms: why client money segregation is non-negotiable under CASS and MiFID II

Under FCA CASS rules, MiFID II, and the SEC custody rule, client funds must be held separately from the platform’s operational funds. The requirement is structural, not presentational: each client’s funds must be identifiable, attributable, and protected in the event of insolvency. Ledger entries inside a pooled account do not satisfy this.

Named virtual IBANs address this at the infrastructure level. Deposits are automatically attributed to the correct client without reference matching, and the audit trail is built into the account structure rather than layered on after the fact. Pooled models place the burden of proof on the platform to demonstrate that its internal ledger constitutes adequate segregation. The regulatory direction across jurisdictions favours structural separation. Lorum’s custody account model, with named client accounts and DFSA regulation, aligns with what compliance teams need to evidence to auditors.

For crypto exchanges, the virtual IBAN serves as the fiat on-ramp and off-ramp. Correspondent banks are increasingly scrutinising vIBAN-originated payments connected to digital assets, and some have restricted them entirely. BCB Group has built infrastructure specifically for digital asset businesses, offering virtual IBANs in GBP and EUR alongside its BLINC network for instant crypto-fiat settlement.

Embedded finance and BaaS: full-stack bundling vs modular clearing infrastructure

The platform embedding financial services typically never touches virtual IBAN infrastructure directly. It works through a BaaS provider, and the vIBAN provider sits one layer beneath. Full-stack BaaS providers like Solaris, Railsr, and Gemba bundle accounts, cards, payments, and compliance into a single API. This is the right model for platforms that are not themselves regulated and need the entire product stack delivered as a service. Infrastructure-layer providers serve licensed fintechs building their own stack and needing clearing and settlement as a discrete component.

__

Geographic scope is what separates providers at this layer. Most BaaS platforms concentrate on Europe and the UK. Platforms building for the Middle East, Africa, or genuine multi-region coverage need clearing partners with infrastructure in those markets. Lorum spans 30+ markets across Europe, the Middle East, and Africa, serving as the clearing layer beneath BaaS providers or directly for licensed platforms.

Match your archetype to what matters

__

2. Payroll/EOR: settlement predictability, payout coverage well beyond SEPA, named client accounts for corporate trust and reconciliation.

3. Marketplaces: PSP orchestration vs raw clearing infrastructure. B2B and regulated marketplaces need the latter. Consumer marketplaces need the former.

4. PSPs/EMIs: safeguarding account structure, IBAN country codes to avoid discrimination, EU AML readiness, institutional onboarding. Your provider’s compliance model becomes yours.

5. Trading/investment: named custody accounts as the structural answer to client money segregation rules. Pooled models create audit risk.

6. Embedded finance: full-stack BaaS vs clearing-layer infrastructure. Geographic coverage outside Europe is the differentiator most platforms underestimate.

The common thread across every archetype is account structure. The market is moving from pooled virtual IBAN models toward named custody accounts with structural fund segregation, driven by regulators, auditors, and the platforms themselves. The most expensive mistake is not choosing a slightly pricier provider. It is choosing one whose account structure or compliance model does not fit your use case, and discovering that six months into an integration.

Frequently asked questions

What is the difference between a virtual IBAN and a custody account?

A virtual IBAN is typically a reference number layered on top of a pooled omnibus account. Incoming payments are routed to the pool and attributed to the correct client via the reference. A custody account is a named, individually held account at a credit institution, registered to the end client. The distinction matters for safeguarding, audit, and regulatory compliance: custody accounts provide structural fund segregation, while virtual IBANs rely on ledger-level segregation within a shared pool.

Can I use the same virtual IBAN provider across all five platform types?

In theory, yes. In practice, the requirements diverge enough that a provider optimised for one archetype will have meaningful gaps in another. A PSP-layer marketplace provider like Stripe Connect does not offer the custody account infrastructure a trading platform needs for CASS compliance. A clearing-layer provider like Banking Circle or Lorum does not offer checkout or card acquiring. Choosing a provider means choosing a layer of the stack, not just a feature set.

Why does IBAN discrimination matter for my provider choice?

IBAN discrimination occurs when payers or their banks reject payments to IBANs from certain country codes, despite SEPA regulation requiring equal treatment. If your provider issues IBANs from a single jurisdiction (for example, Lithuania), your end clients may face rejected payments in markets like France or Germany. Providers with multi-country IBAN issuance capabilities, or those operating outside SEPA entirely, reduce this risk significantly.

What does the new EU AML Regulation mean for virtual IBANs?

The EU’s Anti-Money Laundering Regulation (AMLR) formally defines virtual IBANs for the first time in EU law. It requires issuers to identify end users and register their details in member state bank account registers. This is a material shift for pooled models where end-user visibility has historically been limited. Platforms using virtual IBAN infrastructure in the EU should confirm their provider’s roadmap for compliance with these requirements before the regulation takes effect.

How do I evaluate whether I need a BaaS provider or direct clearing infrastructure?

If your platform is not itself regulated and you need compliance, licensing, and product APIs bundled together, a BaaS provider is the appropriate layer. If your platform holds its own licence and wants to control the product experience while outsourcing clearing and settlement, direct clearing infrastructure is the better fit. The decision comes down to whether you need a full product stack or a specific infrastructure component beneath your own.