The FATF Travel Rule for VASPs: Technical Implementation and Cross-Border Compliance

The FATF Travel Rule — Recommendation 16 as extended to virtual assets — requires VASPs to obtain and transmit originator and beneficiary information alongside virtual asset transfers above the threshold. Conceptually simple, the Travel Rule has proved technically challenging to implement at scale. The problem is not regulatory ambiguity — the obligation is clear — but rather the practical difficulty of creating a messaging infrastructure for a pseudonymous, permissionless asset class that was explicitly designed to function without centralized intermediaries. In 2026, Travel Rule compliance is operational at major regulated VASPs, but coverage gaps, counterparty authentication challenges, and the "sunrise problem" continue to require active management.

The Core Obligation

FATF Recommendation 16, as applied to VASPs in the October 2021 updated guidance, requires that for virtual asset transfers above USD/EUR 1,000 (or equivalent), the originating VASP must obtain and transmit to the beneficiary VASP: originator name; originator account number (the wallet address); originator's physical address or national identity number or date and place of birth; and the beneficiary's name and account number. The beneficiary VASP must screen this information against its own KYC records and AML controls.

In the UK, Travel Rule obligations are implemented through the Funds Transfer Regulation as amended. In the EU, they are implemented under the Transfer of Funds Regulation (TFR) as updated under MiCA. Both frameworks require simultaneous transmission of originator/beneficiary data with the transfer — not after settlement. This creates a technical challenge: unlike traditional SWIFT messages, which carry structured data fields for originator and beneficiary information as standard, the blockchain itself carries no KYC data. The compliant information must travel through a separate messaging layer.

The Sunrise Problem

The "sunrise problem" refers to the asymmetric implementation timeline for Travel Rule compliance across jurisdictions. When a VASP in the UK (where the Travel Rule is live) sends to a VASP in a jurisdiction that has not yet implemented the requirement, the receiving VASP may be unable to receive, process, or verify Travel Rule messages. The UK VASP faces a dilemma: decline to transact with non-compliant counterparties (which may restrict legitimate business significantly), or accept transfers without Travel Rule data (which may breach UK obligations).

The FCA's guidance acknowledges this practical difficulty. For transfers to VASPs in jurisdictions that have not implemented the Travel Rule, UK VASPs should: assess whether the counterparty VASP is subject to equivalent AML obligations; apply risk-based due diligence proportionate to the jurisdiction risk; retain records of their assessment; and consider whether to apply enhanced scrutiny to transfers in lieu of Travel Rule data. This risk-based approach is acceptable to the FCA as an interim measure but cannot substitute indefinitely for actual Travel Rule compliance as implementation becomes more widespread.

Technical Protocols

Several industry protocols have emerged to handle the secure peer-to-peer transmission of Travel Rule data between VASPs:

TRISA (Travel Rule Information Sharing Architecture)

TRISA is an open-source, decentralised protocol developed by CipherTrace (now Mastercard). It uses mutual TLS authentication and certificate authorities to verify VASP identities, then transmits Travel Rule data peer-to-peer. TRISA maintains a VASP directory that allows counterparty VASPs to look up each other's endpoint and certificate. The protocol is permissionless in the sense that any VASP can implement it, subject to directory verification.

OpenVASP

OpenVASP is a similar protocol developed by Bitcoin Suisse, using Ethereum whisper messaging for peer-to-peer data exchange. It is less widely adopted than TRISA but has a dedicated user base in certain European markets.

Commercial Solutions (Notabene, Sygna Bridge)

For VASPs that prefer not to implement open-source protocols directly, commercial Travel Rule solutions such as Notabene, Sygna Bridge, and 21 Analytics provide compliance-as-a-service platforms. These typically integrate with multiple underlying protocols and provide a dashboard for reviewing, approving, or querying Travel Rule transactions. Most FCA-registered VASPs use one of these commercial solutions rather than implementing raw protocol libraries.

Unhosted Wallet Compliance

Transfers to or from unhosted wallets (self-custody wallets, hardware wallets, DeFi addresses) present the most practically difficult Travel Rule scenario. There is no receiving VASP to transmit information to; the wallet holder is directly controlling the funds. Both the UK and EU frameworks require additional due diligence for transfers above the threshold involving unhosted wallets: specifically, the regulated VASP must obtain from its customer a self-certification that the unhosted wallet belongs to them, and must conduct risk-based verification of that claim.

In practice, verification methods include: cryptographic proof of wallet ownership (signing a message with the private key); blockchain analytics-based risk scoring of the unhosted wallet address; and customer self-declaration combined with plausibility assessment. VASPs should document their unhosted wallet procedure in their AML policy and ensure it has been tested against both technical and regulatory expectations before relying on it for live transactions.

Counterparty VASP Due Diligence

The Travel Rule framework implies an ongoing relationship with counterparty VASPs beyond individual transaction data transmission. VASPs should maintain a counterparty VASP due diligence process that assesses: whether the counterparty is licensed or registered in its home jurisdiction; the AML/CFT standard of that jurisdiction (FATF membership, grey-list status); the counterparty's published compliance policies and Travel Rule implementation status; and adverse media or enforcement history. This due diligence should be refreshed at least annually and following material developments (enforcement actions, exchange hacks, significant regulatory changes in the counterparty's jurisdiction).