The Travel Rule Sunrise Issue: Why Half of Cross-VASP Transfers Still Fail in 2026

Eighteen months after MiCA, two years after FinCEN's renewed crypto guidance, four years after FATF's updated Recommendation 16 — and a meaningful share of cross-border VASP-to-VASP transfers still cannot exchange Travel Rule data. The reason is not technical. It is jurisdictional, and it has a name: the sunrise issue.

The metaphor is exact. The sun is up in some places. Still dark in others. A CASP in a fully-implemented regime trying to send to a VASP in a jurisdiction that has not yet implemented — or has implemented with incompatible requirements — cannot transmit the data the rule requires it to transmit. That is not the fault of either party. It is a multi-year transition problem with operational consequences right now.

What the Sunrise Issue Actually Is

FATF Recommendation 16 applied to virtual assets in 2019. It binds FATF member jurisdictions, which then implement domestically. Implementation has been uneven across three dimensions:

• Timing — the EU went live with the recast TFR on 30 December 2024; the US has had a Travel Rule for crypto since 2019 under the BSA but with a higher threshold; Singapore, Switzerland, the UK, and Japan have all implemented on their own schedules; large parts of Africa, Latin America, and South-East Asia are still in consultation
• Thresholds — the EU has no threshold (every transfer covered); the US sets USD 3,000; Singapore and the UK apply local-currency equivalents of about USD/EUR 1,000; the FATF default is USD/EUR 1,000
• Acceptance methods — different jurisdictions have approved different messaging protocols (TRISA, Notabene, Sygna, OpenVASP, proprietary national systems); not all of them speak to each other natively

The result is a geography of compliance with seams in it. A CASP regulated in a strict jurisdiction is required to send Travel Rule data on every covered transfer. The counterparty in a not-yet-implementing jurisdiction may have no obligation to receive it, no technical means to receive it, and no incentive to install one.

The Four Failure Modes

When a Travel Rule message cannot be exchanged, it is for one of four operational reasons. The CASP's response — and the documentation it produces — needs to distinguish between them:

1. The counterparty is in a jurisdiction with no Travel Rule

The destination VASP has no domestic obligation to receive TR data. It may have no infrastructure to do so. The originator's obligation does not disappear — the FATF and EU expectation is that the originator attempts transmission, documents the inability, and applies risk-based mitigation. The transfer can still proceed in many cases; the audit trail of the attempt is what auditors will look for.

2. The counterparty has implemented an incompatible protocol

Both sides have Travel Rule obligations, but they use different messaging systems. A CASP on TRISA, a counterparty on Sygna Bridge, no native bridge in place. Inter-protocol bridges have improved — Notabene now bridges to TRISA and OpenVASP, and IVMS101 provides a common data layer — but coverage is not universal. Where bridges fail, the technical impossibility is documented and the transfer either proceeds with risk-based mitigation or is rejected.

3. The counterparty cannot identify itself as a VASP

The originator's attribution layer does not recognise the destination address as belonging to a VASP. The destination treats itself as unhosted, or operates without registering with a VASP directory. The originator either reclassifies the transfer as one to an unhosted wallet (and applies the unhosted-wallet workflow, including ownership verification above EUR 1,000) or holds the transfer for manual review. False classification of a VASP as unhosted is itself a control gap; the attribution layer needs to be accurate.

4. The destination address is unhosted

Not a sunrise issue per se, but the operational reality blends into it: a significant share of crypto withdrawals go to self-custodied wallets where there is no counterparty VASP at all. The EU TFR addresses this explicitly with the EUR 1,000 ownership-verification threshold. Jurisdictions outside the EU handle unhosted wallets differently — some require equivalent verification, some do not. A CASP serving customers across jurisdictions has to apply the strictest applicable rule, which usually means the EU's.

What CASPs Are Actually Doing

Across the regulated CASP population, three operational strategies have emerged for the sunrise period:

• Refuse-on-failure — if Travel Rule data cannot be exchanged, the transfer is rejected. Operationally clean, but loses legitimate flow to less-strict competitors. Tends to be the posture of CASPs in the most-scrutinised jurisdictions (banks doing crypto in Switzerland, German BaFin-licensed CASPs)
• Document-and-proceed — attempt transmission, log the inability, apply risk-based mitigation (enhanced screening, transaction limits, manual review for high-risk corridors), proceed unless other red flags are present. The most common strategy, and the one explicitly contemplated by FATF guidance
• Queue-and-retry — hold the transfer for a defined window, retry transmission as counterparty capabilities evolve, then either complete or refund. Operationally heaviest, but smooths the customer experience as the sunrise progresses

Each strategy is defensible if it is documented and risk-based. The indefensible strategy is the one most failures point to: no strategy. Transfers proceed silently when transmission fails, with no documented attempt and no risk-based decision — the audit equivalent of a flat "we forgot."

How Long Does This Last

Optimistic FATF assessments target broad convergence by 2027. Realistic ones extend further. The trajectory is positive — large emerging markets are passing implementing legislation, the major messaging protocols are interoperating more, IVMS101 is consolidating as the data layer — but the long tail of small-jurisdiction VASPs without compliance infrastructure will persist past any optimistic date.

The practical implication for CASPs is that the sunrise issue is not a temporary inconvenience to wait out. It is the operating environment. The compliance programmes that win are the ones that productise the sunrise handling: explicit per-corridor policies, automated attempt-and-document workflows, quantitative success metrics, and risk-based mitigation that scales without manual triage on every transfer.

For the regulatory baseline see The Travel Rule for Virtual Assets: Implementation Guide. For the operational workflow with BA, see Travel Rule, End-to-End: Sending Originator/Beneficiary Data in 4 Steps.