Category: Travel Rule compliance infrastructure / VASP interoperability registry API / IVMS101 routing and beneficiary-discovery layer
Summary: Travel Rule Protocol (TRP) is best cataloged as Travel Rule messaging-and-routing infrastructure rather than as a generic compliance consultancy or narrow KYC add-on. Its first-party materials combine a public registry API for discovering and identifying TRP participants, API-key and JWT-based VASP authentication, beneficiary-side Travel Address generation, IVMS101-compliant transfer initiation, secure originator/beneficiary data exchange, and callback-driven status updates. The product is especially notable because it appears to decouple transfer-compliance routing logic into a single API surface that VASPs can plug into across MiCA, FinCEN, and broader global Travel Rule regimes.
What it does:
Provides a public TRP Registry API that lets third-party systems and VASPs discover, identify, and register participants in the TRP network
Authenticates VASPs through API keys and short-lived JWT access tokens before protected operations are allowed
Generates Travel Addresses that act as beneficiary-side routing identifiers for where IVMS101 data should be delivered
Accepts Travel Rule transfer requests containing originator data, beneficiary data, asset and amount details, a Travel Address, and a callback URL
Validates IVMS101 payloads, determines the beneficiary VASP from the Travel Address, forwards the data securely, waits for the counterparty decision, and sends callback updates back to the initiating backend
Positions the same integration surface as usable across EU MiCA/TFR, US FinCEN expectations, and broader APAC/global Travel Rule enforcement environments
Key claims:
The homepage says TRP is a crypto Travel Rule compliance provider for global VASPs that offers “Global, Interoperable, and Instant Compliance for All Jurisdictions” through “a single API”
The homepage frames TRP as a way to decouple Travel Rule compliance logic from application code so compliance teams can stay operational across markets without adding transfer friction
The docs say the public API is meant for third-party systems and VASPs to discover, identify, and register participants in the TRP network, and that it follows REST conventions over HTTPS with JSON responses
The docs say the TRP API enables VASPs to authenticate using API keys, generate Travel Addresses, initiate Travel Rule transfers, exchange originator and beneficiary data securely, and receive callback notifications during verification
The docs say access tokens are short-lived JWTs with a one-hour TTL, which is a useful signal that TRP treats authenticated session control as a first-class part of the workflow rather than as a static API-key-only integration
The docs say a Travel Address is generated from beneficiary first and last name only, acts like a routing code for where IVMS101 data should be delivered, and is intended to reduce sensitive-data exposure and manual-entry risk
The docs say transfer requests include originator data, beneficiary data, asset and amount, Travel Address, and callback URL, after which TRP validates IVMS101 data, identifies the beneficiary VASP, routes the payload securely, waits for the beneficiary decision, and sends callback notifications to the initiator
Whitepaper: No canonical standalone Travel Rule Protocol whitepaper or litepaper surfaced in this pass. The clearest current sources of truth were the official homepage and the docs portal’s raw markdown index; see ../whitepapers/travel-rule-protocol-primary-sources-2026-05-01.md.