Short answer: the Travel Rule requires that information about the sender (originator) and recipient (beneficiary) travels with a payment from one financial institution to the next. FATF Recommendation 16 set this for wire transfers; since 2019, FATF has applied the same principle to transfers of virtual assets between virtual asset service providers (VASPs). It is a core CCAS topic.
Sourcing note. This post follows FATF Recommendation 16 and its interpretive note, FATF's guidance on virtual assets and VASPs, and the EU transfer-of-funds rules. Thresholds and data fields differ by jurisdiction; confirm local requirements.
The basic idea
When money moves, each institution in the chain should know who sent it and who receives it, so that they can screen against sanctions, detect suspicious activity and support investigations. The rule is called the "Travel Rule" because the information must travel with the transfer.
What information must travel
| Party | Information (FATF standard) |
|---|---|
| Originator | Name; account number (or a unique transaction reference); address, national identity number, customer ID, or date and place of birth |
| Beneficiary | Name; account number (or a unique transaction reference) |
For wires, FATF allows a de minimis threshold (USD/EUR 1,000) below which less information may be required. Countries may set their own thresholds; the EU's rules for crypto transfers apply to transfers regardless of amount. Check the local rules for your jurisdiction.
How it applies to virtual assets
| Aspect | Rule |
|---|---|
| Who is covered | VASPs (and financial institutions that handle virtual assets) |
| Transfers between VASPs | Originator and beneficiary information must be sent securely, before or at the time of the transfer |
| Beneficiary VASP | Must obtain and hold required information and screen it |
| Technology | Several protocols and solutions exist for exchanging data; the rule does not prescribe one |
| Unhosted wallet transfers | No VASP on one side, so there is nobody to receive the information; VASPs apply a risk-based approach and may collect information from their own customer |
Unhosted wallets
A transfer between a VASP and an unhosted wallet is not a VASP-to-VASP transfer. FATF guidance says VASPs should apply risk-based measures: obtain information from their own customer, assess the risk, and in some regimes verify wallet ownership. Rules differ: the EU requires VASPs to collect information and, above a threshold, to verify that the customer controls the unhosted wallet. Always read the scenario for jurisdiction.
Challenges
- Sunrise issue: one VASP is subject to the rule and the counterparty's jurisdiction does not yet implement it.
- Counterparty due diligence: a VASP needs to know whether the other VASP is licensed, secure and compliant.
- Data protection: transmitting personal data must comply with privacy law.
- Incompatible technology: different protocols and formats.
Why the exam cares
CCAS tests whether you know:
- That R.16 applies to VASP transfers through R.15 and its interpretive note.
- What information must travel.
- Who is obliged (VASPs, not private users).
- How to handle transfers involving unhosted wallets.
- That non-compliance is a regulatory failing and a red flag for the counterparty.
Practice-style reasoning
A customer asks to withdraw to an address that the analytics tool attributes to a VASP in a high-risk jurisdiction without a licence. What is the best step? Apply enhanced due diligence on the counterparty, request information, consider declining, and escalate. Do not proceed solely because the address is "just a wallet".
A customer sends from an exchange account to their own hardware wallet. An unhosted wallet transfer: apply the risk-based measures set by your jurisdiction, including collecting wallet information and possibly proof of ownership.