Virtual IBAN Issuance for Non-EU VASPs: The Chain of Liability (2026)

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.

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.

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.

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¹^[1] / PSD2 with respect to the BaaS aggregator's customers — even though the aggregator is the contractual customer of the sponsor.

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.

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²^[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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

• The Non-EU VASP Banking Stack — the architecture inside which the chain sits.

• Sponsor Bank Profile for Fintech BaaS — diligence framework for the sponsor bank in the chain.

• BaaS Due Diligence Checklist — 30 questions to put to any BaaS aggregator including chain-of-liability mapping.

• IBAN Architecture for Crypto Exchanges — three-architecture decision framework that intersects with the chain.

• Banking Access for Regulated Fintechs — 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.