For VASPs & CASPs

Meet the Travel Rule without handing over your customer.

Last updated: 30 August 2026

Recommendation 16 obliges you to pass originator and beneficiary information to the counterparty VASP. In practice that has meant sending the full customer record to an institution you do not control, which then stores it — and every stored copy is somebody else’s breach with your customer’s name in it.

There is a narrower way to satisfy the same obligation: disclose the fields the rule actually requires, and prove the rest rather than sending it.

What runs today

A live exchange between two separate VASP services — an originator and a beneficiary, over a real OpenVASP TRP network hop, not a single process pretending to be two.

The FATF‑required identity fields (name, account or wallet, and an identifier) are selectively disclosed via SD‑JWT over IVMS101 — the beneficiary receives those and nothing more.
Three further checks are satisfied in zero knowledge, each bound to the specific payment by its transaction‑context hash: an identity commitment; amount‑over‑threshold, with the amount itself hidden; and beneficiary‑VASP registration, without revealing which VASP.
A cleartext‑only exchange is refused, not merely discouraged.

The effect is to reduce what the counterparty learns and stores, rather than to reduce the required data set.

Lawful access, without standing surveillance

Accountability that only works by making everyone visible is not accountability, it is exposure. Identity material sits in an escrow envelope using a hybrid X25519 + ML‑KEM‑768 key encapsulation — hybrid so that a transcript captured today is not decryptable by a future quantum adversary — recoverable under lawful process rather than by anyone who happens to be on the path.

Evidence you can produce later

Every decision emits a signed receipt. Receipts are hash‑chained and committed to an RFC 6962 Merkle log, so a supervisor can be shown that a specific decision was made, when, and that the record has not been altered since — without that record containing personal data.

Interoperability

The working transport today is OpenVASP TRP. A published note sets out how the same payload maps onto TRISA, so the choice of transport does not decide the choice of privacy model.

You run it. That is the point.

The control plane belongs with the regulated entity that already carries the obligation. We publish the software under Apache‑2.0; you deploy it, you hold the keys, you set the policy, and no transaction detail reaches us or anyone else. We do not operate a service in your money path and we take no fee per transaction.

Honest boundaries

SPT‑Txn is a proof of concept and a specification effort. Nothing in it has been externally audited or certified, and it is not in production use. Our security reviews are our own. On‑chain footprints are on public testnets except where stated otherwise. An independent review of the zero‑knowledge circuits and the protocol is wanted and has not happened. We say this plainly rather than implying assurances we have not earned. One more, since an institution will ask it first: key reconstitution is designed but not settled. If an issuer loses its signing key, the revocation cascade and a cross‑organisation quorum are specified, but the ceremony shape is an open decision. Who holds what, and what it takes to stand an issuer back up without invalidating the delegations beneath it, is not a runbook we can hand you today.

If this is useful to you

Everything is public and reproducible — the reference implementation, the specification work, and the tests behind each claim above.

Reference implementation on GitHub →
Framework paper and IETF Internet‑Draft →
rudi@violetskysecurity.com