Crypto Travel Rule: VASP Compliance Requirements Explained

The crypto Travel Rule is the application of FATF Recommendation 16 to virtual-asset transfers. It requires the originating virtual asset service provider (VASP) to collect, hold and transmit specified originator and beneficiary information to the beneficiary VASP, and to make that data available to authorities. FATF extended R.16 to virtual assets in 2019.

For any crypto business that moves customer funds, the Travel Rule is now one of the defining compliance obligations. It binds VASPs, EU crypto-asset service providers (CASPs) and US money services businesses that handle crypto, and it sits at the centre of every credible AML/CFT programme. This guide explains what the rule is, who must comply, the exact data elements that must travel, the thresholds in each regime, and how the FATF, EU and US versions differ in practice.

*By Magnus Müller. Reviewed by Magnus Müller, founder and crypto-licensing expert, Crypto Valley Partners AG, Zug. Last updated: 2026-06-14.*

What is the crypto Travel Rule?

The crypto Travel Rule is FATF Recommendation 16 applied to virtual-asset (VA) transfers. The originating VASP must obtain and hold required originator and beneficiary information, transmit it to the beneficiary VASP, and make it available to authorities on request. FATF extended R.16, originally a wire-transfer rule, to VAs and VASPs in 2019.

In plain terms, the identifying data attached to a payment must "travel" alongside the value itself. When a customer sends crypto from one regulated provider to another, the sending provider has to pass on who is sending it and who is receiving it, in a structured, machine-readable form. The rule mirrors the long-standing obligation that applies to bank wire transfers, transposed onto blockchain-based transfers that would otherwise carry no identifying information beyond a wallet address.

The origin of the rule: FATF Recommendation 16

Recommendation 16 began life as the FATF standard for wire transfers, requiring originator and beneficiary information to accompany funds moving through the traditional banking system. In 2019, FATF amended its standards to bring virtual assets and VASPs within scope, so that the same originator and beneficiary information must accompany VA transfers. This extension is why the obligation is universally referred to as the "crypto Travel Rule", even though the underlying recommendation predates crypto by many years. The authority sits with FATF as the global AML/CFT standard-setter, but the recommendation itself is not directly binding. It becomes enforceable only when a jurisdiction transposes it into national law, which is exactly what the EU and the US have done in different ways. R.16 is one element of a wider AML framework, set out in more detail in our FATF crypto guidelines overview.

Why the Travel Rule matters for crypto businesses

The Travel Rule closes a gap that blockchain technology created. A wallet address alone tells a regulator nothing about who controls the funds, so without the rule, crypto transfers would be an effective blind spot for money-laundering and terrorist-financing controls. By forcing identifying data to accompany each transfer between providers, the rule restores the traceability that the AML/CFT regime depends on. For a crypto business, that means the Travel Rule is not an optional add-on: it is a precondition for operating as a licensed provider and for maintaining banking and counterparty relationships. Supervisors expect a documented Travel Rule solution as part of any licensing or registration assessment, which is where compliance obligations and licensing requirements meet.

Who must comply with the crypto Travel Rule?

VASPs and CASPs, plus financial institutions and money services businesses that handle crypto, must comply with the Travel Rule. The terminology differs by regime: FATF uses "VASP", the EU uses "CASP", and the US covers crypto money services businesses and money transmitters. The common thread is any regulated intermediary that conducts virtual-asset transfers on behalf of customers.

The obligation attaches to the entity, not the individual user. A retail customer sending crypto does not personally carry Travel Rule duties; the provider executing the transfer does. Understanding precisely which entities fall within scope is the first step in any compliance assessment, and it depends on how the regulated subject is defined in each regime.

VASPs, CASPs and crypto MSBs

The three main regimes use different labels for the same broad category of regulated business. FATF speaks of "virtual asset service providers" and defines them by the activities they perform, such as exchange, transfer, safekeeping and administration of virtual assets. The EU, under MiCA and the Transfer of Funds Regulation, uses "crypto-asset service providers" (CASPs). The US frames the obligation around money transmitters and money services businesses, including those dealing in convertible virtual currency, under the Bank Secrecy Act. For a fuller treatment of the FATF definition and which activities trigger it, see our explainer on what is a VASP.

Where licensing fits in

The Travel Rule is a compliance obligation, not a licence in itself, but it is inseparable from the licensing process. To operate as a VASP or CASP you first need the relevant authorisation or registration, and supervisors will examine your Travel Rule capability as part of that assessment. Operators who are at the point of building or buying a compliant programme should start with the broader picture of VASP licensing and then work through the detailed VASP licence requirements, of which the Travel Rule is one core component.

What information must travel with a crypto transfer?

A crypto transfer must carry originator and beneficiary identifying data. At minimum that means the name of each party and the account number or VA wallet (DLT) address used for the transfer, or a unique transaction reference where no account exists. Depending on the regime, additional originator identifiers such as a physical address, an ID number, or date and place of birth are also required. The data is typically transmitted using the IVMS101 standard.

The precise field set differs between FATF, the EU and the US, but the structure is consistent: identify both ends of the transfer in a way that authorities can later trace. The following sub-sections set out the FATF baseline; the EU-specific fields under Article 14 are covered in the dedicated EU section below.

Originator data elements (FATF R.16)

Under FATF R.16 and its Interpretive Note, the originator information that must travel with a VA transfer at or above the threshold is: the originator's name; the account number or VA wallet (DLT) address used for the transfer, or a unique transaction reference where no account exists; and the originator's physical (geographical) address, OR national identity number, OR customer identification number, OR date and place of birth. The "OR" choice between address, ID number and date and place of birth is a feature of the FATF standard. (VERIFY: FATF.org returned HTTP 403 to automated fetch; the exact wording and paragraph numbers should be confirmed against the live FATF PDF before publication.)

Beneficiary data elements (FATF R.16)

The beneficiary information required under FATF R.16 is narrower than the originator set. The beneficiary VASP must receive the beneficiary's name and the account number or VA wallet (DLT) address used to process the transaction, or a unique transaction reference where no account exists. The asymmetry reflects the fact that the originating institution holds more information about its own customer than about the recipient. (VERIFY: confirm against the live FATF text per the 403 caveat above.)

IVMS101: the interVASP messaging standard

IVMS101, the interVASP Messaging Standard, is the data format the industry uses to package and transmit Travel Rule information from one VASP to another. It standardises how names, addresses, account references and identifiers are structured, so that providers using different Travel Rule solutions can still exchange data that each side can read and validate. IVMS101 is an industry standard, not a FATF instrument: FATF sets the obligation to transmit the data, while IVMS101 provides the common language for doing so. Adopting an IVMS101-compatible messaging solution is, in practice, the way most VASPs operationalise counterparty data exchange.

What is the crypto Travel Rule threshold?

Thresholds differ by regime. FATF sets a de-minimis floor of USD/EUR 1,000. The EU has no de-minimis for crypto: the obligations apply to all amounts under Regulation (EU) 2023/1113. The US applies a USD 3,000 transmittal threshold under 31 CFR 1010.410(f). The threshold determines when the full data-collection and verification obligations are triggered.

FATF de-minimis threshold (USD/EUR 1,000)

FATF sets a de-minimis threshold of USD/EUR 1,000 for VA transfers. Below this floor, a reduced data set may apply (typically names and account or wallet references, without mandatory verification unless suspicion arises). At or above the floor, full collection and verification of the required originator and beneficiary elements apply. FATF is the baseline that both the EU and the US implement, but each has moved away from the USD/EUR 1,000 figure in its own direction. (VERIFY: the USD/EUR 1,000 figure should be confirmed against the live FATF PDF per the 403 caveat; do not state any other figure.)

EU: no de-minimis for crypto transfers

The EU is the strictest of the three regimes. Recital 27 of Regulation (EU) 2023/1113 confirms there is no exemption for low-value crypto-asset transfers, so the Travel Rule obligations apply regardless of amount. Unlike a bank wire transfer, where a low-value threshold may reduce the data burden, a crypto-asset transfer between EU CASPs carries the full obligation from the first euro. This makes EU compliance the most demanding to operationalise, because there is no transaction below which a provider can switch the rule off.

US: the USD 3,000 transmittal threshold

The US Travel Rule applies to transmittals of funds equal to or greater than USD 3,000 (or the foreign equivalent), regardless of whether currency is involved. It sits in the Bank Secrecy Act recordkeeping rules at 31 CFR 1010.410(f), with FinCEN guidance in FIN-2010-G004. A 2020 FinCEN and Federal Reserve proposal to lower the crypto cross-border threshold to USD 250 has not been finalised and should not be treated as in force. (VERIFY: status of the USD 250 proposal not confirmed final as of 2026-06-13.)

[Infographic 1 placement: Travel Rule threshold comparison bars, see Infographics section below.]

How do FATF, EU and US Travel Rule requirements differ?

The three regimes differ by legal nature, threshold, application date and the entities they bind. FATF is a non-binding global standard set at USD/EUR 1,000; the EU is a directly applicable regulation with no de-minimis for crypto; and the US is a binding Bank Secrecy Act rule set at USD 3,000. The comparison table below sets out the key dimensions side by side.

Comparison table: FATF vs EU TFR vs US FinCEN

The practical takeaway: the EU is strictest with a zero threshold for crypto, the US uses a higher monetary floor and an older recordkeeping frame, and FATF is the baseline that both implement at USD/EUR 1,000. A provider operating across all three must build to the strictest applicable standard for each transfer.

How does the EU Travel Rule (Regulation 2023/1113) work?

The EU implements the Travel Rule through the recast Transfer of Funds Regulation, Regulation (EU) 2023/1113, which applies the rule to crypto-asset transfers across the EU. It applies from 30 December 2024, aligned with the date of application of MiCA, and it repeals the previous Regulation (EU) 2015/847. The TFR closed the single biggest gap in older crypto compliance content by setting concrete, directly applicable obligations for EU CASPs.

When the EU TFR took effect (30 December 2024)

Regulation (EU) 2023/1113 applies from 30 December 2024. That date was chosen deliberately to align with the date of application of MiCA (Regulation (EU) 2023/1114), so that the EU's substantive crypto authorisation regime and its Travel Rule obligations came into force together. For a CASP authorised under MiCA, the TFR is therefore not a separate timeline to track but part of the same go-live moment. The alignment with the EU's MiCA regime means EU operators should treat licensing and Travel Rule readiness as a single project.

EU originator and beneficiary data (Art. 14(1)/(2))

Article 14(1) of the TFR sets the originator information that must accompany a crypto-asset transfer: the name of the originator; the originator's DLT address (where the transfer is registered on a network using DLT or similar technology) or crypto-asset account number; the originator's address (including country name), official personal document number and customer identification number, OR alternatively the date and place of birth; and, where it exists, the LEI or equivalent official identifier. Article 14(2) sets the beneficiary information: the name of the beneficiary; the beneficiary's DLT address or crypto-asset account number; and, where it exists, the LEI or equivalent identifier. The EU field set is more prescriptive than the FATF baseline, particularly on the originator side.

Self-hosted wallet rules under the EU TFR

The TFR addresses transfers involving self-hosted (unhosted) wallets directly. For a transfer above EUR 1,000 involving a self-hosted address, the CASP must apply enhanced verification and confirm that its customer is the owner or controller of the self-hosted wallet. Below that EUR 1,000 figure the obligation is lighter, but the CASP must still apply its risk-based controls. This is one of the more operationally demanding parts of the EU regime, because verifying ownership of an address that no other regulated entity controls requires additional technical and procedural measures.

How does the US Travel Rule (FinCEN, 31 CFR 1010.410) work?

The US Travel Rule predates crypto and lives in the Bank Secrecy Act recordkeeping rules at 31 CFR 1010.410(f) and 31 CFR 1010.410(e), with FinCEN guidance in FIN-2010-G004. It applies to transmittals of funds at or above USD 3,000 and binds money transmitters and financial institutions, including crypto money services businesses. Because the rule is older than the asset class, US crypto businesses comply with a framework originally written for traditional value transfer.

Required transmittal-order information (31 CFR 1010.410(f))

Under 31 CFR 1010.410(f), the transmittor's financial institution must include in the transmittal order: the name of the transmittor; the account number of the transmittor (if the payment is ordered from an account); the address of the transmittor; the amount of the transmittal order; the execution date of the transmittal order; and the identity of the recipient's financial institution. It must also include, as many as are received with the order, the name and address of the recipient, the account number of the recipient and any other specific identifier of the recipient. Intermediary institutions must pass on all listed information received, but have no general duty to retrieve information that was not provided.

The proposed USD 250 cross-border threshold

In 2020, FinCEN and the Federal Reserve issued a notice of proposed rulemaking to lower the threshold to USD 250 for cross-border transmittals, including crypto. As of the research date this proposal had not been finalised, so the binding US threshold remains USD 3,000. Providers should monitor the proposal but must not build to or describe a USD 250 figure as if it were in force. (VERIFY: status of the USD 250 NPRM not confirmed final as of 2026-06-13; do not present as binding.)

What is the sunrise problem in Travel Rule compliance?

The sunrise problem describes the friction created when jurisdictions adopt and enforce the Travel Rule at different times. A VASP in a jurisdiction where the rule is in force may need to send Travel Rule data to a counterparty VASP in a jurisdiction where the rule is not yet required or not enforced. The result is one-sided compliance gaps and interoperability friction until global adoption catches up.

[Infographic 2 placement: the sunrise problem map, see Infographics section below.]

How the sunrise problem affects VASP-to-VASP transfers

In practice, the sunrise problem means a compliant sending VASP cannot always rely on the receiving side to accept, validate or reciprocate Travel Rule data. The sender still carries its own obligation to collect and attempt to transmit the required information, even if the counterparty cannot yet receive it in a standardised form. This forces sending providers to build fallback procedures: documenting the attempt, applying counterparty due diligence and, where the counterparty's regime is materially weaker, treating the transfer as higher risk.

From our practice: the most common operational friction we see is not the data collection itself but counterparty onboarding. When a counterparty VASP sits in a jurisdiction that has not yet enforced the rule, the sending provider has to make a judgement call with incomplete reciprocity, and that judgement is exactly what supervisors scrutinise. Building a defensible, documented counterparty assessment process matters more than any single piece of technology.

How do VASPs comply with the Travel Rule step by step?

Travel Rule compliance follows a repeatable workflow. The nine steps below move from scoping the obligation through to ongoing regulatory monitoring, and they apply across regimes even though the specific thresholds and data fields differ. Use them as a framework, not legal advice, and confirm each step against your applicable jurisdiction(s).

The nine-step VASP Travel Rule compliance workflow

1. Scope determination. Confirm whether the entity is a VASP or CASP and which jurisdiction(s) apply, mapping the FATF baseline against local implementation such as the EU TFR or US BSA.
2. Threshold mapping and aggregation. Set transaction logic per jurisdiction: USD/EUR 1,000 for FATF, zero for EU crypto, USD 3,000 for the US, and build aggregation logic for linked transactions. (VERIFY: aggregation mechanics differ by regime; confirm against primary text per jurisdiction.)
3. Data collection and verification. Capture and verify the required originator and beneficiary elements at onboarding and per transfer.
4. Counterparty exchange via IVMS101. Implement a Travel Rule messaging solution using IVMS101 to transmit data to the beneficiary VASP before or with the transfer.
5. Counterparty VASP due diligence. Assess the receiving VASP's legitimacy and regime, mitigating the sunrise problem described above.
6. Self-hosted wallet handling. Apply enhanced checks for unhosted-wallet transfers per local rules, for example the EU EUR 1,000 ownership-verification requirement.
7. Recordkeeping. Retain the required records: the FATF standard is five years, but confirm the exact local period. (VERIFY: confirm retention period per target jurisdiction.)
8. Monitoring and reporting. Integrate Travel Rule data with transaction monitoring and file SARs or STRs as required. For the wider control set, see our compliance guide.
9. Ongoing review. Track regulatory updates, including the June 2025 FATF R.16 revision and the pending US USD 250 proposal.

Have questions about your specific situation? Book a free 15-minute discovery call with our licensed advisers, no commitment. Book a Call

What is changing in the Travel Rule (2025 onward)?

The Travel Rule is not static. The most significant forthcoming change is the June 2025 FATF revision of Recommendation 16, alongside the still-pending US proposal to lower the crypto cross-border threshold. Both are signposts for what providers should monitor, but neither should be treated as a current binding requirement.

The June 2025 FATF R.16 revision (monitor, not yet in force)

FATF revised Recommendation 16 on 18 June 2025, expanding its objectives to cover fraud and proliferation financing, with a longer compliance runway reportedly cited toward around 2030. The exact impact on virtual-asset data elements and thresholds has not been confirmed from the primary FATF text, so this should be treated as a forthcoming development to monitor rather than a new set of requirements in force. Providers should plan to revisit their Travel Rule programme as national supervisors transpose the revised standard, and should watch the wider crypto regulation news landscape for transposition timelines. (VERIFY: exact impact of the June 2025 R.16 revision not confirmed from primary text; do not state new requirements as in force.)