FATF Travel Rule Compliance for Tokenization Platforms

The Travel Rule: Background and Scope

FATF Recommendation 16, originally designed for correspondent banking wire transfers, was extended to virtual asset service providers in 2019 through FATF’s updated Guidance on Virtual Assets and VASPs. The extension requires VASPs — which include tokenization platforms, exchanges, custodians, and wallet providers — to collect, transmit, and hold originator and beneficiary information for virtual asset transfers above the applicable monetary threshold.

The Wire Transfer Rule for conventional banking had been in place since the early 1990s. Its extension to VASPs reflects FATF’s view that the same anti-money laundering logic applies: without identifying who is sending funds to whom, regulatory authorities cannot trace illicit financial flows through the virtual asset ecosystem.

The threshold is $1,000 (or local currency equivalent). For transfers at or above this threshold, the sending VASP must transmit originator and beneficiary data to the receiving VASP concurrently with the transfer. The receiving VASP must verify the beneficiary information against its own KYC records for the recipient.

Jurisdictional Implementation Details

European Union — Transfer of Funds Regulation (TFR)

The revised Transfer of Funds Regulation (EU) 2023/1113, which applies MiCA’s VASP scope to the TFR framework, entered into force in June 2023. The EU’s Travel Rule is notable for two features that go beyond FATF’s minimum standard:

No minimum threshold for VASP-to-VASP transfers. The EU’s TFR removes the €1,000 threshold for transfers between two VASPs. All VASP-to-VASP transfers — regardless of amount — require originator and beneficiary data transmission. The €1,000 threshold only applies to transfers between a VASP and a non-VASP (i.e., transfers to or from unhosted wallets).

Unhosted wallet requirements. For transfers from a VASP to an unhosted wallet above €1,000, the sending VASP must collect the originator’s information and apply a risk-based approach to verifying that the unhosted wallet belongs to the originator. ESMA and the EBA have published guidance on the risk-based assessment — high-risk unhosted wallet transactions require more extensive verification than routine self-transfers.

Data required (EU/TFR):

• Originator: name, distributed ledger address, account number, address/national ID/customer ID/date+place of birth
• Beneficiary: name, distributed ledger address, account number

United Kingdom

The UK Travel Rule came into force under the amended MLRs in September 2023. The threshold is £1,000.

The FCA has published guidance on the UK Travel Rule’s application to unhosted wallets, requiring VASPs to apply a risk-based approach. Higher-value transfers to unhosted wallets require evidence of the customer’s relationship with the wallet address (e.g., signed message verification or withdrawal/deposit matching).

Singapore

MAS Notice PSN01 (amendment) effective January 2024. Threshold: S$1,500 (~US$1,100). Singapore’s implementation closely tracks the FATF standard. MAS has published FAQs addressing the treatment of unhosted wallets and the technical requirements for Travel Rule data transmission.

Hong Kong

SFC licensing conditions for VATPs (effective January 2024). Threshold: HKD 8,000 (~US$1,025). The SFC requires VATPs to implement the Travel Rule for both retail and institutional client transfers. For institutional-only VATPs, the SFC expects Travel Rule compliance to be integrated into the institutional onboarding and transfer procedures.

UAE

CBUAE and VARA guidance (effective 2024). Threshold: AED 3,500 (~US$953). VARA’s Transfer and Settlement Services Rulebook specifies Travel Rule requirements for VARA-licensed VASPs. UAE-based VASPs must comply when transacting with counterpart VASPs regardless of the counterpart’s jurisdiction.

Switzerland

Swiss Travel Rule (revised AMLA and FINMA circular, effective 2021) — Switzerland was an early implementer. Threshold: CHF 1,000. FINMA requires SRO-affiliated VASPs to have Travel Rule procedures documented in their AML manuals.

The Data Transmission Challenge: IVMS101

The International Virtual Asset Service Provider Messaging Standard (IVMS101) is the emerging global standard for Travel Rule data formatting. IVMS101 was developed by a consortium of industry bodies (JMLSG, Accredited Standards Committee X9, SWIFT) and endorsed by FATF.

IVMS101 defines:

• Data fields and data types for originator and beneficiary information
• JSON and XML encoding specifications
• Field-level validation rules
• Multi-jurisdictional name and address field handling

VASPs that implement IVMS101 can exchange Travel Rule data with any other IVMS101-compliant VASP, regardless of which technical protocol (TRISA, Notabene, Sygna, etc.) is used for transmission — because the data payload format is standardized.

Practical implication: Compliance officers should require that their chosen Travel Rule solution is IVMS101-compliant. Solutions that use proprietary data formats create interoperability barriers that will need to be resolved as the Travel Rule ecosystem matures.

Technical Solution Evaluation Framework

Unhosted Wallet Compliance: The Hard Problem

Transfers to unhosted wallets (self-custodied addresses not associated with any VASP) present the Travel Rule’s most operationally challenging requirement. The receiving address is not a VASP — it cannot receive or process Travel Rule data. Yet regulators expect VASPs to apply appropriate controls to such transfers.

The approaches employed by compliant VASPs:

1. Proof of ownership via signed message: The customer demonstrates ownership of the destination address by signing a specified message (the VASP’s transaction reference) with the private key of the destination address. If the signature is valid, the VASP has reasonable assurance that the transfer is a self-transfer — effectively an intra-customer movement.

2. Small deposit verification: The VASP sends a small test transaction to the destination address and asks the customer to confirm receipt of the specific amount — demonstrating access to the wallet.

3. Risk-based threshold application: Some VASPs apply proof-of-ownership requirements only for unhosted wallet transfers above a higher threshold (e.g., $5,000 or $10,000) and accept standard CDD documentation for smaller amounts. This approach is supported by the FCA’s and MAS’s risk-based guidance.

4. Enhanced screening: All unhosted wallet transfers are screened through blockchain analytics at the time of transaction and at regular intervals after (to catch retrospective sanctions exposure). Blockchain analytics is not a substitute for beneficial ownership verification, but it is a necessary complement.

For tokenization platforms specifically: Transfers to unhosted wallets most commonly arise when clients are moving tokenized assets to self-custody. The compliance officer must decide: does the platform permit self-custody withdrawals? If so, what verification is required at each value tier? The answer should be documented in the AML procedures and disclosed to clients in the terms of service.

The Sunrise Problem in Practice

As of Q1 2026, the Travel Rule has been implemented in approximately 30+ FATF member jurisdictions but remains unimplemented in more than 100. The sunrise problem is therefore still live for transactions involving VASPs in non-compliant jurisdictions.

What compliant VASPs do in practice:

1. Maintain a VASP counterpart database identifying which counterpart VASPs are in Travel Rule-compliant jurisdictions and which Travel Rule solution they use
2. For transfers involving non-compliant jurisdiction VASPs, apply enhanced due diligence at the customer level (rather than relying on VASP-to-VASP data exchange)
3. Set risk appetite policies for transactions with VASPs in non-compliant jurisdictions — some VASPs refuse transactions with unidentified counterparts entirely; others apply enhanced screening
4. Document the risk-based approach and the rationale for treatment of non-compliant counterparts in the AML manual

Regulators expect VASPs in compliant jurisdictions to document how they manage the sunrise problem. The absence of a documented approach is itself a compliance gap.

VASP Identification: The VASP Directory Infrastructure

A foundational requirement for Travel Rule compliance is knowing whether a counterpart address is associated with a VASP (and which one) or is an unhosted wallet. Without reliable VASP identification, VASPs cannot determine whether to transmit Travel Rule data or apply unhosted wallet controls.

Three VASP identification mechanisms are in use:

GLEIFs VASP ID: The Global Legal Entity Identifier Foundation (GLEIF) has proposed extending the Legal Entity Identifier (LEI) system to VASPs. Several Travel Rule solutions have incorporated GLEIF-based VASP IDs as the authoritative identifier.

TRISA Directory: The TRISA directory provides a decentralized registry of VASP public keys and contact endpoints for Travel Rule data exchange. VASPs registered in the TRISA directory are verifiably identified VASPs.

Notabene / Sygna networks: Both commercial platforms maintain their own VASP directories with counterpart VASP verification. These are effective within the platform’s network but create siloing issues when a sending VASP and receiving VASP use different platforms.

The practical solution: Use blockchain analytics tools (Chainalysis, Elliptic, TRM Labs) for initial wallet screening to determine whether an address is associated with a known VASP. Blockchain analytics providers maintain large databases of VASP-attributed addresses, which allows automated determination of whether a transfer is VASP-to-VASP or VASP-to-unhosted wallet.

Compliance Workflow Integration

Travel Rule compliance must be integrated into the transaction processing workflow — it cannot function as a manual, post-hoc process. The compliance workflow should:

1. At transfer initiation: Automatically screen destination address against blockchain analytics to determine VASP or unhosted wallet classification
2. If VASP: Automatically initiate Travel Rule data exchange via integrated protocol (Notabene, TRISA, etc.) before or concurrent with transaction broadcast
3. If unhosted wallet: Trigger appropriate verification workflow (signed message, deposit verification) if above applicable threshold
4. At receipt: Screen incoming transfers; verify beneficiary against KYC records; flag mismatches for manual review
5. Alert management: Automated flagging of Travel Rule failures (no counterpart response, data mismatch, sanctions exposure) with defined escalation path

This integration requires API development work connecting the Travel Rule solution to the custody platform, order management system, and compliance case management system. The integration timeline is typically 2–4 months for a well-resourced engineering team.

Further information: FATF Guidance on Virtual Assets (2021) | FSB Crypto-Asset Activities

Related Resources

• AML Framework for Tokenization Platforms
• EU MiCA License: AML Requirements
• Singapore MAS License: Travel Rule Requirements
• Regulatory Encyclopedia
• Compliance Benchmarks