ISO 20022-3:2013

Financial services - Universal financial industry message scheme - Part 3: Modelling

ISO 20022-3:2013 describes the modelling workflow, complementing ISO 20022-1:2013 and ISO 20022-2:2013. The modelling workflow describes the required steps a modeller follows in order to develop and maintain standardized BusinessTransactions and MessageSets. ISO 20022-3:2013 is not intended to describe what will be the permissible artefacts and/or documents to be submitted to the Registration Authority (this information is contained in ISO 20022-7). Examples are provided only to illustrate the modelling methodology and are not normative.

Services financiers — Schéma universel de messages pour l'industrie financière — Partie 3: Modélisation

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-3 - Financial services — Universal financial industry message scheme — Part 3: Modelling
• Effective Date: 06-Jun-2022
• Revises: ISO/TS 20022-3:2004 - Financial services - UNIversal Financial Industry message scheme - Part 3: ISO 20022 modelling guidelines
• Effective Date: 22-Aug-2009

Overview

ISO 20022-3:2013 - "Financial services - Universal financial industry message scheme - Part 3: Modelling" defines a structured, methodical modelling workflow for creating and maintaining ISO 20022 message models. It complements ISO 20022-1 (metamodel) and ISO 20022-2 (UML profile) and focuses on the activities modellers follow to develop standardized BusinessTransactions and MessageSets. The standard uses a four-level modelling approach (Scope, Conceptual, Logical, Physical), is technology‑independent, and provides guidelines, constraints and naming conventions. Examples in the document are illustrative only and are not normative. Registration procedures and permissible artefacts are handled separately in ISO 20022-7.

Key Topics

• Modelling workflow and activities: stepwise guidance across Scope, Conceptual, Logical and Physical levels (e.g., define business context, business model, BusinessTransactions, MessageSets, compose MessageDefinitions, create syntax schemes).
• Levels of abstraction: clear separation of business scope, conceptual models, logical message definitions, and physical syntax implementations to ensure consistency and scalability.
• UML and MOF grounding: alignment with ISO 20022-1 (MOF metamodel) and ISO 20022-2 (UML profile) for model representation.
• Repository concepts: use of a central Repository maintained by the Registration Authority with a DataDictionary (reusable model elements) and a BusinessProcessCatalogue (message definitions, processes and syntax implementations).
• Constraints, naming and conventions: rules and guidelines to ensure interoperable, predictable message structures (including constraints, inheritance, normalization and naming conventions).
• Non-normative examples and Annexes: applied UML diagrams and practical modelling illustrations are provided to clarify methodology without being normative.

Applications

ISO 20022-3 is designed for anyone responsible for modelling financial messaging and ensuring interoperability across systems:

• Message architects and modellers designing standardized BusinessTransactions and MessageSets.
• Banks, clearing houses, payment schemes and market infrastructures defining industry message exchanges.
• Fintech vendors and system integrators implementing ISO 20022 payloads and transformations.
• Standards and governance teams responsible for repository submissions and lifecycle management of message artefacts.

Practical outcomes include consistent message design, a repeatable modelling process, easier transformation to physical syntaxes (XML, ASN.1 via other ISO 20022 parts), and clearer registration-ready artefacts for repository management.

Related Standards

• ISO 20022-1 - Metamodel (MOF)
• ISO 20022-2 - UML profile
• ISO 20022-4 - XML Schema generation rules
• ISO 20022-5 - Reverse engineering / logical model alignment
• ISO 20022-6 - Message transport characteristics
• ISO 20022-7 - Registration processes (permissible artefacts)
• ISO 20022-8 - ASN.1 generation

Using ISO 20022-3 in conjunction with these parts ensures a robust, end‑to‑end approach to designing, registering and implementing standardized financial industry messages.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 20022-3
First edition
2013-05-01
Financial services — Universal financial
industry message scheme —
Part 3:
Modelling
Services financiers — Schéma universel de messages pour l'industrie
financière —
Partie 3: Modélisation
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 . v
Introduction . vii
1  Scope . 1
2  Normative references . 1
3  Terms and definitions . 1
4  Workflow activities overview . 1
5  Scope level . 4
5.1  General . 4
5.1.1  Purpose . 4
5.1.2  Key topics . 4
5.1.3  Main activities . 4
5.1.4  Deliverables . 4
5.2  Activities . 5
5.2.1  Define business context . 5
5.2.2  Define BusinessProcesses . 6
5.3  Guidelines . 6
6  Conceptual level . 7
6.1  General . 7
6.1.1  Purpose . 7
6.1.2  Key topics . 7
6.1.3  Main activities . 7
6.1.4  Deliverables . 7
6.2  Activities . 8
6.2.1  Define business model . 8
6.2.2  Define BusinessTransactions . 9
6.3  Guidelines . 12
7  Logical level . 12
7.1  General . 12
7.1.1  Purpose . 12
7.1.2  Key topics . 12
7.1.3  Main activities . 13
7.1.4  Deliverables . 13
7.2  Activities . 13
7.2.1  Define the MessageSet . 13
7.2.2  Compose MessageDefinition . 13
7.3  Constraints . 17
7.3.1  Inheritance . 17
7.3.2  Normalized MessageDefinitions . 18
7.3.3  Normalization . 18
7.3.4  Non-Constraint preference . 18
7.3.5  Sibling constraints . 18
7.3.6  Value derivation . 18
7.3.7  Versions versus flavours . 18
7.3.8  Modelling associations between MessageComponent Types. . 18
7.4  Guidelines . 19
7.4.1  BusinessTransactions . 19
7.4.2  MessageInstance style . 19
7.4.3  Party Neutral MessageInstance . 19
7.4.4  MessageInstance granularity .19
7.4.5  How to handle bi-directional relations .20
7.4.6  Factorize .20
7.4.7  How to define an ExternalSchema .20
7.4.8  How to enforce canonical form for date or time related user-defined DataTypes .20
8  Physical level .21
8.1  General .21
8.1.1  Purpose .21
8.1.2  Key topics .21
8.1.3  Main activities .21
8.1.4  Deliverables .21
8.2  Activities .21
8.2.1  Create syntax scheme .21
9  Conventions .22
9.1  Constraints .22
9.2  Naming .22
9.2.1  General .22
9.2.2  Generic rules applicable to all Repository Concepts .22
Annex A (normative) Applied UML diagrams .23
Bibliography .24

iv © ISO 2013 – All rights reserved

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-3 was prepared by Technical Committee ISO/TC 68, Financial services.
This first edition cancels and replaces ISO/TS 20022-3:2004.
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-1:2013, ISO 20022-2:2013, ISO 20022-3:2013, ISO 20022-4:2013, ISO 20022-5:2013,
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.
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

vi © ISO 2013 – All rights reserved

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
here on 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 ISO 20022-1, 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.
 ISO 20022-1 describes in MOF (Meta-Object Facility) the metamodel of all the models and the Repository.
 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).
 This part of ISO 20022 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.
viii © ISO 2013 – All rights reserved

INTERNATIONAL STANDARD ISO 20022-3:2013(E)

Financial services — Universal financial industry message
scheme —
Part 3:
Modelling
1 Scope
This part of ISO 20022 describes the modelling workflow, complementing ISO 20022-1 and ISO 20022-2. The
modelling workflow describes the required steps a modeller follows in order to develop and maintain
standardized BusinessTransactions and MessageSets.
This part of ISO 20022 is not intended to describe what will be the permissible artefacts and/or documents to
be submitted to the Registration Authority (this information is contained in ISO 20022-7).
Examples are provided only to illustrate the modelling methodology and are not normative.
2 Normative references
ISO 20022-1, Financial services — Universal financial industry message scheme — Part 1: Metamodel
ISO 20022-2, Financial services — Universal financial industry message scheme — Part 2: UML profile
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 20022-1 and ISO 20022-2 apply.
4 Workflow activities overview
The objective of a standardized BusinessTransaction is to define a commonly agreed solution for
communication problems existing among different organizations within the context of a given
BusinessProcess.
For a given communication problem in a given business context, several solutions can be developed. The
purpose of this part of ISO 20022 is to explain the different steps a modeller should follow to ensure that all
ISO 20022 items such as BusinessComponents/BusinessElements,
MessageComponentTypes/MessageElements, BusinessTransactions and MessageDefinitions are defined in
a consistent way.
The ISO 20022 methodology is composed of a set of activities. These activities are grouped into the following
levels:
 Scope level;
 Conceptual level;
 Logical level;
 Physical level.
For each of these activities, this part of ISO 20022 describes:
 the artefacts needed to start this activity (required input);
 the artefacts that should be the result of this activity (expected output);
 an example (where useful);
 any constraints and rules of modelling that should be followed or taken into account.
2 © ISO 2013 – All rights reserved

Figure 1 — High level workflow activity diagram
5 Scope level
5.1 General
5.1.1 Purpose
The purpose of the Scope level is to achieve a better understanding of the BusinessArea and
BusinessProcesses for which ISO 20022 compliant BusinessTransactions and MessageSets will be
developed.
a) Describing the BusinessProcesses, including the BusinessRoles and their need for business information,
helps in the identification of the communication problems that exist among the organizations that take part
in these processes. Those communications problems are the main drivers for the next phase (Conceptual
level).
b) Identifying business information manipulated in a BusinessArea is also important because the
MessageDefinitions, which will be designed later, will contain data elements that are related to the
BusinessConcepts. An explicit link between BusinessConcepts and MessageConcepts will be helpful for
interoperability for later maintenance and for change management; if something changes in a
BusinessArea, it will be possible to identify the impact on previously defined MessageDefinitions.
5.1.2 Key topics
The key topics of the Scope level are:
 identification of the business context of the communication problem to be solved;
 understanding the daily business in the BusinessArea and BusinessProcesses with no special focus on
the BusinessTransactions and MessageSets to be developed;
 capturing the Business Concepts manipulated within the BusinessProcesses;
 ensuring that all users, such as business experts and standards developers, have a common
understanding of the BusinessArea and the BusinessProcesses.
5.1.3 Main activities
The main activities of the Scope level are:
 specification of the boundaries of the project by selecting the BusinessArea(s), defining the Business
Goal and identifying key BusinessComponents;
 specification of the BusinessProcesses.
5.1.4 Deliverables
The deliverables of the Scope level are:
 a textual description of the Business Context (objectives, scope and boundaries);
 models describing the BusinessProcesses, and the BusinessContext and BusinessRoles involved in
these BusinessProcesses. (all model elements are enriched with textual descriptions, including a glossary
of business terms).
4 © ISO 2013 – All rights reserved

5.2 Activities
5.2.1 Define business context
The following steps are followed to define the business context (see Figure 2).
 Define the BusinessArea(s): identification and any assumptions related to the BusinessArea(s) covered
by the scope.
 Specify the business goal: global objectives and purposes for the considered BusinessArea, expected
functionality and constraints (e.g. market infrastructures to be part of the solution, performance
requirements such as settlement having to occur one business day after the Trade, interoperability
requirements, market practices to be considered).
 Identify key BusinessComponents and Elements that are handled and/or used within the business context.
They can be classified into input information (i.e. information that influences the BusinessProcesses but
that is not controlled within the scope of the business context) and output information (i.e. information that
is controlled within the scope of the business context and impacts other BusinessProcesses).

Figure 2 — Define business context
NOTE See Figure 1.
5.2.2 Define BusinessProcesses
This activity defines the following elements.
1) The organization of the BusinessProcesses, starting from a top-level node (representing the overall
business goal). Refinements can be made using "include" and "extend" relations between
BusinessProcesses.
2) For each BusinessProcess and each activity within a BusinessProcess:
i) the definition, i.e. a description of the activity;
ii) the trigger, i.e. an event that causes the start of the activity;
iii) the pre-conditions, i.e. conditions that shall be fulfilled in order to start the activity;
iv) the post-conditions, i.e. conditions that shall be fulfilled when the activity is completed;
v) the arguments, i.e. information that is required, created or changed for the execution of the
activity.
3) The BusinessRoles that are relevant for the defined BusinessProcess(es). A BusinessRole also
applies to any BusinessProcesses that are extended or included from the owning BusinessProcess.
NOTE See Figure 1.
5.3 Guidelines
Apply a "bird's eye view". At the Scope level, it is desirable to concentrate on the business and avoid
discussing the solution or even the communication problem. This means that it is assumed that there is no
communication problem and each of the BusinessRoles has a perfect knowledge of and access to all
information manipulated within its BusinessProcess. It should be remembered that a "good" BusinessProcess
adds tangible business value.
Focus mainly on BusinessProcesses that provide a lot of added value, by eliciting BusinessComponents or
BusinessRoles. It is not advisable to become immersed in details, e.g. "cancel", "modify", "create", error
handling, at this stage. For example, the description of an "Interbank Transfer" BusinessProcess will elicit
concepts like "Account", "Credit", etc.; the description of the "Cancel Interbank Transfer" will have no specific
added value and should not be considered at this stage. These details will be elaborated during the
Conceptual level and the Logical level, when BusinessTransactions and MessageSets are defined.
Concentrate on functional roles, rather than on real-life actors. For instance, it is important at this stage to
identify the role "Buyer", but it is not yet important to identify whether the buyer is an individual, a corporate or
a financial institution.
Depending on the useful level of detail, one may decide to decompose a BusinessProcess into more detailed
BusinessProcesses.
Roles should only be associated to the most detailed BusinessProcesses, i.e. the lowest level.
Business terms will either be accompanied by a short and clear description to remove possible ambiguities or,
preferably, refer to an existing glossary of business terms.
6 © ISO 2013 – All rights reserved

6 Conceptual level
6.1 General
6.1.1 Purpose
The purpose of the Conceptual level is to define and understand the business semantics and to define the
communication requirements caused by the physical separation of the various BusinessRoles in the
BusinessProcesses.
The Conceptual level identifies and specifies all communication requirements that exist within the agreed
scope of BusinessProcesses and activities. It identifies who needs what kind of information, from whom, and
at what moment. As such, the Conceptual level will provide the specifications for the solution (i.e. the
BusinessTransactions) that will be developed, without going into the actual definition of messages.
6.1.2 Key topics
The key topics of the Conceptual level are:
 analysis of the business model in order to discover the communication requirements that arise;
 precise definition of the expected properties of the BusinessTransactions and MessageSets to be
developed;
 establishing the overall architecture of the solution, i.e. whether to pursue a user-to-user solution or a
centrally co-ordinated solution;
 establishing what the BusinessTransactions are (the different MessageInstances can be exchanged
according to a number of message flows that need to be identified).
6.1.3 Main activities
The main activities of the Conceptual level are:
 specification of functional (behavioural) requirements of the BusinessTransactions and MessageSets to
be developed;
 specification of Constraints (imposed restrictions) of the BusinessTransactions and MessageSets to be
developed;
 refinement of the BusinessProcesses (expressed as use cases) into concrete BusinessTransactions
(expressed as Sequence Diagrams);
 identification of the overall architecture of the solution.
6.1.4 Deliverables
The deliverables of the Conceptual level are:
 textual descriptions refining the scope and boundaries of the final solution;
 a BusinessComponent diagram depicting the information used by each of the Participants (possibly
complemented with textual descriptions of some business related Rules);
 a BusinessTransaction diagram containing a description of the BusinessTransactions.
6.2 Activities
6.2.1 Define business model
Having established a physical separation among the different BusinessRoles, refine the BusinessProcesses
and activities that need to be supported by the BusinessTransactions and MessageSets to be developed. This
is done based on the BusinessProcess diagrams defined during Scope level.
1)
Produce a diagram of all BusinessComponents derived from the "arguments" in the use case. It can contain
inheritance, association and aggregation relations. Go through all existing BusinessComponents in the
DataDictionary and add the required ones to the BusinessComponent diagram. Complete the diagram with
those BusinessConcepts that have been identified and that do not yet exist in the DataDictionary. All these
new artefacts will have to be submitted to the Registration Authority.
The BusinessComponent diagram can contain information regarding multiplicity and shall indicate the type
(represented by a DataType or a BusinessComponent) of each Business Element.
 BusinessComponents have meaning and a context and are composed of BusinessElements and
Constraints.
 DataTypes have no, or insignificant, context or semantics; they have no identity. BusinessAttributes
shall be typed by DataTypes or other BusinessComponents.
 In IdentifierSets, each individual value has very little context and has an insignificant impact on the
semantics of the BusinessAttribute.
 CodeSets contain considerably more semantics than IdentifierSets; each individual value (i.e. each
CodeSetLiteral) qualifies the BusinessAttribute and gives it specific meaning.
 There are different relations possible between two BusinessComponents.
 Where a BusinessComponent is entirely part of another BusinessComponent, the latter's
BusinessAssociationEnd (i.e. its associationDomain) has its Property aggregation set to
"COMPOSITE". Real business containment means that in real life the contained element
(the part) can never exist without the container (the whole). So be careful in the
BusinessComponent diagram to use aggregation only to represent real business
containment.
EXAMPLE An account balance cannot exist without an account.
 Where a BusinessComponent is part of several BusinessComponents, the latter's
BusinessAssociationEnd (i.e. its associationDomain) has its Property aggregation set to
"SHARED".
EXAMPLE A person has an address, but so has a financial institution.
 Where the BusinessComponents are related and independent, both
BusinessAssocia
...