The Rule That Arrived Unevenly

The sunrise problem isn't a policy debate. It's a decision you make today.

FATF Recommendation 16, the Travel Rule, was written for wire transfers and extended to virtual assets in June 2019 [1]. It requires firms to collect, verify, and transmit originator and beneficiary information on qualifying transfers, the same basic obligation correspondent banks have carried for decades, applied to a rail that didn't exist when the standard was first drafted.

The complication is not the requirement itself, it's the pace at which jurisdictions have actually brought it into force. Practitioners call this the sunrise problem, after the fact that the sun rises at different times across time zones. A firm operating in a jurisdiction that has fully implemented the rule still has to transact with counterparties in jurisdictions where no equivalent obligation yet exists, or exists on paper but isn't supervised in practice. The rule doesn't arrive everywhere at once, and a transfer doesn't wait for both ends of the pipe to be compliant before it moves.

Stated plainly, that's the argument this guide makes: the sunrise problem isn't something to read about, it's something an analyst decides, in the moment, on incomplete data, with a small number of real actions available and a real consequence attached to each one. Reading about FATF Recommendation 16 doesn't prepare you for the moment a transfer lands with no originator data attached and a live business decision waiting. This guide teaches that decision, through an interactive tree covering both directions, sending and receiving.

One distinction is worth fixing before anything else, because it's the single most common and costly error in this area. In the EU, originator and beneficiary data must travel with a transfer between two crypto firms from the first cent, there is no minimum [2]. The 1,000 euro figure that gets quoted constantly is a different, narrower thing entirely: it's the point above which a firm must verify that its customer actually controls a self-hosted wallet involved in the transfer [3]. Conflating the two produces exactly the failure mode you'd expect, a small transfer waved through with no Travel Rule data at all, on the mistaken belief that it fell under a threshold that was never about data transmission in the first place.

The enforcement picture backs up why this matters in practice, not just on paper. French and German regulators have both moved against unlicensed offshore crypto operators through 2025. The AMF added dozens of names to its unauthorised-provider blacklist over the course of the year, including a dedicated crypto-derivatives category [6]. BaFin issued public warnings against unlicensed crypto-linked websites in May 2025 and against the DAO1 scheme in October [7]. And FATF's own supervision data is blunt about the gap that remains: of the jurisdictions that have passed Travel Rule legislation, only around 40% have actually taken enforcement or supervisory action to test compliance against it [5]. That enforcement gap isn't a footnote to the sunrise problem, it's a core part of it, since it's precisely the space in which a counterparty jurisdiction can have a rule in force with nobody checking whether firms are actually following it.

How to use this guide

Read this section and the five patterns below first. Then work the decision tree in both directions, as a sender and as a receiver, and read the basis cited for each terminal action, not just its instruction. The knowledge check at the end pulls the same distinctions from new angles.

Make the Call

You're mid-transfer. The data hasn't arrived the way it should have. What do you do?

Work through it as it would actually happen: pick whether you're sending or receiving, then answer each question as it's put to you. There's no fixed number of steps, some paths resolve in two clicks, others in three. Every ending states the action to take and the specific rule behind it. Click "Start over" to run it again from either side.

Five Patterns

Five patterns, five cards

Most Travel Rule misses trace back to one of these five shapes. Learn to recognise them, the decision tree above tests several of them directly.

🎯
The Threshold Trap
Two different euro figures, one data-transmission rule, one verification rule, and analysts merge them into one.

The 1,000 euro figure gets attached to the wrong obligation constantly, treated as though it were the point at which Travel Rule data starts being required. It isn't. Under the Transfer of Funds Regulation, originator and beneficiary data travels with every CASP-to-CASP transfer from the first cent, no threshold at all. The 1,000 euro figure is a separate, narrower trigger under Articles 14(5) and 16(2), it decides only when a firm must verify that a customer controls a self-hosted wallet. Treating them as one rule is the single most common way a firm ends up with a Travel Rule gap it didn't know it had.

Risk
Assuming the 1,000 euro figure is a data-transmission threshold.
Signal
A small CASP-to-CASP transfer waved through with no Travel Rule data.
Response
Transmit data from the first cent between firms, the 1,000 euro figure only triggers wallet-ownership verification.
🌅
The Sunrise Gap
The sender wasn't obliged to send data. That's not the same as a free pass to credit the funds blind.

When a transfer lands from a firm in a jurisdiction where the Travel Rule isn't yet in force, or is in force but unsupervised, it's tempting to treat the absence of data as explained and move on. It isn't a clean explanation, it's a risk that needs assessing on its own terms. FATF's own guidance is to treat these counterparty relationships the way a bank treats a correspondent-banking relationship, which means active due diligence, not passive acceptance because the other side technically had no obligation to do better.

Risk
Treating a non-implementing counterparty jurisdiction as a free pass to credit blind.
Signal
An inbound transfer from a firm in a jurisdiction with no Travel Rule in force.
Response
Apply correspondent-banking-style due diligence, don't proceed just because the sender wasn't obliged to send data.
📥
The Blind Inbound
A firm can be fully compliant on everything it sends and still have no real controls on what it receives.

Outbound Travel Rule compliance gets the engineering attention because it's the part a firm controls end to end. Inbound is different, the data arrives in whatever shape the sending firm chose to send it, and if that's a free-text memo field rather than a structured, machine-readable message, a system built only to send data correctly may not even parse what it received. Being compliant in your home jurisdiction says nothing about whether you're actually equipped to process what lands.

Risk
Being compliant outbound but never building incoming-transfer controls.
Signal
Transfers arriving with data buried in a free-text memo field your system can't parse.
Response
Build machine-readable inbound controls, a compliant home jurisdiction doesn't make you compliant on what lands.
🤐
The Silent Proceed
Crediting a transfer with missing data because holding it is friction, and leaving no record that a gap existed at all.

The EBA's guidelines give four real options when data is missing or incomplete: execute, suspend, return, or reject, chosen on a risk basis [8]. What isn't an option is silently crediting the transfer and moving on because a hold slows the customer down. An empty hold-and-reject log across a meaningful volume of transfers is itself a red flag under review, it suggests a firm that never actually exercises the judgement the rule expects it to exercise.

Risk
Crediting a transfer with missing originator data because holding it is friction.
Signal
A hold-and-reject log that's suspiciously empty.
Response
Suspend, return, or reject on missing data, and keep the log that proves you did.
🔐
The Self-Hosted Assumption
A self-hosted wallet isn't outside the regime, it's treated as inherently higher risk within it.

Self-custody is sometimes read as a gap in the regulatory perimeter, since there's no counterparty firm on the other end to exchange data with. That reading misses the actual rule, which is that above the local verification threshold, the firm must confirm its own customer controls the destination wallet, and the regulation's own recitals treat self-hosted transfers as inherently higher risk regardless of amount. A large withdrawal to an unverified external address is the exact scenario the threshold exists to catch.

Risk
Assuming a self-hosted wallet is out of scope.
Signal
A large withdrawal to an unverified external address.
Response
Verify ownership above the local threshold, document the method, treat self-hosted as inherently higher risk per the regulation's own recitals.
Knowledge Check
Five questions. Would you make the same call the decision tree just walked you through?
1. Under the EU TFR, at what value must Travel Rule data travel with a transfer between two crypto firms?
2. What does the 1,000 euro self-hosted wallet figure actually trigger?
3. A transfer arrives from a firm in a jurisdiction with no Travel Rule in force, carrying no originator data. What's the right approach?
4. A transfer arrives from a compliant jurisdiction with incomplete originator data. Which is NOT one of your options?
5. What did the FATF's July 2026 update report on global Travel Rule adoption?
0/5
Frequently Asked

FAQ

Is the 1,000 euro figure the point at which I have to start sending Travel Rule data? +
No, and this is the most common misunderstanding. Between two crypto firms in the EU, originator and beneficiary data must travel with every transfer from the first cent, there is no minimum. The 1,000 euro figure is a separate, narrower trigger: it's the point above which a firm must verify that its customer actually controls a self-hosted wallet involved in the transfer.
A transfer arrived from a firm in a country with no Travel Rule in force, with no originator data. Can I just process it? +
Not without a risk-based assessment. The sender may not have been legally obliged to transmit data, but you're still obliged to manage the risk. FATF recommends treating these counterparty relationships the way a bank treats correspondent-banking ones. Depending on what you can establish, proceed with enhanced due diligence, suspend and request the data, or reject.
What are my actual options when a transfer arrives with missing or incomplete data? +
Under the EBA's guidelines, four: execute, suspend, return, or reject, chosen on a risk basis. What you cannot do is silently credit it and move on. Whichever you choose, log it.
How do I verify a customer controls a self-hosted wallet? +
Three methods are generally accepted: a micro test transfer from the wallet, a Satoshi test, cryptographic message signing from the wallet, or a video-based verification flow. Message signing is common but fragile in practice, a signing-format mismatch can fail a legitimate customer, so test across wallet types before relying on it.
Could the EU tighten the rules on self-hosted wallets further? +
Possibly. Under TFR Article 37, the European Commission was required to assess the risks of transfers to and from self-hosted addresses by 1 July 2026 [9] and, if it saw fit, propose tighter measures, which it can bring in through a fast-track delegated act. Options discussed in policy circles range from keeping the status quo to mandatory wallet whitelisting or transaction caps. As of this guide's publication that assessment had not been published, so the position remains unsettled, worth watching.
Quick Reference

At a glance

Five patterns, the risk that makes each one look routine, the signal that actually gives it away, and the response that fits.

🎯
The Threshold Trap
Two different euro figures, one data-transmission rule, one verification rule, and analysts merge them into one.
Risk
Assuming the 1,000 euro figure is a data-transmission threshold.
Signal
A small CASP-to-CASP transfer waved through with no Travel Rule data.
Response
Transmit data from the first cent between firms, the 1,000 euro figure only triggers wallet-ownership verification.
🌅
The Sunrise Gap
The sender wasn't obliged to send data. That's not the same as a free pass to credit the funds blind.
Risk
Treating a non-implementing counterparty jurisdiction as a free pass to credit blind.
Signal
An inbound transfer from a firm in a jurisdiction with no Travel Rule in force.
Response
Apply correspondent-banking-style due diligence, don't proceed just because the sender wasn't obliged to send data.
📥
The Blind Inbound
A firm can be fully compliant on everything it sends and still have no real controls on what it receives.
Risk
Being compliant outbound but never building incoming-transfer controls.
Signal
Transfers arriving with data buried in a free-text memo field your system can't parse.
Response
Build machine-readable inbound controls, a compliant home jurisdiction doesn't make you compliant on what lands.
🤐
The Silent Proceed
Crediting a transfer with missing data because holding it is friction, and leaving no record that a gap existed at all.
Risk
Crediting a transfer with missing originator data because holding it is friction.
Signal
A hold-and-reject log that's suspiciously empty.
Response
Suspend, return, or reject on missing data, and keep the log that proves you did.
🔐
The Self-Hosted Assumption
A self-hosted wallet isn't outside the regime, it's treated as inherently higher risk within it.
Risk
Assuming a self-hosted wallet is out of scope.
Signal
A large withdrawal to an unverified external address.
Response
Verify ownership above the local threshold, document the method, treat self-hosted as inherently higher risk per the regulation's own recitals.
Quick Reference

Summary snapshot

The full guide in one image, for quick reference or sharing.

Crypto Travel Rule summary infographic showing the zero threshold for data transmission between crypto firms versus the EUR1,000 wallet ownership verification trigger, the four options for missing data, execute, suspend, return, or reject, five patterns including the threshold trap and the sunrise gap, and BaFin's blocking of six offshore exchange domains for lacking proper CASP authorisation.
⬇️ Download summary
The Decision Is the Guide

The sun rises unevenly. Your obligations don't wait for it to catch up.

FinCrimeRadar's Scenario Lab puts the same investigative decisions in front of you under real time pressure and partial information, free, no signup required.

Want to practise the decisions rather than read about them? Free. No account needed. Work real cases under time pressure and partial information.
Open the Scenario Lab →
Verification

Sources

Each numbered claim above is checked against the specific source below it. Figures without a bracketed number are industry estimates or illustrative examples rather than verified facts; the surrounding text says which.

  1. FATF, Seventh Targeted Update on Implementation of the FATF Standards on Virtual Assets and VASPs, Table 1.1, 16 July 2026. fatf-gafi.org/en/publications/Fatfrecommendations/targeted-updated-virtualassets-vasps-2026.html
  2. Regulation (EU) 2023/1113 of the European Parliament and of the Council of 31 May 2023 (Transfer of Funds Regulation), applicable from 30 December 2024. eur-lex.europa.eu/eli/reg/2023/1113/oj/eng
  3. Regulation (EU) 2023/1113, Articles 14(5) and 16(2) (self-hosted wallet ownership verification above EUR 1,000). eur-lex.europa.eu/eli/reg/2023/1113/oj/eng
  4. FATF, Seventh Targeted Update on Implementation of the FATF Standards on Virtual Assets and VASPs, 16 July 2026 (83%, 91 of 109 surveyed jurisdictions, up from 73% a year earlier). fatf-gafi.org/en/publications/Fatfrecommendations/targeted-updated-virtualassets-vasps-2026.html
  5. FATF, Seventh Targeted Update on Implementation of the FATF Standards on Virtual Assets and VASPs, 16 July 2026 (enforcement/supervisory action gap). fatf-gafi.org/en/publications/Fatfrecommendations/targeted-updated-virtualassets-vasps-2026.html
  6. Autorité des Marchés Financiers (AMF), unauthorised-provider blacklist, crypto-assets and crypto-asset derivatives categories. The AMF republishes this blacklist on a rolling basis rather than archiving dated snapshots; the specific per-release name counts reported for December 2025 and August 2025 could not be independently re-verified against a stable, currently-live source, so the figure is not asserted precisely here. protectepargne.amf-france.org/acteurs-listes-noires/biens-divers-crypto-actif
  7. BaFin, consumer warnings against unauthorised crypto-linked websites: valuewanderer.com, 14 May 2025 and DAO1 / Apertum Holding Limited, 2 October 2025.
  8. European Banking Authority, EBA issues 'travel rule' guidance to tackle money laundering and terrorist financing in transfers of funds and certain crypto-assets, 4 July 2024 (EBA/GL/2024/11, risk-based execute/suspend/return/reject options for missing data). eba.europa.eu, EBA issues travel rule guidance
  9. Regulation (EU) 2023/1113, Article 37(2) (Commission assessment of self-hosted address transfer risk due by 1 July 2026). eur-lex.europa.eu/eli/reg/2023/1113/oj/eng
Continue Reading

Related topics