ISO 20022-1:2026

Financial services — Universal financial industry message scheme — Part 1: Metamodel

This document specifies: the overall description of the modelling approach; the overall description of the ISO 20022 Repository (hereby referred to as Repository) contents; a high-level description of the input to be accepted by the Registration Authority to feed/modify the Repository’s DataDictionary and BusinessProcessCatalogue; a high-level description of the Repository output to be made publicly available by the Registration Authority. BusinessTransactions and MessageSets Conforming with ISO 20022 series can be used for electronic data interchange amongst any industry participants (financial and others), independently of any specific communication network. Network-dependent rules, such as message acknowledgement and message protection, are beyond the scope of the ISO 20022 series.

Services financiers — Schéma universel de messages pour l'industrie financière — Partie 1: Métamodèle

General Information

• Status: Published
• Publication Date: 12-Apr-2026
• ICS: 03.060 - Finances. Banking. Monetary systems. Insurance
• Technical Committee: ISO/TC 68/SC 9 - Information exchange for financial services
• Drafting Committee: ISO/TC 68/SC 9 - Information exchange for financial services
• Current Stage: 6060 - International Standard published
• Start Date: 13-Apr-2026
• Due Date: 23-Dec-2025
• Completion Date: 13-Apr-2026

Relations

• Revises: ISO 20022-1:2013 - Financial services — Universal financial industry message scheme — Part 1: Metamodel
• Effective Date: 06-Jun-2022

Overview

ISO/FDIS 20022-1 - Financial services - Universal financial industry message scheme - Part 1: Metamodel - defines the metamodel and repository framework that underpin the ISO 20022 message scheme. It specifies the modelling approach, the content and structure of the ISO 20022 Repository (DataDictionary and BusinessProcessCatalogue), and the high‑level rules for what the Registration Authority accepts as input and publishes as repository output. The standard supports a model‑driven approach to financial messaging so BusinessTransactions and Message Sets can be used for electronic data interchange across the industry, independent of any particular communication network. Network‑dependent rules (e.g., acknowledgements, message protection) are explicitly out of scope.

Key topics and technical requirements

• Metamodel structure: Defines packages and components that describe messaging at multiple modelling levels - Scope, Conceptual, Logical, and Physical - and the allowed transformations between these levels.
• Type Library: A normative set of base types, enumerations and binary/string/text conventions used across messages.
• Repository contents and structure: Formal description of the DataDictionary and BusinessProcessCatalogue, including item lists, lifecycle and registration status.
• Registration rules: High‑level input expected by the Registration Authority to add or modify Repository items and expected Repository outputs and formats for public access.
• Model transformations: Rules and traces for converting Scope→Conceptual→Logical→Physical models; includes relationships such as MessageSet, Choreography and Conversation traces.
• Conformance and versioning: Defined notions of “Conformance” (replacing earlier use of “compliance”), minor version properties (revision, variation), draft handling, and version relationships among repository concepts.
• Notable updates (third edition): Adoption of ISO/IEC 11404 (replacing XML Schema for type definitions except for XML temporal types), formalising CodeSet→BusinessCodeSet trace, and other clarifications to cardinality and naming.

Applications and who uses it

ISO 20022-1 is intended for:

• Banks, market infrastructures and payment schemes building or harmonizing message sets.
• Solution architects and developers implementing ISO 20022 message parsers, validators, and translators.
• Fintech vendors and middleware providers that map conceptual financial business processes to physical message formats.
• Standards bodies and the Registration Authority for accepting, registering and publishing Repository items. Practical uses include designing interoperable message schemas, managing a canonical DataDictionary, mapping business processes to technical interfaces, and ensuring consistent message metadata and version control.

Related standards

• ISO 20022 series (other parts defining message definitions, registration procedures)
• ISO/IEC 11404 (type system adopted in this edition)
• Predecessor: ISO 15022 (historical context)

Keywords: ISO 20022-1, ISO/FDIS 20022-1, metamodel, ISO 20022 Repository, DataDictionary, BusinessProcessCatalogue, financial messaging, Registration Authority, model-driven messaging.

Standards Content (Sample)

International
Standard
ISO 20022-1
Third edition
Financial services — Universal
2026-04
financial industry message
scheme —
Part 1:
Metamodel
Services financiers — Schéma universel de messages pour
l'industrie financière —
Partie 1: Métamodèle
Reference number
© ISO 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Type Library .11
5 Metamodel packages .13
5.1 General . 13
5.2 The metamodel’s use of ISO20022::TypeLibrary . 13
5.3 Levels .14
5.3.1 General .14
5.3.2 Scope level . 15
5.3.3 Conceptual level .16
5.3.4 Logical level .18
5.3.5 Physical level .21
5.4 Models Transformation . 22
5.4.1 General . 22
5.4.2 Scope to Conceptual . 23
5.4.3 Conceptual to Logical . 23
5.4.4 Logical to Physical . 25
6 Repository .25
6.1 Repository structure . 25
6.1.1 Overview . 25
6.2 DataDictionary .27
6.2.1 Overview .27
6.2.2 List of Dictionary Items . 28
6.2.3 DictionaryItem Registration Status .31
6.2.4 DictionaryItems description information .32
6.2.5 DataDictionary life cycle .32
6.3 BusinessProcessCatalogue .32
6.3.1 Overview .32
6.3.2 List of BusinessProcessCatalogueItems . 33
6.3.3 CatalogueItem Registration Status . 33
6.3.4 CatalogueItem description information . 33
6.3.5 BusinessProcessCatalogue life cycle . 34
7 Registration .34
8 Repository access .34
8.1 General . 34
8.2 Repository output types . 34
8.3 Output format . 34
Annex A (normative) Type library .35
Annex B (normative) Metamodel.49
Bibliography . 154

iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 68, Financial services, Subcommittee SC 9,
Information exchange for financial services.
This third edition cancels and replaces the second edition (ISO 20022-1:2013), which has been technically
revised.
The main changes are as follows:
— changes:
— Use of ISO/IEC 11404 instead of XML schema, except XML Schema temporal types remain.
— CodeSet trace to BusinessCodeSet, formalising the two-level approach used in practice.
— Top level entries across the catalogue and dictionary have unique names.
— BusinessArea moved to scope level to contain BusinessProcesses
— clarifications:
— Cardinality specified and updated related constraints.
— Lengths of Binary, String and Text types are positiveIntegers.
— MessageAssociationEnd aggregation to align with BusinessAssociationEnd.
— Choreography associated indirectly with MessageDefinitions via MessageSet, instead of directly.
— additions:
— Defined term "Conformance" to replace use of "compliance"
— SyntaxMessageScheme linked to Syntax.
— Import relationship amongst BusinessTransactions.

iv
— Conversation trace to Choreography, as a conversation is an instance of a choreography.
— Conversation aggregates MessageInstances to MessagingEndpoints, as per its definition.
— Pointer data type to enable direct references within each message instance.
— Binary types specify preferred text representation.
— Minor version properties (revision, variation) and draft were added to MessageDefinition
— Path of traces from BusinessComponent to BusinessElement.
— InterfaceSpecifications traces to logical InterfaceDefinitions comprising of Operations with
Parameters.
— Kind and Type of Constraint.
— Version relationships amongst RepositoryConcept.
A list of all parts in the ISO 20022 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

v
Introduction
The ISO 20022 series defines a scalable, methodical process to ensure consistent descriptions of messages
throughout the financial services industry.
The purpose of the ISO 20022 series is to describe precisely and completely the externally observable aspects
of financial services messaging in a way that can be verified independently against operational messaging.
The trigger for the creation of the ISO 20022 series was the rapid growth in the scale and sophistication
of messaging within financial services during the 1990s using the ISO 15022 series. The financial services
industry (hereafter referred to as "the industry") created the first version of the ISO 20022 series as the
successor to the ISO 15022 series in response to that trigger. Since the ISO 15022 series, the industry has
broadened the scope from securities to the entire industry for the ISO 20022 series.
The ISO 20022 series is based on open technology standards, which historically have evolved more rapidly
than the industry itself. Consequently, the ISO 20022 series adopted a model-driven approach where the
model of the industry's messaging can evolve separately from the evolution of the messaging technology
standards. The period during which the ISO 20022 series has emerged followed the widespread adoption
of the internet for business. The eXtensible Mark-up Language (XML) emerged as the de facto standard for
document representation on the internet and it became the first syntax for the ISO 20022 series.
The modelling process is further refined into three levels which, in addition to the messaging technology
standard, is why the ISO 20022 series is based on four levels: the scope level, the conceptual level, the
logical level and the physical level. This four-level approach is based on the first four levels of the Zachman
[5]
Framework . The remaining two levels of the Zachman Framework are equivalent to the implementations
and the operational levels, respectively.
In this document, the first, second and third levels are described in Unified Modelling Language (UML)
because it is widely supported and supports multiple levels of abstraction. The models created in accordance
with this document are technology independent in that they do not require any particular physical
expression or implementation. Such models aim to describe all parts of the message exchange. The models
form the definition of the protocol between participants exchanging messages. This document defines a
process by which these models can be created and maintained by the modellers.
The model and physical level artefacts artefacts are stored in an ISO 20022 Repository (hereafter referred
to as "the Repository"). The Repository and physical level artefacts are exposed in a publicly accessible
location, such as a website, serviced by a Registration Authority. The name and contact information of the
Registration Authority for the ISO 20022 series can be found at www.iso.org/maintenance_agencies.
The Repository is organized into two areas:
— a DataDictionary containing the industry model elements likely to have further or repeated use;
— a BusinessProcessCatalogue that contains models describing specific MessageDefinitions, and business
processes and physical syntax implementations.
The ISO 20022 series is organized into the following parts:
— This document describes the metamodel of all the models and the Repository according to
ISO/IEC 19502:2005 (MOF).
— ISO 20022-2 covers the UML profile, a grounding of general UML into a specific subset defined for the
ISO 20022 series (to be used when UML is selected to define the models).
— ISO 20022-3 describes a modelling method to produce models for the ISO 20022 series.
— ISO 20022-4 covers XML schema generation rules to transform a logical level model into a physical level
description in the syntaxes.
— ISO 20022-5 covers business concept model interoperability, and logical model alignment and reverse
engineering.
vi
— ISO 20022-6 covers message transport characteristics that define the quality of service required by the
business process definitions so that they can operate successfully.
— ISO 20022-7 describes the process of managing the registration of models and physical syntax
implementations.
— ISO 20022-8 gives ASN.1 syntax generation rules to transform a logical level model into a physical level
description in ASN.1.
— ISO 20022-9 describes generic guidelines which are used to define schema generation rules for any
specific syntax.
Defined terms of this document are in PascalCase and will use PascalCase throughout the document.

vii
International Standard ISO 20022-1:2026(en)
Financial services — Universal financial industry message
scheme —
Part 1:
Metamodel
1 Scope
This document specifies:
— the overall description of the modelling approach;
— the overall description of the ISO 20022 Repository (hereby referred to as Repository) contents;
— a high-level description of the input to be accepted by the Registration Authority to feed/modify the
Repository’s DataDictionary and BusinessProcessCatalogue;
— a high-level description of the Repository output to be made publicly available by the Registration
Authority.
BusinessTransactions and MessageSets Conforming with ISO 20022 series can be used for electronic
data interchange amongst any industry participants (financial and others), independently of any specific
communication network. Network-dependent rules, such as message acknowledgement and message
protection, are beyond the scope of the ISO 20022 series.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 20022-2, Financial services — Universal financial industry message scheme — Part 2: UML profile
ISO 20022-3, Financial services — Universal financial industry message scheme— Part 3: Modelling
ISO/IEC 11404, Information technology — General-Purpose Datatypes (GPD)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
Address
identification and efficient resolution to the location of a MessagingEndpoint (3.67)
Note 1 to entry: The purpose of an Address is to efficiently resolve a location. This is what distinguishes an Address
from any other Identifier, which merely identifies something.

3.2
Amount
number of monetary units specified in a currency where the unit of currency is explicit or implied
3.3
application programming interface
API
set of well-defined methods, functions, protocols, routines or commands which application software uses
with facilities of programming languages to invoke services
Note 1 to entry: An API is available for different types of software, including Web-based system/ecosystem.
[SOURCE: ISO/TS 23029:2020, 3.1]
3.4
binary
set of values drawn from the value space of "octetstring", the datatype of variable-length encodings using
8-bit codes, as specified by ISO/IEC 11404
3.5
Boolean
set of values drawn from the value space of "Boolean", two-value logic, as specified by ISO/IEC 11404
3.6
BroadcastList
set of references to MessagingEndpoints (identified by their Address (3.1)) that is used for message
broadcasting.
Note 1 to entry: The BroadcastList is managed by the MessageTransportSystem, which provides a mechanism to
maintain the BroadcastList.
Note 2 to entry: "Set" means the list of Addresses is unordered and each Address is present once.
3.7
BusinessActivity
decisions or actions by a Participant (3.71) which can initiate the sending of a MessageTransmission (3.63) or
be triggered by receiving a MessageTransmission (3.63)
Note 1 to entry: A BusinessActivity can exchange information via an API.
3.8
BusinessArea
set of strongly related BusinessProcesses (3.19) that provide a self-standing business value to a set of
BusinessRoles (3.22)
EXAMPLE Securities pre-trade, payment initiation.
Note 1 to entry: BusinessAreas are stored in the BusinessProcessCatalogue.
3.9
BusinessAssociation
relation between two BusinessComponents (3.13)
EXAMPLE The servicing of an account by a party.
Note 1 to entry: BusinessAssociations are a category of BusinessConcepts. Their meaning can only be described
unambiguously in combination with these two BusinessComponents.
Note 2 to entry: There can be several BusinessAssociations between two particular BusinessComponents.

3.10
BusinessAssociationEnd
the endpoint of a BusinessAssociation (3.9), which connects the BusinessAssociation to the BusinessComponent
(3.13)
3.11
BusinessAttribute
a BusinessElement (3.17), typed by a BusinessComponent (3.13) or a DataType (3.35)
EXAMPLE AccountIdentification, PhoneNumber.
Note 1 to entry: A BusinessAssociationEnd is always typed by another BusinessComponent
3.12
BusinessCodeSet
complete and enumerated set of Codes (3.27) grouped together to characterize all the values of an attribute
3.13
BusinessComponent
representation of a (part of a) key business notion, characterized by specific BusinessElements (3.17)
EXAMPLE Account, trade, party.
Note 1 to entry: BusinessComponents are a category of BusinessConcepts. They are stored in the DataDictionary.
Note 2 to entry: A BusinessComponent can have one or more semantic relations with other BusinessComponents.
3.14
BusinessComponentTrace
semantic relationship between a MessageComponentType (3.55) or MessageElement (3.60) and the
BusinessComponent (3.13) from which it is derived
3.15
BusinessConcept
DataDictionary (3.34) item of meaning to the business expressed as a BusinessComponent (3.13),
BusinessElement (3.17) or BusinessAssociation (3.9)
3.16
business domain
broad area of an industry with its own regulatory framework(s), usually supported by specialist areas
within organisations with its own terminology
EXAMPLE Card payments and related transactions, payments and cash management, trade services, securities,
foreign exchange, bank loan and deposits, derivatives, commodities.
3.17
BusinessElement
property of a BusinessComponent (3.13) that has a distinctive meaning within the scope of that
BusinessComponent (3.13)
EXAMPLE Account status, deal price, trade date and deal time.
3.18
BusinessElementTrace
semantic relationship between a MessageElement (3.60) and the BusinessElement (3.17) from which it is
derived
3.19
BusinessProcess
name and definition of a set of related business activities undertaken by BusinessRoles (3.22) within a
BusinessArea (3.8) which fulfils a business objective
EXAMPLE Securities ordering, trade matching.

Note 1 to entry: A BusinessProcess can contain other BusinessProcesses such as in a hierarchical structure.
Note 2 to entry: BusinessProcesses are stored in the BusinessProcessCatalogue.
Note 3 to entry: The definition of a scope level BusinessProcess can include or extend other BusinessProcesses.
3.20
BusinessProcessCatalogue
part of the Repository (3.76) which contains all items related to BusinessProcess (3.19) and BusinessTransaction
(3.24)
Note 1 to entry: It contains related items from the BusinessArea down to the MessageDefinitions and their physical
implementation.
Note 2 to entry: CatalogueItem is used as a synonym for entries in the BusinessProcessCatalogue.
3.21
BusinessProcessTrace
relationship between a BusinessTransaction (3.24) and the BusinessProcess (3.19) on which the
BusinessTransaction (3.24) is based
3.22
BusinessRole
functional role played by a business actor in a particular BusinessProcess (3.19) or BusinessTransaction (3.24)
EXAMPLE Account owner, buyer.
Note 1 to entry: BusinessRoles are a category of BusinessConcepts and are stored in the DataDictionary.
Note 2 to entry: A business actor can play different BusinessRoles in different BusinessProcesses.
3.23
BusinessRoleTrace
relationship between a Participant (3.71) in a BusinessTransaction (3.24) and a BusinessRole (3.22) identified
in the BusinessProcess (3.19) from which the BusinessTransaction (3.24) is derived
3.24
BusinessTransaction
particular solution that meets the communication requirements and the interaction requirements of a
particular BusinessProcess (3.19) and BusinessArea (3.8)
Note 1 to entry: A BusinessTransaction is typically based on the use of MessageInstances.
3.25
BusinessTransactionTrace
relationship between a BusinessTransaction (3.24) and its physical implementation
3.26
ChoiceComponent
re-usable DictionaryItem (3.40) that is a building block for assembling MessageDefinitions (3.57), composed
of a choice of MessageElements (3.60)
Note 1 to entry: ChoiceComponents are stored in the DataDictionary.
3.27
Code
character string (letters, figures or symbols) that for either brevity or language independence, or both, can
be used to represent or replace a definitive value or text of an attribute
3.28
CodeSet
type that has a finite set of valid Code (3.27) values, as specified by the State (ISO/IEC 11404:2007, 8.1.2)
datatype of ISO/IEC 11404
3.29
CodeSetTrace
semantic relationship between two CodeSets (3.28) whereby the derived CodeSet (3.28) is used as the type
of a BusinessElement (3.17) and the deriving CodeSet (3.28) is used as the type of a MessageElement (3.60)
3.30
Conformant
adherence to requirements, rules, guidelines and advice
EXAMPLE 1 A model design is Conformant with ISO 20022-1 and ISO 20022-3.
EXAMPLE 2 Schema generation is Conformant with its specification.
Note 1 to entry: "Conformance", "Conforming", "Conform" forms of the term carry the same definition.
3.31
Constraint
rule that is universally satisfied, i.e. all conditions required for the Constraint (3.31) to be applicable are
known
EXAMPLE An Account has an AccountOwner.
3.32
ConvergenceDocumentation
documentation set showing relations between ISO 20022 MessageDefinitions (3.57), MessageComponentTypes
(3.55), MessageElements (3.60), BusinessComponents (3.13) or BusinessElements (3.17), or between all, and
items defined in other IndustryMessageSets (3.46)
3.33
Conversation
exchange of one or more MessageInstances (3.61) amongst MessagingEndpoints (3.67)
Note 1 to entry: In a synchronous Conversation, the sending MessagingEndpoint blocks the sending and receipt of
other TransportMessages within the conversation, in which the TransportMessage was sent, while waiting for a
response to this sent TransportMessage. This is not the case in an asynchronous conversation.
Note 2 to entry: If MessageChoreography exists for this business transaction, the Converstion conforms to it.
3.34
DataDictionary
part of the Repository (3.76) that contains all items that can be re-used during BusinessProcess (3.19)
modelling and message definition activities
Note 1 to entry: The DataDictionary therefore contains BusinessConcepts, MessageConcepts and DataTypes.
3.35
DataType
representation of a set of values without identity
3.36
date
any set of values drawn from the value space of "time" with a time-unit of "day", as specified by ISO/IEC 11404
3.37
dateTime
any set of values drawn from the value space of "time", as specified by ISO/IEC 11404
3.38
Day
any set of values drawn from the value space of "dayof-Month" operation of time datatype, as specified by
ISO/IEC 11404
3.39
decimal
any set of values drawn from the value space of "scaled" with a radix of "10", as specified by ISO/IEC 11404
3.40
DictionaryItem
BusinessConcept (3.15), DataType (3.35), MessageConcept (3.56) items
3.41
duration
any set of values drawn from the value space of "time interval", as specified by ISO/IEC 11404
3.42
Encoding
wire format of message instances
EXAMPLE 1 ASN.1 PER
EXAMPLE 2 ASN.1 XER
EXAMPLE 3 XSD XML
[12]
EXAMPLE 4 JSON
EXAMPLE 5 RDF TTL
Note 1 to entry: An encoding specifies the format of message instances that are structured according to a
SyntaxMessageScheme.
3.43
ExternalSchema
reusable DictionaryItem (3.40) that allows referral to a structure defined outside the
ISO 20022MessageDefinition (3.57)
EXAMPLE In case of XML (eXtensible Markup Language), this artefact is transformed into an XML Schema "any"
element and the external structure is defined through another XML Schema.
3.44
IdentifierSet
unenumerated set of values outside the Repository (3.76) whereby each value distinguishes uniquely one
instance of an object within an identification scheme from all other instances of the objects within the same
scheme
3.45
Indicator
list of exactly two mutually exclusive values that express the only two possible states of an instance of an
object
EXAMPLE 1 PlusOrMinusIndicator can be plus or minus.
EXAMPLE 2 DebitCreditIndicator can be debit or credit.
3.46
IndustryMessageSet
set of non-ISO 20022 Conformant (3.30) messages, which is defined and used by part of the financial industry
EXAMPLE The set of FIX messages.
3.47
InterfaceDefinition
aggregation of Operations (3.70) used in MessageChoreography (3.53)

3.48
InterfaceSpecification
rendering of the InterfaceDefinition (3.47) in a specific interface definition language
EXAMPLE Open API Specification (Swagger), AsyncAPI Specification, WDSL.
3.49
ISO15022MessageSet
IndustryMessageSet (3.46) constructed according to the rules defined in ISO 15022 series, which is stored in
the ISO 15022 Catalogue of Messages
3.50
MessageAssociationEnd
type of MessageElement (3.60) that specifies the role of a message association
3.51
MessageAttribute
type of MessageElement (3.60) which is either a DataType (3.35) or a MessageComponentType (3.55)
3.52
MessageBuildingBlock
characteristic of a MessageDefinition (3.57) that has a unique meaning within the scope of that
MessageDefinition (3.57)
Note 1 to entry: MessageBuildingBlocks are not reused, since they only have meaning within a specific
MessageDefinition.
3.53
MessageChoreography
precise and complete description of a message exchange within a BusinessTransaction (3.24), describing
the sequence and correlation of messages within a conversation, including the constraints on the
interaction between Participants (3.71) including conforming to corresponding MessageDefinitions (3.57) or
InterfaceDefinitions (3.47)
Note 1 to entry: Every BusinessTransaction contains its own MessageChoreography.
Note 2 to entry: Includes messaes that flow either to or from interfaces.
3.54
MessageComponent
re-usable DictionaryItem (3.40) that is a building block for assembling MessageDefinitions (3.57), composed
of a sequence of MessageElements (3.60)
EXAMPLE "Trade Details" which contains a number of the properties of the related BusinessComponent "Trade".
3.55
MessageComponentType
MessageComponent (3.54),ExternalSchema (3.43) or ChoiceComponent (3.26)
Note 1 to entry: When a MessageComponentType has a business meaning it is linked to a BusinessComponent.
Note 2 to entry: MessageComponentTypes are a category of MessageConcepts and are stored in the DataDictionary.
3.56
MessageConcept
DataDictionary (3.34) artefact, which is not a DataType (3.35), that is used in a MessageDefinition (3.57)
3.57
MessageDefinition
formal description of the structure of a MessageInstance (3.61)
Note 1 to entry: The MessageDefinition is built as a tree structure of MessageComponentTypes and DataTypes. A
MessageDefinition is uniquely identified in the BusinessProcessCatalogue.

Note 2 to entry: A MessageDefinition can have several market practices.
3.58
MessageDefinitionIdentifier
identification of a MessageDefinition (3.57) within the ISO 20022 namespace, identifying the BusinessArea
(3.8) to which the MessageDefinition (3.57) belongs, the message functionality it covers, its flavour and its
version
Note 1 to entry: The combination of MessageDefinition.minorVersion with the MessageDefinitionIdentifier uniquely
identifies a MessageDefinition
3.59
MessageDefinitionTrace
relationship between a MessageDefinition (3.57) and its physical implementation as a SyntaxMessageScheme
(3.84)
Note 1 to entry: This relationship is explained in ISO 20022-4.
3.60
MessageElement
characteristic of a MessageComponent (3.54) or ChoiceComponent (3.26), which has a unique meaning within
the scope of that MessageComponent (3.54) or ChoiceComponent (3.26)
EXAMPLE "Trade Date" and "Time" as part of the MessageComponent "Trade Details".
Note 1 to entry: MessageElements are a category of MessageConcepts. They are stored in the DataDictionary
where they are owned by a particular MessageComponent/ChoiceComponent. Their meaning can only be described
unambiguously in combination with that MessageComponent/ChoiceComponent.
3.61
MessageInstance
instance of MessageDefinition (3.57), containing a set of structured information exchanged between
BusinessRoles (3.22), in the scope of a BusinessTransaction (3.24)
EXAMPLE "Notice Of Execution"," Order To Buy", "Credit Transfer".
Note 1 to entry: A MessageInstance is expected to be valid against the related MessageDefinition in the Repository.
This implies validity against the SyntaxMessageScheme as well as validity against the Constraints and market
practices that are registered for this MessageDefinition.
Note 2 to entry: A MessageInstance includes an exchange of information from one participant to another.
3.62
MessageSet
set of MessageDefinitions (3.57)
Note 1 to entry: MessageDefinitions within a MessageSet do not have to belong to the same BusinessArea.
3.63
MessageTransmission
passing of information from one Participant (3.71) to another in the context of a BusinessTransaction (3.24)
3.64
MessageTransportMode
group of settings for the values for message transport properties
Note 1 to entry: A MessageTransportMode is named and registered in the Repository. Each
MessageTransportCharacteristic is given a value.
Note 2 to entry: A MessageTransportMode can be associated with many BusinessTransactions. The
MessageTransportMode is used to organize commonly used combinations of MessageTransportCharacteristic settings.

3.65
MessageTransportSystem
mechanism that receives TransportMessages (3.90) from the sending MessagingEndpoint (3.67), transports
them, and delivers them to the receiving MessagingEndpoint (3.67)
Note 1 to entry: The MessageTransportSystem is responsible for delivering Transport Messages to each Addressee.
Note 2 to entry: The purpose of the MessageTransportSystem is to provide a clear delineation of the responsibility
of the MessagingEndpoints and any MessageTransportSystem service providers. The role can be fulfilled by
the sending MessagingEndpoint or by a separate service provider who provides a MessageTransportSystem.
MessagingTransportSystems can be chained together into a single MessageTransportSystem
3.66
MessageTypeTrace
relationship between a MessageTransmission (3.63) in a BusinessTransaction (3.24) and its corresponding
MessageDefinition (3.57)
3.67
MessagingEndpoint
addressable node on the MessageTransportSystem (3.65) which is capable of sending and receiving
TransportMessages (3.90)
Note 1 to entry: A MessagingEndpoint has an Address.
3.68
Month
any set of values drawn from the value space of "month" operation of "time" datatype, as specified by
ISO/IEC 11404
3.69
MonthDay
any set of values drawn from the value space of "month" operation of "time" dataype, as specified by
ISO/IEC 11404
3.70
Operation
name, type, parameters and constraints for invoking a behaviour associated with BusinessActivity (3.7)
3.71
Participant
involvement of a BusinessRole (3.22) in a BusinessTransaction (3.24)
3.72
pointer
generates a so-called pointer datatype
3.73
Quantity
counted number of non-monetary units possibly including fractions
3.74
Rate
quantity or amount measured with respect to another measured quantity or amount
EXAMPLE US Dollars per hour, US Dollars per Euro.
3.75
receive
handling of a stimulus passed from a sender instance

3.76
Repository
place where all RepositoryConcepts (3.77) are stored
Note 1 to entry: This term is used in the ISO 20022 series to refer to the "ISO 20022 Repository".
3.77
RepositoryConcept
artefact that has been defined during the development of an ISO 20022MessageDefinition (3.57) and
ResourceDefinition (3.79), which is stored in the Repository
3.78
Resource
data set that is managed by an application programming interface (API) (3.3)
Note 1 to entry: Data set can be expressed as MessageComponent
3.79
ResourceDefinition
formal description of one or more data sets that can be managed by an application programming interface
(API) (3.3)
Note 1 to entry: The ResourceDefinition is built as a tree structure of MessageComponents and DataTypes. A
ResourceDefinition is uniquely identified in the BusinessProcessCatalogue.
Note 2 to entry: Like MessageComponents, ResourceDefinitions can be used by various APIs that each have seperate
market practices
3.80
ResourceSet
set of Resources (3.78)
3.81
send
passing of a stimulus from a sender instance to a receiver instance
3.82
string
any set of values drawn from the value space of "characterstring", as specified by ISO/IEC 11404
3.83
Syntax
data or interface definition language
EXAMPLE 1 W3C XML Schema 1.0
EXAMPLE 2 ISO ASN.1
EXAMPLE 3 OpenAPI Specification
EXAMPLE 4 RDF SHACL
Note 1 to entry: A syntax is the specification language of a SyntaxMessageScheme.
3.84
SyntaxMessageScheme
specification in a syntax used to define, constrain or validate the structure of a MessageInstance (3.61) in a
possible encoding
EXAMPLE 1 A SyntaxMessageScheme specified in XML Schema validates messages encoded in XML.
EXAMPLE 2 A SyntaxMessageScheme specified in ASN.1 defines the structure of messages encoded as XML, JSON,
and several binary formats.
EXAMPLE 3 A SyntaxMessageScheme specified in SHACL constrains RDF graphs encoded in XML, JSON-LD, TTL
and several other textual formats.
EXAMPLE 4 A SyntaxMessageScheme specified in ISO 3531-1 (FIX tagvalue) defines the structure of messages
encoded as tag-value format.
3.85
Text
finite array of characters
3.86
time
any set of values drawn from the value space of "time", as specified by ISO/IEC 11404
3.87
TopLevelCatalogueEntry
artefact in the BusinessProcessCatalogue (3.20) that is not owned by another artefact in the Repository (3.76)
3.88
TopLevelDictionaryEntry
artefact in the DataDictionary (3.34) that is not owned by another artefact in the Repository (3.76)
3.89
trace
relationship between two objects that represent the same concept but have a different but related context
3.90
TransportMessage
document that is an instance of the MessageTransportSystem (3.65) message schema
3.91
Year
any set of values drawn from the value space of "year" operation of "time" dataytype, as specified by
ISO/IEC 11404
3.92
YearMonth
any set of values drawn from the value space of the composit of "year" and "month" operations of "time"
datatype, as specified by ISO/IEC 11404
4 Type Library
The Type Library contains the primitive data types used in both this document's metamodel and the models
created in accordance with this document. It consists of Built-in DataTypes, see Figure 1, and Enumerations,
see Figure 2. These packages shall be defined in accordance with Annex A.

Figure 1 — Type library Built-in DataTypes

Figure 2 — Type library enumerations
5 Metamodel packages
5.1 General
The metamodel describes the structure of models built in accordance with this document. All models
produced according to this document shall comply with this one model, see Figure 3.
5.2 The metamodel’s use of ISO20022::TypeLibrary
The metamodel imports the ISO20022::TypeLibrary Package and its subpackages, which are defined in
Annex A. It uses the types defined therein to define the metamodel.
NOTE The ISO20022::TypeLibrary Package is not contained within the ISO20022::Metamodel Package
because it is used by both the metamodel and the UML Profile defined in ISO 20022-2, which also imports it. The
ISO20022::TypeLibrary::BaseTypesPackage contains definitions of the built-in DataTypes in a form that makes it
possible for modellers to use these DataTypes in UML and Meta Object Facility (MOF) models (see ISO/IEC 19502).

Figure 3 — ISO 20022 level structure
5.3 Levels
5.3.1 General
The metamodel has four levels of model, each of increasing realization, see Figure 3. These four levels, as
[5]
shown in Table 1, are based upon the first four levels of the Zachman Framework .

Table 1 — Metamodel levels
Level name Focus
Achieving a thorough understanding of the business objectives of
...