ISO 20022-3:2013

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 20022-3:2013(E)
©
ISO 2013

---------------------- Page: 1 ----------------------
ISO 20022-3:2013(E)

COPYRIGHT PROTECTED DOCUMENT


©  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 copyright@iso.org
Web www.iso.org
Published in Switzerland

ii © ISO 2013 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 20022-3:2013(E)
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
© ISO 2013 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 20022-3:2013(E)
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

---------------------- Page: 4 ----------------------
ISO 20022-3:2013(E)
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.
© ISO 2013 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO 20022-3:2013(E)
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

---------------------- Page: 6 ----------------------
ISO 20022-3:2013(E)
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 2013 – All rights reserved vii

---------------------- Page: 7 ----------------------
ISO 20022-3:2013(E)
 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

---------------------- Page: 8 ----------------------
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;
© ISO 2013 – All rights reserved 1

---------------------- Page: 9 ----------------------
ISO 20022-3:2013(E)
 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

---------------------- Page: 10 ----------------------
ISO 20022-3:2013(E)

Figure 1 — High level workflow activity diagram
© ISO 2013 – All rights reserved 3

---------------------- Page: 11 ----------------------
ISO 20022-3:2013(E)
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

---------------------- Page: 12 ----------------------
ISO 20022-3:2013(E)
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.
© ISO 2013 – All rights reserved 5

---------------------- Page: 13 ----------------------
ISO 20022-3:2013(E)
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

---------------------- Page: 14 ----------------------
ISO 20022-3:2013(E)
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 dev
...