Travel Rule Networks

A Travel Rule exchange reaches the counterparty VASP over one rail. Three rails need no membership of anyone: INTERNAL between two Didit customers, the open Travel Rule Protocol (TRP), and EMAIL. The four network rails (GTR, TRUST, VERIFYVASP, SYGNA) need a membership of that network on the sending side. This page says what each one does today, so you know where your counterparties are reachable before you depend on a route.

​

Status at a glance

“Works” means Didit sends the exchange and reads the answer. “Implemented, not yet proven live” means Didit sends the exchange and reads the network’s answer, but no exchange over that network has completed against a live network yet. Neither ever means a given counterparty is reachable: that depends on the counterparty, and the directory routes of each VASP say which rails your application can use for it today. EMAIL only carries your outbound requests: the response page is where a counterparty answers one of them, and no VASP can send you a transfer by email. Before you rely on GTR, VerifyVASP, Sygna Bridge or TRUST, connect your membership and run a first exchange with a counterparty you know.

​

Rails that need no membership

​

INTERNAL

Both VASPs run on Didit, so the exchange settles inside the platform with no outbound call. The recipient must be a live Didit customer with Travel Rule on that proved control of the destination wallet with a signed message or a test deposit. A self-declared, screenshot-only or unverified wallet receives nothing. See Sending a transfer.

​

TRP

Didit speaks the Travel Rule Protocol natively. A transfer goes over TRP when it carries the counterparty’s travel address, the destination wallet’s address-book entry stores one, or the counterparty resolves in the directory with a TRP endpoint the directory verified. Every TRP exchange that does not finish in a single call needs Didit’s public TRP host, the one travel addresses point at:

• Sending. A counterparty that answers your inquiry at once, in its response, completes or declines the transfer. A counterparty that answers later posts its answer to Didit’s TRP host, so that exchange cannot complete until the host is live; the transfer waits and expires at its deadline. Didit sends the inquiry once and does not retry it: when the counterparty’s TRP host cannot be reached or refuses the inquiry, the transfer becomes COUNTERPARTY_VASP_NOT_REACHABLE at once, and you can retry it with action: "resend".
• Receiving. Other VASPs reach you at your travel address on that host, so no counterparty can send you a TRP inquiry until it is live.

Didit’s public TRP host does not serve these endpoints yet. Travel Rule interoperability documents the endpoints counterparties call once it does.

​

EMAIL

When no protocol reaches the counterparty, Didit emails its compliance addresses a one-time link to a hosted page where they accept or decline. No account or integration is needed on their side. See Email pickup.

​

Network rails

​

With your own membership

Connect your own membership in the console Marketplace (Travel Rule networks category). Your transfers then travel under your own network identity, and a connected membership always takes precedence over Didit’s. GTR, TRUST and VerifyVASP also take an optional mutual TLS client certificate, client key and CA bundle (PEM), for a membership that uses mutual TLS or a private CA.

• Didit sends in the background and retries a network that does not answer, or answers with a temporary failure (no answer in time, a failed connection, HTTP 408, 429 or 5xx): after 30 seconds, then 2, 10, 30 and 60 minutes. After the sixth failed attempt the transfer becomes COUNTERPARTY_VASP_NOT_REACHABLE. A refusal, such as another 4xx answer or a redirect, is not retried: the transfer becomes COUNTERPARTY_VASP_NOT_REACHABLE at once.
• A transfer whose answer never arrives waits in AWAITING_COUNTERPARTY until confirmation_timeout_hours passes, then expires and applies your timeout_outcome.
• Receiving a transfer that another VASP sends you over GTR, VerifyVASP or Sygna Bridge is not switched on yet: Didit switches it on per network, and until then those networks cannot deliver a transfer to you.
• Saving a membership answers 400 when its participant code is Didit’s own code on that network, or a code another application already holds.
• Network requests carry your credentials only to that network’s own host and never follow a redirect. The TRUST data packet goes to the beneficiary without your API key, member ID or client certificate.

​

Through Didit’s membership

Once Didit holds a network membership, a customer without one can reach the network as its own participant on Didit’s membership, with the participant code the network gives it: outbound messages name your code, never Didit’s. This is offered for GTR and Sygna Bridge only. TRUST admits members one VASP at a time and a VerifyVASP Enclave serves one VASP, so both are reached with your own membership only. Joining takes three steps: answer Didit’s network due-diligence questionnaire, have Didit approve it, then request the network. Didit registers you with the network, and your participant becomes active once the network gives it a code. This flow is not open yet. Until it is, saving or submitting the questionnaire and requesting a network answer 403 with code: travel_rule_platform_networks_disabled, and GET /v3/travel-rule/networks/ reports platform_networks_enabled: false.

​

Reading your application’s status

GET /v3/travel-rule/settings/ and GET /v3/travel-rule/networks/ return networks, keyed by gtr, trust, verifyvasp and sygna. Each entry says what the network can do for your application today: mode sums the state up as own, didit, off or unavailable. Your own membership is checked first, then disabled_networks, then Didit’s membership. Today a network reads own_membership once you connect your own membership. Otherwise GTR and Sygna Bridge read didit_onboarding (unavailable with sandbox_application on a sandbox application), and TRUST and VerifyVASP read unavailable with own_membership_only, in sandbox too. A sandbox application never sends over a network, even with your own membership connected and reading own_membership: its transfers go to the Didit Test VASP. connected means your saved membership passed local validation, not that an exchange succeeded. The first live exchange proves it against the network.

​

What changes when a network goes live

This page, the networks status and every directory route change together. Nothing changes in your integration: a transfer starts routing over the network as soon as your application has a membership on it, in the rail order described in How Didit routes an exchange. To ask for a network Didit does not reach yet, use its Request access tile in the Marketplace. Each request shows its status (Open, Contacted, In progress, Live or Declined) with Didit’s latest note. When Didit changes the status or the note, it emails the teammate who made the request, while they are still in your organization. A request made with an API key gets no email, so follow it in the Marketplace.

​

Next steps