The Travel Rule: Sharing Originator Data Between VASPs

The FATF Travel Rule (Recommendation 16) requires that certain transfers carry identifying information about both sender and recipient. It began in traditional wire transfers and now extends to virtual asset service providers (VASPs). The obligation is deceptively simple to state and difficult to implement: attach the right data to the right transaction, deliver it to the counterparty, and do so without creating a new privacy liability. This article is general information, not legal advice.

What Data Has to Travel

For qualifying transfers, the originating institution must collect, verify, and transmit a defined set of fields alongside the value movement. In most implementations the payload includes:

• Originator name and account or wallet identifier.
• Originator address, national ID number, or date and place of birth, depending on jurisdiction.
• Beneficiary name and account or wallet identifier.

Thresholds vary. FATF sets a reference point of USD/EUR 1,000 for virtual assets, above which full verified data applies; below it, reduced information may be acceptable but institutions still screen against sanctions lists. Fiat wire thresholds differ again. The practical consequence is that your onboarding must capture these attributes cleanly at the point of KYC, because you cannot manufacture verified originator data at the moment a transfer leaves.

The Counterparty Discovery Problem

Traditional banking has SWIFT as a shared messaging rail. Crypto has no equivalent by default. Before a VASP can transmit Travel Rule data, it must answer two questions: is the beneficiary address controlled by another regulated institution, and if so, how do I reach that institution securely? This is counterparty discovery, and it is where most of the engineering effort goes.

Several interoperable protocols address this — TRP, IVMS 101 as a common data model, and messaging layers that negotiate a secure channel between two VASPs. IVMS 101 matters because it standardizes how a name, address, or identifier is structured, so that a German exchange and a Singaporean one interpret the same fields identically. Without a shared schema, name matching and sanctions screening on the receiving side degrade quickly.

Unhosted or self-custodied wallets complicate this further. When the beneficiary is an individual holding their own keys, there is no counterparty institution to receive the data. Many jurisdictions require the VASP to collect beneficiary information from its own customer and, in higher-risk cases, take reasonable measures to verify that the customer controls the destination address.

Privacy Engineering the Exchange

The Travel Rule creates a tension: you are legally required to share personal data about your customer with a third party, sometimes before you know whether that third party is trustworthy. Poorly designed implementations broadcast originator details to any address that requests them, which is a data-leakage vector attackers can probe.

Sound designs address this with sequencing and minimization:

• Confirm the counterparty first. Establish that the receiving VASP is real and regulated before releasing personal data, not after.
• Encrypt in transit and at rest. Payloads should be readable only by the intended counterparty, not the messaging intermediary.
• Transmit only required fields. If a jurisdiction accepts date of birth, do not also send a passport scan.
• Log the exchange, not just the transfer. Keep a record of what was sent, to whom, and on what legal basis, aligned with your retention schedule.

The same discipline that governs chat-based verification applies here: collect the attribute you need, prove it once, and avoid holding or forwarding raw documents when a verified data point suffices.

Building for a Moving Target

Implementation timelines and thresholds differ by country, and the FATF standards are transposed unevenly. Treat the Travel Rule as a data-quality problem more than a messaging one. If your KYC records store originator attributes in a structured, verified, deduplicated form, mapping them to IVMS 101 is mechanical. If your records are scanned PDFs and free-text notes, every transfer becomes a manual extraction. Invest in clean capture at onboarding, keep the exchange encrypted and minimized, and document each transmission so an examiner can reconstruct what left your system and why.