Travel Rule Compliance: FATF Recommendation 16 for VASPs
FATF Recommendation 16 was originally the wire transfer rule — banks transmitting payment messages must include originator and beneficiary information. In 2019 FATF extended the requirement to Virtual Asset Service Providers (VASPs) handling crypto-asset transfers above the regulatory threshold. The extension is operationally novel, jurisdictionally fragmented, and the source of the recurring 'sunrise problem' compliance teams navigate.
The Travel Rule's extension to crypto in 2019 marked the moment regulators stopped treating crypto as an exception to financial-system AML obligations and started treating it as an integrated participant. The operational difficulty was — and partly remains — that the existing wire-transfer messaging infrastructure (SWIFT, SEPA, domestic systems) does not handle crypto transfers, and there is no native equivalent in the crypto rails themselves. Compliance teams have had to build new infrastructure to satisfy a rule that the underlying technology was not designed for.
The result is a working but uneven implementation. Major VASP jurisdictions have functional Travel Rule operations. Cross-border transfers between matched-protocol VASPs are increasingly routine. Transfers involving non-VASP counterparties (self-custody wallets, decentralised exchanges, VASPs in non-implementing jurisdictions) remain operationally complex. The guide below covers the substantive obligations, the messaging-protocol landscape, and the operational patterns that work.
What Recommendation 16 Actually Requires
FATF's Updated Guidance for a Risk-Based Approach to Virtual Assets and VASPs (October 2021, updated July 2024) sets out the operational expectations:
- Originator VASP obligations. When sending a crypto-asset transfer above the threshold on behalf of a customer, obtain and hold required originator information (name, account/wallet address, and either physical address, customer ID number, or date and place of birth) plus beneficiary information (name and account/wallet address). Transmit this information to the beneficiary VASP simultaneously with or immediately following the transfer.
- Beneficiary VASP obligations. Obtain and hold the required originator and beneficiary information. Screen against sanctions and watchlists. Have procedures for transfers that arrive without required information — typically including holding the transfer, requesting the missing information from the originator VASP, and considering whether to return the transfer or file an STR.
- Thresholds. FATF's recommended threshold is USD/EUR 1,000. Member jurisdictions implement at this level or lower; some apply zero threshold (the Travel Rule applies to all transfers regardless of size). Singapore's MAS, the EU's MiCA/TFR, Switzerland's FINMA, and several others apply the lower-threshold approach.
- Treatment of unhosted wallets. Transfers to or from self-custody (unhosted) wallets sit outside the VASP-to-VASP framework. Jurisdictions handle this differently — some require enhanced due diligence on counterparty wallets, some require the originating VASP to collect the equivalent information from the customer, some impose no specific obligation but require risk-based assessment.
- Sanctions screening. Both originator and beneficiary VASPs must screen the counterparty information against sanctions lists. Wallet-address screening (against OFAC SDN list designations, EU sanctions designations) is increasingly part of the operational baseline.
The Sunrise Problem and Why It Persists
The 'sunrise problem' is the operational reality that Travel Rule implementation does not happen globally on a single date. Jurisdictions enforce at different times; VASPs in earlier-implementing jurisdictions are obligated to comply when transacting with counterparties in jurisdictions that have not yet implemented or enforced. The problem creates several recurring operational patterns:
- Asymmetric counterparty capability. The originating VASP is required to transmit Travel Rule data, but the receiving VASP in a non-implementing jurisdiction has no infrastructure to receive it, no obligation to acknowledge it, and no incentive to maintain matching protocols. The transfer settles on the blockchain regardless; the data transmission fails.
- Counterparty due diligence on VASPs. The originating VASP must assess whether the counterparty VASP is regulated, whether it implements equivalent AML controls, and whether information transmitted will be appropriately handled. The assessment is the operational substitute for the missing regulatory baseline.
- Risk-based decisions on non-cooperating counterparties. Where a counterparty VASP cannot or will not receive Travel Rule data, the originating VASP must decide whether to continue the relationship, restrict the relationship, or terminate it. Risk-based decisions are documented and consistently applied across counterparties.
- Operational asymmetry vs market access. VASPs serving a customer base that transacts with counterparties in non-implementing jurisdictions face a market-access tension. Restricting all such transfers protects regulatory standing but constrains customers; permitting them accepts unmitigated counterparty risk. The balance is firm-specific and evolves as global implementation matures.
The sunrise problem is narrowing but not closed. As of 2026, the substantial majority of major-jurisdiction VASPs are Travel Rule capable; the remaining gaps are in smaller jurisdictions and among VASPs that operate at the margins of regulation.
Messaging Protocols: TRP, TRISA, Sumsub TRC
Three messaging protocols dominate VASP-to-VASP Travel Rule communication, with several smaller protocols also in use. None has become the universal standard; most production VASPs support multiple protocols.
TRP (Travel Rule Protocol)
Developed by the OpenVASP Association and adopted by a large group of European and US VASPs. Open protocol with reference implementations available. Uses HTTPS-based messaging with PKI for sender/receiver authentication. Generally considered the most operationally mature in major-jurisdiction VASP-to-VASP transfers. Strength: broad European adoption; weakness: less common in Asian VASP corridors.
TRISA (Travel Rule Information Sharing Architecture)
Developed by CipherTrace (now Mastercard) and operated as an open-source protocol. Uses mTLS for peer-to-peer messaging with directory services for VASP discovery. Particularly common among US-regulated VASPs. Strength: peer-to-peer architecture without central intermediary; weakness: directory adoption is uneven outside the US.
Sumsub TRC (Travel Rule Connectivity)
Hosted service operated by Sumsub. Provides centralised intermediation between VASPs and abstracts the protocol-fragmentation problem behind a single interface. Strength: lower implementation burden, particularly for smaller VASPs; weakness: dependency on a single intermediary.
Common data standard: All three protocols use IVMS101 (Inter-VASP Messaging Standard 101) for the data payload. IVMS101 standardises the structure of originator and beneficiary information across protocols, meaning that the data is interoperable even when the transport protocol is not. This is the closest thing to a universal standard the Travel Rule has produced.
Interoperability initiatives: Several initiatives bridge protocols — the Travel Rule Protocols Alliance, vendor partnerships between major TRSPs (Travel Rule Solution Providers), and direct bilateral integrations between specific VASPs. Interoperability is improving but cross-protocol messaging still adds operational friction.
Jurisdictional Implementation Variation
Implementation timelines and specific obligations vary materially by jurisdiction. Major-jurisdiction summary:
- Singapore (MAS): Travel Rule operational since 2020 under the Payment Services Act 2019. Threshold of SGD 1,500. All licensed Digital Payment Token service providers covered. Robust supervisory framework with documented expectations.
- European Union: The Transfer of Funds Regulation (TFR, Regulation 2023/1113) applies to crypto-asset transfers from 30 December 2024, with zero threshold (all transfers covered). Originator and beneficiary VASP obligations harmonised across Member States. Applies to transfers between VASPs and to/from unhosted wallets in specific circumstances.
- United Kingdom: Money Laundering Regulations 2017 amended to include the Travel Rule for crypto from September 2023, threshold of GBP 1,000. FCA supervisory expectations are detailed in published guidance.
- United States: FinCEN's Travel Rule has applied to crypto transfers above USD 3,000 under the Bank Secrecy Act since 2019, with FinCEN's 2019 guidance confirming application. The threshold is higher than FATF recommends but operational implementation is substantial.
- Japan (FSA): Travel Rule effective June 2023 under amendments to the Act on Prevention of Transfer of Criminal Proceeds. Threshold of JPY 100,000. Implementation handled through JVCEA-coordinated industry framework.
- South Korea (FIU): Travel Rule effective March 2022 under the Specified Financial Information Act. Threshold of KRW 1 million.
- UAE (VARA in Dubai, ADGM elsewhere): Travel Rule applied to VASPs operating in the relevant zones since 2023. Threshold varies by zone and license type.
- Switzerland (FINMA): Travel Rule applies through FINMA Circular 2016/7 amendments. Threshold of CHF 1,000.
The variation matters because cross-border transfers must satisfy the originating-VASP's jurisdictional obligations regardless of where the beneficiary VASP sits. A Singapore-licensed VASP sending to a US VASP applies Singapore Travel Rule obligations; a US VASP sending to a Singapore VASP applies US obligations.
Operational Compliance Patterns That Work
Five operational patterns for VASPs operating under Travel Rule obligations:
- Multi-protocol capability. Single-protocol implementations leave gaps where counterparty VASPs use a different protocol. Production VASPs implement at least two of TRP, TRISA, Sumsub TRC, with the choice driven by where the customer base's counterparty VASPs sit.
- Counterparty VASP due diligence. Maintain a counterparty assessment for each VASP the firm transacts with: jurisdiction, regulatory status, Travel Rule capability, AML programme assessment. The assessment supports risk-based decisions about which counterparties to engage with.
- Unhosted wallet treatment. Define and document the firm's approach to transfers involving self-custody wallets — what verification is required, what risk-based thresholds apply, what enhanced due diligence is triggered. The approach varies by jurisdiction; the documentation is needed regardless.
- Sanctions screening integrated with Travel Rule data. The originator and beneficiary information flowing through the Travel Rule protocol is the basis for sanctions screening. Integration between the Travel Rule infrastructure and the sanctions screening platform is operational requirement, not nice-to-have.
- STR filing readiness on Travel Rule failures. Where Travel Rule data is missing, incomplete, or implausible, the operational response includes consideration of STR filing. The case-management workflow needs to handle Travel Rule-specific dispositions in addition to standard transaction-monitoring alerts.
For broader VASP and crypto compliance context see our upcoming Cluster E posts on VASP licensing and crypto wallet screening, and our AML/CFT platform overview for the wider operational stack.
Travel Rule Built Into the AML Stack
One Constellation supports VASP compliance with integrated Travel Rule messaging, IVMS101 data handling, multi-protocol capability, and sanctions screening on originator and beneficiary information — purpose-built for the operational realities of crypto AML.
