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:
- Data model. What the payload looks like. This one is solved: everyone uses IVMS101.
- Discovery. Given a destination, who do I talk to, and at which endpoint?
- 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?
- 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:
Read the full article on tomcn.uk →
About the Author
I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.
Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.
Top comments (0)