Travel Rule Protocol primary sources — 2026-05-01

Project status in this pass

• No canonical standalone whitepaper or litepaper surfaced.
• The clearest current source of truth was the docs portal’s raw markdown export plus the official marketing site.

Primary-source snapshots

1) Official homepage

• URL: https://travel-rule.com/
• Key excerpts/signals:
  • Describes TRP as a “Crypto Travel Rule Compliance Provider for Global VASPs.”
  • Says it offers “Global, Interoperable, and Instant Compliance for All Jurisdictions” through “a single API.”
  • Frames the product around decoupling Travel Rule compliance logic from application code so compliance teams can stay operational across markets.
  • Explicitly positions the product against EU MiCA/TFR, US FinCEN expectations, and broader APAC/global Travel Rule enforcement.
• Why it mattered:
  • The homepage makes clear that TRP wants to be understood as a reusable compliance-and-routing layer, not as a one-off advisory service.

2) Docs hub / raw markdown index

• URLs:
  • https://docs.travel-rule.com/
  • https://docs.travel-rule.com/index.html.md
• Key excerpts/signals:
  • Says the public endpoints are part of the Travel Rule Protocol Registry API.
  • Says the endpoints allow third-party systems and VASPs to discover, identify, and register participants in the TRP network.
  • Says the API follows REST conventions, returns JSON, and should be used over HTTPS.
• Why it mattered:
  • This is the clearest first-party evidence that TRP includes a network-discovery / participant-registry layer instead of only point-to-point messaging.

3) API workflow overview

• Source: https://docs.travel-rule.com/index.html.md
• Key excerpts/signals:
  • Says the TRP API enables VASPs to authenticate using API keys, generate unique Travel Addresses for beneficiaries, initiate Travel Rule transfers, exchange originator and beneficiary data securely, and receive callback notifications during verification.
  • Says TRP follows FATF and IVMS101 standards and uses secure, encrypted communication between VASPs.
  • Summarizes the integration flow as: request JWT token → generate Travel Address → initiate transfer with IVMS101-compliant data → receive callback updates.
• Why it mattered:
  • This page provides the best compact view of the operational sequence and makes the callback-driven backend integration model explicit.

4) Authentication model

• Source: https://docs.travel-rule.com/index.html.md
• Key excerpts/signals:
  • Says protected endpoints require generating a JWT access token using an API key.
  • Says the access token has a one-hour TTL.
  • Says the authentication step is meant to secure API access, verify VASP identity, track API usage, and authorize Travel Rule transfer initiation.
• Why it mattered:
  • The TTL and verification language show that TRP is packaging identity, access control, and auditability as part of the network protocol surface.

5) Travel Address model

• Source: https://docs.travel-rule.com/index.html.md
• Key excerpts/signals:
  • Describes a Travel Address as a unique identifier for the beneficiary VASP.
  • Says it acts like a routing code that tells TRP where to deliver IVMS101 beneficiary data.
  • Says generating it only requires beneficiary first and last name, and that no sensitive data is exposed.
• Why it mattered:
  • This is the cleanest clue that TRP is building a beneficiary-routing abstraction, not only a generic payload relay.

6) Transfer request lifecycle

• Source: https://docs.travel-rule.com/index.html.md
• Key excerpts/signals:
  • Says a transfer request includes originator data, beneficiary data, asset and amount, Travel Address, and callback URL.
  • Says TRP validates IVMS101 originator and beneficiary data, identifies the beneficiary VASP via Travel Address, forwards the data securely, waits for the beneficiary’s decision, and sends callback notifications to the initiating backend.
• Why it mattered:
  • This is the strongest first-party evidence that TRP is an operational Travel Rule workflow engine spanning validation, routing, counterparty response handling, and backend notification.

Working conclusion

Travel Rule Protocol is best cataloged as Travel Rule interoperability and routing infrastructure for VASPs. The most important signal in this pass was the docs portal’s explicit workflow: authenticated VASPs generate Travel Addresses, submit IVMS101-compliant transfer requests, and receive callback-based state updates as TRP handles routing and counterparty coordination.