The Non-EU VASP Banking Stack: Operating, Issuing, Customer-Facing (2026)

A VASP authorised in Georgia, Armenia, Cayman, BVI, or Seychelles cannot passport into the EEA. The licence is valid in the home jurisdiction; the regulatory perimeter ends at the border. And yet — almost universally — the VASPs operating from these jurisdictions need EU and USD payment rails to serve their customers. EUR-denominated IBANs, USD wires, SEPA Instant flows, card-issuing infrastructure: the operational backbone of crypto on/off-ramps lives inside the EEA and US correspondent banking systems. The non-EU VASP must access them through a different mechanism.

The architecture that works in 2026 is what we call the Non-EU VASP Banking Stack — three layers, each with its own counterparty, regulatory perimeter, and diligence cycle. Layer 1 is the operating bank for the VASP entity itself. Layer 2 is the issuing partner that provides the IBAN/card products the VASP fronts to its customers. Layer 3 is the customer-facing safeguarding wrapper — the regulated EU entity that holds end-customer balances on its own licence. The VASP sits on top, branding the customer experience; the regulated work happens inside Layer 2 and Layer 3.

This article codifies the Stack: what each layer does, how the layers interact, the MiCA Article 61 boundary that constrains the design, the implementation sequence for non-EU founders, and the cost envelope at each cohort. The Stack is not optional — non-EU VASPs that try to skip a layer end up with either a non-functional product or a regulatory exposure that cannot survive the first inspection cycle.

MiCA¹^[1] applied fully from 30 December 2024. The framework is restrictive about who can provide crypto-asset services to EU customers: an authorised CASP based in an EEA member state, passporting into other EEA states. Third-country firms are confined to a narrow reverse-solicitation exemption under Article 61 — and ESMA's guidelines on reverse solicitation construe it narrowly.

In its February 2025 final Guidelines on reverse solicitation²^[2], ESMA stated that the exemption is to be "very narrowly framed, time bound" and that the definition of "solicitation" must be construed broadly. Critically, ESMA also held that EU-regulated entities are explicitly prohibited from soliciting or redirecting EU clients to crypto-asset services provided by a third-country firm — even if that firm is part of the same corporate group. The exemption is not a workaround for the passporting question.

The practical consequence: a Georgian or Armenian VASP wanting to offer EU/USD rails to its end-customers must do so through an EU-authorised entity that holds the regulatory perimeter — typically an EU EMI, PI, or CASP serving as the issuing partner. The VASP cannot simply contract for an EU bank account and pass IBANs through to its customers; the issuance and safeguarding happen inside the EU regulated entity, and the VASP is operationally a referrer with limited regulatory standing on the EU side.

The bank that holds the VASP entity's own corporate funds. Working capital, payroll, vendor payments, tax. Functionally a corporate account with elevated diligence because of the regulated-crypto status. For a Georgian or Armenian VASP, the operating bank is typically domestic — banking the entity locally is structurally simpler than seeking a foreign relationship for OPEX. For Cayman/BVI/Seychelles VASPs, the operating bank is more often a specialist offshore-friendly institution outside the home jurisdiction (Switzerland, Liechtenstein, Singapore, UAE, Caribbean correspondents).

Layer 1 does not touch customer funds. It carries the entity's own balance sheet, and its diligence is calibrated accordingly — corporate-banking depth with a regulated-crypto overlay. Capital expectation: typically $300k–$1.5M parked at the relationship.

The EU-authorised entity (typically an EMI under EMD2³^[3] or a PI under PSD2⁴^[4]) that issues the IBAN, card, or payment-account product the VASP brands to its customers. Layer 2 holds the EU regulatory perimeter on the customer-facing payment flow. The VASP contracts with Layer 2; Layer 2 contracts with its own sponsor bank; the IBAN range is on the sponsor bank's BIC.

This is where the Stack's regulatory weight sits. Layer 2 must perform full KYC on the end-customers (regardless of any KYC the VASP has done independently), apply EU AML rules, satisfy MiCA Article 61 by ensuring it is not soliciting EU customers on behalf of the third-country VASP, and accept the chain-of-liability mapping that flows from end-customer back through the Layer 2 entity to the sponsor bank. (We cover the chain in detail in our companion article on virtual IBAN issuance.)

In some Stack designs Layer 2 also performs Layer 3 — the EMI both issues the IBAN and safeguards the customer balance under EMD2 Article 7. In more sophisticated designs the two are split, with the customer-fund safeguarding sitting at a separate institution that the issuing partner contracts. The separation question maps directly to the Three-Bank Resilience Standard: pooling issuing and safeguarding at one institution creates concentration that supervisors increasingly flag. Layer 3 separation is the mature pattern for any Stack handling material end-customer volume.

The most common failure pattern. A non-EU VASP secures an EU corporate bank account for its own OPEX (Layer 1 in an EU institution) and then attempts to use that account to receive end-customer fiat. The EU operating bank discovers the activity in transaction monitoring within weeks and exits the relationship. The VASP loses both Layer 1 and any nascent customer-facing rails simultaneously.

The VASP secures a Layer 2 issuing partner but markets the EU IBANs to EU customers as if it (the VASP) were the regulated counterparty. ESMA's reverse-solicitation guidelines treat this as a clear violation. Both the VASP and the Layer 2 EMI face exposure; the EMI typically terminates the relationship to protect itself.

Acceptable at small cohort, structurally fragile at scale. When Layer 2 also performs safeguarding, a single sponsor-bank exit terminates the entire customer-facing product. The Three-Bank Resilience Standard recommends progressively splitting the layers as customer-fund volume rises.

The non-EU VASP runs OPEX through a single domestic bank. When that bank de-risks (the Caucasus banking filter is a recurring driver), the VASP loses the ability to pay employees and vendors — and Layer 2 typically sees the operational disruption in monitoring and tightens its own posture. Layer 1 redundancy is non-negotiable.

The Stack works only inside the boundary set by Article 61. The non-EU VASP cannot:

• Solicit EU customers directly. Marketing into EU member states triggers the requirement for MiCA CASP authorisation in the relevant home state.

• Use the Layer 2 EMI's licence as a de-facto passport. ESMA explicitly prohibits this.

• Have the Layer 2 EMI redirect or cross-sell EU customers to its (the VASP's) third-country crypto services. Even intra-group redirects are out of bounds.

• Rely on reverse solicitation as a steady-state operating model. ESMA holds the exemption is time-bound and narrow.

The legitimate use of the Stack is for non-EU customers — the VASP's customer base in its home jurisdiction or in non-EU regions where it has direct or licensed access. The EU/USD rails enable cross-border payment processing for those customers; they do not unlock the EU customer base.

Domestic operating bank for the VASP entity. Document the home VASP authorisation, complete bank-side diligence, fund the relationship. For Caucasus VASPs, build the documented sanctions perimeter that demonstrates Russia-flow separation; for offshore VASPs, prepare the substance dossier the home jurisdiction's bank network expects.

Identify Layer 2 candidates — EU EMIs or BaaS aggregators willing to onboard non-EU VASPs. The candidate set is narrower than founders expect and the diligence is heavier than founders expect, calibrated against the EBA outsourcing guidelines⁵^[5]. The non-EU VASP's home jurisdiction, customer base composition, and sanctions-perimeter evidence dominate the Layer 2 underwriting.

BaaS Due Diligence Checklist applied: 30 questions to the candidate Layer 2 with explicit chain-of-liability mapping. Contract negotiation. API integration. Customer onboarding flow with the Layer 2's KYC overlay enforced. Test transactions through full end-customer cycle.

At material customer-fund volume, request Layer 2 to separate safeguarding to a distinct institution. This is typically a contract amendment rather than a re-platforming, but requires Layer 2's own sponsor bank's approval. Document the separation in the firm's BCP and inspection-readiness pack.

All-in indicative annual cost of the Stack at Year-1 mid-cohort (€10–€50M annual revenue):

• Layer 1 (operating): €15–€40k direct fees + €5–€15k legal advisory.

• Layer 2 (issuing partner): €60–€180k annual platform + per-transaction fees, plus €30–€80k integration cost in year 1.

• Layer 3 (separated safeguarding): €15–€40k incremental cost over Layer 2-bundled safeguarding.

• Compliance overhead allocated to Stack governance: €40–€120k.

• Total Year-1 indicative range: €165k–€475k all-in for the full Stack.

This sits below the equivalent direct-CASP authorisation cost (which is typically €1M+ Year-1 in Lithuania or Cyprus) and that is the strategic logic of the Stack: it provides EU/USD rails without the licensing burden, at the cost of the constraints discussed above.

Yes, at small cohort and limited customer-fund volume. The single-partner pattern is operationally simpler and represents the typical Year-1 architecture. The split into a separate Layer 3 becomes important as customer-fund volume rises and as supervisors increasingly inspect concentration risk under DORA and the forthcoming PSD3 diversification expectations.

The Stack is the wrong architecture. Direct MiCA CASP authorisation in an EEA home state is the durable answer. Lithuania, Cyprus, and Malta are the most-used jurisdictions; our existing guides walk those processes. The Stack is for non-EU VASPs serving non-EU customers with EU/USD rails — fundamentally different.

Materially. Layer 2 EU EMIs underwriting a Caucasus VASP weight Russia-flow separation heavily. The VASP's documented sanctions perimeter — geo-fencing, on-chain forensics overlay, customer-base composition test — is the dominant Layer 2 underwriting input. We cover this in detail in our Sanctions-Edge VASP article.

Yes, with adjustments. Offshore VASPs typically place Layer 1 in a third country (Switzerland, Singapore, UAE) rather than the home jurisdiction, because the home jurisdiction has a thinner banking ecosystem. Layers 2 and 3 are structurally identical to the Caucasus case. Our companion offshore-VASP article covers the jurisdictional differences.

PSD3's mandatory diversification — customer funds spread across at least two credit institutions above a threshold — directly maps to the Layer 2 / Layer 3 separation question. Stacks designed today should anticipate the separation as the regulatory baseline, not the operational refinement. We expect Layer 3 separation to become structurally non-negotiable for non-EU VASP Stacks once PSD3 applies.

• The Three-Bank Resilience Standard — the resilience pattern that informs Layer 3 separation.

• Sponsor Bank Profile for Fintech BaaS — the diligence framework for evaluating Layer 2 sponsor relationships.

• BaaS Due Diligence Checklist — the 30 questions to put to any Layer 2 candidate.

• Bank Diligence File for a Regulated Crypto Firm — the document set that Layer 2 will require during onboarding.

• Banking Access for Regulated Fintechs — our service: Stack architecture design, Layer 2 introductions, supervisor-readiness.

The Non-EU VASP Banking Stack is not a marketing phrase. It is the architecture that separates non-EU VASPs whose EU/USD rails survive the first inspection cycle from those whose rails fail in the first six months. Build the layers deliberately. Sequence them properly. Document the chain of liability. Then audit the Stack annually against the latest ESMA guidelines and the regulatory direction of travel under PSD3.