IVMS101 explained: the Travel Rule data standard, its elements, and how it maps to ISO 20022 party fields

IVMS101, the interVASP Messaging Standard, is the common data model that virtual asset service providers use to exchange the originator and beneficiary information the Travel Rule requires. It defines the data elements, their structure and their coded values, so that a name, an address, a wallet identifier or a national identification number means the same thing to the sending VASP and the receiving VASP regardless of the protocol that carries it. It does not define how the data is transmitted; that is left to Travel Rule protocols. This article sets out who maintains the standard, what elements it defines, how it relates to FATF Recommendation 16 and to the party fields in ISO 20022 messages, and how the data should be transmitted and stored.

What is IVMS101 and who maintains it?

The standard was produced by the interVASP joint working group, which was convened in late 2019 by three industry bodies, the Chamber of Digital Commerce, Global Digital Finance and the International Digital Asset Exchange Association, in response to FATF's June 2019 extension of the Travel Rule to virtual asset transfers. The first version was published in May 2020 and a revised edition followed in 2023. The standard is available without charge and is expressed as a data model with a normative definition of each element, its cardinality and its permitted coded values, together with encodings in JSON and XML. It was written to be protocol neutral so that competing Travel Rule solutions could interoperate on content even where they did not interoperate on transport.

In practice a VASP encounters IVMS101 in three places: as the payload format inside whichever Travel Rule protocol or vendor it has adopted, as the schema its compliance system validates outgoing data against before a transfer is released, and as the structure in which incoming counterparty data is stored for screening and retention. A firm that has integrated a Travel Rule vendor is already producing IVMS101 whether or not its analysts have read the specification; the value of reading it is knowing what a rejected payload was missing.

Which data elements does IVMS101 define?

The top level of the model has six parts: Originator, Beneficiary, OriginatingVASP, BeneficiaryVASP, TransferPath for intermediary VASPs, and PayloadMetadata, which records the character set and the version of the standard used. Originator and Beneficiary each contain one or more persons plus account identifiers, which for a virtual asset transfer are the wallet addresses or, where the transfer is within a custodial ledger, the internal account references. A person is either a natural person or a legal person, and the two have different structures.

• A natural person carries a name made of one or more name identifiers, each with a primary identifier such as a family name, a secondary identifier such as given names, and a type code distinguishing the legal name from an alias or a name at birth.
• A legal person carries a name with a type code distinguishing the legal name from a short name or a trading name, so that a beneficiary VASP can match the entity on its own records.
• Both person types carry a geographic address with a type code for home, business or geographic, and structured elements for street, building, post code, town, country sub division and country.
• Both carry a national identification block with the identifier, a typed code such as passport number, national identity card, driver's licence, tax identification number, social security number, registration authority identifier, alien registration number or legal entity identifier, and the issuing country.
• A natural person additionally carries date and place of birth and country of residence, and both types carry a customer identification, which is the identifier the VASP itself uses for that customer.
• The VASP blocks carry the VASP as a legal person, with its own name, address, national identification and, where it has one, its legal entity identifier.

The typed codes are the point of the standard. A free text field labelled identification tells a receiving VASP nothing about whether the value is a passport number or a tax number. A typed field allows the receiving VASP to validate the format, match it against its own record and screen it correctly. Three practical rules follow: populate the type code on every identifier, populate the country on every national identification, and never put a wallet address in a person name field to satisfy a validator.

How does IVMS101 relate to FATF Recommendation 16?

FATF Recommendation 16 requires that a transfer of funds carry accurate originator information and required beneficiary information, and that the information stays with the transfer through the chain. In 2019 FATF applied the same requirement to virtual asset transfers between VASPs, which is what the industry calls the Travel Rule. The recommendation lists the elements: originator name, originator account number or, for virtual assets, the wallet address used to process the transaction, and one of the originator's address, national identity number, customer identification number, or date and place of birth; and beneficiary name and beneficiary account number or wallet address. FATF's threshold below which reduced information is acceptable is one thousand US dollars or euros.

Recommendation 16 therefore says what must travel, and IVMS101 says how to encode it. Every required element in the recommendation has a home in the model, and the optional alternatives, address, national identifier, customer number and date and place of birth, are separate structured blocks so that a VASP can include whichever it holds. National implementations set their own thresholds and additions. In the United States the funds transfer rule applies from three thousand US dollars, and FinCEN has treated convertible virtual currency transmitters as subject to it. In Canada, FINTRAC's virtual currency travel rule applies from one thousand Canadian dollars. In the European Union the transfer of funds regulation applied to crypto asset service providers from the end of December 2024 without a threshold. The IVMS101 payload does not change between these regimes; what changes is when a VASP must send it and which optional elements it includes.

The Travel Rule is a data quality problem wearing a compliance badge. If the originator record was captured badly at onboarding, no messaging standard will repair it at the moment of transfer.

How do IVMS101 fields map to ISO 20022 party fields?

An institution that runs both fiat rails and stablecoin settlement holds the same facts about the same customer in two models, and the mapping between them is closer than it first appears. The ISO 20022 party block used in pacs.008 for the debtor and creditor has a name, a structured postal address with street name, building number, post code, town name, country sub division and country, and an identification block that is either an organisation identification, carrying elements such as the legal entity identifier or a coded other identifier, or a private identification, carrying date and place of birth and a coded other identifier with a scheme code such as passport number, national identity number, driver's licence number, tax identification number or customer identification number. Accounts are carried in the debtor account and creditor account blocks, and a wallet address fits the other identification element of an account with a proprietary scheme name.

The correspondence is therefore: IVMS101 natural person name to the party name, geographic address to postal address, national identification with its type code to private identification with its scheme code, date and place of birth to the same named element, customer identification to the customer identification scheme code, legal entity identifier to the organisation identification LEI element, and wallet address to the account identification. The originating and beneficiary VASPs correspond to the debtor agent and creditor agent. A platform that stores the customer record once and generates both the pacs.008 party blocks and the IVMS101 payload from it removes the most common Travel Rule defect, which is that the two disagree. The UETR in the pacs.008 and the on chain transaction hash then bind the instruction, the settlement and the Travel Rule exchange together for one payment.

How should IVMS101 data be transmitted and stored?

The data never goes on chain. It is exchanged between the originating and beneficiary VASPs through a Travel Rule protocol or vendor network, over an encrypted channel, either before the on chain transfer is broadcast or in parallel with it, and the exchange is linked to the transfer by the transaction hash and, on an ISO 20022 platform, by the UETR. Sending before broadcast is preferable, because it gives the beneficiary VASP the opportunity to reject a transfer it cannot accept, for example where the beneficiary name does not match its customer record, before value moves and needs returning. The beneficiary VASP's acknowledgement or rejection is itself a record to retain.

Storage follows the rules that apply to any customer identification data, with two additions. The two additions are that the record must be retrievable by transaction hash and by UETR, because that is how an examiner or a law enforcement request will identify the transfer, and that counterparty data received from another VASP must be kept separate from the firm's own customer records so that it is not mistaken for verified data. The data is encrypted at rest, access is limited to compliance and to the systems that screen it, every access is logged, and the retention period is at least five years from the transaction under both the Bank Secrecy Act and the Canadian regime, with privacy law such as PIPEDA in Canada and the GDPR for European counterparties governing what may be collected and for how long beyond that. Incoming IVMS101 data is screened on receipt against sanctions and PEP lists in the same way as the parties in a pacs.008, and the screening result is stored with the payload.

Where StableNet fits

StableNet, built by SpendTheBits, carries FATF Travel Rule data in IVMS101 form as part of every stablecoin settlement it processes, and because the platform is ISO 20022 native the same customer record populates both the pacs.008 party blocks and the IVMS101 payload, so the two cannot drift apart. The payload is exchanged off chain, the on chain transfer in regulated stablecoins such as USDC or USDT is recorded by transaction hash, and both are bound to the UETR that tracks the instruction end to end through pacs.002 status reports and any pacs.004 return inside head.001 envelopes. Incoming counterparty data is screened against sanctions and PEP lists on receipt, held items are worked in the compliance workbench, and the whole record sits in a tamper evident audit trail retrievable by UETR or hash. SpendTheBits is a Bank of Canada registered payment service provider and a named finalist in the Swift Hackathon 2026 Technical Challenge.