The Travel Rule Is an Interoperability Problem Wearing a Compliance Costume
Solidus has no Travel Rule product, and one of the corrections below is about our own live pages. Nothing here is legal advice.
What the rule asks for, in one paragraph
When a virtual asset service provider sends assets to another one, it has to send identifying information about the originator alongside the transfer, and the receiving provider has to receive it, check it, and keep it. Recommendation 16 of the Financial Action Task Force's standards, written originally for wire transfers and extended to virtual assets in 2019.
FATF itself enforces nothing. The recommendation becomes binding when a country writes it into law, which the EU did through its recast transfer-of-funds regulation and the United States does through Bank Secrecy Act rulemaking. So the obligation a given business actually carries is national, and the text of it varies.
Why it is genuinely hard, and it is not the part people expect
The identity check is not the hard part. Every regulated provider already establishes who its customers are.
The hard part is that two companies who have never met, in different jurisdictions, under different national implementations, using different vendors, have to exchange structured personal data about a specific transaction, in real time, and each has to trust that the other is who it says it is.
That is an interoperability problem. It has a data-format layer, a discovery layer, an authentication layer and a trust layer, and getting any one of them wrong means the transfer either does not complete or completes without the data.
The compliance framing hides all of it. A rule that reads like a records requirement is in practice a request to build a federated messaging network between competitors.
Where the sub-problems actually sit
Format. Both sides need to agree on the shape of originator and beneficiary data. A standard exists for this and adopting it is the easiest of the four.
Discovery. Given a destination address, which provider holds it, and where do you send the message? There is no universal directory, and this is where most of the real engineering goes.
Authentication. How does the receiving provider know the sender is a genuine regulated business rather than someone fishing for customer data? A rule designed to fight financial crime creates, if done carelessly, an excellent channel for obtaining personal data by impersonating a counterparty.
Trust. Which providers do you accept messages from at all? This is the same question a credential network faces about issuers, and it has the same answer shape: somebody maintains a list, and whoever maintains it holds real power.
A correction about our own pages
Three of our live pages say otherwise.
They state that our credential attestation model satisfies the VASP Travel Rule, that it is compatible with originator and beneficiary identification under the rule, and that our credentials include fields compliant with Recommendation 16 requirements. Travel Rule data capture is listed as a capability.
None of those sentences is supportable. A credential format that can carry originator and beneficiary fields is not a system that identifies originators and beneficiaries, and neither one is a Travel Rule implementation. The distance between "our data model could hold this" and "we do this" is the entire product.
The copy is wrong, it is ours, and correcting it is a task rather than a debate. We are publishing that here rather than waiting for a buyer's compliance team to find it during due diligence, because when they do they learn two things and the second one is about us.
What a credential network could honestly contribute here
Not the rule itself. The trust layer underneath it.
The unsolved question in Travel Rule compliance is which counterparties a provider accepts data from, and how it verifies that a message came from a genuine regulated business. That is a verifiable-credential question, and it is close to the problem we work on: an issuer registry, credentials that prove an attribute without disclosing a dossier, and a way for two parties with no prior relationship to establish that each is what it claims.
That is a real contribution and it is a component, not a compliance product. Anyone selling you the second when they have built the first is doing what our own pages currently do.
What to ask any vendor claiming Travel Rule support
"Which national implementation are you built against?" The rule is not directly binding anywhere. A vendor that answers "FATF" has answered about a standard-setting body rather than about the law you are subject to.
"Show me a message exchanged with a counterparty you do not control." Two systems from the same vendor talking to each other demonstrates a format, not interoperability.
"How do you discover the receiving provider from a destination address, and what is your coverage?" This is the hard part, coverage is always partial, and a specific percentage is a better sign than an architecture diagram.
"How does a receiving provider authenticate you?" If the answer is thin, the same channel that satisfies a regulator is a way to request customer data by claiming to be a counterparty.
Where this leaves a decision
If you need Travel Rule compliance, we do not provide it. It is not a roadmap item with a date attached, and we would rather say that than list it as one. Buy it from a vendor whose product it is, and use the four questions above on them.
If what you need is a way for counterparties to establish trust in each other without a bilateral integration for every pair, that is the layer we work on. That is a component such a system would use, and it is not the system.