Travel Rule (FATF)

For transactions exceeding a threshold (e.g., $1,000/€1,000), the originating VASP must obtain and transmit, and the beneficiary VASP must receive and hold, the following data:

• Originator: Name, account number (e.g., wallet address), and physical address, national ID number, or date/place of birth.
• Beneficiary: Name and account number (e.g., wallet address). This creates a standardized data envelope for cross-border compliance.

The rule applies to Virtual Asset Service Providers (VASPs), a broad category defined by FATF. This includes:

• Centralized exchanges (CEXs) and custodians.
• Some decentralized exchange (DEX) operators and administrators.
• Wallet providers offering hosted/custodial services.
• Entities providing financial services for Initial Coin Offerings (ICOs). The definition focuses on the service provided, not the underlying technology.

To ensure interoperability, the InterVASP Messaging Standard (IVMS 101) provides a universal data model for Travel Rule compliance. It defines:

• A common JSON schema for originator and beneficiary data.
• Standardized fields and formats for names, addresses, and identifiers.
• Structured data to prevent ambiguity between different VASP systems. IVMS 101 is the foundational standard upon which specific communication protocols (like TRP, Shyft, etc.) are built.

VASPs use specific protocols to securely exchange Travel Rule data. Common solutions include:

• Travel Rule Protocol (TRP): An open-source API standard.
• Shyft Network's Veriscope: A decentralized attestation network.
• Sygna Bridge & TRISA: Peer-to-peer secure channels.
• Notabene & CipherTrace TRP: Commercial SaaS platforms. These protocols handle the secure, encrypted transmission of the IVMS 101 data payload between VASPs.

Transactions to or from unhosted wallets (private, non-custodial wallets) present a compliance challenge. Requirements vary by jurisdiction but often involve:

• Outgoing to private wallet: The VASP must collect and verify Travel Rule data for the originator (their customer).
• Incoming from private wallet: The VASP may be required to collect beneficiary data and perform enhanced due diligence on the source of funds. This area remains a focal point for regulatory guidance and technological solutions like decentralized identity.

A critical adjunct to the Travel Rule is the requirement for real-time sanctions screening. VASPs must:

• Screen both the transaction details and the accompanying Travel Rule data (names, addresses) against global sanctions lists (e.g., OFAC SDN List).
• Implement procedures to block or reject transactions involving sanctioned parties or jurisdictions.
• Maintain audit trails of all screening checks. Failure to screen can result in severe penalties for sanctions evasion.

The core regulatory requirement, FATF Recommendation 16, obligates Virtual Asset Service Providers (VASPs) to collect and transmit specific customer data for transactions. This includes:

• Originator Information: Sender's name, account number (wallet address), and physical address or national ID number.
• Beneficiary Information: Recipient's name and account number (wallet address).
• The rule applies to cross-border and, in many jurisdictions, domestic transfers exceeding a set threshold (e.g., $1,000/€1,000).

A foundational technical challenge is determining if the counterparty in a transaction is another regulated VASP (requiring data sharing) or an unhosted private wallet (requiring enhanced due diligence). Solutions include:

• IVMS 101 Data Model: The InterVASP Messaging Standard, a common format for Travel Rule data.
• Discovery Protocols: Systems like the Travel Rule Universal Solution Technology (TRUST) in the US or proprietary APIs that allow VASPs to identify and connect with each other to exchange required data securely.

Once a counterparty VASP is identified, secure communication channels are needed to transmit sensitive customer data. Key protocols and solutions include:

• OpenVASP: An open-source protocol using decentralized identifiers (DIDs) and peer-to-peer messaging.
• TRP (Travel Rule Protocol): A standardized API protocol for VASP-to-VASP communication.
• Proprietary Enterprise Solutions: Offered by compliance technology firms (e.g., Chainalysis, Elliptic, Notabene) that provide integrated platforms for data formatting, encryption, and secure delivery.

To mitigate the privacy risks of sharing sensitive personal data, protocols are integrating advanced cryptographic techniques:

• Zero-Knowledge Proofs (ZKPs): Allow a VASP to prove compliance (e.g., that data was shared and validated) without revealing the underlying personal data to all parties.
• Secure Multi-Party Computation (sMPC): Enables computation on encrypted data, allowing checks (like sanctions screening) to be performed without exposing raw data.
• These technologies aim to achieve regulatory compliance while upholding principles of data minimization and user privacy.

Transactions to or from unhosted wallets (private wallets not managed by a VASP) present a significant compliance hurdle. The FATF requires VASPs to:

• Obtain and hold required originator/beneficiary information for these transactions.
• Conduct enhanced due diligence on customers transacting with unhosted wallets.
• This creates friction for users and pushes protocols to develop solutions for verified credentials or decentralized identity that can provide necessary assurances without central custody.

There is no single global standard for Travel Rule implementation, leading to a fragmented landscape:

• Jurisdictional Variance: Thresholds, specific data fields, and enforcement timelines differ (e.g., EU's Transfer of Funds Regulation (TFR), Singapore's MAS guidelines, US state-by-state rules).
• Protocol Interoperability: Different VASPs may adopt different technical solutions (TRUST, OpenVASP, proprietary), requiring bridges or aggregators for universal compliance.
• This fragmentation increases complexity and cost for global VASPs, which must navigate multiple, sometimes conflicting, regulatory regimes.

The FATF's Recommendation 16 sets the primary transaction value threshold for the Travel Rule. VASPs must collect and transmit required information for virtual asset transfers exceeding $1,000 USD or €1,000. This threshold applies to the transaction amount, not the aggregate over time. Jurisdictions may set lower thresholds for domestic implementation.

For applicable transactions, the originating VASP must obtain and share specific data with the beneficiary VASP. Mandatory fields include:

• Originator's name
• Originator's account number (e.g., wallet address)
• Originator's physical address, national ID number, or customer ID
• Beneficiary's name
• Beneficiary's account number (e.g., wallet address) This parallels the data required for traditional wire transfers under the original Travel Rule.

While the FATF sets the global standard, individual countries and regions enact their own laws and regulations to enforce it. Key examples include:

• European Union: Enforced via the Transfer of Funds Regulation (TFR), applying to crypto asset transfers.
• United States: Enforced by FinCEN, applying to Money Transmitters and MSBs handling convertible virtual currencies.
• Singapore: Enforced by the Payment Services Act, overseen by MAS. Implementation timelines and specific technical requirements can vary significantly.

The rule's application differs based on the counterparty:

• VASP-to-VASP Transfers: The rule fully applies. Both VASPs must verify and share customer information.
• Transfers to/from Unhosted Wallets (private wallets): Requirements are less prescriptive. VASPs must still collect originator information for outgoing transfers and conduct enhanced due diligence for incoming transfers from such wallets, but may not be required to obtain full beneficiary data from the unhosted wallet owner.

To automate the secure exchange of Travel Rule data, several competing technical standards have emerged. These protocols enable interoperability between VASPs. Major solutions include:

• IVMS 101: The FATF's InterVASP Messaging Standard, a data model.
• Travel Rule Universal Solution Technology (TRUST) in the U.S.
• OpenVASP
• Sygna Bridge
• VerifyVASP VASPs often need to support multiple protocols to ensure global coverage.

Non-compliance with national implementations of the Travel Rule carries severe consequences for VASPs. Regulators can impose:

• Hefty financial penalties (often millions of dollars)
• License revocation or suspension
• Civil and criminal liability for institutions and executives Enforcement actions have increased globally as jurisdictions finalize their regulatory frameworks and conduct examinations.

A Virtual Asset Service Provider (VASP) is any business that conducts one or more of the following activities for or on behalf of another person:

• Exchange between virtual assets and fiat currencies
• Exchange between one or more forms of virtual assets
• Transfer of virtual assets
• Safekeeping and/or administration of virtual assets or instruments enabling control over them
• Participation in and provision of financial services related to an issuer's offer and/or sale of a virtual asset. The Travel Rule applies specifically to transactions between VASPs.

FATF Recommendation 16 is the specific international standard that mandates the Travel Rule. It requires VASPs to obtain, hold, and transmit required originator and beneficiary information for virtual asset transfers. The rule applies to transactions at or above a designated threshold (USD/EUR 1,000). It is the binding interpretation of the broader FATF Recommendations (specifically Recommendation 15) as applied to virtual assets.

The core data elements that must be collected and shared under the Travel Rule.

• Originator Information: The name of the sender, their account number/unique identifier (e.g., wallet address), and physical address, national identity number, or customer ID number.
• Beneficiary Information: The name of the recipient and their account number/unique identifier (e.g., wallet address). This information must "travel" with the transaction from the originating VASP to the beneficiary VASP.

InterVASP Messaging Standards (IVMS) are a common set of data fields and formats developed by the industry to standardize Travel Rule compliance messages. The IVMS 101 data model ensures that originator and beneficiary information is structured uniformly, enabling interoperability between different VASP compliance solutions and jurisdictions. It is a critical technical standard for practical implementation.

Technology solutions that enable VASPs to securely share the required Travel Rule data. They typically fall into two architectures:

• Decentralized Solutions: Use distributed ledger technology or peer-to-peer protocols for direct VASP-to-VASP data exchange (e.g., using a Decentralized Identifier or DID).
• Centralized Solutions: Rely on a central hub or API-based network to route compliance messages between VASPs. Examples include proprietary vendor networks and open protocols like the Travel Rule Protocol.

The "Sunrise Issue" refers to the compliance challenge that arises when a regulated VASP in a Travel Rule jurisdiction sends a virtual asset transfer to a VASP in a jurisdiction where the rule is not yet enforced (or to an unhosted wallet). The originating VASP may be unable to obtain the required beneficiary information, potentially blocking legitimate transactions. This creates friction and is a major focus of regulatory alignment efforts.