--- title: "Virtual IBAN Issuance for Non-EU VASPs: The Chain of Liability (2026)" slug: virtual-iban-non-eu-vasp-chain-of-liability publishedAt: 2026-05-08T11:00:00Z author: Finconduit Editorial Team tags: MiCA, EMD2, PSD2, ESMA canonicalUrl: https://finconduit.com/resources/virtual-iban-non-eu-vasp-chain-of-liability --- # Virtual IBAN Issuance for Non-EU VASPs: The Chain of Liability (2026) Non-EU VASPs increasingly want to offer their end-customers EU-rail IBANs as a customer-facing product. The architecture relies on an EU sponsor bank and a BaaS aggregator that hold the regulated function. The structural question — and the inspection question — is the chain of liability when an end-customer of a Georgian VASP holds funds in an IBAN issued via a German sponsor bank through a Lithuanian aggregator. Three jurisdictions, three regulators, one customer. This article maps the chain. A Georgian VASP wants its end\-customers to hold EUR balances at EU\-rail IBANs. The customer experience is straightforward: a Georgian\-branded app, a Georgian\-domiciled VASP entity, a EUR IBAN, SEPA inflows and outflows. Underneath that experience sit three other entities: a **BaaS aggregator** \(typically Lithuanian or Estonian\) that runs the platform, a **sponsor bank** \(typically German, French, or Dutch\) that owns the IBAN range, and a **safeguarding bank** \(often the same as the sponsor at small cohort\) that holds the segregated customer funds. Three jurisdictions, three regulators, one customer. The structural question — and the inspection question that EU NCAs increasingly ask — is the **chain of liability**. Who is the regulated provider of the payment service to the end\-customer? Who holds the AML obligation on the customer? Who is responsible for the customer fund's safeguarding? Who is the EU regulatory point of contact in a wind\-down? The naive answer is that each link in the chain handles its own piece. The supervisor's answer is that the chain must be drafted explicitly, documented in contract, and **survive the test of an end\-customer's claim against the EU regulated entity**. This article maps the chain. The four actors and what each owns; how MiCA Article 61 constrains the chain's design; the three failure modes when the chain breaks; how to draft the chain into the contract; how EU sponsor banks underwrite the chain during diligence. ## The four actors and what each owns ### Actor 1 — The non\-EU VASP Holds the customer relationship, the brand, and the home\-jurisdiction VASP authorisation. Owns customer onboarding \(KYC\) at the front\-line, ongoing customer service, and any product\-design decisions. **Does not own the EU regulatory perimeter** — and explicitly cannot pretend to under MiCA Article 61. ### Actor 2 — The BaaS aggregator Owns the platform — the API, the IBAN\-issuance orchestration, the ledger, the customer dashboard. Typically holds an EU EMI or PI licence in its own right. Performs second\-line KYC on the end\-customers \(alongside the non\-EU VASP's first\-line KYC\) and applies the EU AML rules. Owns the contractual relationship with the sponsor bank. ### Actor 3 — The sponsor bank Owns the IBAN range. The IBAN's BIC traces to the sponsor bank in any reconciliation. Holds the relationship with the central bank's payment system. Inherits a piece of the regulatory perimeter under [EMD2](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0110)¹[^1] / PSD2 with respect to the BaaS aggregator's customers — even though the aggregator is the contractual customer of the sponsor. ### Actor 4 — The end\-customer Has a contract with the non\-EU VASP, an IBAN at the sponsor bank, segregated funds at the safeguarding bank, and KYC files at both the non\-EU VASP and the BaaS aggregator. Holds the right to claim against the EU regulated entity \(typically the BaaS aggregator under EMD2\) if the chain breaks. *Table: The four actors — what each owns and what each is liable for.* | Actor | Owns | EU regulatory liability | | --- | --- | --- | | Non\-EU VASP | Customer relationship, brand, home\-VASP licence | None on EU side \(Article 61 boundary\) | | BaaS aggregator | EU EMI/PI licence, platform, customer\-facing IBAN, end\-customer KYC | Primary EU liability — EMD2 / PSD2 perimeter | | Sponsor bank | IBAN range, payment\-system access | Inherited liability via outsourcing arrangement | | End\-customer | Holdings, claim rights | Beneficiary of EMD2 Article 7 safeguarding | ## Article 61 in the chain The chain works only if the BaaS aggregator does not market its EU IBAN product to EU customers **on behalf of** the non\-EU VASP. ESMA's [Guidelines on reverse solicitation](https://www.esma.europa.eu/sites/default/files/2025-02/ESMA35-1872330276-2030_Guidelines_on_reverse_solicitation_under_MiCA.pdf)²[^2] published in February 2025 are explicit that EU\-regulated entities are prohibited from soliciting or redirecting EU customers to third\-country firms — including intra\-group redirects. The legitimate use of the chain is to provide EU/USD rails to the non\-EU VASP's **existing non\-EU customer base** — customers in Georgia, Armenia, Cayman, BVI, Seychelles, or wherever the VASP has its home\-licence customer relationships. The chain is not a workaround for soliciting EU customers; ESMA construes solicitation broadly and treats the exemption as time\-bound and narrow. A non\-EU VASP that uses the BaaS aggregator's EU IBAN issuance to onboard EU customers triggers an Article 61 violation that flows up the chain to the BaaS aggregator and the sponsor bank. ## Three failure modes when the chain breaks ### 1. End\-customer files a claim against the wrong actor Customer experiences a service failure \(delayed transfer, frozen funds, account closure\) and brings the complaint to the non\-EU VASP — who has no EU regulatory standing to remediate. The legitimate path is to escalate to the BaaS aggregator \(the EU regulated counterparty for that end\-customer's funds\), but the customer typically does not know the aggregator exists. Result: regulatory complaint to the customer's local NCA, who in turn surfaces the chain and asks the BaaS aggregator who their actual customer is. ### 2. AML escalation routes wrong VASP detects suspicious activity. Files SAR/STR to home\-jurisdiction FIU \(Georgian FMS, Armenian FMC, etc.\). Does not file with the EU FIU where the IBAN sits. The BaaS aggregator's MLRO has parallel obligations under EU AML rules — the SAR should also be filed with the EU FIU through the aggregator. Failure to align creates a documented compliance gap that surfaces at the aggregator's next supervisory inspection. ### 3. Wind\-down ambiguity Either the non\-EU VASP or the BaaS aggregator winds down. Customer\-fund segregation should preserve customer balances regardless of which entity fails — but the operational mechanics depend on the chain being clearly drafted. Ambiguity here turns a 30\-day wind\-down into a 12\-month customer\-fund\-access crisis. ## Drafting the chain into the contract The contract suite \(non\-EU VASP ↔ BaaS aggregator ↔ sponsor bank ↔ safeguarding bank where separated\) must explicitly cover, at minimum: - Customer\-fund segregation under EMD2 Article 7, with named safeguarding bank and account\-naming convention. - KYC division of responsibilities — first\-line at non\-EU VASP, second\-line at BaaS aggregator, with explicit data\-sharing and re\-screening cadence. - AML escalation routing — single SAR/STR with parallel filing obligations articulated. - Article 61 governance — explicit prohibition on the BaaS aggregator soliciting EU customers on behalf of the non\-EU VASP, with audit rights for the aggregator's own compliance team. - Wind\-down playbook — sequenced steps for fund segregation, customer notification, regulator engagement, fund return. - Outsourcing governance per EBA Guidelines on outsourcing³ — board\-level approval, third\-party\-risk register entry, exit plan documented. > **Tip:** The chain becomes inspectable when the contract is drafted as if both NCAs \(the BaaS aggregator's home NCA and the sponsor bank's home NCA\) will read it during a thematic review. They will. The clearer the chain reads on first inspection, the lower the supervisory pressure on the aggregator's overall book and the more durable the relationship with the non\-EU VASP. ## How sponsor banks underwrite the chain EU sponsor banks underwriting BaaS aggregators that serve non\-EU VASPs ask, at minimum: - Composition of the aggregator's non\-EU VASP book — count, jurisdictional spread, customer\-base composition by VASP. - AMLR\-readiness of the aggregator's KYC stack — particularly with the AMLR self\-hosted\-wallet rules and the lower CDD thresholds applying from July 2027. - Article 61 governance evidence — how the aggregator prevents non\-EU VASPs from soliciting EU customers via the IBAN product. - Sanctions perimeter at each non\-EU VASP, especially any with Caucasus / Central Asia / Gulf nexus. - Wind\-down playbook depth and operational readiness for an aggregator failure scenario. The sponsor bank effectively **diligences the aggregator and the aggregator's non\-EU\-VASP book together**. An aggregator with one risky non\-EU VASP in the book can have its entire sponsor relationship re\-examined. AMLR⁴ application in July 2027 will harden this further as supervisors apply direct AMLA oversight to selected aggregators. ## Frequently Asked Questions ### Who is the regulated provider of the IBAN to the end\-customer? The BaaS aggregator \(or its underlying sponsor bank, depending on the contract structure\). Not the non\-EU VASP. The non\-EU VASP is the customer\-facing brand and front\-line KYC operator; the regulated provider is the EU EMI/PI that holds the licence. ### Can the non\-EU VASP brand the IBAN as its own product? Co\-branded is acceptable; pure non\-EU\-VASP branding without disclosure of the EU regulated provider triggers consumer\-protection issues and Article 61 risk. Best practice is clear front\-line disclosure that the IBAN is provided by the named EU EMI/PI partner. ### What changes under PSD3? PSD3 collapses EMD2 into the PSD framework, which simplifies the BaaS aggregator's regulatory perimeter \(EMI and PI become a single licence category\). The chain logic is preserved; the principal change is mandatory diversification of safeguarding across at least two credit institutions, which forces Layer 3 separation as the regulatory baseline. ### Does the chain apply to USD IBANs? Conceptually yes, with US\-correspondent and OFAC overlay added at the sponsor\-bank layer. USD products typically introduce a fifth actor \(the US correspondent\) and the chain expands accordingly. The Article 61 boundary is replaced by US state MTL and FinCEN MSB perimeter questions for the US\-side actors. ### What's the most\-litigated point in the chain? Customer\-fund segregation in a wind\-down. The contract should leave no ambiguity on who has operational control over fund release and on what timeline. Ambiguity here is what turns a wind\-down into a year\-long customer\-fund\-access crisis. > **Call to action:** Book a free regulatory bankability assessment. We respond within 24 hours. ## Related Guides - [The Non\-EU VASP Banking Stack](/resources/non-eu-vasp-banking-stack) — the architecture inside which the chain sits. - [Sponsor Bank Profile for Fintech BaaS](/resources/sponsor-bank-profile-fintech) — diligence framework for the sponsor bank in the chain. - [BaaS Due Diligence Checklist](/resources/baas-due-diligence-checklist) — 30 questions to put to any BaaS aggregator including chain\-of\-liability mapping. - [IBAN Architecture for Crypto Exchanges](/resources/iban-architecture-crypto-exchange) — three\-architecture decision framework that intersects with the chain. - [Banking Access for Regulated Fintechs](/services/banking) — our service: chain\-of\-liability drafting, Article 61 governance, BaaS aggregator selection. The chain of liability is invisible to the end\-customer and decisive to the supervisor. Draft the chain at the contract stage, document it in the BCP, audit it annually. **The chain that survives inspection is the chain that was drafted as if it would be inspected**. ## Footnotes [^1]: Directive 2009/110/EC \(EMD2\) — Article 7 customer\-fund safeguarding requirements applicable to electronic money institutions and the credit institutions where they place safeguarded funds. [^2]: ESMA — Guidelines on reverse solicitation under MiCA \(ESMA35\-1872330276\-2030\), February 2025. [^3]: European Banking Authority — Guidelines on outsourcing arrangements \(EBA/GL/2019/02\), establishing chain\-of\-liability and outsourcing\-governance expectations applicable to BaaS arrangements. [^4]: Regulation \(EU\) 2024/1624 \(AMLR\) — single rulebook on AML/CTF for financial entities, OJ L, 19.6.2024. --- Source: https://finconduit.com/resources/virtual-iban-non-eu-vasp-chain-of-liability