Zum Inhalt springen
Startseite Seqlense DOC Seqlense Web3 Monitoring Seqlense Notes Seqlense IMMO Krypto-Untersuchung OSINT-Untersuchung Schulung & Beratung Preise Unterstützte Blockchains Academy Blog Partner Kontakt
EN FR DE
Mein Seqlense Loslegen
Back to blog

The crypto Travel Rule, explained for compliance teams

What FATF Recommendation 16 requires when value moves on-chain, and how firms actually implement it.

When money moves through the banking system, information about who sent it and who receives it travels alongside the payment. The crypto Travel Rule extends that same logic to value moving on-chain. It is one of the more operationally demanding parts of any crypto compliance programme, because a blockchain address on its own tells you nothing about the human or entity behind it. This guide explains what FATF Recommendation 16 actually requires, how the EU has implemented it, and what firms do in practice to comply.


What the Travel Rule is

The Travel Rule comes from Recommendation 16 of the Financial Action Task Force (FATF), the global standard-setter for anti-money-laundering and counter-terrorist-financing rules. It originally applied to wire transfers between banks. In 2019, FATF extended it to virtual asset service providers (VASPs), meaning exchanges, custodians, and similar intermediaries.

The core obligation is simple to state and harder to build: when a VASP sends a crypto transfer above a set threshold, it must collect and transmit identifying information about the originator (the sender) and the beneficiary (the recipient) to the receiving VASP. The receiving institution must in turn receive that data, check it, and hold it. The point is to attach an auditable identity trail to transactions that would otherwise be pseudonymous.


What information has to travel

Under the FATF standard, a qualifying transfer must carry, at minimum:

  • Originator: name, the account number or wallet address used for the transfer (or a unique transaction reference), and either a physical address, a national identity or customer number, or date and place of birth.
  • Beneficiary: name, and the account number or wallet address (or unique reference) used to receive the transfer.

FATF sets a de minimis threshold of USD/EUR 1,000. Below it, a lighter set of data (essentially the names of both parties and the wallet references) can travel without mandatory verification, unless there is a suspicion of money laundering or terrorist financing. Above it, the identifying details must be collected and, where required, verified.


How the EU implemented it

The EU has gone further than the FATF baseline. The relevant text is Regulation (EU) 2023/1113, the recast Transfer of Funds Regulation (often called the TFR), which applies from 30 December 2024 and runs alongside the Markets in Crypto-Assets Regulation (MiCA).

Two features stand out for firms operating in Europe:

  1. No de minimis threshold. Unlike the FATF 1,000 floor, the EU rule applies to crypto-asset transfers of any value. Every transfer between crypto-asset service providers (CASPs) must be accompanied by the required information, even small ones.
  2. Detailed data expectations. The European Banking Authority has issued Guidelines on the information requirements, clarifying what fields are needed, how to handle missing or incomplete data, and what to do with transfers involving self-hosted (unhosted) wallets.

For self-hosted wallets, the picture is different from CASP-to-CASP transfers. There is no counterparty institution to receive the data, so the obligation shifts toward collecting information from the firm's own customer and, above certain amounts, taking steps to verify that the customer controls the wallet.


How firms actually implement it

The rule is one line of policy and a large amount of engineering. In practice, compliance teams work through several moving parts:

  • Counterparty VASP discovery. Before sending data, you have to know which institution controls the beneficiary address, and whether it is even a regulated VASP. This is a genuinely hard problem and relies on address attribution and shared industry directories.
  • A secure messaging protocol. The personal data cannot ride on the blockchain itself, so it moves through an off-chain channel. Several interoperable protocols and networks exist to carry Travel Rule messages between institutions.
  • Sanctions and risk screening. Names and addresses that arrive with an incoming transfer are screened against sanctions and watchlists, and the wallet is risk-scored against known illicit activity.
  • Handling data gaps. A large share of real-world transfers arrive with missing or malformed information. Firms need a documented policy for what to request, when to hold or return funds, and how to record the decision.

The last two points are where on-chain analytics matter most. Attributing a counterparty address, scoring it for exposure to sanctioned or high-risk sources, and monitoring flows over time are what turn a raw address into a risk decision you can defend to a regulator.


Where this connects to Seqlense

Two Seqlense capabilities sit close to this work. Blockchain address Monitoring provides on-chain surveillance, risk scoring, and alerts on the addresses your transfers touch, which supports both the screening and the ongoing-monitoring side of a Travel Rule programme. And because the rules keep moving (EBA guidance, MiCA-related standards, national supervisory expectations), the Doc regulatory-watch module tracks publications across EBA, ESMA, and national authorities, so a change in the information requirements does not reach you late. You can narrow the feed with filters such as source:EBA and doctype:guidance.


Sources

Related articles

Why compliance is a monitoring problem, not a paperwork problem

The thesis behind treating regulatory and on-chain watch as one live signal.

KYT vs KYC: why transaction monitoring is now non-negotiable

Where identity checks stop and continuous behaviour monitoring has to start.