How to Implement Travel Rule Messaging on a Crypto Exchange (VASP Go-Live Checklist)
Your withdrawal engine is live, but Travel Rule messaging is not. Supervisors expect VASPs (crypto platforms that hold or transfer virtual assets for customers) to send verified sender and receiver data with in-scope transfers. Use this go-live checklist to map thresholds, freeze an IVMS101 field contract, pick a multi-protocol stack, wire VASP discovery plus sunrise and unhosted branches, then enforce go / hold / reject before broadcast and monitor the first 30 days.
TL;DR / Quick insight: Travel Rule messaging is not “another KYC form.” It is a near-time data envelope that must travel with the transfer. Freeze IVMS101 fields from KYC first, choose a primary protocol plus a bridge for coverage, code sunrise and unhosted branches, and never broadcast when required fields or a valid counterparty path are missing. Treat overnight batch-only messaging as a control gap unless counsel says otherwise.
This guide covers messaging ops – not a full KYC/AML redesign. Onboarding must already produce verified fields; if not, fix that via the KYC / KYB / AML guide, then return here. Thresholds differ by market – confirm with counsel. Not legal advice.
1. Map thresholds, fields, and jurisdiction triggers
Start with a corridor matrix, not a vendor demo. List every market you serve and write the Travel Rule trigger: FATF-style guidance often cites USD/EUR 1,000, while the EU Transfer of Funds Regulation (TFR, Reg. 2023/1113) applies Travel Rule-style rules to crypto-asset transfers involving Union CASPs with a practical €0 floor for crypto (unlike the €1,000 fiat floor). Full TFR application is widely described from 30 December 2024.
| Corridor example | Typical trigger (verify locally) | Freeze in policy |
|---|---|---|
| FATF baseline framing | Often cited at USD/EUR 1,000 | Fields + when messaging fires |
| EU TFR (crypto) | €0 practical threshold | Full originator/beneficiary data |
| Other 2026 waves | e.g. Australia reported from 1 July 2026 | Go-live date + local field set |
Originator data usually includes verified name, account or wallet ID, and address or an allowed alternate (national ID, customer ID, or date/place of birth). Thresholds are per transfer; structuring below the line is an AML red flag.
Do: get compliance to sign the matrix before engineering picks a protocol. Don’t: hard-code one global $1,000 rule for an EU-facing book.
2. Choose the messaging stack: IVMS101 plus protocols
Two layers. IVMS101 (IVMS 101.2023) is the shared data model – the “form fields” for originator and beneficiary. It is a payload schema, not a network. Protocols carry that payload. Open examples: TRISA, OpenVASP/TRP (HTTPS/JSON with mTLS and Travel Address discovery), VerifyVASP; closed vendor hubs also exist. In 2026 no single protocol covers every counterparty – plan primary plus bridge.
| Layer | What it is | Operator takeaway |
|---|---|---|
| IVMS101 / 101.2023 | Data schema for Travel Rule fields | Canonical payload KYC → outbound message |
| TRISA | Messaging with directory/federation patterns | Strong when partners already use TRISA |
| OpenVASP / TRP | Open P2P over HTTPS/JSON + mTLS | Travel Address discovery; bridges toward TRISA exist |
- Confirm KYC stores every IVMS-required verified field; stop if gaps remain.
- Freeze IVMS101.2023 as the canonical outbound schema.
- Pick a primary protocol from top counterparties by volume.
- Add a multi-protocol bridge so one missing network does not strand withdrawals.
- Document routing: VASP ID → protocol → credentials → fallback.
- Prove staging credentials: API keys, callbacks, public keys, IP allowlists, PII prefs.
Do: treat protocol choice as coverage. Don’t: lock one brand after a single demo. Need a branded stack with compliance hooks faster than a custom rebuild? Review White Label Exchange – still validate messaging ownership.
3. Wire VASP discovery, sunrise, and unhosted branches
VASP discovery finds who is on the other side: protocol directories (e.g. TRISA GDS-style lookups), vendor directories, analytics attribution, customer declaration (weakest). Keep a counterparty register: legal name, licence status, protocol, last outcomes.
The sunrise problem means you are live under Travel Rule but the counterparty cannot receive messages yet. FATF-aligned practice still expects collect, attempt, and documented risk measures.
An unhosted wallet (self-hosted) has no counterparty VASP to message. FATF expects VASPs to collect required info even then. EU secondary guidance often points to ownership checks above about EUR 1,000 – confirm with counsel.
Decision workflow: In-scope withdrawal → identify counterparty → hosted VASP with live protocol → send IVMS + await ack → sunrise → collect, retain, attempt, risk-rate, document → unhosted → ownership/EDD, screen, retain → go or hold.
Do: code sunrise and unhosted as first-class branches. Don’t: trust “customer said it is an exchange” without directory or analytics corroboration.
4. Pre-broadcast controls: go, hold, reject, sanctions, audit
Messaging must sit before chain broadcast. Practice expects near-time transmission – overnight batch-only queues are widely treated as a gap.
- Sanctions-screen originator, beneficiary, and counterparty VASP.
- Build the IVMS101 payload from verified KYC fields only.
- Resolve discovery and choose the protocol route.
- Send the Travel Rule message; apply ack / timeout policy.
- Decide go (broadcast), hold (ops queue), or reject (fail closed with a clear user reason).
- Never broadcast when required fields or a valid counterparty path are missing.
- Write an immutable audit record: metadata, decision, screener result, timestamps.
- Retain typically 5–7 years unless local law differs; test a supervisory export.
Encrypt PII in transit and at rest. Hold queues need operator UX – pair stalled withdrawals with customer dispute handling.
Do: fail closed on a missing Travel Rule path. Don’t: “send later” after coins left the hot wallet.
5. Go-live checklist and first-30-days monitoring
Before production:
- Jurisdiction threshold matrix signed by compliance
- IVMS101.2023 field mapping from KYC → outbound message
- Primary + secondary protocol/bridge credentials in staging
- Counterparty register seeded with top corridors by volume
- Sunrise policy written (collect / attempt / EDD / block)
- Unhosted ownership flow tested (signature / micro-tx / analytics)
- Sanctions lists on originator, beneficiary, counterparty VASP
- Hold queue + reject reasons + user messaging UX
- Audit export tested for a supervisory sample
- PoC messages with at least 3–5 protocol-diverse VASPs
- On-call runbook for timeouts and failed acks
First 30 days: track ack rate; sunrise/unhosted exceptions; failed discoveries weekly; false-positive holds with the MLRO; retention backups; escalate SAR/STR when messages surface suspicion.
Launching the whole venue? See how to start a crypto exchange, then keep this checklist as the withdrawal gate.
What to do next
- Export markets into a one-page threshold matrix; get a compliance signature.
- Diff KYC fields against IVMS101.2023; ticket every gap.
- Shortlist primary + bridge paths from your top five counterparties.
- Schedule a PoC with 3–5 real VASPs across different protocols.
- Wire go / hold / reject in staging; run a timeout drill before production.
More playbooks: the White Label Exchange blog.
Material reviewed: White Label Exchange Editorial.
Data note: Thresholds, IVMS101.2023, EU TFR (Reg. 2023/1113), protocol roles, sunrise/unhosted practice, retention, and PoC guidance attributed to FATF, EUR-Lex, interVASP, OpenVASP/TRISA docs, and 2026 industry checklists (research notes, 18 July 2026). Wordstat: “travel rule” = 249/mo; EN long-tail and IVMS101 EMPTY/PARTIAL – no fabricated volumes. Not legal advice.
Frequently asked questions
What is the Travel Rule for crypto exchanges?
VASPs/CASPs must obtain, hold, and transmit verified originator and beneficiary info with in-scope virtual-asset transfers (FATF R.16 framing). Local thresholds differ; EU TFR is stricter for crypto (€0 practical floor). Map corridors before you code.
TRISA vs OpenVASP – which should you pick?
Pick from your counterparty graph. TRISA fits directory/federation patterns; OpenVASP/TRP is open P2P over HTTPS/JSON with Travel Address discovery. Most exchanges need a hub or bridge – one protocol will not cover every partner.
How do you handle unhosted wallet transfers under Travel Rule?
Branch the flow: no VASP to message. Collect required data, apply ownership verification and EDD per local rules (EU practice often tightens above about EUR 1,000), screen sanctions, and retain evidence before release.
What is the sunrise problem?
You must comply, but the counterparty cannot receive messages yet. Still collect and attempt transmission, apply written risk measures, and log the attempt – do not treat “they cannot receive” as a free pass.
Is IVMS101 a messaging network?
No. IVMS101 is the data schema for fields inside the message. TRISA, OpenVASP/TRP, and vendor networks are the transport.
Can we batch Travel Rule messages overnight?
Practice expects near-time transmission with the transfer. Treat batch-only as a control gap unless counsel confirms a jurisdiction-specific exception – and keep an audit trail of delays.
Where does KYC fit into Travel Rule messaging?
KYC must already produce verified IVMS fields. Messaging cannot invent a legal name that onboarding never captured. Fix the field contract first, then connect protocols.