IVMS 101 Data Standard Explained

IVMS 101 — InterVASP Messaging Standard 101 — is the global data standard for Travel Rule messages. Published in 2020 by the Joint Working Group on InterVASP Messaging Standards, it defines what data originating and beneficiary VASPs must share and how that data is structured. The standard exists for a simple reason: without it, every VASP pair would negotiate its own format and interoperability would collapse. This article covers the full IVMS 101 anatomy, field-level expectations, and a worked example payload.

Purpose and scope of the standard

IVMS 101 is only a data schema. How the message is transported (HTTPS, messaging protocol, decentralized network), encrypted or signed is out of scope — that is the job of protocols like TRP, OpenVASP, Sygna and TRISA. IVMS 101 answers "what" travels, not "how."

As covered in our FATF Travel Rule guide, the application of FATF Recommendation 16 to virtual assets needed a practical industry standard to avoid national regulators imposing message formats unilaterally. IVMS 101 filled that gap.

Message structure — High level

An IVMS 101 message contains four main objects:

Originator: information about the person or entity initiating the transfer.
Beneficiary: information about the recipient.
OriginatingVASP: the VASP where the originator holds their account.
BeneficiaryVASP: the VASP where the beneficiary holds their account.

Each originator and beneficiary object can be carried in two sub-structures:

naturalPerson: an individual.
legalPerson: a legal entity.

Originator/beneficiary are mandatory for each transfer; the two VASP objects are typically auto-populated by the protocol layer.

naturalPerson — Individual field structure

For an individual originator:

name (required): primaryIdentifier (family name), secondaryIdentifier (given name), nameIdentifierType (LEGL = legal name, BIRT = birth name, etc.).
geographicAddress (recommended): street, building, town, country, postal code. AddressType from a controlled list: HOME, BIZZ, GEOG.
nationalIdentification: national ID number, type (NIDN = national ID, DRLC = driver's license, PASS = passport, etc.), issuing country.
dateAndPlaceOfBirth: date of birth, place of birth (city + country).
customerIdentification: VASP's internal customer ID.
countryOfResidence: ISO 3166-1 alpha-2 country code.

The name field is the strictest part — primaryIdentifier and secondaryIdentifier must be correctly separated. For multi-name cases like "Anna Maria Schmidt," "Anna Maria" goes as secondaryIdentifier, "Schmidt" as primaryIdentifier.

legalPerson — Entity field structure

For a legal entity originator:

name: legalPersonName (commercial name), legalPersonNameIdentifierType (LEGL, TRAD = trading name, SHRT = short name).
geographicAddress: registered office address.
customerNumber: customer identifier.
nationalIdentification: LEI (Legal Entity Identifier) is the most common.
countryOfRegistration: country code.

LEI is not mandatory but recommended — a 20-character global standard for legal entity identification.

Controlled vocabularies

IVMS 101's interoperability secret is its controlled vocabularies. Instead of free-form fields, standardized codes are used:

nameIdentifierType: LEGL, BIRT, MAID (maiden), ALIA (alias), MISC.
addressType: HOME, BIZZ, GEOG.
nationalIdentifierType: NIDN, DRLC, PASS, ARNU, RAID, CCPT, etc. (about 15 types).
countryCode: ISO 3166-1 alpha-2 (DE, GB, FR, US, etc.).

These lists are defined in the IVMS 101 specification annex — implementations must reference them.

Example message (simplified JSON)

A German exchange sending 0.5 BTC to a UK exchange:

{
  "originator": {
    "originatorPersons": [{
      "naturalPerson": {
        "name": {
          "nameIdentifiers": [{
            "primaryIdentifier": "Schmidt",
            "secondaryIdentifier": "Anna Maria",
            "nameIdentifierType": "LEGL"
          }]
        },
        "geographicAddresses": [{
          "addressType": "HOME",
          "streetName": "Hauptstrasse",
          "buildingNumber": "42",
          "townName": "Berlin",
          "country": "DE"
        }],
        "nationalIdentification": {
          "nationalIdentifier": "DE1234567890",
          "nationalIdentifierType": "NIDN",
          "countryOfIssue": "DE"
        },
        "dateAndPlaceOfBirth": {
          "dateOfBirth": "1985-03-17",
          "placeOfBirth": "Munich"
        },
        "countryOfResidence": "DE"
      }
    }],
    "accountNumbers": ["bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh"]
  },
  "beneficiary": {
    "beneficiaryPersons": [{
      "naturalPerson": {
        "name": {
          "nameIdentifiers": [{
            "primaryIdentifier": "Brown",
            "secondaryIdentifier": "James",
            "nameIdentifierType": "LEGL"
          }]
        },
        "countryOfResidence": "GB"
      }
    }],
    "accountNumbers": ["bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq"]
  },
  "originatingVASP": {
    "originatingVASP": {
      "legalPerson": {
        "name": {
          "nameIdentifiers": [{
            "legalPersonName": "Exchange GmbH",
            "legalPersonNameIdentifierType": "LEGL"
          }]
        },
        "countryOfRegistration": "DE"
      }
    }
  }
}

This is a minimal example; production messages add beneficiaryVASP objects and protocol-specific wrappers (TRP envelope, Sygna metadata, etc.).

Common mistakes in IVMS 101 mapping

When mapping from a KYC database into IVMS 101, the recurring errors:

Name splitting: Multi-name strings like "Anna Maria Schmidt" being mis-split. Standard: middle/given names all go to secondaryIdentifier, family name to primaryIdentifier.
Address type: Mis-coding a customer's work address as HOME or vice versa (BIZZ vs HOME matters for some receivers).
Place of birth: Sending "Germany" without city. The standard expects a city; country goes in a separate field.
National ID type: Coding a national ID number as DRLC by mistake. Correct: NIDN.
Wallet address format: Account number field receiving malformed wallet addresses (e.g. Ethereum addresses without checksum).

These errors cause the receiving VASP's validation layer to reject the message — which should not be confused with the sunrise problem; the message is delivered but rejected on quality grounds.

IVMS 101 and the protocol layer

The IVMS 101 message is carried by a protocol:

TRP: REST API, JSON-wrapped IVMS 101.
TRISA: gRPC, mTLS-signed, protobuf-serialized IVMS 101.
Sygna Bridge: WebSocket + REST hybrid, with its own metadata wrapper.
OpenVASP: Ethereum messaging layer, IVMS 101 as encrypted payload.

All these protocols support IVMS 101 — the difference is only in how it is serialized and transported. Our Travel Rule integration how-to covers protocol selection and the mapping layer in depth.

Frequently Asked Questions

How are IVMS 101 version updates managed?

IVMS 101 uses major.minor versioning (e.g. 1.0.0, 1.1.0). Major updates contain breaking changes — schema redesign. Minor updates typically add optional fields. Practical advice: maintain compatibility with the version that all your counterparty protocols currently support (1.0 is still dominant); verify counterparty support before upgrading to a new version. Backward compatibility is a design goal but edge cases exist.

Are all fields mandatory, or which are optional?

Required fields vary by jurisdiction. FATF baseline: originator name, account number and sufficient identification (national ID or date/place of birth); for the beneficiary, only name and account number. But EU TFR requires broader data (originator address mandatory) and UK MLR differs again. The IVMS 101 specification flags fields as "required" (schema-level mandatory) and "conditional" (jurisdiction-dependent). Practical recommendation: always send the maximum data set; how the receiving side interprets each field is not your problem.

Can I use an alternative to IVMS 101?

Technically yes — you could agree a bilateral custom format with a counterparty VASP. Practically no. Every production Travel Rule protocol is built on IVMS 101; a custom format limits you to a tiny pool of counterparties willing to negotiate. If you intend to operate at scale, IVMS 101 is mandatory in practice.

What do I do if I don't have the customer's place of birth?

dateAndPlaceOfBirth is optional in the schema — but if national identification is missing (NIDN, PASS, etc.), many receiving VASPs rely on date/place of birth as alternative identification. Making this field mandatory during KYC is the practical fix. For existing customer bases with gaps: trigger backfill KYC; you can leave the field empty and accept the counterparty rejection rate, but this is not sustainable.

How Legichain helps

Keeping IVMS 101 mapping piecemeal is a source of operational error. Legichain's Travel Rule module integrates directly with your existing digital KYC and customer database — fields collected during KYC (national ID, place of birth, address) are auto-translated into IVMS 101 format without you writing manual mapping code. For missing fields, a customer-side correction flow (validation error → customer update → automatic retry) is bundled. The protocol layer (TRP, Sygna, TRISA) is multi-supported, so routing adapts to counterparty preference. Test the example message flow via our sandbox at /en/travel-rule.

Next steps

FATF Travel Rule guide — the bigger picture in which IVMS 101 sits.
How to implement Travel Rule — where IVMS 101 mapping fits in the 8-step build.
The sunrise problem and workarounds — what happens when the message is correctly formed but the counterparty cannot accept it.

Legichain Team· Compliance editorial

Written by Legichain's compliance editorial team — regulated-financial-services veterans who built and integrated AML platforms for banks and crypto exchanges across EMEA.

Be screen-ready in an afternoon.

Spin up a free workspace, paste your first API key into a curl, ship a verified onboarding flow before your next stand-up.

Start free Book 30 min with sales