Virtual IBANs for Multinational Receivables Management

A vIBAN can't hold money on its own, and that single fact explains almost everything a multinational's finance team gets wrong once the business crosses its second or third border. Opening a local sales channel in a new country causes incoming payments to start pooling into shared accounts with no automatic link back to the entity, currency, or invoice that generated them. Closing that gap between money arriving and money being understood is what virtual IBANs are for, but doing it right takes more than signing up for a product. It takes knowing how the mechanism actually works, and where the regulatory ground is shifting under it, particularly in Europe right now.

The dysfunction compounds fast once a company operates across five or six jurisdictions. Finance teams burn disproportionate hours every month-end doing manual matching, trying to work out which customer, in which country, paid which invoice. FX exposure creeps up because funds get converted at whatever default rate the payment service provider applies, rather than at a time treasury actually chose. Liquidity goes dark: cash sits in siloed local accounts, technically the company's own money, but unreachable by the center when it's needed. And every new market tends to demand its own banking relationship, its own onboarding timeline, its own local compliance paperwork, its own reporting format that talks to nothing else in the stack.

The scale of the problem only moves one direction. Swift's analysis puts cross-border payment volumes on track to top $183 trillion by 2027, which puts the reconciliation burden on the same growth curve as the payments themselves. Treasury teams, finance ops, and CFOs at multinational corporations, or the agencies and platforms running financial operations on their behalf, need to solve this on purpose. Papering over it with spreadsheets stops working long before the volume does.

What a virtual IBAN is and how it differs from a physical bank account

A virtual IBAN is a digital sub-account identifier tied to a master physical bank account held at a licensed institution. It receives payments and routes them into that master account, but it carries metadata along the way, tagging each transaction with information the master account alone would never preserve.

From the payer's side, nothing changes. Sending money to a vIBAN looks and feels exactly like sending to any standard IBAN: same format, same rails, nothing unfamiliar to explain to a customer in any given city. On the receiving side, though, funds land in the master account carrying identifiers that specify the entity, currency, customer, order, or product involved, depending on how that particular vIBAN was set up.

A well-built vIBAN setup does a fairly specific set of things: it hands out a unique IBAN per customer, order, product, or currency; it matches incoming payments to invoices automatically; it supports EUR, USD, GBP, and other currencies side by side; it plugs into ERP systems like SAP, Navision, or Datev; and it reports in real time using formats like XML, JSON, camt.053, and MT940.

Lay that next to a traditional bank account and the gap isn't subtle. Setup through a vIBAN provider takes one to three business days with proper documentation in hand; opening a new account at a banking institution can take weeks. Account volume is effectively unlimited with vIBANs, generated through an API, scaled into the thousands, and switched off instantly when no longer needed. A traditional account means one application, one review, one account, every single time. Reconciliation runs on its own instead of by hand, and cross-border, multi-currency support comes built into the product rather than bolted on or boxed into a single region.

None of that makes a vIBAN a bank account in the legal sense, and treating it as one sets up a bad surprise later. It holds no funds independently. The master account remains the actual legal home of the money. A vIBAN is a label, a genuinely useful one, but a label all the same. Anyone pitching it as a replacement for a real banking relationship is either confused about the mechanics or hoping the buyer won't ask.

How virtual IBANs automate reconciliation and restore visibility into who paid, in what currency, and for which entity

Traditional global acquiring models pool incoming transactions together, which makes it genuinely hard to trace any single payment back to the customer, invoice, or entity that generated it. Finance teams end up rebuilding that link after the fact, often by hand, often at month-end, when nobody has spare time for it.

Virtual IBANs fix this at the structural level. Each incoming payment lands against a dedicated identifier, so who paid, in what currency, and for what purpose gets captured the moment the money arrives, not reconstructed three weeks later from a pile of remittance emails. The assignment logic goes down to a fine grain: it can map by customer, by order, by product line, or by business unit, whichever mapping the finance team actually needs. Automated matching against invoices removes the manual step that has historically driven month-end delays.

The FX benefit follows directly from that structure, and it isn't a minor one. When funds land in local currency through a dedicated IBAN instead of getting converted automatically at whatever rate the payment service provider defaults to, treasury holds that balance and converts it on its own schedule, timed to actual FX strategy rather than to whatever moment the payment happened to clear. That single change, holding instead of auto-converting, can deliver meaningful value over a year on top of the reconciliation savings. Companies that skip this step and let the payment processor auto-convert are ceding control over FX timing on every transaction, all year, without a clear view of what that costs them.

Reporting formats here, camt.053, MT940, XML, JSON, iDoc, camt.054, feed straight into ERP and treasury management systems. The automation doesn't stop at the bank statement; it runs through to the general ledger. The downstream effects are concrete: faster month-end close, fewer manual errors in how payments get allocated, and finance teams spending their time analyzing cash instead of chasing it. Cost reduction is real here, but it's a byproduct. The actual gain is visibility and control over money that used to go dark the moment it left the customer's account.

How multinationals use virtual accounts for POBO, ROBO, in-house banking, and netting

An industry group focused on financial professionals draws a useful line between two deployment models. A single legal entity typically deploys virtual accounts to cut its bank account count or automate reconciliation. A multi-entity organization does something more ambitious: the virtual account network becomes a de facto cash pool, settling payments on behalf of other entities and replacing zero-balancing accounts. The goal there is more efficient use of liquidity and working capital, and tighter control over financial and operational risk.

Pay on Behalf of, or POBO, centralizes outgoing payments through a single legal entity while still preserving entity-level reporting underneath. Receive on Behalf of, or ROBO, does the same for collections, and it's harder by a fair margin, because it touches customer-facing payment flows directly instead of sitting entirely inside the company's own processes.

Virtual accounts also form the backbone of in-house banking. Treasury can record intercompany transactions, manage internal lending and borrowing, and run virtual netting, all without physically moving funds between dozens of local accounts every time two subsidiaries trade with each other.

The AFP recommends a specific build order, and companies that skip it tend to regret it. Start with POBO, since it's easier and doesn't touch customers directly. Add internal settlements next. Build out netting after that, single currency first, multicurrency only once that's stable. ROBO comes last, precisely because it's the most operationally sensitive piece. Companies that lead with ROBO because it looks like the biggest win are building the riskiest piece on top of nothing, and trying to run it before the rest of the structure exists is a significant way these rollouts stall. The AFP is also blunt about a related point: tax, legal, and accounting advice is critical for any multi-entity, multi-jurisdictional rollout. That isn't boilerplate caution. It decides which entities can even participate in a structure like this, and how intercompany flows get treated on the income statement and balance sheet.

ABB shows what the end state looks like when the sequencing gets followed. The Switzerland-headquartered electrification and automation group, with 111,900 employees and 2025 annual revenues of $33.2 billion, built a global POBO structure through its in-house bank legal entity, running accounts payable, salary, and tax payments for group companies everywhere legally permitted; Deutsche Bank's 2025 account of the rollout describes the structure. Roughly five years earlier, ABB was making local payments out of hundreds of separate bank accounts. Today, more than 60% of its global payables flow through fewer than 10 accounts, with POBO running across 16 currencies. In January 2025, ABB began migrating ROBO for entities transacting in EUR, CHF, USD, CAD, and GBP, including virtualizing account numbers with Deutsche Bank. By May 2025, groupwide intercompany netting had moved off a third-party system and onto SAP S/4HANA.

The ABB case is not unique; other multinationals following the same sequencing have used combined POBO, ROBO, and in-house banking structures to consolidate treasury operations and reduce their reliance on local banking relationships. Read both cases as proof of what the sequencing makes possible, and read every rollout that stalls on ROBO as proof of what skipping it costs.

The regulatory changes reshaping how virtual IBANs must be issued and governed, particularly in Europe

Virtual IBANs have operated for years in something close to a legal grey zone: widely used across payments, treasury, and fintech, but without a harmonized legal definition anywhere. As usage grew, so did the attention from regulators and law enforcement, for reasons that are fairly concrete rather than theoretical.

Criminal actors have used vIBANs to obscure which actual institution or country sits behind a given payment, a pattern documented in joint work from bodies focused on financial crime. A related technique, sometimes called downstreaming, re-issues vIBANs in chains that bury the underlying master account several layers deep. Law enforcement has struggled to freeze funds in these cases for a simple reason: a vIBAN is an identifier, not an account that holds money, so seizing it doesn't actually seize anything.

Europe is where the regulatory response has moved fastest, and it's moved further than most providers have adjusted for. A major regulatory package introduces the first formal region-wide definition of a virtual IBAN. Issuers now have to identify and verify the actual end-user behind each vIBAN and link every one of them to a specific underlying master payment account. The new framework strengthens traceability requirements, with regulators describing the changes as giving law enforcement improved ability to follow funds moved through vIBANs that they previously couldn't trace. Institutions currently running "light" KYC checks on vIBAN holders will need to move to full KYC, including customer and beneficial ownership identification, under the new package.

The timeline matters for anyone planning a multi-jurisdiction rollout, and it's tighter than it looks at first glance. A new regional authority focused on anti-money laundering became operational on July 1, 2025, and has started setting technical standards. Member states must implement the key beneficial ownership registry rules under AMLD6 by July 10, 2026. The AMLR applies in full, and the rest of AMLD6 must be transposed into national law, by July 10, 2027.

Germany has already moved on its own track. On July 27, 2026, BaFin published Supervisory Communication 06/2026, addressing money laundering and terrorist financing risks tied to virtual IBANs, with particular attention to their potential use in underground banking networks. The communication doesn't ban vIBANs or invent new legal obligations from scratch. It clarifies how existing AML and counter-terrorist-financing rules apply to banks, payment service providers, e-money institutions, Banking-as-a-Service providers, and any other firm operating inside a vIBAN or master-account structure. It applies immediately and stays in force until the EU AMLR takes over on July 10, 2027.

A regional banking authority has done its own groundwork here too, publishing a report on vIBANs built on a 2023/2024 fact-finding exercise that examined their characteristics and benefits alongside the risks: money laundering, regulatory arbitrage, and gaps in consumer protection, with recommendations aimed at both payment service providers and national authorities.

The direction across 2025 and 2026 runs away from reactive compliance and toward building compliance into the product from day one. That cuts the risk of a service getting yanked mid-stream by a regulatory change nobody planned for. Any company evaluating a vIBAN provider today should put regulatory alignment at the top of the checklist, not somewhere below pricing and integrations. Regulatory alignment usually ends up ranked below those factors instead. Any deployment spanning multiple jurisdictions needs its implementation plan built around these specific dates, not around a loose assumption that the rules have settled.

The provider landscape across institutional banks, specialist fintechs, and infrastructure platforms

The market splits into three fairly distinct tiers. Institutional and major bank offerings serve treasury-grade virtual account management for large corporates. Specialist fintech platforms offer multi-currency accounts aimed at small and mid-market businesses, often bundled with broader integrations into the rest of a company's software stack. Infrastructure and wholesale providers supply embedded finance and Banking-as-a-Service layers that let platforms, payment service providers, and e-money institutions issue vIBANs to their own customers, sitting underneath both bank and fintech offerings.

SAP Fioneer's landscape review reports that, among the major banks, Goldman Sachs is expanding its Virtual Integrated Accounts offering into a major market and the UK. Bank of America extended its virtual account management into a major market in 2022. JPMorgan runs a full suite built around centralizing global operations with real-time liquidity management. Barclays supports clients holding diverse pools of client funds with self-service account management, automated reconciliation, and granular reporting. ING's Virtual Cash Management product focuses on cash concentration and reporting across multiple jurisdictions at once.

The specialist fintech tier looks different in both scale and pricing, and the differences aren't cosmetic. Wise Business serves more than 600,000 businesses globally, from individual freelancers up to multinational corporations, with conversion fees starting from 0.57%, local account details in more than 160 countries, and support for holding over 40 currencies, all on a pay-as-you-go model with a one-time setup fee. Airwallex offers local bank details, including IBANs, in more than 60 markets, holds over 23 currencies, accepts more than 130, and sends to more than 150 countries, with monthly account fees starting from £19 and FX rates set at 0.5% above interbank for major currencies and 1% for others; it's also known for its integration with Shopify and WooCommerce. Revolut Business offers multi-currency IBANs alongside expense management and corporate cards, charging a 0.6% FX fee above the plan's monthly allowance and an extra 1% outside market hours, and it has particular traction in the tech sector. Payoneer operates in more than 190 countries, supporting more than 10 primary receiving currencies and local receiving accounts in a smaller set of currencies.

None of these tiers is "better" in the abstract, and shopping this like a single ranked list is how a buyer ends up with the wrong fit. A large multinational running POBO and ROBO across a dozen entities carries different needs, and a different appetite for regulatory exposure, than a mid-market exporter that just needs clean local collection accounts in a handful of currencies. Buying an institutional bank's treasury-grade platform for a business that only needs three currencies and a Shopify integration is as much of a mistake as trying to run ROBO across a dozen entities on a fintech tool built for freelancers. The same sequencing discipline that governs a multi-entity rollout, build the easy piece first, prove it, then add complexity, applies just as much to picking a provider tier as it does to building POBO before ROBO. Get the tier wrong, and the vIBAN layer ends up solving a smaller problem than the one the business actually has.