IVMS 101. The schema is the easy part, and we do not even emit that

No IVMS 101 message construction, parsing or transmission exists anywhere in the Solidus codebase, confirmed by searching every TypeScript, Rust and SQL file, re-run 2026-07-31, not recalled from memory.

What it is

IVMS 101, the InterVASP Messaging Standard, is the wire format that makes the FATF Travel Rule practically implementable.

Knowing that originator and beneficiary information must travel with a transfer does not tell two businesses with no prior relationship and different internal systems which fields to send, named how, structured how. IVMS 101 answers that: a shared field list, originator name, address, national identity number, date and place of birth where required, account or wallet reference, and the mirror set for the beneficiary, expressed as a common schema, with a later mapping to the messaging format traditional banking already uses.

It is the crypto industry's version of what interbank messaging settled decades ago: not a new legal requirement, but the common format that lets independently built compliance systems actually talk to each other instead of each inventing its own incompatible "originator info".

The Joint Working Group published it in 2020, drawing on industry bodies including Global Digital Finance and INATBA. Nearly every commercial Travel Rule product implements it. Solidus contributed nothing to its design. The specification is public, read it directly rather than take anyone's summary, including ours.

Why the schema is the easy part

If serialising a field list were the problem, this would have been solved in a week. It is not the problem. What makes Travel Rule compliance hard is everything the schema assumes has already happened:

• Counterparty discovery. Before you can send an IVMS 101 message you must establish that the receiving address belongs to a service provider at all, and which one. No scheme fully resolves this.
• A transport both sides speak. Several competing protocols carry these messages, and interoperability between them is the live industry problem.
• A trust relationship. You are handing another company a person's identity data. Deciding you are willing to is a legal and commercial decision, not a serialisation one.
• Data-protection constraints. Sending more than required is a privacy problem; sending less is a compliance one, and the correct amount differs by jurisdiction.

A vendor that emitted perfectly-formed IVMS 101 and solved none of the above would have shipped nothing useful. We have not even shipped the easy part.

Our own compliance page is wrong about this, in two directions at once

Our live compliance page currently states that our "credential attestation model satisfies VASP Travel Rule", marked Current, and, in a comparison table on the same page, that Travel Rule support is "Not offered."

The second is correct. The first is not, and there is no reading of the codebase that supports it.

There is also a softer variant on that page: that our model is "compatible with FATF Travel Rule originator/beneficiary identification via W3C VC metadata fields." Mapping credential metadata onto the concepts of originator and beneficiary is not IVMS 101, and it does not become a Travel Rule capability by being adjacent to one. Compliance failures in this area carry consequences that a marketing overstatement does not survive.

We are stating this on our own page rather than waiting for a compliance team to find it.