Contents
The FATF Travel Rule pushes virtual asset service providers (VASPs) to exchange sender and recipient information alongside transfers. It’s a compliance requirement, but it also shapes product flows, data models, and how customers experience moving crypto. Getting the data fields right, supporting self-hosted wallets sensibly, and smoothing the UX can cut failure rates and reduce support load.
What the Travel Rule covers
The rule requires originating and beneficiary VASPs to share specific identifying information for transfers at or above a set threshold. Many regulators now expect VASPs to collect this data even below thresholds to manage risk and ensure interoperability. Messaging happens off-chain; the blockchain transaction still looks the same.
- Actors: originator VASP (sending), beneficiary VASP (receiving), and sometimes a self-hosted wallet owner.
- Scope: VASP-to-VASP transfers primarily; self-hosted wallet rules vary by jurisdiction.
- Thresholds: FATF guidance at 1,000 USD/EUR; local rules may be stricter or looser.
Think of it as attaching a secure “travel slip” to a transfer. The slip never goes on-chain; it moves via a messaging network or bilateral channel.
Required data fields: the practical set
Most implementations follow IVMS101, a common data model for Travel Rule messages. Fields differ slightly across regimes, but the core set has stabilized. Teams should map these to their user profiles and transaction objects early to avoid rework.
| Field | Originator required | Beneficiary required | Notes |
|---|---|---|---|
| Full legal name | Yes | Yes | Given and family name; no nicknames |
| Account identifier | Yes | Yes | Wallet address, tag/memo, or unique customer ID |
| National ID or address | Yes (one of) | Sometimes | Jurisdiction-dependent; DoB often acceptable |
| Date of birth | Often | Sometimes | Helps disambiguate common names |
| VASP identifier | Yes | Yes | Legal name, LEI, or TR network ID |
| Transaction reference | Yes | Yes | Link the off-chain message to the on-chain tx |
| Amount and asset | Yes | Yes | Include fiat equivalent for threshold checks |
Two patterns work well: store immutable snapshots of submitted identity data per transaction, and keep a normalized customer profile. Snapshots support audits; profiles reduce re-entry friction.
- Define your canonical fields based on IVMS101 plus local extras.
- Map KYC data to those fields; identify gaps requiring fresh collection.
- Create a “Travel Rule package” object linked to each transfer.
- Validate synchronously before broadcasting on-chain.
- Retain messages and acknowledgements for the statutory period.
Once these mechanics are set, adding new jurisdictions becomes a matter of toggling a few optional fields and adjusting validation rules rather than rebuilding flows.
Thresholds and jurisdiction wrinkles
The FATF baseline is simple; local rules are not. Build for variability and explicit thresholds in code, not constants buried in UI copy.
- US: 3,000 USD Travel Rule threshold for funds transfers; crypto included. Originator and beneficiary info must accompany qualifying transfers.
- EU: The recast Transfer of Funds Regulation applies to virtually all crypto-asset transfers between CASPs, with stricter checks for self-hosted interactions above 1,000 EUR.
- UK: Risk-based approach; collect, verify where possible, and “travel” the data. Receiving firms can hold or reject if data is missing.
- APAC: Patchwork. Some markets follow the 1,000 USD/EUR line; others set zero thresholds or mandate specific identifiers.
Micro-scenario: a user sends 0.8 ETH from a German CASP to a French CASP. The firms exchange both parties’ names and account identifiers regardless of fiat value, because EU rules expect it. Contrast with a US-to-US transfer at 500 USD where data exchange may be lighter, depending on firm policy.
Self-hosted wallets: what’s expected
Self-hosted (unhosted) wallets are not VASPs, so they can’t “receive” Travel Rule messages. Regulators still expect the originating VASP to collect and, in some regions, verify information about the owner of that wallet when thresholds or risk conditions are met.
- Ownership checks: signed message from the private key, micro-transfer verification, or proof via wallet-connect session.
- Beneficiary identification: name and, if feasible, a minimal identifier (email handle, phone hash) subject to local rules.
- Risk flags: new or first-use addresses, mixers, sanctioned exposure, high-value jumps.
EU example: if a customer withdraws 3,000 EUR equivalent to their own self-hosted wallet, the CASP must verify ownership. A simple pattern is to prompt a one-time signature using the address, store the attestation, and reuse it for future withdrawals to the same wallet.
Messaging networks and address discovery
VASPs need to find the counterparty VASP and deliver the message securely. Multiple networks and service providers exist, and many support the IVMS101 schema to keep payloads interoperable.
- Discovery: address-book registries, on-chain tags, and protocol lookups (e.g., TRP, TRISA) to map an address or domain to a VASP endpoint.
- Delivery: encrypted API exchanges with acknowledgements and error codes; retry queues for timeouts.
- Screening: sanctions and blockchain analytics pre-checks before you send funds, not after.
A reliable approach is “pre-flight”: identify the beneficiary VASP and exchange data, receive an OK, then broadcast the on-chain transaction. If discovery fails, keep the transfer in a pending state and ask the user for more details before money moves.
UX patterns that reduce drop-off
Compliance can feel heavy. Thoughtful microcopy and timing turn it into a quick checkpoint instead of a hard stop. Aim for clarity, not legalese.
- Collect once, reuse often: save verified self-hosted wallets and beneficiary details; let users pick from favorites.
- Inline validation: show which field is missing and why it’s required (“We need a date of birth to meet international transfer rules”).
- Pre-flight confirmation: “We found Beneficiary VASP: BlueExchange EU. Data verified. Ready to send?”
- Soft holds with timers: display a countdown when awaiting the counterparty’s acknowledgement.
- Privacy notice at point-of-collection: concise, jurisdiction-aware consent that fits on a single screen.
Tiny example of effective copy: “Travel Rule check: we share your name and account ID with the receiving exchange to process this transfer. Nothing goes on-chain. Learn more.” Short, factual, and reassuring.
Handling failures and edge cases
Failures happen: the counterparty is offline, data mismatches, or the address belongs to a self-hosted wallet you can’t verify yet. Build graceful exits.
- Counterparty unreachable: queue retries, notify the user, and provide a cancel option that restores their balance.
- Data mismatch: show the exact mismatch (e.g., name doesn’t match account) and a one-tap way to edit or upload proof.
- Self-hosted unknown: offer ownership verification flows or route to a smaller threshold-limited transfer if permitted.
- Sanctions hit: block, provide a neutral notice, and surface a support channel with no sensitive detail.
Record the final state of each failed attempt with timestamps and error codes. It speeds audits and triage when regulators or partners ask questions months later.
Metrics and testing
Measure the Travel Rule like a funnel. If you can see where users stall, you can unstick them with better defaults and smarter prompts.
- Track time-to-ack from counterparty VASPs and set SLOs per region.
- Monitor drop-off by field, device, and language to refine forms.
- AB-test microcopy on consent screens and error modals.
- Segment by first-time vs repeat beneficiaries; prioritize favorites in UI.
- Audit weekly: random-sample message logs for completeness and schema drift.
Compliance and UX aren’t opposites. When data fields are clear, self-hosted wallet flows are verified once and reused, and messaging is reliable, transfers feel fast and predictable while meeting the letter of the rule.
