Travel Rule Data Exchange: TRISA, TRP & OpenVASP

Strip the FATF Travel Rule down to its mechanics and it's a messaging problem. Before a crypto transfer settles, the sending VASP has to hand the receiving VASP a structured packet describing the originator and the beneficiary — name, identifiers, account references — and the receiving side has to acknowledge it. The catch is that there's no single global rail for that handshake. Instead there are competing interoperability protocols, and a transfer succeeds only when both VASPs can speak one of them.

Didit runs that handshake for you. Travel Rule data exchange is built into Transaction Monitoring, and the engine speaks the three protocols VASPs actually use in production — TRISA, TRP, and OpenVASP. You send the transfer once; the engine resolves the counterparty, picks a protocol both sides support, exchanges the originator and beneficiary payloads, and tracks the obligation to a status. This guide explains the protocols, the payloads, and how the exchange runs.

Key takeaways

• The Travel Rule is a VASP-to-VASP data exchange. The sender transmits originator and beneficiary information; the receiver collects and confirms it.
• Three protocols carry that exchange — TRISA, TRP, and OpenVASP — each with a different trust and transport model. Didit supports all three.
• The payload is the originator and beneficiary record — the parties to the transfer, structured so both VASPs read the same fields.
• Didit runs the exchange inside Transaction Monitoring, resolving each obligation to one of six statuses (UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED, EXEMPT).
• One /v3/ API. Crypto transfers post to POST https://verification.didit.me/v3/transactions/ with currency_kind: "crypto", and wallet screening runs alongside from $0.02 (bring-your-own-key).

What the protocols do

All three protocols solve the same two problems — how do I find and trust the counterparty VASP? and how do I securely send it the customer data? — but they make different trade-offs.

• TRISA (Travel Rule Information Sharing Architecture) is a peer-to-peer model built on a certificate authority. VASPs enrol, prove their identity, and receive certificates, then exchange data directly over an encrypted channel. Trust is anchored in the directory of verified members.
• TRP (Travel Rule Protocol) is an API-first specification favored by a group of larger institutions. It defines a lightweight REST handshake for sending the originator and beneficiary payload between counterparties that have established a connection.
• OpenVASP is an open standard that uses on-chain and messaging-layer signaling to establish a session between VASPs before the transfer, then exchanges the customer data off-chain.

A VASP that wants broad reach has to support more than one, because its counterparties won't all be on the same protocol. Running the exchange inside Didit means you don't pick one and hope — the engine negotiates whichever protocol the counterparty supports.

Why it matters

Under FATF Recommendation 16 and its regional implementations — the EU Transfer of Funds Regulation chief among them — the originator and beneficiary data exchange is mandatory above the threshold, and supervisors examine for it. But the requirement is written in terms of outcomes (the data must be transmitted, held, and confirmed), not protocols. The protocol fragmentation is an engineering reality you inherit, not a rule you can read your way out of.

That's exactly why protocol support shouldn't be your problem to build. Standing up TRISA enrolment, a TRP endpoint, and OpenVASP signaling — and keeping all three current — is a standing engineering cost that has nothing to do with your product. Folding it into the same monitoring engine that already scores the transfer collapses that cost into one integration.

Technical details

The transfer is created against the unified /v3/ API. The originator is the subject, the beneficiary is the counterparty, and currency_kind: "crypto" triggers the Travel Rule and wallet-screening paths.

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_7b9e22",
    "category": "travel_rule",
    "amount": 12500,
    "currency": "BTC",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "txn_date": "2026-05-21T12:14:00Z",
    "subject": {
      "vendor_data": "user_8830",
      "role": "ORIGINATOR",
      "entity_type": "INDIVIDUAL",
      "first_name": "Marta",
      "last_name": "Ferreira"
    },
    "counterparty": {
      "role": "BENEFICIARY",
      "entity_type": "INDIVIDUAL",
      "wallet_address": "bc1q...0a7k"
    }
  }'

The engine resolves the counterparty VASP, selects a supported protocol, exchanges the payload, and returns the protocol used plus the Travel Rule status:

{
  "transaction_id": "txn_7b9e22",
  "status": "APPROVED",
  "travel_rule_status": "COMPLIANT",
  "protocol": "TRP",
  "counterparty_vasp": "vasp_resolved",
  "wallet_screening": {
    "risk_score": 9,
    "risk_level": "LOW"
  }
}

The originator/beneficiary payload. Each transfer carries the two parties as structured records — the originator (the customer sending) and the beneficiary (the customer receiving) — so both VASPs map to the same fields regardless of protocol. The originator data is yours to supply from the KYC you already hold; the beneficiary side is confirmed by the counterparty during the exchange.

The six statuses. Whatever protocol carries the exchange, the obligation resolves to one status:

Status	Meaning
UNKNOWN	Not yet evaluated, or the counterparty VASP couldn't be resolved.
COMPLIANT	Data exchanged and confirmed — obligation met.
PENDING_ACTION	Something on your side is required to proceed.
PENDING_COUNTERPARTY	Waiting on the counterparty VASP to respond.
FAILED	The exchange couldn't complete — unreachable counterparty, rejected data, or protocol mismatch.
EXEMPT	Out of scope — below threshold or otherwise not obligated.

Wallet screening alongside. The counterparty address is screened on-chain in the same call from $0.02 per screening with bring-your-own-key (Crystal or Merkle Science), so a protocol-level COMPLIANT doesn't hide an address-level risk.

Choosing — and not choosing — a protocol

The practical guidance for a VASP is: don't choose. Your counterparties are spread across TRISA, TRP, and OpenVASP, and the protocol that gets a given transfer to COMPLIANT is whichever one that counterparty supports. Because Didit negotiates the protocol per transfer, your integration is the same regardless — you send the originator and beneficiary data once, and the engine handles the handshake. A FAILED status with a protocol mismatch is a signal to investigate the counterparty, not a gap in your stack.

Use cases

• VASPs and exchanges — reach counterparties across all three protocols from one integration, instead of building and maintaining each rail.
• On/off-ramps — exchange originator and beneficiary data with destination VASPs while screening the receiving wallet in the same call.
• Custodians — handle a long tail of counterparties on mixed protocols with a single, consistent status model.
• DeFi front-ends — perform the exchange where a regulated VASP sits in the flow, and resolve to EXEMPT where the obligation genuinely doesn't apply.

How to integrate with Didit

1. Enable the travel-rule rules. In the Business Console, switch on the preset travel-rule rules alongside crypto monitoring and crypto screening.
2. Send the transfer. POST /v3/transactions/ with currency_kind: "crypto", the originator as subject, the beneficiary as counterparty, and the travel_rule category.
3. Read the protocol and status. The response tells you which protocol carried the exchange and the resulting travel_rule_status. Act on PENDING_* and FAILED obligations.
4. Work exceptions in the Console. Pending and failed exchanges, alerts, and the case workflow live in the same surface as your monitoring.

It all runs on the unified /v3/ API, so the customer you onboarded with KYC, screened with AML, and now serve a transfer for is the same identity threaded through monitoring, wallet screening, and the Travel Rule.

Frequently asked questions

Which Travel Rule protocols does Didit support?

TRISA, TRP, and OpenVASP — the three protocols VASPs use in production. The engine negotiates whichever one a given counterparty supports.

What data gets exchanged?

The originator and beneficiary records — the parties to the transfer — structured so both VASPs read the same fields. You supply the originator from your existing KYC; the counterparty confirms the beneficiary side.

Do I have to pick one protocol?

No. Picking one would cut you off from counterparties on the others. Didit selects the protocol per transfer based on what the counterparty supports.

What happens if the counterparty can't be reached?

The obligation resolves to FAILED (with a reason such as protocol mismatch or unreachable counterparty) or sits at PENDING_COUNTERPARTY while you wait — both visible in the Console.

Is this a separate product from Transaction Monitoring?

No. The data exchange is built into Transaction Monitoring, on the same crypto transfer you already send for monitoring and wallet screening.

Ready to get started?

Read the Travel Rule documentation, see the full picture on the crypto Travel Rule solution page and the Transaction Monitoring product page, and check transparent per-call pricing on the pricing page. When you're ready, start free — 500 free KYC checks every month, with the Travel Rule data exchange built into monitoring.