Travel Rule Protocols: TRISA vs TRP vs TRUST

Choosing a Travel Rule protocol decides which counterparties you can reach. Choosing a data format does not. Every protocol in use today carries the same IVMS101 payload, and none of them can tell you, from a bare blockchain address, which exchange is on the other end.

That second problem is where integrations stall. The pages ranking for this topic are mostly vendor overviews: a list of protocol logos, a paragraph each, a call to book a demo. None of them walks through the message flow, the field constraints that make payloads bounce, or what your code should do when the other side never answers. This guide does, from the specs.

For the regulatory field lists, I have covered the UK Part 7A fields and the EU's missing €1,000 threshold before. This piece sits one layer down, at the wire.

What Is a Travel Rule Protocol?

FATF Recommendation 16, applied to virtual assets through Recommendation 15, says the sending VASP must pass originator and beneficiary information to the receiving VASP. A blockchain transaction has no field for a name and a postal address, so the data has to travel off-chain over a separate channel. That channel is the protocol.

Each protocol has to solve four problems, and they are worth separating because vendors blur them:

1. Data model. What the payload looks like. This one is solved: everyone uses IVMS101. 2. Discovery. Given a destination, who do I talk to, and at which endpoint? 3. Transport and trust. How do I know the endpoint really belongs to the VASP it claims to be, and that nobody else can read the PII? 4. Workflow. Inquiry, accept or reject, then link the on-chain transaction hash back to the message.

The timing is not optional in Europe. The EBA Travel Rule Guidelines (EBA/GL/2024/11, paragraph 25) require CASPs to transmit the information "immediately and securely and no later than the initiation of the blockchain transaction". A nightly batch of IVMS101 files fails that test, so this has to sit in the request path of your withdrawal flow.

What Does an IVMS101 Payload Look Like?

IVMS101 is the interVASP Messaging Standard. There are two versions in circulation: the original from May 2020, and IVMS101.2023 from the interVASP Standards Working Group, published August 2023. The top level is the same in both: originator, beneficiary, originatingVASP, beneficiaryVASP, transferPath and payloadMetadata.

Here is an abridged natural-person originator in the 2020 shape, taken from the TRP specification:

"originator": {
  "originatorPersons": [{
    "naturalPerson": {
      "name": { "nameIdentifier": [{
        "primaryIdentifier": "Post",
        "secondaryIdentifier": "Johnny",
        "nameIdentifierType": "LEGL"
      }]},
      "geographicAddress": [{
        "addressType": "GEOG",
        "streetName": "Potential Street",
        "buildingNumber": "123",
        "postCode": "91361",
        "townName": "Thousand Oaks",
        "country": "US"
      }],
      "customerIdentification": "1002390"
    }
  }]
}

The constraints that actually cause rejections are in the spec, not the vendor pages:

Two things catch teams out.

The EBA also defines "meaningless" information as missing (paragraph 50): xxxxx, a title with no name, or placeholder strings such as "My Customer". A schema validator will pass all of those. Your own validation has to catch them.

How Does TRISA Work?

TRISA is an open-source protocol (MIT licence, latest trisacrypto/trisa release v1.7.0 in July 2025) built on gRPC over mutual TLS.

The error codes are the most useful part for developers, because they are grouped by what you should do next:

Map these ranges to your retry policy directly. A 154 means a payload you can fix and resend. A 54 means a person in compliance has to look at it. Treating every non-success as a generic failure sends both to the same queue.

How Does TRP (Travel Rule Protocol) Work?

TRP comes from the OpenVASP Association. The current version is 3.2.1, dated 29 July 2024. It is plain HTTPS and JSON, with mandatory mutual TLS since version 3.0.0, and unlike TRISA it accepts certificates from any CA.

Its answer to discovery is the Travel Address: the string ta followed by a base58check encoding of a URL that must contain t=i. The specification's test vector encodes beneficiary.com/x/12345?t=i as ta2W2HPKfHxgSgrzY178knqXHg1H3jfeQrwQ9JrKBs9wv. The beneficiary's customer copies this from their exchange the way they would copy a deposit address, and the sender decodes it to get the endpoint. No directory lookup at all. Version 3.1.0 moved away from the earlier LNURL-style bech32 encoding because of bech32's length limit.

The flow is three POSTs:

1. The originator POSTs an inquiry to the decoded URL: asset.dti, amount in the asset's smallest unit, a callback URL, and the IVMS101 payload. Headers carry api-version: 3.2.1 and a UUIDv4 request-identifier. 2. The beneficiary POSTs back to the callback with either {"approved": {"address": "...", "callback": "..."}} or {"rejected": "..."}. 3. The originator broadcasts, then POSTs {"txid": "..."} (or {"canceled": "..."}) to the confirmation callback.

Look at step 2. The beneficiary returns the deposit address after its checks pass. The sender never has a destination until the receiving VASP has screened the originator. That ordering removes most of the "funds arrived, data is bad, now what" problem, because unwanted funds rarely get sent in the first place. The spec allows a VASP to send funds before approval, though not before sending the IVMS101 payload, and it warns that doing so throws away the benefit.

The gaps: TRP specifies no timeouts, leaves callback URL layout up to the implementer, and has no directory, so a Travel Address only helps when the counterparty runs TRP.

TRISA vs TRP vs TRUST vs GTR: Which Should You Integrate?

TRUST reported more than 125 VASPs across 20+ jurisdictions in early 2025, by a competitor's count. Circle joined GTR in August 2025. I could not find a public technical spec for either.

The two open protocols trade off differently. TRISA gives you stronger trust (one CA, a vetted directory, envelope-level encryption that survives storage) at the cost of a registration process and a directory that does not resolve addresses. TRP is cheaper to stand up and solves discovery for the customer-initiated case, but trusts any CA and needs the customer to paste an extra string. The two have bridged since 2023: the TRISA Go package ships TRP handlers, and TRP has sealed-trisa-envelope and unsealed-trisa-envelope extensions.

Be sceptical of "interoperable with X" claims. Korea's CODE network documents that its links to other networks are "technically integrated" but not necessarily approved at the policy level, and lists different required fields per network: GTR wants dateOfBirth for natural persons, Sygna wants identification, address and date and place of birth together. IVMS101's C1 rule only demands one of those. If you route through a hub, validate against the strictest network you reach, not against IVMS101.

How Do You Know a Crypto Address Belongs to a VASP?

This is the question none of the protocols fully answers, and it is the one your withdrawal screen has to answer before anything else.

The EBA guidelines (paragraphs 77 and 78) tell CASPs to identify a self-hosted address using "blockchain analytics, third-party data providers and identifiers used by messaging systems", and to ask the customer only when those fail. In practice the sequence looks like this:

1. Check whether the customer gave you a Travel Address. If yes, you have your counterparty. 2. Query blockchain analytics attribution for the address. A hit gives you a VASP name, not an endpoint. 3. Resolve that name through each network's directory (TRISA GDS, GTR's VASP list, your aggregator). 4. If nothing resolves, ask the customer: "Is this your own wallet, or an account at another platform?"

If the answer is a self-hosted wallet and the transfer exceeds €1,000, Article 14(5) of Regulation (EU) 2023/1113 requires you to assess whether your customer owns or controls it. EBA paragraph 83 accepts video verification, a satoshi test (a predefined small amount sent from the address), or a signed message using the address's key. Once verified, you may whitelist the address with ongoing risk monitoring. Build the signed-message path. A satoshi test costs your customer a fee and a confirmation wait every time they add an address.

What Happens When a Travel Rule Counterparty Doesn't Respond in the UK and EU?

The "sunrise problem" is the counterparty in a jurisdiction that has not switched the rule on, or that has but runs no compatible protocol. It is shrinking but real. Summaries of FATF's July 2026 targeted update report that 91 of 109 responding jurisdictions have passed Travel Rule legislation, and that 55 of those 91 have issued no Travel Rule supervisory findings or enforcement actions. (I could not fetch the FATF PDF itself, so treat the exact figures as secondhand.)

The UK FCA's statement, updated February 2026 with no change in substance, says that when sending to a jurisdiction without the rule you must take reasonable steps to check whether the recipient can receive the data, and collect, verify and store it regardless. When receiving, decide on a risk basis.

The EU is more prescriptive, and the deadlines are concrete enough to code. Under EBA paragraph 56, when you request missing information the deadline must not exceed three working days for transfers within the Union, five for transfers from outside it, and up to seven for longer chains or those involving a non-EU party. When the deadline passes you choose to reject, return, suspend or execute. Counterparties that keep failing must be reported to your competent authority within three months.

On the protocol side, TRISA has a local-only Sunrise record and the open-source Envoy node implements it by emailing the counterparty's compliance contact a one-time link. Envoy's own documentation still lists "Solve the Sunrise problem" among the things nothing does yet, which is honest. Email is a fallback, not a protocol.

Travel Rule Thresholds in 2026: UK, EU, US, Singapore

Several vendor pages still show the UK at €1,000 and the US $250 proposal as pending. Hard-code neither. Put thresholds in configuration keyed by jurisdiction and effective date, because the UK has already changed once and FATF's June 2025 rewrite of Recommendation 16 runs to an end-2030 implementation date.

My Take: Discovery Is the Real Standard Still Missing

This section is opinion.

The messaging war is over and IVMS101 won it. What remains unsettled is discovery, and I expect the TRP pattern to become the default for customer-initiated withdrawals between exchanges: the beneficiary issues an identifier that carries its own endpoint, and returns a deposit address only after screening the originator. It is the same lesson UK banks applied with Confirmation of Payee: check the payee before money moves, not after. Directory lookup by VASP identity will survive for institutional flows where both sides already know each other.

I also expect the first serious EU enforcement to come through Article 17's "repeatedly failing" reports, not through headline fines. Those reports are built from exactly the metrics the EBA lists: the percentage of transfers with missing data and the percentage of unanswered requests. If your system cannot produce those two numbers per counterparty, a supervisor will eventually ask why.

What This Means for Exchange and Wallet Engineers

1. Store names in two forms from onboarding: the native script and a transliteration, with the script code. Back-filling this later means re-contacting customers. 2. Parse IVMS101 by payloadVersion. Support both 2020 and 2023 keys on receive, emit 2023 on send, and reject mixed payloads. 3. Add a semantic validator on top of the schema for C1, C6 and C8, plus the EBA's meaningless-data cases. 4. Model Travel Rule state on the withdrawal, not in the compliance tool. States should include awaiting counterparty, needs repair, under review, approved, rejected, and sunrise. Map TRISA's error ranges onto them. 5. Put the information exchange before the broadcast. Pass the EU timing test by design, not by luck. 6. Track per-counterparty failure rates now: missing-data percentage and unanswered-request percentage. You will need them for Article 17 reports. 7. Support at least two networks, or use an aggregator, and test reachability against your actual top 20 withdrawal destinations. Coverage claims are only worth checking against your own traffic.

Travel Rule compliance looks like a form-filling problem and turns out to be a routing problem. The payload format is settled; knowing who is on the other end of an address, and what your system does while it waits for them, is where the engineering goes. More on crypto payment infrastructure from Tom Wang.