Travel Rule for crypto payments

1) What is the Travel Rule and why is it needed

Travel Rule is a regulatory requirement for virtual asset providers (VASPs) to exchange sender and recipient identities when transferring crypto assets. The goal: to reduce AML/CTF risks, simplify investigations and increase the transparency of cross-VASP transfers, while maintaining the operability of the online infrastructure.

• The data "travels" with the translation (off-chain communication channel VASP↔VASP).
• Requirements and thresholds vary by jurisdiction; often the threshold is close to ~ 1000 (equivalent), but in a number of modes it applies to smaller amounts - fix the local norm in your policy.
• Requirements distinguish between hosted (custodial) and unhosted (independent) wallets.

2) Objects and areas of application

VASP → VASP (hosted ↔ hosted): full exchange of data according to the standard (preferably before online broadcast).

VASP → Unhosted: collection/verification of information about the addressee and origin of funds under the local RBA policy; there is no exchange with the "counterparty-VASP."

Cross-border: Use Discovery/Directory and trust agreements to find a counterparty and secure channel.

3) What data is transmitted (minimum composition)

• Name (or name. company), unique identifier of the customer (from your system),
• Address/country or date of birth (country-specific),
• Account/wallet number (internal ID/address),
• Contacts (if required), VASP ID (LEI/BIC/Reg. number - where applicable).

• Name (if the recipient is in another VASP and verified),
• Account/Wallet ID at beneficiary-VASP,
• When unhosted - information collected from the client according to your RBA policy.

• Asset/network (BTC, ETH/chain), amount, timestamp,
• Payment/Transfer ID, reference for TAC/sanction screening,
• ID of the Travel Rule session/message.

4) Exchange standards and protocols

IVMS101 - data model (what and how to name).
TRISA/TRP/OpenVASP - network protocols and "trust networks" (PKI, mTLS, VASP directories, routing, delivery confirmation).
Commercial hubs/aggregators can implement interoperability (Gateway approach) and Discovery.

Recommendation: abstract the transport (Adapter layer) and store IVMS101 as a "canonical model" in order to freely change the provider/protocol without breaking the API.

5) Implementation architecture (reference)

1. Travel Rule Gateway (microservice): receiving/sending IVMS101 messages, signature/encryption, retrays, quotas.

2. Directory/Discovery: search for counter-VASP (registry, PKI, trust policy).

3. KYT/Sanctions Engine: address/exchange/cluster screening, pre-shipment risk assessment.

4. Compliance Engine (RBA): allow/hold/reject/request for additional data.

5. Case Management: cases, attachments, SLAs, escalations (L1/L2/L3).

6. PII Vault: secure storage of personal data (encryption, tokenization, RBAC, audit).

1. The client creates a transfer → 2) TAC/pre-check sanctions → 3) Counterparty discovery → 4) Exchange of IVMS101 (before onchen) → 5) Decision (allow/hold) → 6) Onchein-broadcast → 7) Post-factum reporting/logging.

6) Unhosted wallets: politics and checks

Collection of information about the counterparty from the client (name/country/relation), confirmation of ownership of the address (signature with a message, small "proof transfer," verification on the exchange).
Risk rules: ban/limits for addresses with high KYT risk (mixers, "dark" markets, sanctions clusters), ban P2P sites without KYC according to your policy.
Address book/whitelisting with TTL and review.

7) Integration with TAC/Sanctions and AML

KYT (Know Your Transaction): risk assessment of addresses/exchanges, connections to N-hops with "bad" clusters, volume/route anomalies.
Sanctions: client/counterparty screening (KYC/KYB) and infrastructure (exchanges, custodians).
Positive risk → hold, document request (SoF/SoW) and/or rejection, if necessary - SAR/STR.

8) Data and privacy (GDPR/security)

Minimization: keep only the required Travel Rule fields; Separate the PII from the payment PANs/keys.
Encryption: at rest (KMS/HSM) and in transit (mTLS), key rotation.
Access: strict RBAC, action log, need-to-know principle.
Retention: by law of jurisdiction (often 5 + years); automatic expiration and deletion reports.
DSR: access/remediation/deletion procedures where applicable.

9) SLA, Retrays and Degradation

• Pre-check (KUT/sanctions): ≤ 5-15 c p95.
• Discovery + Exchange (VASP↔VASP): ≤ 60-120 c p95 (including retrays).
• Solution (allow/hold/reject): ≤ 2-5 min p95 for auto cases; manual review High-risk - ≤ 4 hours.

• Exponential backoff + jitter; alternative endpoints.
• Sunrise problem (counterparty does not support Travel Rule): RBA exceptions/limits, manual exchange over encrypted channel (if allowed by policy/law) or refusal.

10) UX patterns (not breaking conversion)

Prepopulation of recipient data for frequent transfers (address book).

Clear messages: "Address confirmation required "/" Recipient data needed to comply with rule."

Context checks (address signature, micro-translation) with step-by-step prompts.
Statuses and hold/check timers, transparent waits.
Alternatives: "Get on the stock exchange with KYC" if unhosted fails.

11) Metrics and quality control

• Travel Rule coverage% (the share of VASP↔VASP transfers with a successful exchange IVMS101).
• Share of unhosted with passed address verification and SoF (by threshold).
• SLA hit rate by exchange/solutions; share of manual cases.

• KYT high-risk rate, sanctions refusals, SAR-conversion.
• Repeated alerts by addresses/clusters, share "false positive" by KYT.

• Time to transfer p50/p95, refusal due to Travel Rule (impact), conversion of repeated transfers (address book).

12) Decision matrix (sketch)

13) Anti-patterns

Sending online before the end of the VASP↔VASP data exchange (in modes where it is required before translation).
"Deaf" blocking of all unhosted without RBA exceptions and address verification.
Lack of Discovery/Directory → unstable delivery and frequent false hold.
Storage of redundant PII without target/retension; undivided logs and PII.
A rigid tie for one protocol provider without abstraction (vendor lock-in).

14) Implementation checklist

• Travel Rule policy: jurisdictions, thresholds, hosted/unhosted, RBA exceptions.
• Canonical IVMS101 model and Adapter layer under TRISA/TRP/OpenVASP.
• Directory/Discovery и PKI/mTLS; trusted VASP management.
• Integration of TAC/sanctions into pre-check; hold/reject rules.
• PII Vault: encryption, RBAC, auditing, retention/DSR.
• SLA/retrays/alerts, dashboards of metrics; degradation playbooks.
• Processes for unhosted: address verification, SoF requests, whitelisting.
• Case management and communication templates; SAR/STR procedures.
• Test benches: emulation of a VASP counterparty, failure scripts, load test.
• Payments/Risk/Compliance/Support training and regular drills.

15) Summary

Travel Rule is not "about crypt," but about operational-secure data exchange between VASP. Build a gateway with IVMS101 as a canonical model, connect Discovery/Directory, integrate TAC/sanctions and RBA solutions, protect PII and specify understandable SLAs. Then VASP↔VASP transfers and working with unhosted addresses will be fast, compliant and will not destroy the conversion.