How to Implement Travel Rule: 8-Step Integration Blueprint

Travel Rule integration is an operational system build that plugs into existing customer data, transfer flow and counterparty ecosystem. It is not "call an endpoint, send a message" — it requires end-to-end design from protocol selection to sunrise fallback policy, from monitoring to regulator reporting. This guide presents a from-scratch 8-step blueprint for a VASP.

Our FATF Travel Rule guide gives the regulatory background and big picture; this article focuses on the build side.

Step 1: Protocol selection — Which one(s), and why?

Binding to a single protocol is insufficient. Modern Travel Rule infrastructure runs multi-protocol orchestration. Selection criteria:

• Counterparty market mix: EU-centric operations encounter TRP frequently; US-focused operations see TRISA more often; Asian counterparties often run Sygna Bridge.
• Operational maturity: TRP is REST-based, easy to debug. TRISA uses gRPC + mTLS — stronger security but higher operational complexity. Sygna comes with a commercial product layer.
• Ecosystem trust: Once you select a directory service (Notabene, Sumsub, Veriscope, etc.), the protocols that directory supports shape your default mix.

Practical recommendation: support TRP + Sygna + TRISA; route dynamically based on counterparty capability check. Single-protocol = self-imposed sunrise gap expansion.

Step 2: Counterparty VASP discovery

You cannot generate a message without knowing where to send it. Two discovery approaches:

Directory service integration

Third-party directory:

• Notabene: largest VASP directory, commercial, comprehensive capability data.
• Sumsub Travel Rule: KYC + Travel Rule integrated.
• Veriscope: independent directory.
• TRISA Global Directory Service (GDS): open-source, TRISA-specific.

Maintaining your own directory

Keeping the counterparty VASP list up to date in-house (from regulator lists + bilateral discovery). High operational burden, but pragmatic for national counterparties (e.g. FCA-registered list in the UK).

Hybrid approach: 3rd-party directory as primary, internal list for fallback and enrichment.

Step 3: IVMS 101 mapping

As covered in our IVMS 101 standard guide, mapping existing KYC data into IVMS 101 fields is harder than expected — particularly with multi-country customer bases.

Mapping checklist:

• Name: are primaryIdentifier and secondaryIdentifier correctly separated? (Watch multi-name cases.)
• Address: is AddressType correctly coded (HOME vs BIZZ)?
• National ID: passport → PASS; driver's license → DRLC; national ID → NIDN. Country code accordingly.
• Place of birth: city name + country code in separate fields.
• Wallet address: account number in valid format (with checksum where applicable).
• Customer ID: customerIdentification with the internal ID.

Recommendation: isolate mapping code into a separate module. Maintain high test coverage. Integrate a schema validator (IVMS 101 JSON schema is open).

Step 4: Transfer-time orchestration

When a transfer is initiated, the system flow:

1. Threshold check: is the transfer amount above the Travel Rule threshold? (Differs by EU/UK/Turkey.)
2. Counterparty discovery: query the directory to identify which VASP owns the recipient wallet address.
3. Capability check: which protocols does the counterparty support? Which IVMS 101 version?
4. Message creation: invoke IVMS 101 mapping, generate JSON payload, schema validate.
5. Transmission: send the message via the chosen protocol.
6. Response wait: sync or async depending on protocol; TRP uses an async ack pattern.
7. Decision: if response received, proceed or hold based on policy.

If this flow is synchronous-blocking, transfer latency spikes — production systems use async event-driven architecture (e.g. transfer queue + Travel Rule worker + result callback).

Step 5: Sunrise fallback policy

As covered in our sunrise problem guide, the policy choices:

• Reject policy: if counterparty cannot respond, reject the transfer. Aggressive.
• Hold + retain: generate IVMS 101 message, retain, wait for capability.
• Risk-based: dynamic policy based on amount + customer risk + counterparty risk triple.

The policy engine should be configurable via YAML/UI — requiring a code deployment for every policy tweak the compliance team needs is unacceptable. Example policy DSL:

- if: counterparty.capability == none && transfer.amount_usd < 1000
  then: retain_and_proceed
- if: counterparty.capability == none && transfer.amount_usd >= 1000
  then: hold_for_manual_review
- if: customer.risk_score == high
  then: hold_for_manual_review

Step 6: Error handling and retry logic

Travel Rule messages fail in several ways:

• Counterparty timeout: message transmitted but no response (network, downtime).
• Schema validation error: counterparty's IVMS 101 implementation rejected the message.
• Protocol negotiation fail: capability check was misleading; real protocol-level incompatibility.
• Authentication error: mTLS certificate issue (common with TRISA).

Each error type warrants a distinct retry policy: timeout → exponential backoff (1m, 5m, 30m, 2h, 6h); schema error → manual review (auto-retry useless); auth error → certificate rotation workflow.

A dead-letter queue is mandatory — no message should silently vanish. Compliance must have visibility into DLQ contents.

Step 7: Monitoring and KPI dashboard

Metrics to track:

• Message success rate (send + receive response): target ≥95%.
• Sunrise gap rate: percentage of counterparties without capability.
• Average message round-trip latency: <500ms expected (TRP/TRISA), Sygna may be slightly higher.
• Schema validation error rate: <2% target; exceeding it signals mapping bugs.
• Held transfer volume: sunrise fallback metric.
• Manual review queue depth: compliance team workload indicator.

Dashboards integrated with Grafana/Datadog/Prometheus — alerts should flow to compliance and engineering jointly.

Step 8: Regulator reporting

Reporting format and cadence vary by jurisdiction:

• EU: EBA-aligned national competent authorities (BaFin, AFM, MFSA, etc.) — TFR reporting standards expected to firm up through 2025.
• UK FCA: REP-CRIM reports (annual cryptoasset business report) cover Travel Rule effectiveness. JMLSG guidance details format.
• MASAK (Turkey): When KVHS comes into force, Travel Rule reporting format will firm up. For now, embedded in general AML reporting.

Reporting infrastructure:

• All messages on a timestamped, immutable log.
• Periodic export (PDF + CSV) — for fast audit response.
• Event-based reporting (e.g. persistently high Travel Rule rejection rate from a specific counterparty).
• Data retention period: minimum 5 years (up to 10 years by jurisdiction).

Aggregating steps onto a timeline

Typical integration durations for a mid-sized exchange:

Parallelization can compress this to 3–5 months; using a platform like Legichain typically brings it down to 4–8 weeks.

Frequently Asked Questions

Should I build in-house or use a vendor?

In-house: protocol changes (new versions, new protocols), counterparty directory maintenance, sunrise policy engine development — ongoing maintenance burden. Makes sense if team capacity is high and this expertise is strategic to your business. For most VASPs the vendor approach (Notabene, Sumsub, Legichain-class platforms) wins on both cost and time-to-market. Typical vendor integration 4–8 weeks; in-house build 6–9 months.

Can I test in a sandbox environment?

Yes — all major protocols offer sandbox/testnet. TRP testnet, TRISA test directory, Sygna sandbox. Practical recommendation: before going live, run real message flow tests with at least one test partner per counterparty category (EU exchange, UK exchange, Asian exchange, US exchange). Common gotchas when moving from sandbox to production: certificate rotation, endpoint changes, sandbox-specific parameters.

How long does adding a new protocol take?

With modular design, 2–4 weeks. Use a protocol adapter pattern — each protocol in its own adapter class, common interface (receive IVMS 101 message, send, receive response). New protocol = new adapter; business logic (IVMS mapping, policy engine, monitoring) is untouched. Making this separation up front is 5–10x cheaper than refactoring it in later.

What if multiple counterparties chain a transfer (multi-hop)?

Multi-hop transfers are rare but happen — particularly via aggregator brokers. Practically: each hop generates its own Travel Rule message. Your responsibility is only to your direct counterparty. Whether the aggregator carries Travel Rule data to its downstream counterparties is its responsibility, not yours — but if you transact heavily with high-risk aggregators, this should feed your due diligence.

What do I tell the customer when a transfer is held?

Transparent but legally cautious language. Don't avoid the term "Travel Rule compliance" — customer education benefits the industry. Sample text: "The receiving counterparty for this transfer does not yet support the required regulatory data sharing. Your transfer is on hold and will auto-complete once the counterparty acquires capability. Details at [link]." Avoid blaming the customer (it is a counterparty infrastructure issue, not the customer's).

How Legichain helps

Building the above 8 steps in-house takes 6–9 months; with Legichain's Travel Rule module you can be in production in 4–8 weeks. IVMS 101 mapping auto-runs over your existing digital KYC integration, multi-protocol support (TRP, Sygna, TRISA) is built in, counterparty directory (Notabene + our own) is bundled. The sunrise fallback policy engine is YAML-configurable, monitoring dashboards are ready out of the box, and reporting templates exist for FCA/EBA-aligned national authorities/MASAK. Sandbox access is on /en/travel-rule; you can test real message flow within 24 hours.

Next steps

• FATF Travel Rule guide — regulation and big picture.
• IVMS 101 data standard — deep technical detail on message mapping.
• Sunrise problem and fallback — Step 5 deep dive.
• Solutions for crypto exchanges — how the integration fits into exchange operations.