Guides
Jul 27, 2026

What Is the Travel Rule? FATF Rule 16 for Crypto Explained

The Travel Rule explained: what FATF Recommendation 16 requires, which data must travel with a crypto transfer, how thresholds differ in the EU and US, and what compliance looks like in practice.

What Is the Travel Rule? FATF Rule 16 for Crypto Explained

Last updated: July 2026

The Travel Rule is the most operationally disruptive piece of crypto regulation most exchanges will ever implement. It is not a licence, not a capital requirement, and not a reporting form. It is a plumbing problem: identifying information has to travel alongside a transfer, between two companies that may never have spoken, that use different software, and that sit in jurisdictions with contradictory thresholds.

This guide explains what the Travel Rule says, which data fields must move, how thresholds differ between the EU, the United States and the wider FATF membership, and what a working compliance stack looks like. It also answers the question that matters most to anyone building on-chain: does the Travel Rule apply to non-custodial DeFi?

What is the Travel Rule?

The Travel Rule is an anti-money-laundering requirement that obliges financial institutions to collect, verify and transmit identifying information about the sender and recipient of a transfer, and to pass that information on to the next institution in the chain. In crypto, it means a virtual asset service provider (VASP) sending funds must share originator and beneficiary data with the receiving VASP, alongside the on-chain transaction itself.

The name comes from the requirement that the data must travel with the value. A blockchain transfer carries addresses and amounts, but no names. The Travel Rule closes that gap by moving identity data over a separate channel, so the receiving institution knows who it is receiving from before crediting the customer.

Travel Rule meaning in plain terms

If you send 5,000 EUR of crypto from Exchange A to Exchange B, Exchange A must tell Exchange B your name, account identifier and, depending on jurisdiction, your address, date and place of birth or a national ID number. It must also pass the beneficiary's name and account identifier. Exchange B must check that the information arrived, that it is complete, and that neither party appears on a sanctions list before releasing the funds.

Where it comes from: FATF Recommendation 16

The Travel Rule for traditional wire transfers is set out in Recommendation 16 of the Financial Action Task Force (FATF) standards. In June 2019 FATF extended those standards to virtual assets through its interpretive note to Recommendation 15, making the Travel Rule apply to VASPs on the same logic as banks.

FATF sets the standard; it does not make law. Each of the 200-plus jurisdictions in the FATF global network transposes it into domestic legislation, which is exactly why thresholds and data requirements diverge. The FATF baseline is a de minimis threshold of USD/EUR 1,000, below which a reduced data set may be permitted. Many jurisdictions have gone stricter.

What data must travel

The required data set is standardised in practice by IVMS101, an interchange format designed so that sending and receiving VASPs can parse the same fields regardless of which vendor they use. A typical full data set looks like this.

PartyRequired fields
Originator (sender)Name, account identifier or wallet address, and one of: physical address, national identity number, customer identification number, or date and place of birth
Beneficiary (recipient)Name and account identifier or wallet address
InstitutionsIdentifying details of the originating and beneficiary VASPs

Verification obligations sit with the sending institution. It must have verified the originator's identity through its own KYC process before the transfer, not reconstruct it afterwards. That is why Travel Rule readiness always depends on the quality of the onboarding stack underneath it.

Thresholds: why there is no single answer

The most common source of confusion is the threshold. There is no global number.

RegimeThresholdNotes
FATF standardUSD/EUR 1,000Below it, a reduced data set may be allowed without verification
European UnionZeroRegulation (EU) 2023/1113 applies the rule to all crypto transfers by CASPs regardless of value, in force from 30 December 2024
United StatesUSD 3,000The long-standing FinCEN funds travel rule threshold; a lower USD 250 threshold for cross-border transfers has been proposed but not finalised

The EU's zero threshold is the reason the phrase zero threshold Travel Rule keeps appearing in compliance discussions. For a crypto-asset service provider serving European customers, there is no small-transfer carve-out at all: a 12 EUR transfer carries the same data obligation as a 12,000 EUR one.

The sunrise problem

Because jurisdictions adopted the rule at different times, a compliant VASP frequently transacts with a counterparty in a country where the rule is not yet enforced, or is enforced differently. This is known as the sunrise problem: one side has an obligation to send data, the other has no obligation, and often no technical means, to receive it.

There is no elegant fix. Firms handle it with counterparty due diligence, risk-based policies that define which jurisdictions they will transact with, and fallback procedures that document the attempt to transmit data when the receiving side cannot accept it.

Self-hosted wallets and unhosted transfers

Transfers to and from self-hosted wallets are the second hard case. There is no institution on the other side to receive data. Under the EU regime, CASPs must collect the required originator and beneficiary information for transfers involving self-hosted wallets, and for transfers above 1,000 EUR must take steps to verify that the customer controls the self-hosted wallet. Verification is typically done through a signed message, a micro-transfer, or a witnessed signing session in the customer's own wallet.

What a working compliance stack looks like

Travel Rule compliance is rarely a single product. In practice it is four layers working together.

  • Identity and onboarding. Verified customer records are the raw material for the originator data set. Weak KYC produces unverifiable Travel Rule messages. Providers such as iDenfy handle identity verification and the ongoing customer data layer that the rule depends on.
  • Blockchain analytics and screening. Before releasing funds, the receiving institution needs to know whether the counterparty address is associated with sanctioned entities, mixers or illicit flows. Crystal Intelligence provides the address-level risk scoring and sanctions screening that sit alongside the message exchange.
  • Message transport. The protocol layer that actually moves the IVMS101 payload between counterparties, with counterparty discovery and secure delivery.
  • Case management and recordkeeping. Incomplete or missing data has to generate an alert, a decision, and an audit trail retained for the statutory period.

Does the Travel Rule apply to DeFi?

This is where the answer needs care. The Travel Rule binds VASPs, defined as persons who conduct virtual asset activities as a business on behalf of another person. Software that executes autonomously, where no party takes custody of user funds or controls the transfer, does not fit that definition cleanly.

FATF's guidance is nonetheless explicit that the label matters less than the facts: where a person maintains control or sufficient influence over a DeFi arrangement, including through ongoing commercial relationships or fee extraction, that person may be a VASP even if the protocol is described as decentralised.

JewelSwap is a non-custodial protocol. Users interact with smart contracts on MultiversX, Sui and Radix directly from their own wallets, and the protocol never takes custody of user assets. Deposits, liquid staking mints, yield farm positions and loans are all executed by contracts the user signs into. That architecture places JewelSwap outside the custodial intermediary model the Travel Rule was written to regulate, which is a design property, not a compliance strategy. The moment fiat on-ramps, custody or brokerage sit in the flow, the analysis changes.

Frequently asked questions

What is the Travel Rule in simple terms?

It is a rule requiring the sender's financial institution to pass identifying information about the sender and recipient to the receiving institution whenever funds are transferred. In crypto it applies to transfers between virtual asset service providers, so identity data moves alongside the on-chain transaction.

What is the Travel Rule threshold for crypto?

It depends on jurisdiction. The FATF standard sets a USD/EUR 1,000 de minimis threshold. The European Union applies a zero threshold to all crypto transfers by CASPs under Regulation (EU) 2023/1113. The United States uses the USD 3,000 funds travel rule threshold.

What is IVMS101?

IVMS101 is the interVASP messaging standard, a common data format for originator and beneficiary information. It exists so that two institutions using different Travel Rule vendors can exchange and parse the same payload without bespoke integration work.

What is the sunrise problem?

The sunrise problem is the gap created when one jurisdiction enforces the Travel Rule and its counterparties do not. A compliant institution must send data that the receiving side has no legal obligation or technical ability to accept, so firms rely on documented fallback procedures.

Does the Travel Rule apply to self-hosted wallets?

Partly. There is no counterparty institution to receive data, but under the EU regime a CASP must still collect the required information and, for transfers above 1,000 EUR, take steps to verify that its customer controls the self-hosted wallet.

Does the Travel Rule apply to non-custodial DeFi protocols?

Generally not, because the rule binds intermediaries that transfer virtual assets on behalf of others. FATF guidance warns that persons with control or sufficient influence over a DeFi arrangement may still qualify as VASPs, so the analysis turns on facts rather than labels.

Keep reading

About the author.

Co-Founder at JewelSwap & CMO at iDenfy. Viktor brings his successful track record of superb development & project management.