# IVMS101 - interVASP Messaging Standards

**Universal common language for communication of required originator and beneficiary information between virtual asset service providers**

**interVASP data model standard**

**Issue 1 FINAL**

**Joint Working Group on interVASP Messaging Standards**

Website: [intervasp.org](https://intervasp.org)

---

## Table of Contents

1. [Terms and definitions](#1-terms-and-definitions)
   - 1.1 [List of reserved words and definitions](#11-list-of-reserved-words-and-definitions)
   - 1.2 [Abbreviations and Acronyms](#12-abbreviations-and-acronyms)
   - 1.3 [Formatting Notations](#13-formatting-notations)
   - 1.4 [Naming Conventions](#14-naming-conventions)
   - 1.5 [Case sensitivity](#15-case-sensitivity)
2. [Background and rationale](#2-background-and-rationale)
   - 2.1 [Background](#21-background)
   - 2.2 [Rationale](#22-rationale)
   - 2.3 [Process Model](#23-process-model)
3. [Scope of the Standard](#3-scope-of-the-standard)
4. [Data principles](#4-data-principles)
5. [Datatypes](#5-datatypes)
6. [Data model definition](#6-data-model-definition)
7. [Handling of multiple character sets](#7-handling-of-multiple-character-sets)
8. [Business examples](#8-business-examples)

---

## 1 Terms and definitions

### 1.1 List of reserved words and definitions

For the purposes of IVMS101, the following terms are considered to be reserved words and follow the definitions below:

| Term | Definition |
|------|------------|
| **beneficiary** | refers to the natural or legal person or legal arrangement who is identified by the originator as the receiver of the requested VA transfer. |
| **beneficiary VASP** | refers to the VASP which receives the transfer of a VA from the originating VASP directly or through an intermediary VASP and makes the funds available to the beneficiary.<br><br>*Adapted from General Glossary of the FATF Recommendations* |
| **component** | refers to a composite datatype that consists of one or more elements that can be reused across data entities. |
| **constraint** | refers to a rule, limitation or control enforced on a datatype, element, component or entity that restricts the content being created or amended. |
| **country** | refers to a nation with its own government. |
| **country subdivision** | refers to an administrative subdivision of a country. |
| **data entity** | refers to a single object in a data model that can be distinctly identified. |
| **datatype** | refers to an attribute of an element that reflects the possible values that can be represented by the element. |
| **element** | refers to a unit of data that has precise meaning, serving to identify the attributes of a data entity. |
| **intermediary VASP** | refers to a VASP in a serial chain that receives and retransmits a VA transfer on behalf of the originating VASP and the beneficiary VASP, or another intermediary VASP.<br><br>*Adapted from General Glossary of the FATF Recommendations* |
| **interVASP Messaging** | refers to the transmission of structured data between VASPs and/or other affected entities. |
| **legal person** | refers to any entity other than a natural person that can establish a permanent customer relationship with an affected entity or otherwise own property. This can include companies, bodies corporate, foundations, anstalt, partnerships, or associations and other relevantly similar entities.<br><br>*Adapted from General Glossary of the FATF Recommendations* |
| **legal entity** | refers to a unique party that is legally or financially responsible for the performance of financial transactions or has the legal right in its jurisdiction to enter independently into legal contracts, regardless of whether it is incorporated or constituted in some other way (e.g. trust, partnership, contractual). It includes individuals when acting in a business capacity.<br><br>*Adapted from ISO 17442* |
| **locality** | refers to a particular area of a country subdivision, such as a district, suburb, village, town, or city. |
| **natural person** | refers to a uniquely distinguishable individual; one single person. |
| **originating VASP** | refers to the VASP which initiates the VA transfer and transfers the VA upon receiving the request for a VA transfer on behalf of the originator.<br><br>*Adapted from General Glossary of the FATF Recommendations* |
| **originator** | refers to the account holder who allows the VA transfer from that account or, where there is no account, the natural or legal person that places the order with the originating VASP to perform the VA transfer.<br><br>*Adapted from General Glossary of the FATF Recommendations* |
| **other affected entity** | refers to a natural or legal person, other than a VASP, that engages in or provides covered VA activities. |
| **Recommendation** | refers to a FATF Recommendation. |
| **registration authority** | refers to a corporate or business registry, or other national or local authority that maintains the authoritative source of information about legal entities operating in its jurisdiction. |
| **Standard** | refers to the IVMS101 standard. |
| **transfer** | refers to conducting a transaction on behalf of another natural or legal person that moves a virtual asset from one virtual asset address or account to another.<br><br>*Source: FATF guidance for a risk-based approach to virtual assets and virtual asset service providers* |
| **virtual asset** | refers to a digital representation of value that can be digitally traded, or transferred, and can be used for payment or investment purposes. Virtual assets do not include digital representations of fiat currencies, securities and other financial assets that are already covered elsewhere in the FATF Recommendations.<br><br>*Source: General Glossary of the FATF Recommendations* |
| **virtual asset service provider** | refers to any natural or legal person who is not covered elsewhere under the FATF Recommendations, and as a business conducts one or more of the following activities or operations for or on behalf of another natural or legal person:<br>i) exchange between virtual assets and fiat currencies;<br>ii) exchange between one or more forms of virtual assets;<br>iii) transfer of virtual assets;<br>iv) safekeeping and/or administration of virtual assets or instruments enabling control over virtual assets; and<br>v) participation in and provision of financial services related to an issuer's offer and/or sale of a virtual asset.<br><br>*Source: General Glossary of the FATF Recommendations* |

### 1.2 Abbreviations and Acronyms

The following is a list of abbreviations and acronyms used in this document:

| Abbreviation/Acronym | Definition |
|---------------------|------------|
| **AML** | anti-money laundering |
| **CDD** | customer due diligence |
| **CFT** | countering the financing of terrorism |
| **FATF** | Financial Action Task Force |
| **GLEIF** | Global Legal Entity Identifier Foundation |
| **IVMS** | interVASP Messaging Standard |
| **ISO** | International Organisation for Standardisation |
| **KYC** | know your customer |
| **LEI** | Legal Entity Identifier |
| **VA** | virtual asset |
| **VASP** | virtual asset service provider |
| **TSP** | technical solution provider |

### 1.3 Formatting Notations

Entities and components will follow an upper camel case convention with no spaces, with the first word capitalised.

Elements will follow a lower camel case convention with no spaces; the first word will not be capitalised. Datatypes will be referred to in upper camel case, unless convention requires otherwise.

For readability purposes, entities may be referred to in their business context in Title Case, which will permit the use of spaces between words.

### 1.4 Naming Conventions

Any term used within an entity, component or element name does not necessarily dictate the value for such an object. For example, customerNumber, and other elements where the name contains the word 'Number', do not necessarily have to only consist of numerals. Valid values are determined through the datatype definition and any applicable constraints.

### 1.5 Case sensitivity

Unless otherwise specified, all values are case insensitive.

---

## 2 Background and rationale

### 2.1 Background

In October 2018, FATF adopted changes to its Recommendations to explicitly clarify that they apply to financial activities involving VA, effectively expanding the scope of the Recommendations to apply to VASPs and other obliged entities that engage in or provide covered VA activities (together, affected entities).

INR. 15, paragraph 7(b), relating to Recommendation 16 was officially adopted to form part of the FATF standards in June 2019 stating that countries should ensure that:

> "…originating VASPs obtain and hold required and accurate originator information and required beneficiary information on virtual asset transfers, submit this information to beneficiary VASP or financial institution (if any) immediately and securely.
>
> …beneficiary VASPs obtain and hold required originator information and required and accurate beneficiary information…"

Originating VASPs must transmit mandated data to the Beneficiary VASP (if applicable) immediately and securely, ensuring that only those parties processing the transfer have access to the information.

While it is already expected that traditional financial institutions share this information between counterparties, numerous technical, operational and cultural challenges brought about by this clarification are unique to the VA space. The variances between the data that are captured by VASPs, and shared over existing blockchain networks by which VA are transferred locally and globally create a technical challenge that does not impact traditional payments gateways.

The diverse AML/CFT regulatory landscape applying to the VA space has also led to notable differences in the client data already possessed by VASPs between jurisdictions. For all practical purposes, VASPs operate in a global ecosystem and as such, local and regional data compliance and privacy laws with which personal data can be shared and persisted apply. Globalisation challenges, including the use of data captured in multiple languages, character sets and local conventions, can affect the sharing of data between VASPs.

### 2.2 Rationale

Consistency and harmonisation are in the interests of all VASPs. This is particularly the case in the field of domestic and cross-border messaging between VASPs. There exists a need for VASPs to adopt uniform approaches and establish best market practice, especially in relation to meeting obligations resulting from the FATF Recommendations as they apply to VASPs.

Unambiguous data allows VASPs to exchange messages in an automated fashion, reducing costs and minimising risks. A universal common language enables beneficiary VASPs to understand and process required originator and beneficiary information submitted by originating VASPs.

Following the update to FATF paragraph INR.15 7(b)-R.16, several technical solutions that facilitate the transfer of such data between VASPs have been progressed by TSPs to aid VASPs in meeting their regulatory obligations.

As such, there arises a greater need for the standardisation of the data domain to which VASPs can share data to avoid the proliferation of numerous data models. While underlying source data may not align to the Standard, standardisation of the data domain to which the required data is shared can ease the adoption of such technical solutions by VASPs. Irrespective of the technical solution, data should be expected to be structured in line with the Standard at time of transmission.

When consumed, the data for entities covered by the Standard can be received in a structure that is meaningful, well-formed and complete. The technical burden towards adoption can be eased, as a VASP has only to develop transformations for such entities once.

Through the introduction of the Standard, TSPs can focus less on having to model the business domain, assigning resources to deliver the technical solution.

Through the alignment of data structures and those constraints governing the content, sharing or consuming data that is compliant with the Standard can be assured of a quality of data that may be lost should there be numerous models to which the platforms would operate. By assuring the reliability of data, it can be expected that data be obtained and maintained to a higher standard than would be the case without the Standard.

### 2.3 Process Model

![Transfer of data between an originator and beneficiary by way of an originating, intermediary and beneficiary VASP](process-model-diagram)

*Figure 1 Transfer of data between an originator and beneficiary by way of an originating, intermediary and beneficiary VASP*

---

## 3 Scope of the Standard

To meet the challenge as described in Section 2.1 (Background), the Standard covers four primary areas in the sharing of data, agreed through consensus with the Joint Working Group on interVASP Messaging Standards.

### 3.1 Establish a universal lexicon

In a business domain with countless acronyms, definitions and synonyms, identifying a universal lexicon, or common vocabulary, for those terms and concepts that constitute the data universe allows for the reduction of ambiguity and risk of misinterpretation of data that must be shared between parties.

### 3.2 Describe the data model

The data model consists of an agreed representation of format, definition and structure of those entities that form the business domain. A standardised data model also serves to reduce duplication of effort on take-up of TSPs, improving reliability and reducing effort and costs of meeting regulatory obligations in the sharing of data between VASPs.

### 3.3 Define constraints over the data

Appropriate restrictions over permissible content may not ensure the correctness of the data but will ensure the completeness and well-formedness of any data that is shared. It is through the adherence to constraints that data retrieval can be in line with expectations and data quality upheld.

### 3.4 Deliver a model that is fit for global use

Legacy client data will have been captured by VASPs in numerous languages, character sets and structural conventions. Sharing this data across borders, to actors potentially spanning numerous geographies, requires conventions that will ensure that the format, as intended by the originator can be consumed in an expected, meaningful manner by all required VASPs.

### 3.5 Out of scope

It is beyond the scope of the Standard to describe mechanisms that will cater to:

- Information security;
- Data privacy and global compliance requirements;
- Identification of VASPs or other affected entities;
- Representation of verification status or mechanism of a VASP or other entity (for example, CDD/KYC data or other forms of due diligence data that is implementation, TSP or VASP specific);
- Network protocols, or other component leveraged in the mode of transmission;
- Storage of any data included in the payload by the originating or beneficiary VASP;
- The manner in which payload data is leveraged by the beneficiary VASP for the purposes of Recommendation 16, such as the requirement for a VASP to identify and report suspicious transactions, monitor the availability of information, take freezing actions, and prohibit transactions with designated persons and entities.

### 3.6 Layer model representing scope of IVMS101

The following diagram is intended to serve as a conceptual model characterising the partition of a technology platform to which the scope of IVMS101 applies.

![Conceptual model illustrating scope of IVMS101](layer-model-diagram)

*Figure 2: Conceptual model illustrating scope of IVMS101*

The model shows the following layers from top to bottom:
- **Presentation**: Visual representation of the data covered in IVMS101 is not in scope for the Standard
- **National character logic**: Logic related to translation, transliteration and mapping structural conventions is mandatory for the IVMS101 and may optionally be extended for data beyond the scope of IVMS101
- **Data model and constraints**: Scope of IVMS101 includes:
  - The data model
  - Data constraints
  - Global conventions
- **Implementation**: Implementation specific logic related to functionality of the platform leveraging IVMS101 is not in scope for the Standard
- **Messaging model**: Message characteristics & structures supporting payload transmission are not in scope for IVMS101
- **Interface**: Modes of transmission, including protocols are related to the sharing of data are not captured in IVMS101
- **Storage**: Matters related to the persistence, aggregation of data, data compliance and privacy are not in scope for IVMS101
- **Network**: IVMS101 does not include in scope the technical requirements for the sharing of data between counterparties

---

## 4 Data principles

### 4.1 Primary Principles

#### 4.1.1 Adaptability

The IVMS101 data model is able to withstand enhancement or correction and will not compromise the integrity of instances where data is structured in accordance with the Standard has already been shared or held.

#### 4.1.2 Expandability

The IVMS101 model is expandable to support additional requirements from the Standard, and also to permit it being used as a baseline from which subsequent data standards can be prepared.

#### 4.1.3 Fundamentality

The IVMS101 model provides the fundamental structures and rules related to the business entities that are deemed required for transmission between VASPs. As a design principle, the model may be wrapped in data structures supporting the implementation, should it be required. However, while the Standard does not preclude features and functionality from a platform that leverages the model, it will not incorporate proprietary or implementation specific objects or rules.

#### 4.1.4 Portability

The IVMS101 model is technology neutral. It can be codified across markup languages, notations and document specifications, and can be supported by disparate systems.

#### 4.1.5 Individual data points over aggregated or determined values

The IVMS101 model includes individual, granular data over aggregate or determined values. Where required, source data that would serve as inputs into determination logic is preferred over the output of such logic.

#### 4.1.6 Unambiguous data

The IVMS101 model holds data that is specific and not subject to interpretation. Through adherence to the Standard, the consumer of transmitted data will receive it as intended by the originating VASP.

### 4.2 Additional Principles

#### 4.2.1 Stay within the defined scope

In line with the scope set out in Section 3 (Scope of the Standard), the data model adheres to the following:

- The entity, component, attribute or relationship (if deemed necessary) is within the stated scope of IVMS101.
- The entity, component, attribute or relationship is necessary for the purposes of meeting the business challenge as stated in Section 2 (Background and rationale).
- The entity, component, attribute or relationship is specifically required to apply context to the data transmitted to meet the business challenge as stated in Section 2 (i.e. the data would be meaningless or ambiguous without such information).

#### 4.2.2 Group elements into reusable logical components

Elements are grouped into reusable components. Through the grouping of elements into reusable components, it is possible to avoid the duplication of efforts in oversight of each element as it applies to each component.

#### 4.2.3 Data model has been tested with the use of business examples

The data model is tested, both in its initial release and as it evolves, with real business examples to demonstrate the correctness and completeness of the data that may be transmitted.

#### 4.2.4 Leverage existing standards work

IVMS101 leverages relevant and appropriate standards, i.e. standards, by whatever name, issued, adopted and/or published by a standards-setting body.

---

## 5 Datatypes

### 5.1 Context for datatypes

This section describes the components and datatypes leveraged in those entities documented in Section 6 (Data model definition). Definitions to the terms used are available in Section 1.1, (Terms and Definitions).

### 5.2 Components

#### 5.2.1 Person

##### 5.2.1.1 Person structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| naturalPerson | [0..1] | NaturalPerson | C1, C2, C3, C6, C8 | {Or |
| legalPerson | [0..1] | LegalPerson | C3, C4, C5, C7, C8, C9, C10, C11 | Or} |

##### 5.2.1.2 Person constraints

**C1 OriginatorInformationNaturalPerson**

If the originator is a NaturalPerson either (geographicAddress with an addressType value of 'GEOG' or 'HOME' or 'BIZZ') and/or customerNumber and/or nationalIdentification and/or dateAndPlaceOfBirth is required.

**C2 DateInPast**

If dateOfBirth is specified, the date specified must be a historic date (i.e. a date prior to the current date).

**C3 Country**

The value used for the field country must be present on the ISO-3166-1 alpha-2 codes or the value XX.

**C4 OriginatorInformationLegalPerson**

If the originator is a LegalPerson either (geographicAddress with an addressType value of 'GEOG') and/or customerNumber and/or nationalIdentification is required.

**C5 LegalNamePresentLegalPerson**

At least one occurrence of legalPersonNameIdentifier must have the value 'LEGL' specified in the element legalPersonNameIdentifierType.

**C6 LegalNamePresentNaturalPerson**

At least one occurrence of naturalPersonNameID must have the value 'LEGL' specified in the element naturalPersonNameIdentifierType.

**C7 ValidNationalIdentifierLegalPerson**

A legal person must have a value for nationalIdentifierType of either 'RAID' or 'MISC' or 'LEIX' or 'TXID'.

**C8 ValidAddress**

There must be at least one occurrence of the element addressLine or (streetName and buildingName and/or buildingNumber).

**C9 CompleteNationalIdentifierLegalPerson**

A LegalPerson must not have a value for countryOfIssue and (must have a value for the element RegistrationAuthority if the value for nationalIdentifierType is not 'LEIX' and must not have a value for the element RegistrationAuthority if the value for nationalIdentifierType is 'LEIX').

**C10 RegistrationAuthority**

The value used for the applicable element must be present on the GLEIF Registration Authorities List.

**C11 ValidLEI**

A LegalPerson with a nationalIdentifierType of 'LEIX' must have a value for the element nationalIdentifier that adheres to the convention as stated in datatype 'LEIText'.

##### 5.2.1.3 Person elements

**5.2.1.3.1 naturalPerson**

- **Multiplicity:** [0..1]
- **Definition:** refers to a uniquely distinguishable individual; one single person.
- **Component:** NaturalPerson

**5.2.1.3.2 legalPerson**

- **Multiplicity:** [0..1]
- **Definition:** refers to any entity other than a natural person that can establish a permanent customer relationship with an affected entity or otherwise own property. This can include companies, bodies corporate, foundations, anstalt, partnerships, or associations and other relevantly similar entities.
- **Component:** LegalPerson

#### 5.2.2 NaturalPerson

##### 5.2.2.1 NaturalPerson structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| name | [1..n] | NaturalPersonName | C6 | |
| geographicAddress | [0..n] | Address | C1, C3, C8 | |
| nationalIdentification | [0..1] | NationalIdentification | C1, C3 | |
| customerIdentification | [0..1] | Text | C1 | |
| dateAndPlaceOfBirth | [0..1] | DateAndPlaceOfBirth | C1, C2 | |
| countryOfResidence | [0..1] | CountryCode | C3 | |

##### 5.2.2.2 NaturalPerson constraints

(Same constraints C1-C8 as listed in Person component)

##### 5.2.2.3 NaturalPerson elements

**5.2.2.3.1 name**

- **Multiplicity:** [1..1]
- **Definition:** the distinct words used as identification for an individual.
- **Component:** NaturalPersonName

**5.2.2.3.2 geographicAddress**

- **Multiplicity:** [0..n]
- **Definition:** the particulars of a location at which a person may be communicated with.
- **Component:** Address

**5.2.2.3.3 nationalIdentification**

- **Multiplicity:** [0..1]
- **Definition:** a distinct identifier used by governments of countries to uniquely identify a natural or legal person.
- **Component:** NationalIdentification

**5.2.2.3.4 customerIdentification**

- **Multiplicity:** [0..1]
- **Definition:** a distinct identifier that uniquely identifies the person to the institution in context.
- **Datatype:** "Max50Text"

**5.2.2.3.5 dateAndPlaceOfBirth**

- **Multiplicity:** [0..1]
- **Definition:** date and place of birth of a person.
- **Component:** DateAndPlaceOfBirth

**5.2.2.3.6 countryOfResidence**

- **Multiplicity:** [0..1]
- **Definition:** country in which a person resides (the place of a person's home).
- **Datatype:** "CountryCode"

#### 5.2.3 NaturalPersonName

##### 5.2.3.1 NaturalPersonName structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| nameIdentifier | [1..n] | NaturalPersonNameID | C6 | |
| localNameIdentifier | [0..n] | LocalNaturalPersonNameID | | |
| phoneticNameIdentifier | [0..n] | LocalNaturalPersonNameID | | |

##### 5.2.3.2 NaturalPersonName constraints

**C6 LegalNamePresentNaturalPerson**

At least one occurrence of naturalPersonNameID must have the value 'LEGL' specified in the element naturalPersonNameIdentifierType.

##### 5.2.3.3 NaturalPersonName elements

**5.2.3.3.1 nameIdentifier**

- **Multiplicity:** [1..n]
- **Definition:** full name separated into primary and secondary identifier.
- **Component:** NaturalPersonNameID

**5.2.3.3.2 localNameIdentifier**

- **Multiplicity:** [0..n]
- **Definition:** full name separated into primary and secondary identifier using local characters.
- **Component:** LocalNaturalPersonNameID

**5.2.3.3.3 phoneticNameIdentifier**

- **Multiplicity:** [0..n]
- **Definition:** Alternate representation of a name that corresponds to the manner the name is pronounced.
- **Component:** LocalNaturalPersonNameID

#### 5.2.4 NaturalPersonNameID

*Adapted from International Civil Aviation Organization (ICAO) Doc 9303, Machine Readable Travel Documents, Seventh Edition, 2015 Part 3: Specifications Common to all MRTDs, Section 3.4 Convention for Writing the Name of the Holder.*

##### 5.2.4.1 NaturalPersonNameID structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| primaryIdentifier | [1..1] | Text | | |
| secondaryIdentifier | [0..1] | Text | | |
| nameIdentifierType | [1..1] | SingleValueFromList | C6 | |

##### 5.2.4.2 NaturalPersonNameID constraints

**C6 LegalNamePresentNaturalPerson**

At least one occurrence of naturalPersonNameID must have the value 'LEGL' specified in the element naturalPersonNameIdentifierType.

##### 5.2.4.3 NaturalPersonNameID elements

**5.2.4.3.1 primaryIdentifier**

- **Multiplicity:** [1..1]
- **Definition:** This may be the family name, the maiden name or the married name, the main name, the surname, and in some cases, the entire name where the natural person's name cannot be divided into two parts, or where the sender is unable to divide the natural person's name into two parts.
- **Datatype:** "Max100Text"

**5.2.4.3.2 secondaryIdentifier**

- **Multiplicity:** [0..1]
- **Definition:** These may be the forenames, familiar names, given names, initials, prefixes, suffixes or Roman numerals (where considered to be legally part of the name) or any other secondary names.
- **Datatype:** "Max100Text"

**5.2.4.3.3 nameIdentifierType**

- **Multiplicity:** [1..1]
- **Definition:** The nature of the name specified.
- **Datatype:** "NaturalPersonNameTypeCode"

#### 5.2.5 LocalNaturalPersonNameID

*Adapted from International Civil Aviation Organization (ICAO) Doc 9303, Machine Readable Travel Documents, Seventh Edition, 2015 Part 3: Specifications Common to all MRTDs, Section 3.4 Convention for Writing the Name of the Holder.*

##### 5.2.5.1 LocalNaturalPersonNameID structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| primaryIdentifier | [1..1] | Text | | |
| secondaryIdentifier | [0..1] | Text | | |
| nameIdentifierType | [1..1] | SingleValueFromList | | |

##### 5.2.5.2 LocalNaturalPersonNameID constraints

There are no constraints that apply to the LocalNaturalPersonNameID component.

##### 5.2.5.3 LocalNaturalPersonNameID elements

**5.2.5.3.1 primaryIdentifier**

- **Multiplicity:** [1..1]
- **Definition:** This may be the family name, the maiden name or the married name, the main name, the surname, and in some cases, the entire name where the natural person's name cannot be divided into two parts, or where the sender is unable to divide the natural person's name into two parts.
- **Datatype:** "LocalMax100Text"

**5.2.5.3.2 secondaryIdentifier**

- **Multiplicity:** [0..1]
- **Definition:** These may be the forenames, familiar names, given names, initials, prefixes, suffixes or Roman numerals (where considered to be legally part of the name) or any other secondary names.
- **Datatype:** "LocalMax100Text"

**5.2.5.3.3 nameIdentifierType**

- **Multiplicity:** [1..1]
- **Definition:** The nature of the name specified.
- **Datatype:** "NaturalPersonNameTypeCode"

#### 5.2.6 Address

*Adapted from ISO20022 registered message component PostalAddress6.*

##### 5.2.6.1 Address structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| addressType | [1..1] | SingleValueFromList | | |
| department | [0..1] | Text | | |
| subDepartment | [0..1] | Text | | |
| streetName | [0..1] | Text | C8 | |
| buildingNumber | [0..1] | Text | C8 | |
| buildingName | [0..1] | Text | C8 | |
| floor | [0..1] | Text | | |
| postBox | [0..1] | Text | | |
| room | [0..1] | Text | | |
| postcode | [0..1] | Text | | |
| townName | [1..1] | Text | | |
| townLocationName | [0..1] | Text | | |
| districtName | [0..1] | Text | | |
| countrySubDivision | [0..1] | Text | | |
| addressLine | [0..7] | Text | C8 | |
| country | [1..1] | CountryCode | C3 | |

##### 5.2.6.2 Address constraints

**C3 Country**

The value used for the field country must be present on the ISO-3166-1 alpha-2 codes or the value XX.

**C8 ValidAddress**

There must be at least one occurrence of the element addressLine or (streetName and buildingName and/or buildingNumber).

##### 5.2.6.3 Address elements

**5.2.6.3.1 addressType**

- **Multiplicity:** [1..1]
- **Definition:** Identifies the nature of the address.
- **Datatype:** "AddressTypeCode"

**5.2.6.3.2 department**

- **Multiplicity:** [0..1]
- **Definition:** Identification of a division of a large organisation or building.
- **Datatype:** "Max50Text"

**5.2.6.3.3 subDepartment**

- **Multiplicity:** [0..1]
- **Definition:** Identification of a sub-division of a large organisation or building.
- **Datatype:** "Max70Text"

**5.2.6.3.4 streetName**

- **Multiplicity:** [0..1]
- **Definition:** Name of a street or thoroughfare.
- **Datatype:** "Max70Text"

**5.2.6.3.5 buildingNumber**

- **Multiplicity:** [0..1]
- **Definition:** Number that identifies the position of a building on a street.
- **Datatype:** "Max16Text"

**5.2.6.3.6 buildingName**

- **Multiplicity:** [0..1]
- **Definition:** Name of the building or house.
- **Datatype:** "Max35Text"

**5.2.6.3.7 floor**

- **Multiplicity:** [0..1]
- **Definition:** Floor or storey within a building.
- **Datatype:** "Max70Text"

**5.2.6.3.8 postBox**

- **Multiplicity:** [0..1]
- **Definition:** Numbered box in a post office, assigned to a person or organisation, where letters are kept until called for.
- **Datatype:** "Max16Text"

**5.2.6.3.9 room**

- **Multiplicity:** [0..1]
- **Definition:** Building room number.
- **Datatype:** "Max70Text"

**5.2.6.3.10 postCode**

- **Multiplicity:** [0..1]
- **Definition:** Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.
- **Datatype:** "Max16Text"

**5.2.6.3.11 townName**

- **Multiplicity:** [0..1]
- **Definition:** Name of a built-up area, with defined boundaries, and a local government.
- **Datatype:** "Max35Text"

**5.2.6.3.12 townLocationName**

- **Multiplicity:** [0..1]
- **Definition:** Specific location name within the town.
- **Datatype:** "Max35Text"

**5.2.6.3.13 districtName**

- **Multiplicity:** [0..1]
- **Definition:** Identifies a subdivision within a country subdivision.
- **Datatype:** "Max35Text"

**5.2.6.3.14 countrySubDivision**

- **Multiplicity:** [0..1]
- **Definition:** Identifies a subdivision of a country for example, state, region, province, départment or county.
- **Datatype:** "Max35Text"

**5.2.6.3.15 addressLine**

- **Multiplicity:** [0..7]
- **Definition:** Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
- **Datatype:** "Max70Text"

**5.2.6.3.16 country**

- **Multiplicity:** [1..1]
- **Definition:** Nation with its own government.
- **Datatype:** "CountryCode"

#### 5.2.7 DateAndPlaceOfBirth

*Adapted from International Civil Aviation Organization (ICAO) Doc 9303, Machine Readable Travel Documents, Seventh Edition, 2015 Part 3: Specifications Common to all MRTDs, Section 3.7 Representation of Place of Birth.*

##### 5.2.7.1 DateAndPlaceOfBirth structure

| Element | Multiplicity | Type | Constraint | Or |
|---------|--------------|------|------------|-----|
| dateOfBirth | [1..1] | Date | C2 | |
| placeOfBirth | [1..1] | Text | | |

##### 5.2.7.2 DateAndPlaceOfBirth constraints

**C2 DateInPast**

If dateOfBirth is specified, the date specified must be a historic date (i.e. a date prior to the current date)

##### 5.2.7.3 DateAndPlaceOfBirth elements

**5.2.7.3.1 dateOfBirth**

- **Multiplicity:** [1..1]
- **Definition:** Date on which a person is born.
- **Datatype:** Date

**5.2.7.3.2 placeOfBirth**

- **Multiplicity:** [1..1]
- **Definition:** The town and/or the city and/or the suburb and/or the country subdivision and/or the country where the person was born.
- **Datatype:** "Max70Text"

#### 5.2.8 NationalIdentification

##### 5.2.8.1 NationalIdentification structure

| Element | Multiplicity | Type | Constraint | Or |
|---------|--------------|------|------------|-----|
| nationalIdentifier | [1..1] | Text | C11 | |
| nationalIdentifierType | [1..1] | SingleValueFromList | C7, C9, C11 | |
| countryOfIssue | [0..1] | CountryCode | C3 | |
| registrationAuthority | [0..1] | RegistrationAuthority | C9, C10 | |

##### 5.2.8.2 NationalIdentification constraints

**C3 Country**

The value used for the field country must be present on the ISO-3166-1 alpha-2 codes or the value XX.

**C7 ValidNationalIdentifierLegalPerson**

A legal person must have a value for nationalIdentifierType of either 'RAID' or 'MISC' or 'LEIX' or 'TXID'.

**C9 CompleteNationalIdentifierLegalPerson**

A LegalPerson must not have a value for countryOfIssue and (must have a value for the element RegistrationAuthority if the value for nationalIdentifierType is not 'LEIX' and must not have a value for the element RegistrationAuthority if the value for nationalIdentifierType is 'LEIX').

**C10 RegistrationAuthority**

The value used for the applicable element must be present on the GLEIF Registration Authorities List.

**C11 ValidLEI**

A LegalPerson with a nationalIdentifierType of 'LEIX' must have a value for the element nationalIdentifier that adheres to the convention as stated in datatype 'LEIText'.

##### 5.2.8.3 NationalIdentification elements

**5.2.8.3.1 nationalIdentifier**

- **Multiplicity:** [1..1]
- **Definition:** An identifier issued by an appropriate issuing authority.
- **Datatype:** "Max35Text"

**5.2.8.3.2 nationalIdentifierType**

- **Multiplicity:** [1..1]
- **Definition:** Specifies the type of identifier specified.
- **Datatype:** "NationalIdentifierTypeCode"

**5.2.8.3.3 countryOfIssue**

- **Multiplicity:** [0..1]
- **Definition:** Country of the issuing authority.
- **Datatype:** "CountryCode"

**5.2.8.3.4 registrationAuthority**

- **Multiplicity:** [0..1]
- **Definition:** A code specifying the registration authority.
- **Datatype:** "RegistrationAuthority"

#### 5.2.9 LegalPerson

##### 5.2.9.1 LegalPerson structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| name | [1..1] | LegalPersonName | C5 | |
| geographicAddress | [0..n] | Address | C3, C4, C8 | |
| customerIdentification | [0..1] | Text | C4 | |
| nationalIdentification | [0..1] | NationalIdentification | C3, C4, C7, C9, C10, C11 | |
| countryOfRegistration | [0..1] | CountryCode | C3 | |

##### 5.2.9.2 LegalPerson constraints

(Same constraints C3-C11 as applicable)

##### 5.2.9.3 LegalPerson elements

**5.2.9.3.1 name**

- **Multiplicity:** [1..1]
- **Definition:** The name of the legal person.
- **Component:** LegalPersonName

**5.2.9.3.2 geographicAddress**

- **Multiplicity:** [0..1]
- **Definition:** The address of the legal person.
- **Component:** Address

**5.2.9.3.3 customerNumber**

- **Multiplicity:** [0..1]
- **Definition:** The unique identification number applied by the VASP to customer.
- **Datatype:** "Max50Text"

**5.2.9.3.4 nationalIdentification**

- **Multiplicity:** [0..1]
- **Definition:** A distinct identifier used by governments of countries to uniquely identify a natural or legal person.
- **Component:** NationalIdentification

**5.2.9.3.5 countryOfRegistration**

- **Multiplicity:** [0..1]
- **Definition:** The country in which the legal person is registered.
- **Datatype:** "CountryCode"

#### 5.2.10 LegalPersonName

##### 5.2.10.1 LegalPersonName structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| nameIdentifier | [1..n] | LegalPersonNameID | C5 | |
| localNameIdentifier | [0..n] | LocalLegalPersonNameID | | |
| phoneticNameIdentifier | [0..n] | LocalLegalPersonNameID | | |

##### 5.2.10.2 LegalPersonName constraints

**C5 LegalNamePresent**

At least one occurrence of legalPersonNameIdentifier must have the value 'LEGL' specified in the element legalPersonNameIdentifierType.

##### 5.2.10.3 LegalPersonName elements

**5.2.10.3.1 nameIdentifier**

- **Multiplicity:** [1..n]
- **Definition:** The name and type of name by which the legal person is known.
- **Component:** LegalPersonNameID

**5.2.10.3.2 localNameIdentifier**

- **Multiplicity:** [0..n]
- **Definition:** The name and type of name by which the legal person is known using local characters.
- **Component:** LocalLegalPersonNameID

**5.2.10.3.3 phoneticNameIdentifier**

- **Multiplicity:** [0..n]
- **Definition:** The name and type of name by which the legal person is known using local characters.
- **Component:** LocalLegalPersonNameID

#### 5.2.11 LegalPersonNameID

##### 5.2.11.1 LegalPersonNameID structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| legalPersonName | [1..1] | Text | | |
| legalPersonNameIdentifierType | [1..1] | SingleValueFromList | C5 | |

##### 5.2.11.2 LegalPersonNameID constraints

**C5 LegalNamePresent**

At least one occurrence of legalPersonNameIdentifier must have the value 'LEGL' specified in the element legalPersonNameIdentifierType.

##### 5.2.11.3 LegalPersonNameID elements

**5.2.11.3.1 legalPersonName**

- **Multiplicity:** [1..1]
- **Definition:** Name by which the legal person is known.
- **Datatype:** "Max100Text"

**5.2.11.3.2 legalPersonNameIdentifierType**

- **Multiplicity:** [1..1]
- **Definition:** The nature of the name specified.
- **Datatype:** "LegalPersonNameTypeCode"

#### 5.2.12 LocalLegalPersonNameID

##### 5.2.12.1 LocalLegalPersonNameID structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| legalPersonName | [1..1] | Text | | |
| legalPersonNameIdentifierType | [1..1] | SingleValueFromList | | |

##### 5.2.12.2 LocalLegalPersonNameID constraints

There are no constraints that apply to the LocalLegalPersonNameID component.

##### 5.2.12.3 LocalLegalPersonNameID elements

**5.2.12.3.1 legalPersonName**

- **Multiplicity:** [1..n]
- **Definition:** Name by which the legal person is known.
- **Datatype:** "LocalMax100Text"

**5.2.12.3.2 legalPersonNameIdentifierType**

- **Multiplicity:** [1..1]
- **Definition:** The nature of the name specified.
- **Datatype:** "LegalPersonNameTypeCode"

#### 5.2.13 IntermediaryVASP

##### 5.2.13.1 IntermediaryVASP structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| intermediaryVASP | [1..1] | Person | C1, C2, C3, C4, C5, C6, C7, C8, C9, C10, C11 | |
| sequence | [1..1] | Number | C12 | |

##### 5.2.13.2 IntermediaryVASP constraints

(Same constraints C1-C11 as applicable, plus:)

**C12 sequentialIntegrity**

Occurrences of this component must have a corresponding sequence value starting from 0 and remain uninterrupted through to the final instance.

##### 5.2.13.3 IntermediaryVASP elements

**5.2.13.3.1 intermediaryVASP**

- **Multiplicity:** [1..1]
- **Definition:** the VASP in a serial chain that receives and retransmits a VA transfer on behalf of the originating VASP and the beneficiary VASP, or another intermediary VASP.
- **Component:** Person

**5.2.13.3.2 sequence**

- **Multiplicity:** [1..1]
- **Definition:** the sequence in a serial chain at which the corresponding intermediary VASP participates in the transfer.
- **Datatype:** "Number"

### 5.3 Datatypes

#### 5.3.1 "Max100Text"

- **Definition:** A character string that is restricted to a maximum length of 100 characters, limited to Latin characters and numbers.
- **Type:** Text
- **Format:**
  - Minimum Length: 1
  - Maximum Length: 100
- **Regex:** `^[a-zA-Z0-9' ]{1,100}$`

#### 5.3.2 "LocalMax100Text"

- **Definition:** A character string that is restricted to a maximum length of 100 characters.
- **Type:** Text
- **Format:**
  - Minimum Length: 1
  - Maximum Length: 100
- **Regex:** `^.{1,100}$`

#### 5.3.3 "Max50Text"

- **Definition:** A character string that is restricted to a maximum length of 50 characters, limited to Latin characters and numbers.
- **Type:** Text
- **Format:**
  - Minimum Length: 1
  - Maximum Length: 50
- **Regex:** `^[a-zA-Z0-9' ]{1,50}$`

#### 5.3.4 "Max70Text"

- **Definition:** A character string that is restricted to a maximum length of 70 characters, limited to Latin characters and numbers.
- **Type:** Text
- **Format:**
  - Minimum Length: 1
  - Maximum Length: 70
- **Regex:** `^[a-zA-Z0-9' ]{1,70}$`

#### 5.3.5 "Max35Text"

- **Definition:** A character string that is restricted to a maximum length of 35 characters, limited to Latin characters and numbers.
- **Type:** Text
- **Format:**
  - Minimum Length: 1
  - Maximum Length: 35
- **Regex:** `^[a-zA-Z0-9' ]{1,35}$`

#### 5.3.6 "Max16Text"

- **Definition:** A character string that is restricted to a maximum length of 16 characters, limited to Latin characters and numbers.
- **Type:** Text
- **Format:**
  - Minimum Length: 1
  - Maximum Length: 16
- **Regex:** `^[a-zA-Z0-9' ]{1,16}$`

#### 5.3.7 "LEIText"

- **Definition:** a 20-character, alpha-numeric code.
- **Type:** Text
- **Format:**
  - Minimum Length: 20
  - Maximum Length: 20
- **Regex:** `^[0-9A-Z]{18}[0-9]{2}$`

#### 5.3.8 "NaturalPersonNameTypeCode"

**Definition:** A single value corresponding to the nature of name being adopted.

| Code | Name | Description |
|------|------|-------------|
| ALIA | Alias name | A name other than the legal name by which a natural person is also known. |
| BIRT | Name at birth | The name given to a natural person at birth. |
| MAID | Maiden name | The original name of a natural person who has changed their name after marriage. |
| LEGL | Legal name | The name that identifies a natural person for legal, official or administrative purposes. |
| MISC | Unspecified | A name by which a natural person may be known but which cannot otherwise be categorized or the category of which the sender is unable to determine. |

#### 5.3.9 "LegalPersonNameTypeCode"

**Definition:** A single value corresponding to the nature of name being specified for the legal person.

| Code | Name | Description |
|------|------|-------------|
| LEGL | Legal name | Official name under which an organisation is registered. |
| SHRT | Short name | Specifies the short name of the organisation. |
| TRAD | Trading name | Name used by a business for commercial purposes, although its registered legal name, used for contracts and other formal situations, may be another. |

#### 5.3.10 "Date"

- **Definition:** A point in time, represented as a day within the calendar year. Compliant with ISO 8601.
- **Type:** Text
- **Format:** YYYY-MM-DD
- **Regex:** `^([0-9]{4})-([0-9]{2})-([0-9]{2})$`

#### 5.3.11 "AddressTypeCode"

**Definition:** Identifies the nature of the address.

| Code | Name | Description |
|------|------|-------------|
| HOME | Residential | Address is the home address. |
| BIZZ | Business | Address is the business address. |
| GEOG | Geographic | Address is the unspecified physical (geographical) address suitable for identification of the natural or legal person. |

*Note: GEOG is an additional 'Address Type' value for the purposes of IVMS101; covers any physical / geographic address type held by the VASP on their client.*

#### 5.3.12 "CountryCode"

- **Definition:** two alphabetic characters representing an ISO-3166 Alpha-2 country, including the code 'XX' to represent 'an indicator for unknown States, other entities or organisations'.
- **Type:** Text
- **Format:** AA
- **Regex:** `^[A-Z]{2}$`

*Reference: World International Property Organisation Standard ST.3 Recommended standard on two-letter codes for the representation of states, other entities and intergovernmental organizations, Paragraph 6.*

#### 5.3.13 "RegistrationAuthority"

- **Definition:** 8-character code representing a legal entity registration authority.
- **Type:** Text
- **Format:** RA000099
- **Regex:** `^RA([0-9]{6})$`

*Registration Authority Code, as published by the Global Legal Entity Identifier Foundation (GLEIF), Registration Authorities List.*

#### 5.3.14 "NationalIdentifierTypeCode"

**Definition:** Identifies the national identification type.

*NationalIdentifierTypeCode applies a restriction over the codes present in ISO20022 datatype 'TypeOfIdentification4Code'.*

| Code | Name | Description |
|------|------|-------------|
| ARNU | Alien registration number | Number assigned by a government agency to identify foreign nationals. |
| CCPT | Passport number | Number assigned by a passport authority. |
| RAID | Registration authority identifier | Identifier of a legal entity as maintained by a registration authority. |
| DRLC | Driver license number | Number assigned to a driver's license. |
| FIIN | Foreign investment identity number | Number assigned to a foreign investor (other than the alien number). |
| TXID | Tax identification number | Number assigned by a tax authority to an entity. |
| SOCS | Social security number | Number assigned by a social security agency. |
| IDCD | Identity card number | Number assigned by a national authority to an identity card. |
| LEIX | Legal Entity Identifier | Legal Entity Identifier (LEI) assigned in accordance with ISO 17442. |
| MISC | Unspecified | A national identifier which may be known but which cannot otherwise be categorized or the category of which the sender is unable to determine. |

*The LEI is a 20-character, alpha-numeric code that enables clear and unique identification of legal entities participating in financial transactions.*

#### 5.3.15 "Number"

- **Definition:** Number represented as an integer.
- **Format:**
  - totalDigits: 18
  - fractionDigits: 0

#### 5.3.16 "TransliterationMethodCode"

**Definition:** Identifies the national script from which transliteration to Latin script is applied.

*Datatype list 'TransliterationMethodCode' uses the four-letter script code as presented in ISO 15924, Codes for the representation of names of scripts.*

| Code | Script | Standard |
|------|--------|----------|
| arab | Arabic (Arabic language) | ISO 233-2:1993 |
| aran | Arabic (Persian language) | ISO 233-3:1999 |
| armn | Armenian | ISO 9985:1996 |
| cyrl | Cyrillic | ISO 9:1995 |
| deva | Devanagari & related Indic | ISO 15919:2001 |
| geor | Georgian | ISO 9984:1996 |
| grek | Greek | ISO 843:1997 |
| hani | Han (Hanzi, Kanji, Hanja) | ISO 7098:2015 |
| hebr | Hebrew | ISO 259-2:1994 |
| kana | Kana | ISO 3602:1989 |
| kore | Korean | Revised Romanization of Korean |
| thai | Thai | ISO 11940-2:2007 |
| othr | Script other than those listed above | Unspecified |

---

## 6 Data model definition

### 6.1 Context for the data model

This section describes the entities identified as being in scope as set out in Section 2 (Background & Rationale). It includes the structures and constraints applicable to the following entities:

- Originator
- Beneficiary
- Originating VASP
- Beneficiary VASP
- Transfer path
- Payload metadata

### 6.2 Originator

The originator is defined in Section 1.1 as the account holder who allows the VA transfer from that account or, where there is no account, the natural or legal person that places the order with the originating VASP to perform the VA transfer.

#### 6.2.1 Originator structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| originatorPersons | [1..n] | Person | C1, C2, C3, C4, C5, C6, C7, C8, C9, C10, C11 | |
| accountNumber | [0..n] | Text | | |

#### 6.2.2 Originator constraints

(All constraints C1-C11 as previously defined apply)

#### 6.2.3 Originator elements

**originatorPersons**

- **Multiplicity:** [1..n]
- **Definition:** the account holder who allows the VA transfer from that account or, where there is no account, the natural or legal person that places the order with the originating VASP to perform the VA transfer.
- **Component:** Person

**accountNumber**

- **Multiplicity:** [0..1]
- **Definition:** Identifier of an account that is used to process the transaction. The value for this element is case-sensitive.
- **Datatype:** "Max100Text"

### 6.3 Beneficiary

The beneficiary is defined in Section 1.1 as the natural or legal person or legal arrangement who is identified by the originator as the receiver of the requested VA transfer.

#### 6.3.1 Beneficiary structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| beneficiaryPerson | [1..n] | Person | C1, C2, C3, C4, C5, C6, C7, C8, C9, C10, C11 | |
| accountNumber | [0..n] | Text | | |

#### 6.3.2 Beneficiary constraints

(All constraints C1-C11 as previously defined apply)

#### 6.3.3 Beneficiary elements

**beneficiaryPerson**

- **Multiplicity:** [1..n]
- **Definition:** the natural or legal person or legal arrangement who is identified by the originator as the receiver of the requested VA transfer.
- **Component:** Person

**accountNumber**

- **Multiplicity:** [0..1]
- **Definition:** Identifier of an account that is used to process the transaction. The value for this element is case-sensitive.
- **Datatype:** "Max100Text"

### 6.4 OriginatingVASP

The originating VASP is defined in Section 1.1 as the VASP which initiates the VA transfer, and transfers the VA upon receiving the request for a VA transfer on behalf of the originator.

#### 6.4.1 OriginatingVASP structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| originatingVASP | [0..1] | Person | C1, C2, C3, C4, C5, C6, C7, C8, C9, C10, C11 | |

#### 6.4.2 OriginatingVASP constraints

(All constraints C1-C11 as previously defined apply)

#### 6.4.3 OriginatingVASP elements

**originatingVASP**

- **Multiplicity:** [0..1]
- **Definition:** refers to the VASP which initiates the VA transfer, and transfers the VA upon receiving the request for a VA transfer on behalf of the originator.
- **Component:** Person

### 6.5 BeneficiaryVASP

The beneficiary is defined in Section 1.1 as the VASP which receives the transfer of a virtual asset from the originating VASP directly or through an intermediary VASP and makes the funds available to the beneficiary.

#### 6.5.1 BeneficiaryVASP structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| beneficiaryVASP | [0..1] | Person | C1, C2, C3, C4, C5, C6, C7, C8, C9, C10, C11 | |

#### 6.5.2 BeneficiaryVASP constraints

(All constraints C1-C11 as previously defined apply)

#### 6.5.3 BeneficiaryVASP elements

**beneficiaryVASP**

- **Multiplicity:** [0..1]
- **Definition:** the VASP which receives the transfer of a virtual asset from the originating VASP directly or through an intermediary VASP and makes the funds available to the beneficiary.
- **Component:** Person

### 6.6 TransferPath

The transfer path refers to the intermediary VASP(s) participating in a serial chain that receive(s) and retransmit(s) a VA transfer on behalf of the originating VASP and the beneficiary VASP, or another intermediary VASP, together with their corresponding sequence number.

#### 6.6.1 TransferPath structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| transferPath | [0..n] | IntermediaryVASP | C1, C2, C3, C4, C5, C6, C7, C8, C9, C10, C11, C12 | |

#### 6.6.2 TransferPath constraints

(All constraints C1-C12 as previously defined apply)

#### 6.6.3 TransferPath elements

**transferPath**

- **Multiplicity:** [0..n]
- **Definition:** the intermediary VASP(s) participating in a serial chain that receive and retransmit a VA transfer on behalf of the originating VASP and the beneficiary VASP, or another intermediary VASP, together with their corresponding sequence number.
- **Component:** IntermediaryVASP

### 6.7 PayloadMetadata

Data describing the contents of the payload.

#### 6.7.1 PayloadMetadata structure

| Element | Multiplicity | Type | Constraint | OR |
|---------|--------------|------|------------|-----|
| transliterationMethod | [0..n] | SingleValueFromList | | |

#### 6.7.2 PayloadMetadata constraints

There are no constraints that apply to the PayloadMetadata entity.

#### 6.7.3 PayloadMetadata elements

**transliterationMethod**

- **Multiplicity:** [0..n]
- **Definition:** the method used to map from a national system of writing to Latin script.
- **Datatype:** "TransliterationMethodCode"

---

## 7 Handling of multiple character sets

### 7.1 Character set and character encoding

Data shall be submitted using UTF-8 character encoding. Unless otherwise specified, data shall be represented in Latin script (i.e. A to Z, a to z) and Arabic numerals (i.e. 1234567890).

### 7.2 Transformation of national language

Where data is in a national language that does not use Latin script, it must be either:

- Transliterated into Latin characters; or
- Translated into a language to which it may be more commonly known to the international community.

Data may also be transmitted using national language where a suitable element exists (i.e. those elements prefixed 'local').

*Adapted from International Civil Aviation Organization (ICAO) Doc 9303, Machine Readable Travel Documents, Seventh Edition, 2015 Part 3: Specifications Common to all MRTDs, Section 3.1 Languages and Characters.*

### 7.3 Transliteration standards

The following scripts shall be transliterated into Latin characters using the corresponding standards set out below:

| Script | Standard |
|--------|----------|
| Arabic (Arabic language) | ISO 233-2:1993 |
| Arabic (Persian language) | ISO 233-3:1999 |
| Armenian | ISO 9985:1996 |
| Cyrillic | ISO 9:1995 |
| Devanagari & related Indic | ISO 15919:2001 |
| Han (Hanzi, Kanji, Hanja) | ISO 7098:2015 |
| Hebrew | ISO 259-2:1994 |
| Georgian | ISO 9984:1996 |
| Greek | ISO 843:1997 |
| Kana | ISO 3602:1989 |
| Korean | Revised Romanization of Korean |
| Thai | ISO 11940-2:2007 |

*National Institute of Korean Language, Romanization of Korean: https://www.korean.go.kr/front_eng/roman/roman_01.do*

---

## 8 Business examples

### 8.1 Example 1

VASP A, on behalf of originator Alice Smith, transfers 1BTC to Bob Barnes, who holds a custodial wallet with VASP B.

**Originator**

Dr Alice Smith is an American national residing at 1 Weathering Views, 24 Potential Street, 91765, Walnut, California USA. She was born on the 25th of February 1990.

**Beneficiary**

Mr. Bob Barnes is a Canadian national residing at 42 St Johns Close, Pershing Wells, PW3 9NZ London, UK. He was born on the 14th of January 1963 in London, Ontario.

**Originating VASP**

VASP A is a financial institution providing covered VA activities. For the purposes of sharing identification information per Recommendation 16, VASP A uses the geographic address of the customer. The VASP has also been assigned an LEI, which is 3M5E1GQKGL17HI8CPN20.

**Business Data**

The IVMS101 payload between VASP A and VASP B:

| Element | Content |
|---------|---------|
| **Originator** | |
| originatorPersons | |
| naturalPerson | |
| name* | |
| nameIdentifier* | |
| primaryIdentifier | Smith |
| secondaryIdentifier | Dr Alice |
| nameIdentifierType | LEGL |
| geographicAddress | |
| addressType | GEOG |
| streetName | Potential Street |
| buildingNumber | 24 |
| buildingName | Weathering Views |
| postcode | 91765 |
| townName | Walnut |
| countrySubDivision | California |
| country | US |
| customerIdentification | 1002390 |
| accountNumber | 10023909 |
| **Beneficiary** | |
| beneficiaryPersons | |
| naturalPerson | |
| name* | |
| nameIdentifier* | |
| primaryIdentifier | Barnes |
| secondaryIdentifier | Robert |
| nameIdentifierType | LEGL |
| accountNumber | 1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2 |
| **OriginatingVASP** | |
| originatingVASP | |
| name* | |
| nameIdentifier* | |
| legalPersonName | VASP A |
| legalPersonNameIdentifierType | LEGL |
| nationalIdentification | |
| nationalIdentifier | 3M5E1GQKGL17HI8CPN20 |
| nationalIdentifierType | LEIX |

*Note: In Example 1, the method selected by the VASP to identify the originator is the Geographic Address.*

### 8.2 Example 2

VASP C, on behalf of originator 吴信利 (Xinli Wu), transfers 1 ETH to ABC Limited (trading as CBA Trading), which holds a custodial wallet with VASP D. VASP C routes ETH transfers through the intermediary VASP E.

**Originator**

吴信利 (Xinli Wu) is a Chinese national residing in Dar es Salaam, Tanzania. He operates as a sole trader, contracting for a multi-national construction firm in providing civil engineering expertise. Xinli Wu is registered as such under his own name by the Business Registrations and Licensing Agency (BRELA), registration number 446005. Xinli Wu uses VASP C for safekeeping, exchanging and remittances of virtual assets used in a business capacity.

**Beneficiary**

ABC Limited also goes by the registered trading name of CBA Trading in Santiago, Chile. The beneficiary holds a managed wallet with VASP D.

**Originating VASP**

VASP C serves as an exchange for virtual assets, custodial wallet provider and provides a means to send and receive virtual assets. Each managed wallet is assigned a unique identifier. For the purposes of sharing identification information per Recommendation 16, VASP C uses the national identifier of the customer.

**Transfer Path**

VASP C routes ETH transfers through the intermediary VASP E.

**Business Data**

The IVMS101 payload between VASP C and VASP D:

| Element | Content |
|---------|---------|
| **Originator** | |
| originatorPersons | |
| naturalPerson | |
| name* | |
| nameIdentifier* | |
| primaryIdentifier | Wu |
| secondaryIdentifier | Xinli |
| nameIdentifierType | LEGL |
| localNameIdentifier | |
| primaryIdentifier | 吴 |
| secondaryIdentifier | 信利 |
| nameIdentifierType | LEGL |
| nationalIdentification | |
| nationalIdentifier | 446005 |
| nationalIdentifierType | RAID |
| registrationAuthority | RA000553 |
| countryOfResidence | TZ |
| **Beneficiary** | |
| beneficiaryPersons | |
| legalPerson | |
| name* | |
| nameIdentifier* | |
| legalPersonName | ABC Limited |
| legalPersonNameIdentifierType | LEGL |
| nameIdentifier | |
| legalPersonName | CBA Trading |
| legalPersonNameIdentifierType | TRAD |
| accountNumber | 00010190CBATRAD |
| **PayloadMetadata** | |
| transliterationMethod | hani |
| **TransferPath** | |
| transferPath | |
| intermediaryVASP | |
| legalPerson | |
| name* | |
| nameIdentifier* | |
| legalPersonName | VASP E |
| legalPersonNameIdentifierType | LEGL |
| sequence | 0 |

*Note: In Example 2, the method selected by the VASP to identify the originator is the National Identifier.*

---

*IVMS101 interVASP data model standard Issue 1 FINAL*