ISO/FDIS 20022-1

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

ISO 20022-1:2013 consists of: the overall description of the modelling approach; the overall description of the ISO 20022 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 Message Sets complying with ISO 20022 can be used for electronic data interchange among any industry participants (financial and others), independently of any specific communication network. Network-dependent rules, such as message acknowledgement and message protection, are outside the scope of ISO 20022.

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

General Information

• Status: Not Published
• 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: 5020 - FDIS ballot initiated: 2 months. Proof sent to secretariat
• Start Date: 31-Dec-2025
• Completion Date: 31-Dec-2025

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)

FINAL DRAFT
International
Standard
ISO/TC 68/SC 9
Financial services — Universal
Secretariat: AFNOR
financial industry message
Voting begins on:
scheme —
2025-12-31
Part 1:
Voting terminates on:
2026-02-25
Metamodel
Services financiers — Schéma universel de messages pour
l'industrie financière —
Partie 1: Métamodèle
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
FINAL DRAFT
International
Standard
ISO/TC 68/SC 9
Financial services — Universal
Secretariat: AFNOR
financial industry message
Voting begins on:
scheme —
Part 1:
Voting terminates on:
Metamodel
Services financiers — Schéma universel de messages pour
l'industrie financière —
Partie 1: Métamodèle
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© ISO 2025
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
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 Reference number
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 . 20
5.4 Models Transformation . 20
5.4.1 General . 20
5.4.2 Scope to Conceptual . 20
5.4.3 Conceptual to Logical .21
5.4.4 Logical to Physical .21
6 Repository .21
6.1 Repository structure .21
6.1.1 Overview .21
6.2 DataDictionary . 23
6.2.1 Overview . 23
6.2.2 List of Dictionary Items .24
6.2.3 DictionaryItem Registration Status . 25
6.2.4 DictionaryItems description information . 26
6.2.5 DataDictionary life cycle . 26
6.3 BusinessProcessCatalogue . 26
6.3.1 Overview . 26
6.3.2 List of BusinessProcessCatalogueItems . 26
6.3.3 CatalogueItem Registration Status .27
6.3.4 CatalogueItem description information .27
6.3.5 BusinessProcessCatalogue life cycle .27
7 Registration .27
8 Repository access .28
8.1 General . 28
8.2 Repository output types . 28
8.3 Output format . 28
Annex A (normative) Type library .29
Annex B (normative) Metamodel .43
Bibliography .148

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
FINAL DRAFT International Standard ISO/FDIS 20022-1:2025(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.10), which connects the BusinessAssociation (3.10) to the
BusinessComponent (3.13)
3.11
BusinessAttribute
a BusinessElement (3.11), 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.28) 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 20022MessageDefinitions (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.54), 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.54)
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
...

ISO/DISFDIS 20022-1:2025(en)
ISO/TC 68/SC 9
Secretariat: AFNOR
Date: 2025-09-2312-16
Financial services — Universal financial industry message scheme —
Part 1:
Metamodel
Services financiers — Schéma universel de messages pour l'industrie financière —
Partie 1: Métamodèle
FDIS stage
MUST BE USED
FOR FINAL
DRAFT
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: + 41 22 749 01 11
E-mail: [e-mail]
Website: www.iso.org
Published in Switzerland
ICS 03.060
Price based on 152 pages
Erreur ! Source du renvoi introuvable.

ISO/DIS 20022-1:2025(en)
Contents Page
Foreword . v
Introduction . vii
1 Scope .1
2 Normative references .1
3 Terms and definitions .1
4 Type Library . 13
5 Metamodel packages . 17
5.1 General . 17
5.2 The metamodel’s use of ISO20022::TypeLibrary . 17
5.3 Levels . 19
5.4 Models Transformation . 29
6 Repository . 33
6.1 Repository structure . 33
6.2 DataDictionary . 36
6.3 BusinessProcessCatalogue . 42
7 Registration . 43
8 Repository access . 44
8.1 General . 44
8.2 Repository output types . 44
8.3 Output format . 44
Annex A (normative) Type library. 45
Annex B (normative) Metamodel . 62
Bibliography . 189

1 Scope .1
2 Normative references .1
3 Terms and definitions .2
4 Type Library . 13
5 Metamodel packages . 15
5.1 General . 15
5.2 The metamodel’s use of ISO20022::TypeLibrary . 15
5.3 Levels . 17
5.3.1 Scope level . 18
5.3.2 Conceptual level . 19
5.3.3 Logical level . 21
5.3.4 Physical level . 24
5.4 Models Transformation . 25
5.4.1 Scope to Conceptual . 26
5.4.2 Conceptual to Logical . 27
5.4.3 Logical to Physical . 28
MUST BE USED
6 Repository . 29
FOR FINAL
iii
DRAFT
6.1 ISO 20022 Repository structure . 29
6.1.1 Overview . 29
6.2 DataDictionary . 31
6.2.1 Overview . 31
6.2.2 List of Dictionary Items . 32
6.2.3 DictionaryItem Registration Status . 35
6.2.4 DictionaryItems description information . 36
6.2.5 DataDictionary life cycle . 36
6.3 BusinessProcessCatalogue. 37
6.3.1 Overview . 37
6.3.2 List of BusinessProcessCatalogueItems . 37
6.3.3 CatalogueItem Registration Status . 37
6.3.4 CatalogueItem description information . 38
6.3.5 BusinessProcessCatalogue life cycle . 38
7 Registration . 39
8 Repository Access . 40
8.1 General . 40
8.2 Repository output types . 40
8.3 Output format . 40
Annex A (normative) Type library . 41
A.1 General . 41
A.2 Type Library Details . 41
A.2.1 Package ISO20022::TypeLibrary . 41
A.2.2 Package ISO20022::TypeLibrary::Enumerations . 41
A.2.3 Package ISO20022::TypeLibrary::BaseTypes . 48
Annex B (normative) Metamodel . 56
B.1 General . 56
B.2 Metamodel details. 56
B.2.1 Package ISO20022::Metamodel . 56
B.2.2 Package ISO20022::Metamodel::ConceptualLevel . 72
B.2.3 Package ISO20022::Metamodel::ConceptualLevel::Dynamic . 72
B.2.4 Package ISO20022::Metamodel::ConceptualLevel::MessageTransport . 91
B.2.5 Package ISO20022::Metamodel::ConceptualLevel::Static . 98
B.2.6 Package ISO20022::Metamodel::ConceptualToLogicalTransformation . 109
B.2.7 Package ISO20022::Metamodel::DataTypes. 117
B.2.8 Package ISO20022::Metamodel::LogicalLevel . 145
B.2.9 Package ISO20022::Metamodel::LogicalLevel::Reversing . 180
B.2.10 Package ISO20022::Metamodel::LogicalToPhysicalTransformation . 181
B.2.11 Package ISO20022::Metamodel::PhysicalLevel. 184
B.2.12 Package ISO20022::Metamodel::ScopeLevel. 189
B.2.13 Package ISO20022::Metamodel::ScopeToConceptualTransformation . 194
B.3 Metamodel XMI . 197
ICS 03.060
Price based on 152 pages
Erreur ! Source du renvoi introuvable.

ISO/DIS 20022-1:2025(en)
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.
MUST BE USED
FOR FINAL
v
DRAFT
— 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.
— 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.
ICS 03.060
Price based on 152 pages
Erreur ! Source du renvoi introuvable.

ISO/DIS 20022-1:2025(en)
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 this documentthe 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 this documentthe 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 Scopescope level, the
Conceptualconceptual level, the Logicallogical level and the Physicalphysical level. This four-level
[5][ ]
approach is based on the first four levels of the Zachman Framework. 0 . 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
BusinessProcessesbusiness processes and physical syntax implementations.
The ISO 20022 series is organized into the following parts:
— This document describes in ISO/IEC 19502:2024 (MOF) the metamodel of all the models and the
MUST BE USED
Repository. according to ISO/IEC 19502:2005 (MOF).
FOR FINAL
vii
DRAFT
— 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 Schemaschema generation rules to transform a Logicallogical level model
into a Physicalphysical level description in the syntaxes.
— ISO 20022-5 covers business concept model interoperability, and logical model alignment and
reverse engineering.
— ISO 20022-6 covers message transport characteristics that define the quality of service required by
the BusinessProcessbusiness 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 Logicallogical level model into a
Physicalphysical 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 standarddocument are in PascalCase and will use PascalCase throughout the
standarddocument.
ICS 03.060
Price based on 152 pages
Erreur ! Source du renvoi introuvable.

ISO/DISFDIS 20022-1:2025(en)
Financial services — Universal financial industry message scheme —
Part 1: Metamodel
MUST BE USED
FOR FINAL
© ISO 2025 – All rights reserved
ix
DRAFT
DRAFT International Standard ISO/DIS 20022-1:2025(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 3.2
Amount
number of monetary units specified in a currency where the unit of currency is explicit or implied
3.3 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 3.4
binary
set of values drawn from the value space of "octetstring", the datatype of variable-length encodings using 8-
bit codes, which shall conform as specified by ISO/IEC 11404
3.5 3.5
Boolean
set of values drawn from the value space of ”"Boolean”,", two-value logic, which shall conform as specified by
ISO/IEC 11404
3.6 3.6
BroadcastList
set of references to MessagingEndpoints (identified by their Address (3.1))(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 3.7
BusinessActivity
decisions or actions by a Participant (3.71)(3.71) which can initiate the sending of a MessageTransmission
(3.63)(3.63) or be triggered by receiving a MessageTransmission (3.63)(3.63)
Note 1 to entry: A BusinessActivity can exchange information via an API.
3.8 3.8
BusinessArea
set of strongly related BusinessProcesses (3.19)(3.19) that provide a self-standing business value to a set of
BusinessRoles (3.22)(3.22)
EXAMPLE Securities pre-trade, payment initiation.
ICS 03.060
Price based on 152 pages
Erreur ! Source du renvoi introuvable.
ISO/DISFDIS 20022-1:2025(en)
Note 1 to entry: BusinessAreas are stored in the BusinessProcessCatalogue.
3.9 3.9
BusinessAssociation
relation between two BusinessComponents (3.13)(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 3.10
BusinessAssociationEnd
the endpoint of a BusinessAssociation (3.10),(3.10), which connects the BusinessAssociation (3.10)(3.10) to the
BusinessComponent (3.13)(3.13)
3.11 3.11
BusinessAttribute
a BusinessElement (3.11),(3.11), typed by a BusinessComponent (3.13)(3.13) or a DataType (3.35) (3.35)
EXAMPLE AccountIdentification, PhoneNumber.
Note 1 to entry: A BusinessAssociationEnd is always typed by another BusinessComponent
3.12 3.12
BusinessCodeSet
complete and enumerated set of Codes (3.27)(3.27) grouped together to characterize all the values of an
attribute
3.13 3.13
BusinessComponent
representation of a (part of a) key business notion, characterized by specific BusinessElements (3.17)(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 3.14
BusinessComponentTrace
semantic relationship between a MessageComponentType (3.55)(3.55) or MessageElement (3.60)(3.60) and
the BusinessComponent (3.13)(3.13) from which it is derived
3.15 3.15
BusinessConcept
DataDictionary (3.34)(3.34) item of meaning to the business expressed as a BusinessComponent (3.13),(3.13),
BusinessElement (3.17)(3.17) or BusinessAssociation (3.9)(3.9)
3.16 3.16
business domain
broad area of an industry with its own regulatory framework(s), usually supported by specialist areas within
MUST BE USED
organisations with its own terminology
FOR FINAL
© ISO 2025 – All rights reserved
DRAFT
EXAMPLE Card payments and related transactions, payments and cash management, trade services, securities,
foreign exchange, bank loan and deposits, derivatives, commodities.
3.17 3.17
BusinessElement
property of a BusinessComponent (3.13)(3.13) that has a distinctive meaning within the scope of that
BusinessComponent (3.13)(3.13)
EXAMPLE Account status, deal price, trade date and deal time.
3.18 3.18
BusinessElementTrace
semantic relationship between a MessageElement (3.60)(3.60) and the BusinessElement (3.17)(3.17) from
which it is derived
3.19 3.19
BusinessProcess
name and definition of a set of related business activities undertaken by BusinessRoles (3.22) within a
BusinessArea (3.8)(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 3.20
BusinessProcessCatalogue
part of the Repository (3.76)(3.76) which contains all items related to BusinessProcess (3.19)(3.19) and
BusinessTransaction (3.24)(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 3.21
BusinessProcessTrace
relationship between a BusinessTransaction (3.24)(3.24) and the BusinessProcess (3.19)(3.19) on which the
BusinessTransaction (3.24)(3.24) is based
3.22 3.22
BusinessRole
functional role played by a business actor in a particular BusinessProcess (3.19)(3.19) or BusinessTransaction
(3.24)(3.24)
EXAMPLE Account owner, buyer.
ICS 03.060
Price based on 152 pages
Erreur ! Source du renvoi introuvable.
ISO/DISFDIS 20022-1:2025(en)
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 3.23
BusinessRoleTrace
relationship between a Participant (3.71)(3.71) in a BusinessTransaction (3.28)(3.28) and a BusinessRole
(3.22)(3.22) identified in the BusinessProcess (3.19)(3.19) from which the BusinessTransaction (3.24)(3.24) is
derived
3.24 3.24
BusinessTransaction
particular solution that meets the communication requirements and the interaction requirements of a
particular BusinessProcess (3.19) and BusinessArea (3.8)(3.19) and BusinessArea (3.8)
Note 1 to entry: It A BusinessTransaction is typically based on the use of MessageInstances.
3.25 3.25
BusinessTransactionTrace
relationship between a BusinessTransaction (3.24)(3.24) and its physical implementation
3.26 3.26
ChoiceComponent
re-usable DictionaryItem (3.40)(3.40) that is a building block for assembling MessageDefinitions (3.57),(3.57),
composed of a choice of MessageElements (3.60)(3.60)
Note 1 to entry: ChoiceComponents are stored in the DataDictionary.
3.27 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 3.28
CodeSet
type that has a finite set of valid Code (3.27)(3.27) values, which shall conform as specified by the State
[(ISO/IEC 11404:2007, 8.1.2]) datatype of ISO/IEC 11404
3.29 3.29
CodeSetTrace
semantic relationship between two CodeSets (3.28)(3.28) whereby the derived CodeSet (3.28)(3.28) is used
as the type of a BusinessElement (3.17)(3.17) and the deriving CodeSet (3.28)(3.28) is used as the type of a
MessageElement (3.60)(3.60)
3.30 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.
MUST BE USED
FOR FINAL
© ISO 2025 – All rights reserved
DRAFT
3.31 3.31
Constraint
rule that shall beis universally satisfied, i.e. all conditions required for the Constraint (3.31)(3.31) to be
applicable are known
EXAMPLE An Account has an AccountOwner.
3.32 3.32
ConvergenceDocumentation
documentation set showing relations between ISO 20022 MessageDefinitions (3.57),20022MessageDefinitions
(3.57), MessageComponentTypes (3.55),(3.55), MessageElements (3.60),(3.60), BusinessComponents
(3.13)(3.13) or BusinessElements (3.17),(3.17), or between all, and items defined in other IndustryMessageSets
(3.46)(3.46)
3.33 3.33
Conversation
exchange of one or more MessageInstances (3.61)(3.61) amongst MessagingEndpoints (3.67)(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 3.34
DataDictionary
part of the Repository (3.76)(3.76) that contains all items that can be re-used during BusinessProcess
(3.19)(3.19) modelling and message definition activities
Note 1 to entry: The DataDictionary therefore contains BusinessConcepts, MessageConcepts and DataTypes.
3.35 3.35
DataType
representation of a set of values without identity
3.36 3.36
date
any set of values drawn from the value space of ”"time”" with a time-unit of ”"day”, which shall conform", as
specified by ISO/IEC 11404
3.37 3.37
dateTime
any set of values drawn from the value space of ”"time”, which shall conform", as specified by ISO/IEC 11404
3.38 3.38
Day
any set of values drawn from the value space of ”"dayof-Month”" operation of time datatype, which shall
conform as specified by ISO/IEC 11404
ICS 03.060
Price based on 152 pages
Erreur ! Source du renvoi introuvable.
ISO/DISFDIS 20022-1:2025(en)
3.39 3.39
decimal
any set of values drawn from the value space of ”"scaled”" with a radix of ”"10”, which shall conform", as
specified by ISO/IEC 11404
3.40 3.40
DictionaryItem
BusinessConcept (3.15),(3.15), DataType (3.35),(3.35), MessageConcept (3.56)(3.56) items
3.41 3.41
duration
any set of values drawn from the value space of ”"time interval”, which shall conform", as specified by ISO/IEC
3.42 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 4 JSON 0
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 3.43
ExternalSchema
reusable DictionaryItem (3.40)(3.40) that allows referral to a structure defined outside the ISO 20022
MessageDefinition (3.57)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 3.44
IdentifierSet
unenumerated set of values outside the Repository (3.76)(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 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.
MUST BE USED
FOR FINAL
© ISO 2025 – All rights reserved
DRAFT
3.46 3.46
IndustryMessageSet
set of non-ISO 20022 Conformant (3.30)(3.30) messages, which is defined and used by part of the financial
industry
EXAMPLE The set of FIX messages.
3.47 3.47
InterfaceDefinition
aggregation of Operations (3.70)(3.70) used in MessageChoreography (3.53)(3.53)
3.48 3.48
InterfaceSpecification
rendering of the InterfaceDefinition (3.47)(3.47) in a specific interface definition language
EXAMPLE Open API Specification (Swagger), AsyncAPI Specification, WDSL.
3.49 3.49
ISO15022MessageSet
[2]
IndustryMessageSet (3.46)(3.46) constructed according to the rules defined in ISO 15022 series ,, which is
stored in the ISO 15022 Catalogue of Messages
3.50 3.50
MessageAssociationEnd
type of MessageElement (3.60)(3.60) that specifies the role of a message association
3.51 3.51
MessageAttribute
type of MessageElement (3.60)(3.60) which is either a DataType (3.35)(3.35) or a MessageComponentType
(3.55)(3.55)
3.52 3.52
MessageBuildingBlock
characteristic of a MessageDefinition (3.57)(3.57) that has a unique meaning within the scope of that
MessageDefinition (3.57)(3.57)
Note 1 to entry: MessageBuildingBlocks are not reused, since they only have meaning within a specific
MessageDefinition.
3.53 3.53
MessageChoreography
precise and complete description of a message exchange within a BusinessTransaction (3.24),(3.24),
describing the sequence and correlation of messages within a conversation, including the constraints on the
interaction between Participants (3.71)(3.71) including conforming to corresponding MessageDefinitions
(3.57)(3.57) or InterfaceDefinitions (3.47)(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.
ICS 03.060
Price based on 152 pages
Erreur ! Source du renvoi introuvable.
ISO/DISFDIS 20022-1:2025(en)
3.54 3.54
MessageComponent
re-usable DictionaryItem (3.40)(3.40) that is a building block for assembling MessageDefinitions (3.57),(3.57),
composed of a sequence of MessageElements (3.60)(3.60)
EXAMPLE "Trade Details" which contains a number of the properties of the related BusinessComponent “"Trade”.".
3.55 3.55
MessageComponentType
MessageComponent (3.54), (3.54),ExternalSchema (3.43)(3.43) or ChoiceComponent (3.26)(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 3.56
MessageConcept
DataDictionary (3.34)(3.34) artefact, which is not a DataType (3.35),(3.35), that is used in a MessageDefinition
(3.57)(3.57)
3.57 3.57
MessageDefinition
formal description of the structure of a MessageInstance (3.61)(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 3.58
MessageDefinitionIdentifier
identification of a MessageDefinition (3.57)(3.57) within the ISO 20022 namespace, identifying the
BusinessArea (3.8)(3.8) to which the MessageDefinition (3.57)(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 3.59
MessageDefinitionTrace
relationship between a MessageDefinition (3.57)(3.57) and its physical implementation as a
SyntaxMessageScheme (3.84)(3.84)
Note 1 to entry: This relationship is explained in ISO 20022-4.
3.60 3.60
MessageElement
characteristic of a MessageComponent (3.54)(3.54) or ChoiceComponent (3.26),(3.26), which has a unique
meaning within the scope of that MessageComponent (3.54)(3.54) or ChoiceComponent (3.26)(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
MUST BE USED
unambiguously in combination with that MessageComponent/ChoiceComponent.
FOR FINAL
© ISO 2025 – All rights reserved
DRAFT
3.61 3.61
MessageInstance
instance of MessageDefinition (3.54),(3.54), containing a set of structured information exchanged between
BusinessRoles (3.22),(3.22), in the scope of a BusinessTransaction (3.24)(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 3.62
MessageSet
set of MessageDefinitions (3.54)(3.54)
Note 1 to entry: MessageDefinitions within a MessageSet do not have to belong to the same BusinessArea.
3.63 3.63
MessageTransmission
passing of information from one Participant (3.71)(3.71) to another in the context of a BusinessTransaction
(3.24)(3.24)
3.64 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 3.65
MessageTransportSystem
mechanism that receives Transport
...