← Back to guides

Travel Rule Implementation

2026-04-18 · Web3 Compliance AI

What Is the Travel Rule?

FATF Recommendation 16 — commonly called the Travel Rule — requires Virtual Asset Service Providers to exchange originator and beneficiary information when transferring virtual assets. Originally designed for wire transfers in traditional finance, it was extended to crypto in June 2019 as part of the FATF's updated Guidance for a Risk-Based Approach to Virtual Assets and VASPs.

The Travel Rule is now law or regulation in over 50 jurisdictions. Non-compliance carries significant penalties — FinCEN has fined VASPs millions for Travel Rule failures, and EU enforcement under the Transfer of Funds Regulation (Regulation EU 2023/1113) began December 30, 2024.

What Information Must Be Shared

The FATF standard requires transmission of specific data fields for both the originator and beneficiary of a transfer.

Originator information (sender's VASP must collect and transmit):

Field Required Notes
Full name Always Legal name, not username or alias
Account number / wallet address Always The address used for the transfer
Physical address One of these four At least one additional identifier is required
National identity number One of these four Government-issued ID number
Customer identification number One of these four Internal VASP customer reference
Date and place of birth One of these four Both date and place required together

Beneficiary information (receiver's VASP must verify):

Field Required Notes
Full name Always Must be verified against KYC records
Account number / wallet address Always Destination address

Some jurisdictions require additional fields. The EU's Transfer of Funds Regulation requires the originator's address, official document number, customer identification number, or date and place of birth — and for the beneficiary, a broader dataset than the FATF minimum. Singapore's PSN02 notice requires originator and beneficiary identification consistent with MAS AML/CFT standards. Always check local implementation requirements.

Threshold Comparison by Jurisdiction

The FATF recommends applying the Travel Rule to transfers of USD/EUR 1,000 or more. However, jurisdictions have diverged significantly:

Jurisdiction Threshold Legislation Effective Date Notes
United States $3,000 BSA / FinCEN Funds Travel Rule 1996 (applied to CVC 2019) Applies to convertible virtual currency (CVC) transfers
EU EUR 0 (no threshold) Transfer of Funds Regulation (EU 2023/1113) December 30, 2024 Applies to ALL crypto-asset transfers, exceeding FATF standard
United Kingdom GBP 0 (no threshold) Money Laundering Regulations 2017 (amended) September 2023 All crypto transfers require originator/beneficiary data
Singapore SGD 1,500 PSN02 AML/CFT Notice Effective under PSA 2019 Applies to DPT transfers
Switzerland CHF 1,000 FINMA AMLO Aligned with FATF standard FINMA guidance for VASPs
UAE AED 3,500 (~$950) CBUAE regulations Active VARA-licensed entities must comply
Canada CAD 1,000 PCMLTFA regulations Active FINTRAC guidance for MSBs
Japan JPY 0 (no threshold) Act on Prevention of Transfer of Criminal Proceeds April 2023 All crypto transfers
Hong Kong HKD 8,000 AMLO (Part 5B) June 2023 SFC-licensed VATPs

Operational rule: When operating across multiple jurisdictions, apply the strictest applicable threshold. If you serve EU customers, you must transmit Travel Rule data on every transfer regardless of amount.

Technical Implementation Options

Protocol-Based Solutions

TRISA (Travel Rule Information Sharing Architecture)

  • Open-source, decentralized protocol using mTLS certificates for VASP identity verification
  • Operated by the TRISA Directory Service (Global Directory Service)
  • VASPs register in the directory and exchange information via encrypted peer-to-peer messaging
  • Pros: Open standard, no vendor lock-in, strong identity verification
  • Cons: Requires each VASP to run infrastructure, smaller network than commercial solutions
  • Website: trisa.io

OpenVASP

  • Open protocol using decentralized identifiers (DIDs) and encrypted messaging
  • Session-based messaging protocol for VASP-to-VASP communication
  • Pros: Decentralized architecture, no central authority, privacy-preserving
  • Cons: Smaller adoption than commercial solutions
  • Website: openvasp.org

TRP (Travel Rule Protocol)

  • Developed by a consortium including Notabene and other industry participants
  • API-based approach with broad industry adoption
  • Uses a messaging layer that is interoperable with other protocols
  • Pros: Wide adoption, well-documented API, interoperable
  • Cons: Consortium-governed, less decentralized than TRISA/OpenVASP

Commercial Providers

Provider Approach Network Size Key Features
Notabene API-based (TRP) 200+ VASPs Counterparty discovery, risk-based workflows, regulatory reporting
Chainalysis (Comply) Integrated with KYT Large analytics network Combined analytics + Travel Rule, pre-transaction screening
Sygna Bridge (CoolBitX) Bridge protocol Strong in APAC Focused on Asia-Pacific jurisdictions, cross-protocol
Sumsub Integrated KYC + Travel Rule Growing Combined identity verification and Travel Rule

Evaluation criteria when selecting a provider:

  1. Network coverage — How many counterparty VASPs are connected? Can you reach your most frequent counterparties?
  2. Jurisdictional support — Does the provider handle the specific requirements of each jurisdiction where you operate?
  3. Protocol interoperability — Can the provider communicate with VASPs on different protocols?
  4. Integration complexity — API quality, documentation, SDK availability, time-to-integration
  5. Counterparty verification — How does the provider verify that counterparty VASPs are legitimate and licensed?
  6. Cost — Per-transaction fees, monthly minimums, and total cost at your transaction volume

Implementation Steps

Step 1: Map Your Obligations

Identify which jurisdictions' Travel Rule requirements apply to your operations. For each jurisdiction:

  • Determine the applicable threshold
  • Identify required data fields (beyond FATF minimums)
  • Understand unhosted wallet requirements
  • Note any specific technology or reporting mandates

Step 2: Choose a Solution

Select a protocol or vendor based on network coverage and your counterparty landscape. Network effect matters most — choose a solution where your most common counterparties are already connected. Request a counterparty coverage report from each vendor before committing.

If you operate at scale across multiple regions, you may need to support multiple protocols or use an interoperability layer.

Step 3: Collect Required Data

Build Travel Rule data collection into your existing KYC and transaction workflows:

  • At onboarding: Collect all FATF-required originator fields during KYC. Do not collect this data retroactively at withdrawal time — it delays transactions and frustrates customers.
  • At withdrawal: Collect beneficiary name and destination address. For jurisdictions requiring additional beneficiary data, collect it here.
  • Validate data quality: Travel Rule exchanges fail when data is incomplete or formatted incorrectly. Implement validation before attempting the exchange.

Step 4: Integrate into Transaction Flow

The Travel Rule exchange must be embedded in your withdrawal/transfer workflow:

  1. Customer initiates a withdrawal/transfer
  2. System checks if the transfer exceeds the applicable threshold for all relevant jurisdictions
  3. If yes, system identifies the beneficiary VASP (via blockchain analytics or directory lookup)
  4. System transmits originator data to the beneficiary VASP
  5. Beneficiary VASP validates the data and screens the originator
  6. Beneficiary VASP accepts or rejects the transfer
  7. Transaction proceeds (or is blocked if rejected)
  8. All exchange data is logged for record-keeping

For incoming transfers (deposits):

  1. Funds arrive on-chain
  2. System identifies the originator VASP
  3. System requests originator data from the sending VASP (or receives it automatically)
  4. System validates the data against the customer's KYC records
  5. If data is missing or inconsistent, flag for investigation
  6. Transaction is credited (or frozen if Travel Rule data cannot be obtained)

Step 5: Counterparty VASP Verification

You must verify that the receiving VASP is legitimate before sharing customer data. Methods include:

  • Directory services — TRISA Global Directory, OpenVASP registry
  • Regulatory registries — Check the counterparty against the FCA register, MAS license list, VARA registry, etc.
  • Provider verification — Commercial Travel Rule providers typically verify their network participants
  • Direct due diligence — For large or high-risk counterparties, conduct your own assessment

Step 6: Handle Unhosted Wallets

Transfers to/from self-custodied (unhosted) wallets present a special challenge — there is no counterparty VASP to exchange data with.

EU approach (Transfer of Funds Regulation):

  • Transfers over EUR 1,000 to/from unhosted wallets require the VASP to verify that the unhosted wallet belongs to its customer (proof of ownership)
  • Methods: signed message, micro-transaction, or Satoshi test

US approach:

  • FinCEN's proposed rule (2020, not finalized) would require additional recordkeeping for transfers over $3,000 involving unhosted wallets
  • Current practice: apply risk-based monitoring to unhosted wallet transfers

Singapore approach:

  • MAS requires enhanced monitoring for transfers involving non-DPT service providers
  • Risk-based approach to unhosted wallet transfers

Step 7: Record-Keeping

Store all Travel Rule data exchanges for at least five years. Your records must include:

  • Transaction details (amount, date, addresses)
  • All originator and beneficiary data transmitted/received
  • Counterparty VASP identification and verification records
  • Success/failure status of each exchange
  • Investigation records for failed exchanges
  • Timestamps for all events in the exchange lifecycle

Sunrise Issue

Not all jurisdictions have implemented the Travel Rule at the same pace. You will encounter counterparty VASPs in jurisdictions without Travel Rule requirements, or VASPs that have not yet implemented technical solutions.

Recommended approach:

  1. Always attempt the information exchange, regardless of the counterparty's jurisdiction
  2. Document all attempts and failures
  3. Apply enhanced monitoring to transfers where Travel Rule data cannot be obtained
  4. Set risk-based thresholds — you may choose to block transfers above a certain amount if Travel Rule data cannot be exchanged
  5. Maintain a counterparty VASP risk register tracking which VASPs can and cannot exchange Travel Rule data
  6. Review the register periodically as adoption improves

Common Pitfalls

  1. Waiting for perfect coverage — Do not delay implementation because not all counterparties support it. Start now and handle gaps with enhanced monitoring.
  2. Collecting data at withdrawal instead of onboarding — This creates friction at the worst moment. Collect originator data during KYC.
  3. Ignoring the no-threshold jurisdictions — If you serve EU, UK, or Japanese customers, every transfer requires Travel Rule data. No exceptions.
  4. Failing to verify counterparty VASPs — Sharing customer PII with an unverified entity is a data protection violation (GDPR and others) and a compliance failure.
  5. No fallback process — When the automated exchange fails, you need a manual process. Define it in advance.
  6. Incomplete record-keeping — Regulators will request Travel Rule exchange records during examinations. Store everything.

Resources