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. 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. 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. 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 regulators issued 14 enforcement notices to crypto businesses in the fourth quarter of 2025 alone. Germany's BaFin blocked access to six offshore exchange domains that were targeting German users without proper CASP authorisation. And FATF's own supervision data is blunt about the gap that remains: only around 40% of jurisdictions with Travel Rule statutes on the books have actually taken steps to test or enforce compliance against them. 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.

Trap
Assuming the 1,000 euro figure is a data-transmission threshold.
Tell
A small CASP-to-CASP transfer waved through with no Travel Rule data.
Do
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.

Trap
Treating a non-implementing counterparty jurisdiction as a free pass to credit blind.
Tell
An inbound transfer from a firm in a jurisdiction with no Travel Rule in force.
Do
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.

Trap
Being compliant outbound but never building incoming-transfer controls.
Tell
Transfers arriving with data buried in a free-text memo field your system can't parse.
Do
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. 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.

Trap
Crediting a transfer with missing originator data because holding it is friction.
Tell
A hold-and-reject log that's suspiciously empty.
Do
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.

Trap
Assuming a self-hosted wallet is out of scope.
Tell
A large withdrawal to an unverified external address.
Do
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 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 trap that makes each one look routine, the tell 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.
Trap
Assuming the 1,000 euro figure is a data-transmission threshold.
Tell
A small CASP-to-CASP transfer waved through with no Travel Rule data.
Do
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.
Trap
Treating a non-implementing counterparty jurisdiction as a free pass to credit blind.
Tell
An inbound transfer from a firm in a jurisdiction with no Travel Rule in force.
Do
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.
Trap
Being compliant outbound but never building incoming-transfer controls.
Tell
Transfers arriving with data buried in a free-text memo field your system can't parse.
Do
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.
Trap
Crediting a transfer with missing originator data because holding it is friction.
Tell
A hold-and-reject log that's suspiciously empty.
Do
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.
Trap
Assuming a self-hosted wallet is out of scope.
Tell
A large withdrawal to an unverified external address.
Do
Verify ownership above the local threshold, document the method, treat self-hosted as inherently higher risk per the regulation's own recitals.
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 →