Multi-Currency Accounts & IBANs

Banking Built for How the Business Actually Operates

Banking is a core service in its own right. We open and structure the accounts a high-risk or regulated business needs to hold, send and receive funds across currencies, and we build an IBAN architecture that counterparties will accept and that the regulator will recognise. You can come to us for the banking alone, or have it delivered as part of the entity we form and license.

A multi-currency account holds funds in several currencies from a single platform, accessed through virtual or dedicated IBANs at an EMI or payment institution. There are three account structures, and the choice drives counterparty acceptance, regulatory fit and cost:

• Dedicated IBANs are standalone payment accounts, each uniquely assigned to one legal entity and segregated at the bank-account level.
• Named virtual IBANs are issued in the entity’s own name but route to a master safeguarding account at a credit institution.
• Pooled virtual IBANs share a single master IBAN across many end-users, with attribution kept only on an internal ledger.

For the operators we serve, this is not a convenience layer. Cross-border customer bases generate inbound flows in EUR, GBP and USD that have to settle at usable spreads, and a crypto-asset service provider (CASP) authorised under MiCA must segregate client fiat under Article 70(3) of Regulation (EU) 2023/1114, depositing it at a credit institution by the end of the business day following receipt. The account structure we set up determines whether that obligation is met in practice.

Virtual IBANs vs. Dedicated IBANs

The choice between virtual and dedicated IBANs determines cost, scalability, counterparty acceptance and MiCA compliance. A virtual IBAN (vIBAN) is an identifier that routes payments to a separate master account with a different IBAN; a dedicated IBAN is a standalone payment account uniquely assigned to one legal entity, with every flow mapped one-to-one. Article 2 of the EU Anti-Money Laundering Regulation (Regulation (EU) 2024/1624) now defines a virtual IBAN in those terms, and the European Banking Authority has confirmed that vIBANs are indistinguishable to third parties from a standard IBAN.

Within the vIBAN category, the distinction that drives MiCA, AMLR and counterparty outcomes is named versus pooled. A named vIBAN is issued in the entity’s own legal name, the audit trail is one-to-one, and it can satisfy MiCA Article 70(3) when the master sits at a credit institution. A pooled vIBAN routes many end-users into one master IBAN held in the EMI’s name, with attribution kept only on an internal ledger. It is cheaper to run, but it cannot pass a name-match check, cannot evidence client-by-client segregation at bank-account level, and faces growing rejection across European corridors.

Unlike the choice of currency or payment rail, which can be added as the business scales, the IBAN architecture is a one-way door. Moving an end-user book off a pooled vIBAN structure onto named IBANs is a three-to-six-month migration touching every customer, every counterparty mandate and the entire reconciliation layer. That is why we settle the architecture at the start of an engagement, not after the first account is open. The Verification of Payee (VoP) rule under Regulation (EU) 2024/886 makes the point sharper: it has applied to euro-area credit institutions since 9 October 2025 and reaches euro-area EMIs and payment institutions from 9 April 2027. Named vIBANs return the customer’s own name and pass; pooled vIBANs return the master holder’s name and trigger a mismatch warning on every inbound payment.

IBAN Discrimination: What It Is and How We Manage It

IBAN discrimination is the practice of rejecting or surcharging a transaction because of the country code at the start of the IBAN. It is prohibited under Article 9 of Regulation (EU) No 260/2012 (the SEPA Regulation), yet it remains widespread in 2026, with Lithuanian (LT) and Belgian (BE) IBANs facing the highest rejection rates in the European market. We design around it rather than assume the regulator will fix it for you.

Articles 10 and 11 require Member States to designate competent authorities and impose “effective, proportionate and dissuasive” penalties, but enforcement is fragmented. France can fine up to €375,000 (legal persons) under Law No. 2021-1308; the Italian Competition Authority imposed an €800,000 sanction on Agos Ducato S.p.A. on 27 January 2026 for refusing SEPA direct-debit repayments from non-Italian IBANs. The clearest data comes from the Accept My IBAN initiative, whose complaint set shows refused IBANs concentrated in Lithuania (24%), Belgium (23%) and Germany (22%), while the complaints themselves come mostly from France, Germany, Spain and Italy.

The Lithuanian rejection rate is structural, not incidental: Lithuania holds the largest EMI concentration in the EU with direct SEPA access through the Bank of Lithuania’s CENTROlink hub, and high-profile licence revocations across 2023 and 2024 have left payer banks treating LT-prefix IBANs as elevated-risk regardless of the underlying institution’s actual supervision. Estonia sits closer to the middle of the table, but EMIs licensed by Finantsinspektsioon still meet friction with non-Baltic counterparties, partly a legacy of the 2018 Danske Estonia matter.

The mistake we see most often is treating IBAN discrimination as a problem the regulator will solve for you. When we set up banking for an entity we have formed or licensed, we design around it directly:

• Obtain a named IBAN in a high-acceptance country code (DE or NL most commonly) through a provider that issues local IBANs across several jurisdictions under one master agreement.
• Run a multi-provider strategy where it pays: a DE or NL named IBAN for customer-facing collections, a competitively-priced LT or EE IBAN for operational banking, and a separate USD account through a provider that holds its own US correspondent relationship.
• File complaints through the Accept My IBAN portal where a counterparty breaches Article 9, as a parallel pressure mechanism rather than a substitute for the structure above.

The picture should improve. The proposed Payment Services Regulation (PSR), part of the PSD3/PSR package, replaces the directive-and-transposition model with a directly applicable regulation and a harmonised penalty framework, so enforcement risk for a merchant rejecting a Lithuanian IBAN stops depending on which national authority happens to notice. The European Parliament’s ECON Committee approved the final compromise texts on 5 May 2026, with Official Journal publication anticipated in mid-2026 and the practical effect for IBAN discrimination enforcement expected in the H2 2027 to H1 2028 window. Until then, the multi-provider design is the working answer.

Currencies and Coverage

A multi-currency account’s value depends on which currencies it actually settles, on which rails, and at what spread, not on the headline currency count a provider advertises. The currencies that matter for most of the operators we serve are EUR, GBP, USD, CHF and AED, with growing demand for SGD, HKD and the EU non-euro currencies.

The distinction that matters is which currencies a provider settles on-rail, with local clearing access, versus off-rail, with everything routed through a SWIFT correspondent. On-rail USD needs a US correspondent relationship the provider holds; without it, USD flows take one to three business days and pay correspondent fees per transfer. On-rail CHF needs FINMA recognition or a SIX clearing relationship; on-rail AED needs Central Bank of the UAE authorisation. On-rail access is what determines settlement cut-off, correspondent fee and same-day capability, the metrics that actually move the operator’s P&L.

Client Fund Segregation

Client fund segregation is a legal requirement for crypto-asset service providers under MiCA Article 70(3) and for crypto-asset custodians under Article 75(7), and a prudential requirement for electronic money institutions under EMD2 Article 7. The account structure we set up directly determines whether the obligation is met. This is the single most common place we see operators get the architecture wrong before they come to us.

MiCA distinguishes two duties that the market frequently blurs. Article 70(3) governs fiat funds held by a CASP for clients: they must be deposited with a credit institution or central bank by the end of the business day following receipt, in an account separately identifiable from the CASP’s own funds. The duty falls away where the CASP is itself a credit institution, EMI or payment institution, which then safeguards under its primary regime. Article 75(7) governs crypto-assets held in custody: client holdings must be kept separate from the CASP’s own, with means of access clearly identified as the client’s.

The segregation clock varies by regime, and a business in scope of more than one runs to the tightest, not the average:

• EMD2 Article 7: EMIs must safeguard funds received against issued e-money no later than five business days after issuance.
• MiCA Article 70(3): a CASP must deposit client fiat at a credit institution by the end of the business day following receipt, a materially tighter standard.
• FCA Supplementary Safeguarding Regime: under Policy Statement PS25/12, in force since 7 May 2026 for UK-authorised PIs and EMIs, reconciliation runs daily on a D+1 basis and funds must be received directly into a designated safeguarding account.

One point operators routinely misread: deposit-protection coverage does not pass through an EMI to its end-customers. The Deposit Guarantee Schemes Directive protects depositors at credit institutions up to €100,000 per depositor per institution. Where an EMI safeguards client funds at a credit institution, the EMI is the single depositor, so the €100,000 cap applies once at EMI level, not per end-customer. In the EMI’s insolvency the safeguarded pool is excluded from the general estate and distributed pro rata to clients, but the protection is the safeguarding regime, not deposit insurance. We make sure the entity we deliver is structured for the regime it is actually in, rather than a default reading of “safeguarded”.

How We Help

You can engage us for banking on its own, or have it delivered alongside the company and licence we provide. Either way, we set up the multi-currency accounts and IBAN architecture correctly for the licence the business holds and the way it trades. We work directly with licensed EU electronic money institutions, payment institutions and credit institutions through our controlled network of vetted in-country specialists. Some of that work is done in-house; the rest goes to established providers we have personally vetted and continue to work with directly. We never hand a client to an unverified third party.

The work covers three dimensions of the multi-currency decision:

• IBAN strategy: which country codes belong on customer-facing collections, operational banking and counterparty mandates, including local IBAN issuance across DE, NL, FR, IE, LT and EE where the underlying provider supports it.
• Currency and rail fit: matching the on-rail currencies and correspondent relationships to where the business actually settles, so cut-offs and fees match the operating model rather than a headline currency count.
• Segregation compliance: mapping the account structure against MiCA Article 70(3), EMD2 Article 7 and FCA PS25/12 obligations where the business is in scope, so the architecture holds up in a regulator examination.

A single provider rarely covers every requirement. A MiCA-authorised CASP processing EUR and USD volumes typically runs a DE or NL named-IBAN provider for EU collections, a separate USD account through a provider that holds its own US correspondent relationship, and a dedicated IBAN at a credit institution for client-fund segregation under Article 70(3). We coordinate all three in parallel so operational dependency is split from day one, and we stand behind the result.

We are honest about the boundary. We are not ourselves a licensed financial institution, we do not hold client funds or provide custody, and no banking outcome is ever guaranteed by a third party. What we commit to is that the structure we set up is the right one for the entity we form and license, and that the people delivering it are specialists we know and control.

Frequently Asked Questions

What is the difference between a virtual IBAN and a dedicated IBAN?

A virtual IBAN (vIBAN) is an identifier that routes payments to a separate master account with a different IBAN; a dedicated IBAN is a standalone payment account uniquely assigned to one legal entity with one-to-one mapping of all flows. Article 2 of Regulation (EU) 2024/1624 codifies the vIBAN definition. Virtual IBANs come in two operational forms: named (issued in the end-customer’s name) and pooled (shared across many end-users on an internal ledger). Named virtual IBANs and dedicated IBANs both work for MiCA-compliant client fund segregation when properly structured; pooled virtual IBANs do not.

What is IBAN discrimination and is it legal?

IBAN discrimination is the practice of rejecting or surcharging a transaction because of the country code at the start of the IBAN. It is illegal under Article 9 of Regulation (EU) No 260/2012, which prohibits payers and payees from specifying the Member State in which a Union payment account is located. Enforcement is fragmented. France can fine offenders up to €375,000 under Law No. 2021-1308; Italy’s Competition Authority imposed an €800,000 sanction on Agos Ducato S.p.A. on 27 January 2026 for a direct Article 9 breach. The proposed Payment Services Regulation is expected to harmonise enforcement once adopted.

Which IBAN country code has the best acceptance?

German (DE), Dutch (NL), French (FR), and Luxembourgish (LU) IBANs have the highest acceptance rates in 2026. Lithuanian (LT) IBANs face the highest rejection rate: the ECC-Net special report of 3 July 2025 records LT IBANs accounting for 24% of all refused-IBAN complaints in the Accept My IBAN dataset, followed by Belgium at 23% and Germany at 22%. Estonian (EE) IBANs sit in the middle of the table; the legacy of pre-2018 Baltic AML cases still affects perception with some counterparties. The practical response is to obtain named IBANs in high-acceptance countries through providers that issue local IBANs across multiple jurisdictions.

Can I hold USD in a European EMI account?

Yes, most multi-currency EMIs and payment institutions offer USD as a supported currency. The operational quality depends on whether the EMI holds a direct US correspondent banking relationship. With a correspondent, USD flows settle in 1 to 2 business days at standard SWIFT costs and the EMI can offer on-rail USD pricing. Without a correspondent, all USD flows route through a chain of intermediary banks, typically take 2 to 4 business days, and pay correspondent fees of 15 to 50 USD per outbound payment plus FX spread on incoming USD that is auto-converted on receipt. The provider’s correspondent relationship is the operational question, not the headline currency list.

How does MiCA client fund segregation affect my IBAN architecture?

MiCA Article 70(3) requires a crypto-asset service provider to deposit client fiat at a credit institution by the end of the business day following receipt, in an account separately identifiable from the CASP’s own funds, and Article 75(7) requires custodians to keep client crypto-assets separate. A dedicated IBAN at a credit institution, or a named virtual IBAN whose master sits at a credit institution with enforced attribution, both satisfy the Article 70(3) duty; pooled virtual IBANs do not. The duty falls away where the CASP is itself a credit institution, EMI or payment institution, which then safeguards under its own regime. We set the architecture to meet whichever clock applies.

Does Tomberg & Partners help with banking?

Yes, banking is one of our three core services. We help you open and structure multi-currency accounts and IBANs, on their own or alongside the company and licence we deliver. We work with licensed EU electronic money institutions, payment institutions and credit institutions through our controlled network of vetted in-country specialists, so the account structure fits the operating profile and the regulatory regime from day one. Book a free consultation to discuss your situation.

Related Services

• Banking Overview: account opening for high-risk and regulated businesses
• High-Risk Business Accounts: banking for gambling, forex, crypto, adult and other high-risk operators
• Crypto & Fiat Settlement: on-ramp, off-ramp and exchange settlement rails
• Crypto Licensing: MiCA CASP and equivalent regimes
• EMI & Payment Institution Licensing: EMD2 and PSD2 authorisation across the EEA
• Company Formation: form the entity the accounts run through