explains

Travel Rule On-Chain (IVMS-101)

The data standard that lets VASPs exchange Travel Rule messages when value moves on-chain.

By Anton Titov, Founder · Plexo Institute

Published 2026-05-17

IVMS 101 standardizes originator, beneficiary, VASP, and transfer data. The hard part is not the data format alone; it is VASP discovery, sunrise gaps, and reconciliation between off chain messages and on chain value.

Reader Brief

Reading Guide

Four moves that translate fifty-year-old Travel Rule compliance into the on-chain world.

IVMS-101 is the data layer; transport protocols are separate.

IVMS-101 standardizes the fields and schema. Notabene, Sumsub, TRP, OpenVASP, and other systems move the messages. Shared data format makes cross-protocol exchange possible; it does not eliminate onboarding and trust-framework work.

VASP discovery is the first operational problem.

Before sending a Travel Rule message, the originator must identify which VASP controls the destination wallet, or determine that the wallet is self-custodied or unknown.

The sunrise problem is structural.

When only one side of a corridor has Travel Rule infrastructure, FATF guidance accepts documented risk-based mitigation. Undocumented gaps are the compliance failure.

Off-chain messaging plus on-chain value creates reconciliation work.

The Travel Rule message and blockchain transfer move separately. The beneficiary VASP must match them by amount, asset, address, timestamp, and counterparty data.

What IVMS-101 Is

The Travel Rule data format for VASP-to-VASP messaging.

IVMS-101 is the InterVASP Messaging Standard for Travel Rule data between virtual-asset service providers. It defines which originator, beneficiary, VASP, and transfer fields must be exchanged, and how they should be represented in a structured schema [1].

Data standard vs transport protocol

The data layer says what fields exist and how they are formatted. The transport layer says how the message moves. The market has several transport protocols; IVMS-101 is the convergence point that makes translation and bridging possible.

The Message Structure

Six top-level objects carry the compliance packet.

IVMS-101 defines six top-level objects. Every Travel Rule message must populate them in a specified schema so the receiving VASP can identify the parties, verify the counterparties, and reconcile the compliance message to the blockchain transfer.

Object	Contents	Why it matters
Originator	Person or entity initiating transfer	Required identifying data
Beneficiary	Person or entity receiving transfer	Required receiving-party data
Originating VASP	Sending VASP entity data	License and counterparty identification
Beneficiary VASP	Receiving VASP entity data	Counterparty regulatory status
Transfer	Asset, amount, on-chain identifiers, timestamp	Reconciles to blockchain transaction
Payload	Container plus version metadata	Schema versioning and signing

VASP Discovery

Who controls the destination wallet?

Before a Travel Rule message can be sent, the originating VASP must answer a basic operational question: which VASP, if any, controls the destination wallet? That answer determines whether the operator sends a VASP-to-VASP message, collects self-custody beneficiary data, or applies risk-based controls.

Address attribution switchboard showing a destination address routed into known VASP messaging, self-custody evidence collection, or unknown-counterparty hold or rejection before value release. — Travel Rule compliance starts with attribution: the address case determines the message path, evidence path, or stop decision before value moves.

How attribution works

Attribution providers map known wallet addresses to VASPs. Accuracy is high for major centralized exchanges, weaker for mid-tier or regional VASPs, and definitionally unavailable for self-custody wallets. A mature operator combines vendor attribution with its own counterparty mapping and risk-based fallback [6].

Why directories are not enough

Even with attribution, the operator needs message routing, counterparty trust, encryption, onboarding agreements, and protocol compatibility. That is why Travel Rule vendors are onboarding networks, not just message pipes.

The Sunrise Problem

Implementation is uneven across jurisdictions and counterparties.

Global implementation is uneven. Some jurisdictions have full Travel Rule obligations in force, others have partial frameworks, and some counterparties still cannot receive structured messages. The originating VASP has to document the gap and decide whether to proceed, hold, limit, or refuse the transfer.

Three scenarios

**Both sides compliant:** exchange IVMS-101 and verify. **Originator-only compliant:** originator documents the gap, applies mitigation, holds, refuses, or sends with enhanced controls. **Beneficiary-only compliant:** beneficiary applies enhanced due diligence or refuses.

Risk-based mitigation

Document the gap, apply enhanced KYC, set transaction limits, block high-risk corridors where needed, and maintain an audit trail. FATF guidance accepts mitigation; it does not accept unmanaged gaps [2][3].

Self-Custody and the Compliance Gap

No beneficiary VASP means no counterparty to verify against.

Self-custody is the hardest Travel Rule case because there is no beneficiary VASP to verify the receiving party. The originator-side operator must collect beneficiary information from its customer, assess the risk, and decide what extra controls the corridor requires.

Jurisdiction	Self-custody treatment
EU MiCA / TFR	Collect beneficiary data from originator; higher-risk treatment above thresholds
UK	Collected data and risk-based controls
Singapore	Collected data with threshold-based Travel Rule requirements
US FinCEN	Customer attestation accepted within BSA/Travel Rule logic
UAE ADGM	Data collection plus risk-based decisioning

Why Off-Chain Messaging Is Hard

The compliance data and the value transfer do not travel in one packet.

In a bank wire, compliance data travels with the payment message. In a stablecoin transfer, the blockchain transaction carries value but no Travel Rule metadata. The IVMS-101 message travels through a separate channel. The beneficiary VASP must match the two before crediting the customer.

Dual-rail diagram separating the IVMS-101 compliance message from the on-chain token transfer and joining them at a reconciliation gate. — Stablecoin value and Travel Rule data move through different rails; credit release depends on matching the two packets.

The reconciliation problem

The beneficiary VASP matches message and transaction by amount, asset, address, timestamp, and counterparty data. If the message arrives first, it holds credit. If the transaction arrives first, it may hold or claw back credit until compliance data is complete.

Why a clearing network simplifies this

A multilateral clearing network lets members integrate once while the network handles VASP discovery, routing, format translation, and reconciliation as shared infrastructure.

Evidence And Sources

This raw HTML export preserves source visibility for crawler and contractor review. Indexing decision: index, follow.