Multi-Currency Accounts & IBANs for Crypto and Fintech Businesses

What Are Multi-Currency Accounts?

A multi-currency account holds, sends, and receives funds in multiple currencies from a single platform, eliminating the need for separate accounts in each currency. Major multi-currency providers in 2026 support between 10 and 50+ currencies, with access provided through virtual IBANs, dedicated IBANs, or a combination of both.

The provider, typically an EMI or payment institution authorised under EMD2 (Directive 2009/110/EC) or PSD2 (Directive (EU) 2015/2366), maintains a single platform with internal sub-ledgers for each currency.^[1][2] Funds received in one currency settle into the relevant currency ledger; outbound payments draw from the matching balance; intra-platform conversion runs at the provider’s quoted FX spread over the interbank mid. The customer holds one master agreement, one onboarding pack, and one user interface across every currency the account supports.

There are three account structures behind every multi-currency platform. 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 customer’s 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 maintained on an internal ledger rather than at the bank-account level.^[3] The choice of structure determines counterparty acceptance, MiCA compliance, and cost.

For crypto and fintech operators, multi-currency infrastructure is not a convenience layer. Cross-border customer bases generate inbound flows in EUR, GBP, and USD that have to settle at usable spreads. Crypto-asset service providers (CASPs) authorised under MiCA must segregate client fiat under Article 70(3) of Regulation (EU) 2023/1114, with deposit at a credit institution by the end of the business day following receipt.^[4] The account structure chosen drives whether that obligation is met operationally.

Virtual IBANs vs. Dedicated IBANs

The choice between virtual and dedicated IBANs determines cost, scalability, counterparty acceptance, and MiCA compliance capability. 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.^[3][5]

Article 2 of the EU Anti-Money Laundering Regulation (Regulation (EU) 2024/1624) now defines a virtual IBAN as “an identifier causing payments to be redirected to a payment account identified by an IBAN different from that identifier”.^[6] The European Banking Authority (EBA) Report on Virtual IBANs (EBA/Rep/2024/08, 24 May 2024) confirms that vIBANs are “indistinguishable to third parties from a standard IBAN” and that outgoing payments initiated by the end-user of a vIBAN are “debited from the master account”.^[3]

Within the vIBAN category, the distinction that drives MiCA, AMLR, and counterparty outcomes is named versus pooled. A named vIBAN is issued in the end-customer’s legal name. The payer’s bank sees the customer paying their own named account, the audit trail is one-to-one, and the structure can satisfy MiCA Article 70(3) when the master sits at a credit institution.^[7] A pooled vIBAN routes many end-users into one master IBAN in the name of the EMI or PI; attribution is internal-ledger only. The structure is operationally cheaper, 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.

In practice, the named-vs-pooled decision is rarely revisited once the architecture is live. Migrating an end-user book off a pooled vIBAN structure onto named IBANs typically takes 3 to 6 months because every existing customer has to re-receive their new IBAN in writing, every counterparty mandate has to be updated, and reconciliation has to be re-pointed across the entire ledger. Pricing direct applicants are quoted at the contract stage rarely reflects this; the cost of a future migration is the operator’s, not the provider’s.

Unlike the choice of currency or payment rail, both of which can be added incrementally as the business scales, the IBAN architecture choice is a one-way door. Moving an end-user book off a pooled vIBAN structure onto named IBANs is a 3-to-6-month migration involving every existing customer, every counterparty mandate, and the entire reconciliation layer. The decision belongs at the start of the placement assessment, not after the first account-opening.

The Verification of Payee (VoP) rule under Regulation (EU) 2024/886 (the Instant Payments Regulation) has applied to euro-area credit institutions since 9 October 2025 and applies to euro-area EMIs and payment institutions from 9 April 2027.^[8] The check returns the payee’s name and matches it against the name the payer entered before the transfer settles. Named vIBANs return the end-customer’s name and pass cleanly. Pooled vIBANs return the master account holder’s name, generating “name does not match” warnings on every inbound payment from the moment the rule applies to the sending PSP. The operational impact on businesses still relying on pooled vIBAN models becomes binding for euro-area EMIs from 9 April 2027.

IBAN Discrimination: What It Is and How to 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), and yet it remains widespread in 2026, with Lithuanian (LT) and Belgian (BE) IBANs facing the highest rejection rates in the European market.^[9]

Member States are required by Articles 10 and 11 of the SEPA Regulation to designate competent authorities and to impose “effective, proportionate and dissuasive” penalties for breach.^[9] Enforcement, in practice, is fragmented. France granted its consumer-protection authority (the DGCCRF) the power to fine €75,000 (natural persons) and €375,000 (legal persons) under Law No. 2021-1308 of 8 October 2021. The Italian Competition Authority (AGCM) 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, citing a direct Article 9 breach.^[10] The European Court of Auditors Special Report 01/2025 found enforcement across the Union to be uneven and recommended a harmonised penalty regime, which the proposed Payment Services Regulation is expected to deliver.^[11]

The clearest quantitative picture of IBAN discrimination in 2025 comes from the Accept My IBAN initiative, an industry coalition of European payment institutions that collects rejection reports through a single public portal. The European Consumer Centres Network (ECC-Net) published a special report on 3 July 2025 drawing on 4,688 cumulative complaints submitted between February 2021 and March 2025.^[12] The geography of refused IBANs is concentrated: Lithuania accounted for 24% of all refused IBANs, Belgium for 23%, and Germany for 22%. The geography of complainants tells the opposite story: France (22%), Germany (19%), Spain (15%), and Italy (11%) produce most of the reports.^[12]

The Lithuanian rejection rate is structural, not incidental. Approximately 70 electronic money institutions hold Bank of Lithuania authorisation as of end-2024, the largest EMI concentration in the EU, with direct SEPA access through the central bank’s CENTROlink hub. High-profile licence revocations across 2023 and 2024, and the EBA’s May 2024 Report flagging vIBAN risks at scale, have together produced a payer-bank pattern that treats LT-prefix IBANs as carrying elevated AML and operational risk regardless of the underlying institution’s actual supervision. Estonia sits closer to the middle of the table, but Bank of Estonia and Finantsinspektsioon-licensed payment institutions still experience friction with non-Baltic counterparties, in part because of the legacy of the 2018 Danske Estonia matter.

There are three operational responses for crypto and fintech businesses caught by IBAN discrimination:

• Obtain a named IBAN in a high-acceptance country code (DE or NL most commonly) through a multi-currency provider that issues local IBANs across multiple jurisdictions under one master agreement.
• Operate a multi-provider IBAN strategy: a DE or NL named IBAN for customer-facing collections, a LT or EE IBAN for operational banking where the underlying institution’s pricing is competitive, and a separate USD account through a US-correspondent-banked provider.
• File complaints through the Accept My IBAN portal, which feeds into the ECC-Net dataset and produces the enforcement pressure the European Court of Auditors has called for.^[12]

The common mistake is treating IBAN discrimination as a problem the regulator will fix on the operator’s behalf; until the PSR enforcement regime applies in 2027–2028 the practical path is the multi-provider response above, with complaint-filing as a parallel pressure mechanism rather than a substitute.

Unlike the legacy SEPA Regulation, where enforcement depended on twenty-seven national competent authorities each interpreting “effective, proportionate and dissuasive” in their own way, the PSR is a directly applicable regulation with a harmonised penalty framework. The practical effect is that enforcement risk for an Italian merchant rejecting a Lithuanian IBAN moves from “the AGCM might notice and fine you next year” to “the harmonised regime sets the fine schedule from day one.” For crypto operators currently operating through LT-coded IBANs, the PSR transition window is the planning horizon.

The proposed Payment Services Regulation (PSR), part of the PSD3/PSR package adopted by the Commission on 28 June 2023, is expected to strengthen Article 9 enforcement by replacing the directive-and-transposition model with a directly applicable regulation and a harmonised penalty framework.^[13] The Council and Parliament reached provisional political agreement in November 2025; COREPER endorsed the trilogue text on 22 April 2026; the European Parliament’s ECON Committee approved the final compromise texts on 5 May 2026 (PSD3 adopted 55-3-5; PSR adopted 50-2-2), with plenary expected in the 18–21 May 2026 Strasbourg part-session.^[14]

Publication in the Official Journal is anticipated mid-2026, with application following an expected 21-month transition for the PSR generally and a longer transition (between 24 and 27 months in early commentary, pending the final published text) for the Verification of Payee obligation. The practical effect for IBAN discrimination enforcement is expected in the H2 2027 to H1 2028 window.

Currencies and Coverage

A multi-currency account’s value to a crypto or fintech business depends on which currencies it actually settles, on which rails, and at what spread. The major currencies for European crypto and fintech operators in 2026 are EUR, GBP, USD, CHF, and AED, with growing demand for SGD, HKD, and EU non-euro currencies.

Currency selection is not symmetrical with provider selection. Most mid-tier multi-currency providers advertise 25 to 35 currencies; institutional-grade providers reach 50 or more. What matters operationally is which currencies the provider settles on-rail (with local clearing access) versus off-rail (with all flows routed through SWIFT correspondent). On-rail USD requires a US correspondent relationship that the provider holds; without it, USD inbound and outbound flows take 1 to 3 business days and pay 25 to 50 USD in correspondent fees per outbound transfer. On-rail CHF requires either FINMA recognition or a clearing relationship with a SIX participant. On-rail AED requires Central Bank of the UAE authorisation, and the Rulebook specifically requires Licensed Persons to settle in-UAE AED via UAEFTS.^[15]

Experienced operators select a multi-currency provider on the strength of three to five on-rail currencies rather than the headline currency count, because on-rail access is what determines settlement cut-off, correspondent fee, and same-day capability, the metrics that move the P&L.

Editorial position: most multi-currency providers in 2026 lead with their currency count (30, 40, 165), and most of that count is paper coverage with no liquid pricing behind it. The currencies that matter operationally for a crypto or fintech business at scale are five: EUR, GBP, USD, CHF, and the operator’s primary local currency. The right question to ask a provider is not “how many currencies?” but “where do you hold the correspondent relationships and what is the cut-off for same-day settlement in each?”

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 a business chooses (dedicated, named vIBAN, or pooled) directly determines whether the obligation is met operationally.^[4][1]

MiCA distinguishes between two segregation duties that the consultancy market frequently blurs. Article 70(3) of Regulation (EU) 2023/1114 governs fiat funds held by a CASP on behalf of clients: those funds must be deposited with a credit institution or a central bank by the end of the business day following receipt, in an account separately identifiable from the CASP’s own funds. Article 70(5) provides that the safeguarding duty does not apply where the CASP is itself a credit institution; under MiCA, EMIs and authorised payment institutions providing CASP services are subject to the safeguarding rules of their primary regimes (EMD2 and PSD2) rather than to Article 70(3) in addition.^[18] Article 75(7) governs crypto-assets held by a CASP providing custody and administration: client holdings must be kept separate from the CASP’s own holdings, with means of access clearly identified as the client’s.^[4]

The segregation clock varies by regime:

• EMD2 Article 7: EMIs must safeguard funds received against issued e-money by no later than five business days after issuance.^[1]
• MiCA Article 70(3): a CASP must deposit client fiat at a credit institution by the end of the business day following receipt. That is 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 the funds must be received directly into a designated safeguarding account with effectively same-day discipline.

The FCA’s Payment Services and Electronic Money Approach Document Version 8, published 7 May 2026 alongside the Supplementary Regime go-live, is now the operative supervisory text for the safeguarding obligations.^[16][19] A business that operates across all three regimes must run to the tightest clock that applies, not the average.

Deposit-protection coverage does not transfer through an EMI to its end-customers. The Deposit Guarantee Schemes Directive (Directive 2014/49/EU) protects depositors at credit institutions up to €100,000 per depositor per institution.^[17] Where an EMI safeguards client funds at a credit institution, the EMI is the single depositor for DGSD purposes; the €100,000 cap applies once, at EMI level, and not per end-customer. In the EMI’s own 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. The Financial Conduct Authority’s CP24/20 (September 2024), which informed PS25/12, recorded shortfalls of an order of magnitude that would surprise operators relying on a default reading of “safeguarded”.^[16]

Unlike most EU regulatory frameworks, where the safeguarding requirement is a process rule, MiCA Article 70(3) is a one-business-day timing rule. Client fiat received by an authorised CASP must be deposited at a credit institution by the end of the business day following receipt. The operational consequence is that the multi-currency account structure has to support same-day or next-day sweep to a credit-institution-tier IBAN; pooled vIBAN structures that net internally before sweeping do not satisfy this obligation, and the time gap shows up in regulator examinations.

How Jagelski & Partners Helps

Jagelski & Partners matches crypto and fintech businesses with multi-currency account providers whose IBAN country codes, currency rails, and client fund segregation model fit the business. The partner network maintains live account-opening routes in every jurisdiction Jagelski & Partners services, and banking feasibility is confirmed at the scoping stage, before any licence application is filed. We assess the operating profile against the network’s current acceptance criteria, present a shortlist of best-fit providers, and coordinate onboarding through to live accounts.

The placement covers three dimensions of the multi-currency decision. Pre-qualification across the network identifies which institutions will underwrite the business model and licence status before any formal application is submitted, removing the rejection-history risk that comes from going door-to-door. IBAN strategy maps 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. Segregation compliance maps the account structure against MiCA Article 70(3), EMD2 Article 7, and FCA PS25/12 obligations where the business is in scope.

A single multi-currency provider rarely covers every requirement. The typical architecture for a MiCA-authorised CASP processing EUR and USD volumes runs a DE or NL named-IBAN provider for EU customer-facing collections, a separate USD account through a US-correspondent-banked provider, and a dedicated IBAN at a credit institution for client-fund segregation under Article 70(3). We coordinate the onboarding of all three in parallel so that operational dependency is split from day one. Jagelski & Partners is paid by the institution, not by the client. We do not charge an onboarding fee. We do not mark up institutional banking or EMI pricing.

Jagelski & Partners does not provide custody services, does not hold client funds, and does not guarantee account opening. Pre-qualification identifies institutions most likely to accept the business; it does not commit those institutions to approval. We will not pursue placement for businesses whose model the network cannot underwrite.

Frequently Asked Questions

References