ISO 20022-1:2013

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: Published
• Publication Date: 06-May-2013
• 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: 9092 - International Standard to be revised
• Start Date: 23-Mar-2022
• Completion Date: 13-Dec-2025

Relations

• Revised: ISO/FDIS 20022-1 - Financial services — Universal financial industry message scheme — Part 1: Metamodel
• Effective Date: 06-Jun-2022
• Revises: ISO 20022-1:2004 - Financial services - UNIversal Financial Industry message scheme - Part 1: Overall methodology and format specifications for inputs to and outputs from the ISO 20022 Repository
• Effective Date: 22-Aug-2009

Overview - ISO 20022-1:2013 (Metamodel)

ISO 20022-1:2013 defines the metamodel and high-level repository organization for the ISO 20022 universal financial industry message scheme. It specifies the modelling approach, the contents and structure of the ISO 20022 Repository, and the high-level expectations for inputs accepted by the Registration Authority and publicly available Repository outputs. The standard supports technology-independent, model-driven definitions of business processes and message sets used for electronic data interchange in financial services (and beyond). Network-dependent rules (e.g., acknowledgements, message protection) are explicitly outside its scope.

Key topics and technical requirements

• Metamodel & Type Library: Defines the meta-object structure used to describe all models stored in the Repository (MOF-based).
• Four modelling levels: Scope, Conceptual, Logical and Physical levels to separate business semantics from implementation details.
• Repository organization: Two primary areas - the DataDictionary (reusable business elements and types) and the BusinessProcessCatalogue (process models, message definitions, physical syntaxes).
• Model transformations: High-level rules for converting models between Scope → Conceptual → Logical → Physical.
• Registration and governance: High-level submission format, media and registration lifecycle requirements for items submitted to the Registration Authority.
• Repository access and outputs: Types and formats of Repository extracts intended for public access and implementation use.
• Standards grounding: Uses UML/MOF modelling constructs and targets XML (and ASN.1) as physical syntaxes; XML Schema generation and reverse-engineering are covered in companion parts.

Practical applications and users

ISO 20022-1 is used to:

• Create consistent, reusable business and message models for payments, securities, trade finance, cash management and cross-domain financial processes.
• Ensure interoperability across participants by publishing standard DataDictionary items and Message Sets in the ISO 20022 Repository.
• Guide implementers in generating XML/ASN.1 schemas from logical models and aligning existing message formats.

Primary users:

• Banks, clearing and settlement systems, payment schemes and market infrastructures
• Message designers, enterprise architects and standards teams
• Software vendors, integration specialists and ISO 20022 Registration Authority administrators

Related standards

ISO 20022 is a multipart standard. Relevant companion parts include:

• ISO 20022-2 (UML profile)
• ISO 20022-3 (Modelling)
• ISO 20022-4 (XML Schema generation)
• ISO 20022-5 (Reverse engineering)
• ISO 20022-6 (Message transport characteristics)
• ISO 20022-7 (Registration)
• ISO 20022-8 (ASN.1 generation)

Keywords: ISO 20022, metamodel, Repository, DataDictionary, BusinessProcessCatalogue, Registration Authority, financial messaging, UML, XML schema.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 20022-1
Second edition
2013-05-01
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
Reference number
©
ISO 2013
©  ISO 2013
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – All rights reserved

Contents Page
Foreword . iv
Introduction . vi
1  Scope . 1
2  Normative references . 1
3  Terms and definitions . 1
4  Type Library . 9
5  Metamodel packages . 11
5.1  General . 11
5.2  The metamodel’s use of ISO20022::TypeLibrary . 11
5.3  Levels. 12
5.3.1  Scope level . 13
5.3.2  Conceptual level . 14
5.3.3  Logical level . 16
5.3.4  Physical level . 17
5.4  Models Transformation . 18
5.4.1  Scope to Conceptual . 19
5.4.2  Conceptual to Logical . 20
5.4.3  Logical to Physical . 21
6  Repository . 22
6.1  ISO 20022 Repository structure . 22
6.1.1  Overview . 22
6.2  DataDictionary . 23
6.2.1  Overview . 23
6.2.2  List of Dictionary Items . 23
6.2.3  Dictionary Item Registration Status . 26
6.2.4  Dictionary Items description information . 27
6.2.5  DataDictionary life cycle . 27
6.3  BusinessProcessCatalogue . 28
6.3.1  Overview . 28
6.3.2  List of BusinessProcessCatalogue Items . 28
6.3.3  Catalogue Item Registration Status . 28
6.3.4  Catalogue Item description information . 29
6.3.5  BusinessProcessCatalogue life cycle . 29
7  Registration . 29
7.1  General . 29
7.2  Submission format . 30
7.3  Submission media . 30
8  Repository Access . 30
8.1  General . 30
8.2  Repository output types . 30
8.3  Output format . 30
Annex A (normative) Type library . 32
Annex B (normative) Metamodel . 48
Bibliography . 152

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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 20022-1 was prepared by Technical Committee ISO/TC 68, Financial services.
This second edition cancels and replaces the first edition (ISO 20022-1:2004), which has been technically
revised.
ISO 20022 consists of the following parts, under the general title Financial services — Universal financial
industry message scheme:
 Part 1: Metamodel
 Part 2: UML profile
 Part 3: Modelling
 Part 4: XML Schema generation
 Part 5: Reverse engineering
 Part 6: Message transport characteristics
 Part 7: Registration
 Part 8: ASN.1 generation
ISO 20022-6:2013, ISO 20022-7:2013 and ISO 20022-8:2013 will be implemented by the Registration
Authority by no later than the end of May 2013, at which time support for the concepts set out within them will
be effective. Users and potential users of the ISO 20022 series are encouraged to familiarize themselves with
the 2013 editions as soon as possible, in order to understand their impact and take advantage of their content
as soon as they are implemented by the Registration Authority. For further guidance, please contact the
Registration Authority.
iv © ISO 2013 – All rights reserved

For the purposes of research on financial industry message standards, users are encouraged to
share their views on ISO 20022:2013 and their priorities for changes to future editions of the
document. Click on the link below to take part in the online survey:
http://www.surveymonkey.com/s/20022_2013

Introduction
This International Standard defines a scalable, methodical process to ensure consistent descriptions of
messages throughout the financial services industry.
The purpose of this International Standard 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 this International Standard was the rapid growth in the scale and sophistication
of messaging within financial services during the 1990s using ISO 15022. The financial services industry (from
hereon referred to as "the industry") created the first version of this International Standard as the successor to
ISO 15022 in response to that trigger. Since ISO 15022, the industry has broadened the scope from securities
to the entire industry for this International Standard.
This International Standard is based on open technology standards, which historically have evolved more
rapidly than the industry itself. Consequently, this International Standard 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 this International Standard has emerged followed the
widespread adoption of the World Wide Web (the Web) for business. XML (eXtensible Mark-up Language)
emerged as the de facto standard for document representation on the Web and it became the first syntax for
ISO 20022.
The modelling process is further refined into three levels which, in addition to the messaging technology
standard, is why this International Standard 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 Framework. The remaining two levels
of the Zachman Framework are equivalent to the implementations and the operational levels, respectively.
In this part of ISO 20022, the first, second and third levels are described in UML (Unified Modelling Language)
because it is widely supported and supports multiple levels of abstraction. The models created in accordance
with this International Standard 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 International Standard
defines a method that describes a process by which these models can be created and maintained by the
modellers.
The models and the Physical level artefacts are stored in a central repository, serviced by a Registration
Authority. This International Standard's repository is available on the World Wide Web and offers public
access for browsing.
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 message definitions and business
processes, and physical syntax implementations.
This International Standard is organized into the following parts.
 This part of ISO 20022 describes in MOF (Meta-Object Facility) the metamodel of all the models and the
Repository.
vi © ISO 2013 – All rights reserved

 ISO 20022-2 covers the UML profile, a grounding of general UML into a specific subset defined for this
International Standard (to be used when UML is selected to define the models).
 ISO 20022-3 describes a modelling method to produce models for this International Standard.
 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 logical model alignment and reverse engineering of existing message syntaxes.
 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.
INTERNATIONAL STANDARD ISO 20022-1:2013(E)

Financial services — Universal financial industry message
scheme —
Part 1:
Metamodel
1 Scope
This part of ISO 20022 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 amongst 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.
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 — UML profile
The Zachman Framework for Enterprise Architecture — Zachman Institute for Framework Advancement
W3C Recommendation: XML Schema Part 2: Datatypes Second Edition, 28 October 2004
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
Address
identification and efficient resolution to the location of a MessagingEndpoint
NOTE 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
binary
any set of values drawn from the value space of 'base64Binary', as specified by W3C Recommendation XML
Schema Part 2: Datatypes
3.4
boolean
any set of values drawn from the value space of 'boolean', as specified by W3C Recommendation XML
Schema Part 2: Datatypes
3.5
BroadcastList
set of references to MessagingEndpoints (identified by their Address), that is used for message broadcasting.
NOTE 1 The BroadcastList is managed by the MessageTransportSystem, which provides a mechanism to maintain the
BroadcastList.
NOTE 2 “Set” means the list of Addresses is unordered and each Address may only be present once.
3.6
BusinessArea
set of strongly related business activities that provide a self-standing business value to a set of BusinessRoles
EXAMPLE Securities pre-trade, payment initiation.
NOTE BusinessAreas are stored in the BusinessProcessCatalogue.
3.7
BusinessAssociation
relation between two BusinessComponents
EXAMPLE The servicing of an account by a party.
NOTE 1 BusinessAssociations are a category of BusinessConcepts. Their meaning can only be described
unambiguously in combination with these two BusinessComponents.
NOTE 2 There can be several BusinessAssociations between two particular BusinessComponents.
3.8
BusinessAssociationEnd
the endpoint of a BusinessAssociation, which connects the BusinessAssociation to the BusinessComponent
3.9
BusinessAttribute
a BusinessElement, typed by a BusinessComponent or a DataType (contrary to a BusinessAssociationEnd,
which is always typed by another BusinessComponent)
EXAMPLE AccountIdentification, PhoneNumber.
3.10
BusinessComponent
representation of a (part of a) key business notion, characterized by specific BusinessElements
EXAMPLE Account, trade, party.
NOTE 1 BusinessComponents are a category of BusinessConcepts. They are stored in the DataDictionary.
2 © ISO 2013 – All rights reserved

NOTE 2 A BusinessComponent can have one or more semantic relations with other BusinessComponents.
3.11
BusinessComponentTrace
semantic relationship between a MessageComponentType/MessageElement and the BusinessComponent
from which it is derived
3.12
BusinessConcept
a DataDictionary item defined at the Conceptual level with a business meaning
3.13
BusinessElement
property of a BusinessComponent that has a distinctive meaning within the scope of that BusinessComponent
EXAMPLE Account status, deal price, trade date and deal time.
3.14
BusinessElementTrace
semantic relationship between a MessageElement and the BusinessElement from which it is derived
3.15
BusinessProcess
unrealized definition of the business activities undertaken by BusinessRoles within a BusinessArea whereby
each BusinessProcess fulfils one type of business activity and whereby a BusinessProcess might include and
extend other BusinessProcesses
EXAMPLE Securities ordering, trade matching.
NOTE 1 A BusinessProcess can contain other BusinessProcesses such as in a hierarchical structure.
NOTE 2 BusinessProcesses are stored in the BusinessProcessCatalogue.
3.16
BusinessProcessCatalogue
that part of the ISO 20022 Repository which contains all items related to Business Process and
BusinessTransaction
NOTE It contains related items from the BusinessArea down to the MessageDefinitions and their physical
implementation.
3.17
BusinessProcessTrace
relationship between a BusinessTransaction and the BusinessProcess on which the BusinessTransaction is
based
3.18
BusinessRole
functional role played by a business actor in a particular BusinessProcess or BusinessTransaction
EXAMPLE Account owner, buyer.
NOTE 1 BusinessRoles are a category of BusinessConcepts and are stored in the DataDictionary.
NOTE 2 A business actor can play different BusinessRoles in different BusinessProcesses.
3.19
BusinessRoleTrace
relationship between a Participant in a BusinessTransaction and a BusinessRole identified in the
BusinessProcess from which the BusinessTransaction is derived
3.20
BusinessTransaction
particular solution that meets the communication requirements and the interaction requirements of a particular
BusinessProcess and BusinessArea
NOTE It is typically based on the use of MessageInstances.
3.21
BusinessTransactionTrace
relationship between a BusinessTransaction and its physical implementation
3.22
ChoiceComponent
re-usable Dictionary Item that is a building block for assembling MessageDefinitions, composed of a choice of
MessageElements
NOTE 1 It is usually linked to a BusinessComponent.
NOTE 2 ChoiceComponents are stored in the DataDictionary.
3.23
Code
character string (letters, figures or symbols) that for brevity and/or language independence can be used to
represent or replace a definitive value or text of an attribute
3.24
CodeSet
complete and enumerated set of Codes grouped together to characterize all the values of an attribute
3.25
CodeSetTrace
semantic relationship between two CodeSets whereby the derived Codeset is used as the type of a
BusinessElement and the deriving Codeset is used as the type of a MessageElement
3.26
Constraint
rule that shall be universally satisfied, i.e. all conditions required for the Constraint to be applicable are known
EXAMPLE An Account has an AccountOwner.
3.27
ConvergenceDocumentation
documentation set showing relations between ISO 20022 MessageDefinitions, MessageComponentTypes,
MessageElements, BusinessComponents and/or BusinessElements and items defined in other industry
MessageSets
3.28
Conversation
exchange of one or more MessageInstances amongst MessagingEndpoints
NOTE 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.
3.29
DataDictionary
part of the ISO 20022 Repository that contains all items that can be re-used during business process
modelling and message definition activities
NOTE The DataDictionary therefore contains BusinessConcepts, MessageConcepts and DataTypes.
4 © ISO 2013 – All rights reserved

3.30
DataType
representation of a set of values without identity
3.31
date
any set of values drawn from the value space of 'date', as specified by W3C Recommendation XML Schema
Part 2: Datatypes
3.32
dateTime
any set of values drawn from the value space of 'dateTime', as specified by W3C Recommendation XML
Schema Part 2: Datatypes
3.33
day
any set of values drawn from the value space of 'gDay', as specified by W3C Recommendation XML Schema
Part 2: Datatypes
3.34
decimal
any set of values drawn from the value space of 'decimal', as specified by W3C Recommendation XML
Schema Part 2: Datatypes
3.35
duration
any set of values drawn from the value space of 'duration', as specified by W3C Recommendation XML
Schema Part 2: Datatypes
3.36
ExternalSchema
reusable Dictionary Item that allows referral to a structure defined outside the ISO 20022 MessageDefinition
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.37
IdentifierSet
unenumerated set of values outside the Repository 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.38
indicator
a list of exactly two mutually exclusive values that express the only two possible states of an instance of an
object
3.39
industryMessageSet
set of non-ISO 20022 compliant messages, which is defined and used by part of the financial industry
EXAMPLE The set of FIX v5 messages.
3.40
ISO15022MessageSet
industryMessageSet constructed according to the rules defined in ISO 15022-1 and ISO 15022-2, which is
stored in the ISO 15022 Catalogue of Messages
3.41
MessageAssociationEnd
type of MessageElement that specifies the role of a MessageAssociation
3.42
MessageAttribute
type of MessageElement which is either a DataType or a MessageComponentType
3.43
MessageBuildingBlock
characteristic of a MessageDefinition that has a unique meaning within the scope of that MessageDefinition
NOTE MessageBuildingBlocks are not reused, since they only have meaning within a specific MessageDefinition.
3.44
MessageChoreography
precise and complete description of a MessageInstance exchange within a BusinessTransaction, describing
the sequence and correlation of MessageInstances within a conversation, including the constraints on the
interaction between Participants
NOTE Every BusinessTransaction contains its own MessageChoreography.
3.45
MessageComponent
re-usable Dictionary Item that is a building block for assembling MessageDefinitions, composed of a sequence
of MessageElements
EXAMPLE Trade Details, which contains a number of the properties of the related BusinessComponent “Trade”.
3.46
MessageComponentType
MessageComponent, ExternalSchema or ChoiceComponent
NOTE 1 When a MessageComponentType has a business meaning it is linked to a BusinessComponent.
NOTE 2 MessageComponentTypes are a category of MessageConcepts and are stored in the DataDictionary.
3.47
MessageConcept
DataDictionary artefact, which is not a DataType, that is used in a MessageDefinition
3.48
MessageDefinition
formal description of the structure of a MessageInstance
NOTE 1 The MessageDefinition is built as a tree structure of MessageComponentTypes and DataTypes.
A MessageDefinition is uniquely identified in the BusinessProcessCatalogue.
NOTE 2 A MessageDefinition can have several market practices.
3.49
MessageDefinitionIdentifier
unique identification of a MessageDefinition within the ISO 20022 namespace, identifying the BusinessArea to
which the MessageDefinition belongs, the Message Functionality it covers, its flavour and its version
3.50
MessageDefinitionTrace
relationship between a MessageDefinition and its physical implementation as a SyntaxMessageScheme
NOTE This relationship is explained in ISO 20022-4.
6 © ISO 2013 – All rights reserved

3.51
MessageElement
characteristic of a MessageComponent/ChoiceComponent, which has a unique meaning within the scope of
that MessageComponent/ChoiceComponent
EXAMPLE Trade Date and Time, as part of the MessageComponent “Trade Details”.
NOTE 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.52
MessageInstance
instance of MessageDefinition, containing a set of structured information exchanged between BusinessRoles,
in the scope of a BusinessTransaction
EXAMPLE Notice Of Execution, Order To Buy, Credit Transfer.
NOTE A MessageInstance is expected to be valid against the related MessageDefinition in the ISO 20022 Repository.
This implies validity against the SyntaxMessageScheme as well as validity against the Constraints and market practices
that are registered for this MessageDefinition.
3.53
MessageSet
set of MessageDefinitions
NOTE MessageDefinitions within a MessageSet do not have to belong to the same BusinessArea.
3.54
MessageTransmission
passing of information from one Participant to another in the context of a BusinessTransaction
3.55
MessageTransportMode
group of settings for the values for the MessageTransportCharacteristics properties
NOTE 1 A MessageTransportMode is named and registered in the ISO 20022 Repository. Each
MessageTransportCharacteristic is given a value.
NOTE 2 A MessageTransportMode can be associated with many BusinessTransactions. The MessageTransportMode
is used to organize commonly used combinations of MessageTransportCharacteristic settings.
3.56
MessageTransportSystem
mechanism that receives Transport Messages from the sending MessagingEndpoint, transports them, and
delivers them to the receiving MessagingEndpoint
NOTE 1 The MessageTransportSystem is responsible for delivering Transport Messages to each Addressee.
NOTE 2 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.57
MessageTypeTrace
relationship between a MessageTransmission in a BusinessTransaction and its corresponding
MessageDefinition
3.58
MessagingEndpoint
addressable node on the MessageTransportSystem which is capable of sending and receiving
TransportMessages
NOTE A MessagingEndpoint has an Address.
3.59
month
any set of values drawn from the value space of 'gMonth', as specified by W3C Recommendation XML
Schema Part 2: Datatypes
3.60
MonthDay
any set of values drawn from the value space of 'gMonthDay', as specified by W3C Recommendation XML
Schema Part 2: Datatypes
3.61
Participant
involvement of a BusinessRole in a BusinessTransaction
3.62
quantity
a counted number of non-monetary units possibly including fractions
3.63
rate
a quantity or amount measured with respect to another measured quantity or amount
EXAMPLE US Dollars per hour, US Dollars per EURO.
3.64
receive
handling of a stimulus passed from a sender instance
3.65
Repository
place where all RepositoryConcepts are stored
3.66
RepositoryConcept
artefact that has been defined during the development of an ISO 20022 MessageDefinition and which is
stored in the Repository
3.67
send
passing of a stimulus from a sender instance to a receiver instance
3.68
string
any set of values drawn from the value space of 'string', as specified by W3C Recommendation XML Schema
Part 2: Datatypes
3.69
SyntaxMessageScheme
syntax processable notation used to define the structure of a MessageInstance in a particular syntax
NOTE 1 In case of XML, the representation might, for instance, be an XML DTD or an XML Schema and can then be
used as a validation tool for MessageInstances.
8 © ISO 2013 – All rights reserved

NOTE 2 Syntax message representations are stored in the BusinessProcessCatalogue
3.70
text
finite set of characters
3.71
time
any set of values drawn from the value space of 'time', as specified by W3C Recommendation XML Schema
Part 2: Datatypes
3.72
TopLevelCatalogueEntry
artefact in the BusinessProcessCatalogue that is not owned by another artefact in the Repository
3.73
TopLevelDictionaryEntry
artefact in the Dictionary that is not owned by another artefact in the Repository
3.74
trace
relationship between two objects that represent the same concept but have a different but related context
3.75
TransportMessage
document that is an instance of the MessageTransportSystem message schema
3.76
year
any set of values drawn from the value space of 'gYear', as specified by W3C Recommendation XML Schema
Part 2: Datatypes
3.77
yearMonth
any set of values drawn from the value space of 'gYearMonth', as specified by W3C Recommendation XML
Schema Part 2: Datatypes
4 Type Library
The Type Library contains the primitive data types used in both this International Standard's metamodel and
the models created in accordance with this International Standard. It consists of XSD (XML Schema
Definition) Built-in DataTypes and Enumerations. Further details on these packages can be found in Annex A.

Figure 1 — XSD Built-in DataTypes
10 © ISO 2013 – All rights reserved

Figure 2 — DataType enumerated values

5 Metamodel packages
5.1 General
The metamodel describes the structure of models built in accordance with this International Standard. All
models produced according to this International Standard shall comply with this one model.
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::XMLSchema Package contains definitions of the W3C XML Schema built-in Datatypes in a form
that makes it possible for modellers to use these Datatypes in UML and MOF models.

Figure 3 — ISO 20022 level structure

5.3 Levels
The metamodel has four levels of model, each of increasing realization. These four levels are based upon the
first four levels of the Zachman Framework.
12 © ISO 2013 – All rights reserved

Table 1 — Metamodel levels
Level name Focus
Scope Achieving a thorough understanding of the business objectives of the considered
BusinessArea and its relevant Business Processes.
Conceptual Formalizing the semantics and discovering the communication and interaction
requirements related to these Business Processes by defining the
BusinessTransactions, BusinessActivities and Message Choreographies related to
these Business Processes.
Logical Creating a precise description of the messages and systems, without regard to
technology.
Physical Creating a precise description of the messages and systems in a technology that
can be used for implementation.

The Zachmann Framework has two further levels. These are regarded as being under the aegis of the
implementers of this International Standard.
For a BusinessArea being modelled, each level is modelled completely and precisely.
The number of levels may not be added to or reduced.
NOTE 1 Adding or removing levels introduces redundancy or discontinuity.
Each level is disjointed.
NOTE 2 No concept may appear at more than one level without a change in the level of realization.
There is no relationship between the levels other than realization.
There is no sequence, other than the ordering of realization, implicit in the levels. Any level may be completed
in any order.
NOTE 3 This might be further constrained in a modelling method.
NOTE 4 The levels do not subsume each other.
NOTE 5 The metaclasses used to explain the different levels are detailed in Annex B.
5.3.1 Scope level
The purpose of the Scope level is to acquire an understanding of the BusinessArea for which an ISO 20022
compliant BusinessTransaction and MessageSet is to be developed. Describing the BusinessProcesses helps
in the identification of the communication problems that exist among the business actors (modelled as
BusinessRoles) that take part in these processes. Those communication problems will be the main drivers for
the Conceptual level. Identifying the Business Information that is manipulated in a BusinessArea is also
important for the later Logical level, because the MessageDefinitions will contain data elements that are
related to this business information.
Figure 4 — Scope level
5.3.2 Conceptual level
5.3.2.1 Creation of a semantic model of all artefacts (static part)
The Conceptual level starts by using a “black box perspective” in order to avoid prematurely tackling
architectural issues regarding the issues encountered during the implementation. A “black box” perspective
means that one does not try to define BusinessTransactions and MessageDefinitions. The focus is only on
defining “who needs what” in order to execute the BusinessProcesses. There is no attempt yet to define how
to get the information at the right moment to the right business user. All BusinessConcepts that are involved in
the BusinessTransactions shall firstly be identified.
14 © ISO 2013 – All rights reserved

Figure 5 — ConceptualStatic level

5.3.2.2 Identification of the requirements related to communication (dynamic part)
Define the dynamic part (i.e. the process description of the full interaction between all involved Participants) by
specifying the details of the BusinessTransaction and MessageSet that will be developed. This means that the
focus is moving from the “black box” perspective to a “white box” perspective. A “white box” perspective
means that one looks into all the details of the BusinessTransaction and MessageSet. The focus is now on
defining the MessageFlows and MessageDefinitions that are needed to get the required information at the
right time to the right business user.

Figure 6 — ConceptualDynamic level
5.3.3 Logical level
The purpose of the Logical level is to create the MessageSets with their MessageDefinitions:
 the MessageSet is still characterized from a pure business perspective;
 the focus moves from defining the dynamics to defining the static part (i.e. the precise structure of the
MessageInstances) of the BusinessTransaction and MessageSet, which is done in
MessageDefinition Diagrams.
16 © ISO 2013 – All rights reserved

Figure 7 — Logical level
5.3.4 Physical level
The physical level delivers the physical implementation of MessageDefinitions and Constraints in an
appropriate syntax, such as ISO 20022 XML. Specific design rules are used to build the physical
representation of the MessageDefinitions from the deliverables of the Logical level.
The key deliverable of the Physical level is:
 a set of ISO 20022 Syntax Message Schemes;
 the Message Choreography.
Figure 8 — Syntax artefacts
5.4 Models Transformation
Model transformation is inspired by the principles of OMG's MDA (Model Driven Architecture). To maintain
consistency and facilitate realization, there is a transformation of the model at each level to its immediately
subsequent level.
EXAMPLE The Conceptual level may be transformed to the Logical level.
The model at each level is transformed to the next level through being decorated with traces. Each trace is a
map from one level to the next.
18 © ISO 2013 – All rights reserved

Figure 9 — Traces
Table 2 — Transformation levels
Level name Purpose
Scope to Conceptual A map decorating a Scope level for the purpose of transformation to a
Conceptual level.
Conceptual to Logical A map decorating a Conceptual level for the purpose of transformation
to a Logical level.
Logical to Physical A map decorating a Logical level for the purpose of transformation to a
Physical level.
5.4.1 Scope to Conceptual
During the Conceptual level, the communication problem is described (the required information is scattered
amongst the Participants). This means that for each BusinessProcess with its BusinessRoles, one or more
BusinessTransactions with its Participants will have to be defined. A trace is defined for each Scope artefact
to its corresponding Conceptual artefact.
Figure 10 — Scope to Conceptual level mapping

5.4.2 Conceptual to Logical
MessageDefinitions are created by populating them with MessageComponentTypes. These
MessageComponentTypes (which are contextual to the MessageDefinition in which they are used) may be
derived from their more generic BusinessComponents. In such cases they shall be traced.
MessageTransmissions defined in BusinessTransaction Diagrams (identified as Signals in Sequence
Diagrams) trace to MessageDefinitions.
20 © ISO 2013 – All rights reserved

Figure 11 — Conceptual to Logical level mapping
5.4.3 Logical to Physical
This transformation is defined in ISO 20022-4.

Figure 12 — Logical to Physical level mapping
6 Repository
6.1 ISO 20022 Repository structure
6.1.1 Overview
Figure 13 shows a high level view of the structure of the ISO 20022 Repository. As indicated, the ISO 20022
Repository consists of two major parts: the BusinessProcessCatalogue and the DataDictionary.

Figure 13 — Global concepts
The DataDictionary contains BusinessConcepts, MessageConcepts, Constraints and DataTypes. All these
items are re-usable and are TopLevelDictionaryEntries. The DataDictionary as a whole is under release
control.
The BusinessProcessCatalogue consists of TopLevelCatalogueEntries. The communication requirements and
the interaction requirements in the various BusinessAreas are supported by BusinessTransactions,
BusinessActivities and MessageDefinitions. All items that are stored in the BusinessProcessCatalogue are
called Catalogue Items. Within the BusinessProcessCatalogue, the TopLevelCatalogueEntries are under
release control. A BusinessProcessCatalogue release is always based on one single DataDictionary release.
The main relationships between Dictionary Items and Catalogue Items are as follows.
 Within the DataDictionary: MessageConcepts are derived from BusinessConcepts.
 Within the BusinessProcessCatalogue: BusinessTransactions support BusinessAreas.
22 © ISO 2013 – All rights reserved

 Between the BusinessProcessCatalogue and the DataDictionary: BusinessAreas are described using
BusinessConcepts and BusinessTransactions are composed of MessageConcepts.
All Dictionary Items and Catalogue Items are uniquely identified, registered and managed within the
Repository. The ISO 20022 Repository contains change his
...