EU Crypto Travel Rule: Implementation Guide for CASPs

What is the Travel Rule?

The "Travel Rule" is the requirement that crypto-asset service providers (CASPs) must collect and transmit originator and beneficiary information alongside every crypto transfer. The concept originates from FATF Recommendation 16, which has applied to traditional wire transfers for decades. The EU extended it to crypto through Regulation (EU) 2023/1113 -- the recast Transfer of Funds Regulation (TFR).

The regulation entered into force on 9 June 2023 and applies from 30 December 2024. The European Banking Authority published accompanying guidelines (EBA/GL/2024/11) on 4 July 2024, also applicable from the same date. A transitional period for CASPs ran until 31 July 2025 to allow systems adjustment. That window is closed. Full compliance is now required.

Verified 17 August 2026: Regulation (EU) 2023/1113 and EBA/GL/2024/11 remain the operative EU Travel Rule sources; no EU de minimis threshold applies to CASP-to-CASP crypto transfers.

Self-hosted wallet transfers: the EUR 1,000 threshold

There is one area where a threshold applies. When a CASP processes a transfer to or from a self-hosted address (i.e., a non-custodial wallet not controlled by any CASP):

• All amounts: The CASP must collect and retain originator or beneficiary information from their own customer.
• Above EUR 1,000: The CASP must additionally verify that the self-hosted address is owned or controlled by the customer, using at least one reliable and independent method (e.g., Satoshi test, signed message, on-chain proof).

This means self-hosted wallet transfers are not exempt -- they trigger a different set of obligations. For CASP-to-CASP transfers, there is no threshold at all.

What information must be exchanged under the Travel Rule?

The TFR specifies the data fields that must accompany each transfer. In practice, the industry has standardized on IVMS 101 (InterVASP Messaging Standard) as the data format for structuring this information. IVMS 101 was developed by the Joint Working Group on interVASP Messaging Standards and is used by all major Travel Rule solution providers.

Required data fields

For CASP-to-CASP transfers, the originator's CASP must include:

• Originator: full name, account number (wallet address or internal identifier), and one of: address, date and place of birth, or national identity number
• Beneficiary: full name, account number

The beneficiary's CASP must verify that beneficiary information is present before making the funds available. If information is missing, the beneficiary CASP must implement risk-based procedures to decide whether to execute, reject, return, or suspend the transfer.

IVMS 101 message structure

An IVMS 101 message contains four top-level objects. Here's a simplified example of what a Travel Rule message looks like in practice:

{
  "originator": {
    "originatorPersons": [{
      "naturalPerson": {
        "name": {
          "nameIdentifier": [{
            "primaryIdentifier": "SCHMIDT",
            "secondaryIdentifier": "MAX",
            "nameIdentifierType": "LEGL"
          }]
        },
        "geographicAddress": [{
          "addressLine": ["Friedrichstrasse 123"],
          "townName": "Berlin",
          "country": "DE",
          "addressType": "HOME"
        }],
        "nationalIdentification": {
          "nationalIdentifier": "DE-1234567890",
          "nationalIdentifierType": "NATIONAL_IDENTITY_NUMBER",
          "countryOfIssue": "DE"
        }
      }
    }],
    "accountId": ["user-12345"]
  },
  "beneficiary": {
    "beneficiaryPersons": [{
      "naturalPerson": {
        "name": {
          "nameIdentifier": [{
            "primaryIdentifier": "PAPADOPOULOS",
            "secondaryIdentifier": "ANDREAS",
            "nameIdentifierType": "LEGL"
          }]
        }
      }
    }],
    "accountId": ["user-67890"]
  },
  "originatingVASP": {
    "originatingVASP": {
      "legalPerson": {
        "name": {
          "nameIdentifier": [{
            "legalPersonName": "CryptoExchange DE GmbH",
            "legalPersonNameIdentifierType": "LEGL"
          }]
        }
      }
    }
  },
  "beneficiaryVASP": {
    "beneficiaryVASP": {
      "legalPerson": {
        "name": {
          "nameIdentifier": [{
            "legalPersonName": "CyprusCrypto Ltd",
            "legalPersonNameIdentifierType": "LEGL"
          }]
        }
      }
    }
  }
}

The full IVMS 101 specification includes additional fields for legal persons (registered businesses), date and place of birth, customer identification numbers, and more. What's shown above are the minimum fields for a natural person transfer between two CASPs. Your Travel Rule vendor will handle the IVMS 101 serialization -- you typically pass in structured customer data and the vendor formats it.

How does the Travel Rule work technically?

The Travel Rule sounds simple in theory: send customer data along with the transfer. In practice, three technical problems make it hard.

1. Counterparty VASP discovery

When your user sends crypto to an address, you need to figure out which CASP controls the receiving address -- and whether they support Travel Rule at all. This is the discovery problem.

Solutions use different approaches: centralized directories (Notabene maintains a directory of 7,000+ VASPs), decentralized registries (TRISA's Global Directory Service uses a certificate authority model), and blockchain analysis (mapping addresses to known CASP clusters). Most vendors combine multiple methods.

2. Secure messaging

Once you've identified the counterparty, you need to exchange IVMS 101 data securely. The data contains PII (names, addresses, national IDs), so it must be encrypted in transit and never stored by intermediaries without authorization. Several protocols handle this:

• TRP (Travel Rule Protocol) -- open-source, peer-to-peer, built on HTTPS and mTLS. Developed by the OpenVASP Association. No central server. Interoperable with TRISA since 2024.
• TRISA -- open-source, uses a certificate authority model with a Global Directory Service. P2P encrypted messaging between verified VASPs.
• Sygna Bridge -- proprietary API-based protocol by CoolBitX. Strong in Asia-Pacific markets.
• Notabene's network -- connects to multiple protocols (TRP, TRISA, Sygna, and others) through a single API integration.

The protocol landscape is fragmented. Your counterparty may use a different protocol than you. This is why vendors that support multiple protocols through a single integration point have an advantage -- you connect once, and the vendor handles protocol translation.

3. The sunrise problem

The "sunrise problem" is what happens when your CASP sends Travel Rule data to a counterparty that hasn't implemented it yet -- either because their jurisdiction doesn't mandate it, or they simply haven't deployed a solution.

According to Notabene's 2025 State of Crypto Travel Rule report, the industry is still split on how to handle this:

• 12% of VASPs block the transfer entirely if no Travel Rule response is received
• 14% proceed after a timeout period
• 22% proceed without waiting for a response
• 52% don't connect Travel Rule to transaction flows at all

The EBA guidelines expect CASPs to have documented, risk-based procedures for handling non-responsive counterparties. "We just send the transfer anyway" without a documented risk assessment is unlikely to satisfy an inspector.

How do Travel Rule vendors compare?

The vendor landscape has matured significantly since the TFR took effect. Here's a comparison of the major solutions available to EU CASPs as of early 2026.

How to choose

For most small-to-mid-size EU CASPs, the decision comes down to three factors:

1. Network size. The vendor's value is proportional to how many counterparty VASPs they can reach. If 80% of your transfers go to 5 major exchanges, check which vendor those exchanges use.
2. Protocol coverage. Your counterparties may use different protocols. A vendor that bridges multiple protocols (Notabene, Sumsub) reduces your integration burden.
3. Pricing predictability. 21 Analytics offers flat-rate unlimited transactions -- useful if your volume is growing. "Contact sales" vendors may price per transaction or per tier, which scales differently.

If you want to avoid vendor dependency entirely, TRISA's open-source "Envoy" software lets you run your own Travel Rule node. This requires more engineering effort but gives you full control over your data and no ongoing vendor fees.

What is the implementation timeline for small CASPs?

If you haven't implemented Travel Rule yet, you're past the deadline. The transitional period ended 31 July 2025. That said, here's a realistic timeline for getting compliant:

Weeks 1-2: Assessment and vendor selection

• Map your transaction flows: what percentage is CASP-to-CASP vs. self-hosted wallet?
• Identify your top 10 counterparty VASPs by volume
• Check which Travel Rule vendors those counterparties use
• Request demos from 2-3 vendors. Test their APIs in sandbox
• Review your existing KYC data: do you already collect the IVMS 101 required fields from customers?

Weeks 3-4: Integration

• Integrate the vendor API with your transaction processing pipeline
• Implement pre-transfer screening: Travel Rule data exchange must happen before the transfer is released to the beneficiary
• Build the self-hosted wallet verification flow for transfers above EUR 1,000
• Set up data retention: 5-year storage for all Travel Rule messages sent and received
• Most vendors advertise deployment in "less than a day" -- for the API integration, maybe. For end-to-end process integration with your existing systems, plan for 1-2 weeks of engineering.

Weeks 5-6: Policies and testing

• Document your sunrise procedures: what happens when a counterparty doesn't respond?
• Document your missing-information procedures: when do you reject vs. proceed with a transfer?
• Run end-to-end tests with at least 3 counterparty VASPs
• Train operations and compliance staff on the new workflows
• Update your AML/CFT policies and procedures manual

How does the Travel Rule relate to sanctions screening?

Travel Rule and sanctions screening are separate but complementary obligations. They're governed by different regulations, serve different purposes, and require different technical implementations.

• Travel Rule (TFR 2023/1113): ensures identity information accompanies every transfer for AML/CFT traceability
• Sanctions screening (EBA GL/2024/15): ensures you don't process transfers involving sanctioned persons, entities, or addresses

In practice, Travel Rule data feeds into sanctions screening. Once you receive the originator's name and national ID via IVMS 101, you should screen that data against the sanctions and restrictive-measures sources applicable to your firm, starting with EU and national measures for EU CASPs, before releasing funds. The two systems work together -- Travel Rule gives you the data, sanctions screening tells you what to do with it.

For a deeper breakdown of how sanctions screening differs from transaction monitoring and risk scoring, see our guide on screening vs. risk scoring.

Frequently asked questions

Does the EU Travel Rule have a minimum threshold for crypto transfers?

No. Unlike the US ($3,000) or FATF recommendation ($1,000/EUR 1,000), the EU's Transfer of Funds Regulation (TFR 2023/1113) applies to all crypto-asset transfers between CASPs regardless of amount. There is no de minimis threshold. For self-hosted wallet transfers, a EUR 1,000 threshold triggers additional verification requirements, but information collection applies to all amounts.

What is IVMS 101 and why does it matter for Travel Rule compliance?

IVMS 101 (InterVASP Messaging Standard) is the data format standard used to structure originator and beneficiary information exchanged between VASPs during crypto transfers. It defines four objects -- Originator, Beneficiary, OriginatingVASP, and BeneficiaryVASP -- each with specific fields like name, geographic address, national identification, and account numbers. All major Travel Rule vendors use IVMS 101 as their underlying data format, so you won't need to build the serialization yourself.

What is the Travel Rule sunrise problem?

The sunrise problem occurs when your CASP needs to send Travel Rule data to a counterparty VASP that hasn't implemented Travel Rule compliance yet -- either because their jurisdiction hasn't mandated it, or they haven't deployed a compatible solution. EBA guidelines expect CASPs to have documented, risk-based procedures for handling non-responsive counterparties, including whether to proceed, delay, or reject the transfer.

When did the EU Travel Rule take effect?

Regulation (EU) 2023/1113 applies from 30 December 2024. The EBA published accompanying Travel Rule Guidelines (EBA/GL/2024/11) on 4 July 2024, also applicable from 30 December 2024. A transitional period for CASPs ran until 31 July 2025 to allow systems adjustment, but full compliance is now required.

Does ChainScreen offer Travel Rule compliance?

No. ChainScreen now publishes content only. This guide is published to help CASPs understand their obligations and evaluate vendors. Travel Rule compliance remains a separate operational requirement from sanctions screening under EBA GL/2024/15.

Bottom line

The EU Travel Rule is the strictest implementation of FATF Recommendation 16 in any major jurisdiction. No threshold. Mandatory IVMS 101 data exchange. Self-hosted wallet verification above EUR 1,000. Five-year data retention. Documented procedures for every edge case.

The good news: the vendor ecosystem is mature. You don't need to build Travel Rule infrastructure from scratch. Pick a vendor with good counterparty coverage, integrate their API, document your procedures, and you're compliant. For a 5-person CASP, this is a 4-6 week project, not a 6-month initiative.

The bad news: if you haven't started, you're already behind. The transitional period ended in July 2025. Every transfer your CASP processes without Travel Rule compliance is a potential regulatory finding. Start now.