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.

Typically an EMI or payment institution authorised under EMD2 (Directive 2009/110/EC) or PSD2 (Directive (EU) 2015/2366), the provider 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] Counterparty acceptance and cost follow from the structure chosen; MiCA client-fund compliance also depends on who holds the account, where the funds are placed, and how they are protected and attributed.

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) under MiCA that are not themselves credit institutions, EMIs or payment institutions must place client funds other than e-money tokens with a credit institution or a central bank by the end of the business day following receipt, under Article 70(3) of Regulation (EU) 2023/1114.^[4] The account structure chosen is one input to meeting that obligation, not proof of it.

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] Virtual IBANs are “indistinguishable by third parties from standard IBANs”, and outgoing payments initiated by the end-user of a vIBAN are “debited from the master account”, according to the European Banking Authority (EBA) Report on Virtual IBANs (EBA/Rep/2024/08, 24 May 2024).^[3]

Within the vIBAN category, the distinction that drives 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, and the audit trail is one-to-one. For MiCA Article 70(3), the name label alone settles nothing: what counts is who holds the master account, whether client funds sit with a credit institution or central bank in an account separately identifiable from the CASP’s own funds, whether client ownership is protected and each client’s share attributed, and whether placement meets the deadline.^[4][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.

Operationally that structure is cheaper, but it cannot evidence client-by-client segregation at bank-account level. MiCA Article 70(3) does not require a separate bank account for each end client, so pooling is not excluded on that ground alone; the holder, placement, protection, and ledger attribution still have to meet the test.

For Verification of Payee, its client attribution depends on the provider’s additional identifier and response logic: a payer may still receive a mismatch or other warning where the identified payee cannot be confirmed, but the outcome is not a categorical failure for every payment.

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.

The pricing a direct applicant is quoted at the contract stage rarely reflects this; the cost of a future migration falls on the operator, not the provider.

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. Unwinding a pooled structure takes 3 to 6 months because it is not a configuration change but a re-papering of the entire customer book. Decisions of this kind belong at the start of the placement assessment, not after the first account-opening.

Regulation (EU) 2024/886 permits the payer, where an account is held by a PSP on behalf of multiple payees, to supply additional identifying information about the payee, and the PSP maintaining or holding that account must, on request of the payer’s PSP, confirm whether the identified payee is among them. The payer’s authorisation remains required after the Verification of Payee (VoP) result. This creates a lawful validation route for pooled accounts, but it does not guarantee that every pooled implementation complies or that every payer will avoid a warning; firms should verify the provider’s identifier, response and reconciliation design.^[8]

For the VoP duty itself, in-scope euro-area PSPs have applied it from 9 October 2025, while in-scope non-euro-area PSPs apply it from 9 July 2027. Article 16(9) provides a separate timetable for a Member State that later adopts the euro, so these dates are not a universal statement about every provider or transaction.^[8]

The instant euro transfers duty has a different timetable: euro-area EMIs and PIs must send and receive from 9 April 2027; non-euro-area EMIs and PIs must receive from 9 April 2027 and send from 9 July 2027.^[8]

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).^[9] In the Accept My IBAN dataset through March 2025, Lithuanian (LT) and Belgian (BE) IBANs appeared most often in reported refusals, at 24% and 23% respectively.^[12]

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. On 27 January 2026 the Italian Competition Authority (AGCM) imposed an €800,000 sanction on Agos Ducato S.p.A. 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 that penalties varied significantly between Member States, with maximum penalties from €3,500 to, for companies, €10 million plus up to 10% of annual turnover, and recommended that the Commission propose bringing the SEPA Regulation within the EU’s consumer-protection cooperation rules and the EBA’s activities.^[11]

Accept My IBAN, a private-sector initiative that collects rejection reports through a public portal and passes them to the relevant competent authority,^[11] gives the clearest quantitative picture of IBAN discrimination, from complaints collected cumulatively over several years. The European Consumer Centres Network (ECC-Net) published a position paper on 3 July 2025 citing 4,688 complaints received by Accept My IBAN from 2021 to the end of March 2025.^[12] Refused IBANs cluster tightly by geography: Lithuania accounted for 24% of all refused IBANs, Belgium for 23%, and Germany for 22%.

Complainants cluster differently, because the two figures count different populations: the first records which IBAN was refused, the second where the person reporting it is based. France (22%), Germany (19%), Spain (15%), and Italy (11%) produce most of the reports.^[12]

The refusals Lithuania attracts are structural, not incidental. Seventy electronic money institutions hold a full Bank of Lithuania licence (the Bank’s list, checked 29 September 2026),^[21] and the Bank of Lithuania runs CENTROlink, its retail payment system for SEPA payments.^[22] 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 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]

Operators commonly mistake IBAN discrimination for a problem the regulator will fix on their behalf. Under the agreed Payment Services Regulation text, general application would begin 21 months after entry into force and therefore no earlier than July 2028; until then, the practical path is the three-step multi-provider response set out above, with complaint-filing as a parallel pressure mechanism rather than a substitute.

The Commission proposed the Payment Services Regulation (PSR) as part of the PSD3/PSR package on 28 June 2023.^[13] The Council and Parliament reached provisional political agreement in November 2025; COREPER confirmed the trilogue text on 22 April 2026; and the European Parliament’s ECON Committee approved the final compromise texts on 5 May 2026. As of 10 September 2026, the texts had not been formally adopted, and Parliament listed 14 December 2026 as the indicative plenary date.^[14]

No Official Journal publication had occurred by 10 September 2026. Under Article 112 of the agreed text, the PSR would apply generally 21 months after entry into force, while Articles 50 and 57 would apply after 27 months. General application therefore could not begin before July 2028. These proposal-stage clocks are separate from the enacted Verification of Payee dates set out above.

The SEPA Regulation is directly applicable, while the proposed PSR had not been adopted as of 10 September 2026. Under the SEPA Regulation, sanctions remain with national competent authorities; the agreed PSR text would introduce a harmonised penalty framework if adopted. The preserved agreed text sets minimum levels for maximum fines rather than a single fine schedule, and it does not establish that the PSR framework would govern breaches of SEPA Regulation Article 9. For crypto operators using LT-coded IBANs, current national enforcement remains the operative planning basis. The agreed text would also amend the SEPA Regulation to define a virtual IBAN and to treat it as a valid payment account identifier wherever an IBAN is required (Article 110c).^[14]

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 cost per transfer. EUR, GBP, USD, CHF, and AED are the major currencies for European crypto and fintech operators in 2026, 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 transfers routed through SWIFT can take several working days and incur correspondent fees; as a benchmark, Wise quotes 1 to 6 working days for a SWIFT payment to reach it and correspondent fees of about USD 15 to 50, sometimes more.^[20]

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. Five currencies matter operationally for a crypto or fintech business at scale: 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 subject to MiCA Article 70(2)–(3) and for crypto-asset custodians under Article 75(7). Electronic money institutions instead have a prudential safeguarding requirement under EMD2 Article 7, met through the method their Member State or competent authority permits. The account structure a business chooses (dedicated, named vIBAN, or pooled) shapes how the obligation is met operationally, but no label proves compliance on its own.^[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) exempts a CASP that is itself a credit institution, EMI or payment institution from Article 70(2) and (3). The institution remains subject to the client-fund rules of its own sectoral regime; this is not an exemption from the separate crypto-asset custody duties.^[4]

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; payment-instrument receipts must be safeguarded once credited to the EMI’s payment account or otherwise available to it, and in any event no later than five business days after issuance; other funds on receipt.^[1]
• MiCA Article 70(2)–(3): a CASP that is not itself a credit institution, EMI or payment institution must protect clients’ ownership of funds other than e-money tokens, must not use them for its own account, and must place them with a credit institution or central bank by the end of the business day following receipt, in an account separately identifiable from its own funds. That is a materially tighter standard.^[4]
• 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, a resolution pack must be kept and a monthly return filed; receiving funds directly into a designated safeguarding account was proposed only for the later Post-Repeal Regime.

From 7 May 2026 the safeguarding rules sit in CASS 15, with CASS 10A, SUP 3A and SUP 16.14A, and the FCA’s updated Payment Services and Electronic Money Approach Document, in force the same day, gives its guidance on them.^[16][19] A business that operates across all three regimes must run to the tightest clock that applies, not the average.

Deposit protection does not follow client money through an EMI in the ordinary way. The Deposit Guarantee Schemes Directive (Directive 2014/49/EU) protects eligible deposits at credit institutions up to €100,000 per depositor per institution, but e-money is not a deposit, and deposits made by financial institutions, EMIs included, are excluded from repayment.^[17] Whether an EMI’s clients can instead be covered as the persons absolutely entitled to a safeguarding account (Article 7(3)) depends on how the Member State applies the Directive.

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, estimated shortfalls averaging 65% across twelve insolvent payment firms and 80% for EMIs alone, using total assets as a proxy for safeguarded funds. In the six cases where a distribution had been made, the first took an average of 2.3 years; cases still awaiting a distribution were excluded.^[16]

The central-bank option is conditional in practice: Eurosystem central banks do not provide safeguarding accounts to non-bank payment service providers or CASPs under ECB Decision (EU) 2025/222 Article 3. Eligibility for a TARGET settlement account does not change that restriction.^[25]

MiCA Article 70 pairs ownership protection and segregation with a next-business-day placement deadline. A CASP that is not itself a credit institution, EMI or payment institution must place client funds other than e-money tokens with a credit institution or central bank by the end of the business day following receipt, in an account separately identifiable from its own funds, and must not use them for its own account.^[4] That timing rule forces the multi-currency account structure to support same-day or next-day placement with a credit institution or central bank. Any structure, whether named, dedicated or pooled, that holds client funds past that deadline or nets them against the CASP’s own funds before placement does not meet these obligations, 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. From your written brief, we assess the operating profile against the network’s current acceptance criteria, present a shortlist of best-fit providers, and introduce an independent specialist before any account application is filed. You contract directly with the specialist; account approval remains the financial institution's decision.

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, reducing 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).

The independent specialist we introduce coordinates 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