Travel Rule Compliance: FATF Recommendation 16 for VASPs

FATF defines a Virtual Asset Service Provider through five activities. Any natural or legal person conducting any of them as a business is a VASP and is subject to AML/CFT regulation in every FATF member jurisdiction.

The five VASP activities under FATF Recommendation 15:

• Exchange between virtual assets and fiat currencies.
• Exchange between one or more forms of virtual assets.
• Transfer of virtual assets — moving virtual assets from one address or account to another.
• Safekeeping or administration of virtual assets or instruments enabling control over virtual assets.
• Participation in and provision of financial services related to an issuer's offer or sale of a virtual asset (including ICOs).

National implementations vary at the edges. MAS's definition of "Digital Payment Token Service" under the Payment Services Act covers the FATF VASP activities and adds DPT exchange and certain custodial activities. MiCA introduces "Crypto-Asset Service Providers" (CASPs) with broadly equivalent scope. FinCEN treats most crypto exchanges as Money Services Businesses. The vocabularies differ; the substantive scope is similar.

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.

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.

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.

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.

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.

Transaction monitoring scenarios for VASPs need to address typologies that do not exist in traditional banking. A monitoring system designed for fiat banking will miss crypto-specific patterns that are genuinely diagnostic of illicit activity.

The crypto-specific typologies a VASP's transaction monitoring should detect:

• Mixer and tumbler exposure — funds traced to or from anonymising services (Tornado Cash and successors, traditional mixers).
• Darknet market exposure — funds with on-chain provenance from sanctioned darknet markets or known illicit clusters.
• Sanctioned address exposure — direct or indirect transactions with blockchain addresses on the OFAC SDN list (which has included crypto addresses since 2018).
• Chain-hopping — rapid conversion between assets across multiple chains designed to obscure origin.
• Peel chain patterns — large amounts split into small transfers across many addresses, typically associated with laundering ransomware proceeds.
• Unhosted-wallet velocity — large or frequent flows to/from self-custodied wallets without clear economic rationale.
• Front-running and wash trading — manipulative trading patterns that may not be money laundering per se but are typically subject to STR obligations.

See our broader transaction monitoring guide for the underlying framework these crypto-specific scenarios extend.

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.