The Travel Rule: what has to travel with a payment

The Travel Rule is the requirement that information about who is paying whom travels with the payment itself. Set by FATF Recommendation 16 and enforced through national law, it obliges the sending institution to transmit originator and beneficiary details with cross-border transfers above roughly 1,000 dollars or euros, and the receiving institution to check what arrives. Banks have lived with it on wires for decades. Since FATF extended it to virtual assets in 2019, it has become the single most demanding compliance requirement on stablecoin rails, and in June 2025 FATF rewrote the rule itself.

What has to travel

For a bank wire, the payment message carries the originator’s name, account number, and address or equivalent identifier, plus the beneficiary’s name and account number. The MT103 and its ISO 20022 successor were built with fields for exactly this.

For a transfer between virtual asset service providers, the same logic applies with different plumbing. The originator VASP must transmit the originator’s name, wallet or account identifier, and a further identifier (address, national ID number, or date and place of birth), plus the beneficiary’s name and wallet identifier. The catch: public settlement rails carry value, not identity. The data cannot ride in the on-chain transaction, so it moves through separate VASP-to-VASP messaging protocols, most structured to the IVMS 101 standard, that must be matched to the transfer they describe.

That split, value on one rail and identity on another, is where most Travel Rule failure lives: transfers whose data arrives late, malformed, or not at all, and value that has already reached the beneficiary by the time anyone notices.

Where adoption actually stands

FATF’s June 2025 targeted update counted 85 of 117 surveyed jurisdictions with Travel Rule legislation passed, 73%, up from 65 jurisdictions in 2024. Passing legislation is not enforcing it; FATF’s own update and its accompanying best-practices paper press supervisors on enforcement, and note that most illicit on-chain activity now involves stablecoins.

The gap between adopters and non-adopters creates the sunrise problem: a compliant institution facing a counterparty with no legal duty to send the data. Its options are unattractive: reject the transfer, accept it and document enhanced diligence, or route around the counterparty. Every serious compliance program on stablecoin rails now needs a written sunrise policy, because the network will stay partial for years.

The 2025 rewrite of Recommendation 16

At its June 2025 plenary, FATF adopted the largest revision of Recommendation 16 since it was written, reframing it around payment transparency:

• Scope: all payments and value transfers, not just wire transfers.
• Structure: accompanying data should follow established standards, explicitly ISO 20022, to the extent possible.
• Beneficiary data: for cross-border transfers above USD/EUR 1,000, beneficiary name, account number or unique reference, country and town; legal entities identified by a business identifier such as an LEI; for natural persons, year of birth suffices where the full date is unavailable.
• Beneficiary institution duties: receiving institutions must actually use the information, through name and account checks, monitoring, or prevalidation reconciliation, rather than merely store it.

Jurisdictions have until the end of 2030 to implement, and FATF plans implementation guidance in late 2026. The direction is unmistakable: the data is becoming a first-class part of the payment, in a structured standard, checked at both ends.

What it means operationally

Three consequences for institutions settling across borders, on bank rails or stablecoin rails.

First, data quality becomes settlement-critical. A transfer with incomplete originator data is a compliance event even when the funds arrive; at scale, repair queues and returned payments become a measurable cost, one reason payments fail at the rate they do.

Second, counterparty status is now routing input. Whether the beneficiary institution is in a Travel Rule jurisdiction, and whether it can receive the data in a compatible protocol, determines whether a corridor is usable at all.

Third, and most structurally: on today’s rails the check and the transfer are separate systems. Screening happens before, investigation after, and the settlement itself will move value regardless of whether the data requirement was met. The whole apparatus works by remediation. The 2025 revision pushes the other way, toward verifying conditions as part of the payment, and infrastructure is starting to follow.

Where Frame fits

Frame is the settlement layer for global finance: one integration to orchestrate payments at scale across fiat rails, stablecoins, and tokenized deposits, with compliance enforced on every transaction and settlement in seconds instead of days.

The Travel Rule is a clean example of a condition that belongs inside settlement rather than around it. On Frame, the policies governing a payment are evaluated by the Rules Engine on every transaction before it settles: a transfer that cannot satisfy its governing policies, including the data and counterparty conditions a rule like this imposes, does not settle, and every settled transaction produces verifiable evidence that its conditions were met without exposing the underlying business data. For banks, payment providers, exchanges, platforms, and enterprises, that inverts the remediation model this page describes: instead of moving value and chasing the data, the data requirement is enforced at the moment of settlement itself.

See how a rail-neutral settlement layer works: the Frame Blueprint.