ISO/TS 20022-3:2004

TECHNICAL ISO/TS
SPECIFICATION 20022-3
First edition
2004-12-15

Financial services — UNIversal Financial
Industry message scheme —
Part 3:
ISO 20022 modelling guidelines
Services financiers — Schéma universel de messages pour l'industrie
financière —
Partie 3: Lignes directrices pour la modélisation ISO 20022




Reference number
ISO/TS 20022-3:2004(E)
©
ISO 2004

---------------------- Page: 1 ----------------------
ISO/TS 20022-3:2004(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


©  ISO 2004
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 2004 – All rights reserved

---------------------- Page: 2 ----------------------
(Blank page)

---------------------- Page: 3 ----------------------
ISO/TS 20022-3:2004

Contents
Foreword
Introduction
1 Business analysis. 6
1.1 Introduction.6
1.1.1 Purpose.6
1.1.2 Key topics.6
1.1.3 Deliverables.6
1.2 Process overview.7
1.3 Activities.8
1.3.1 Define business context . 8
1.3.2 Define Business Model. 8
1.4 Guidelines.10
2 Requirements analysis. 11
2.1 Introduction.11
2.1.1 Purpose.11
2.1.2 Key topics.11
2.1.3 Main activities.11
2.1.4 Deliverables.12
2.2 Process overview.13
2.3 Activities.14
2.3.1 Define final scope & boundary. 14
2.3.2 Define communication requirements.14
2.3.3 Complete requirements and constraints. 15
2.4 Guidelines.15
3 Logical analysis . 16
3.1    Introduction. 16
3.1.1 Purpose.16
3.1.2 Key topics.16
3.1.3 Main activities.17
3.1.4 Deliverables.17
3.2 Process overview.18
3.3 Activities.19
© ISO 2004 – All rights reserved 2

---------------------- Page: 4 ----------------------
ISO/TS 20022-3:2004

3.3.1 Define “architecture”.19
3.3.2 Define Business Transactions. 19
3.4 Guidelines.20
3.4.1 General.20
3.4.2 Message granularity.21
4 Message design . 23
4.1 Introduction.23
4.1.1 Purpose.23
4.1.2 Key topics.23
4.1.3 Main activities.23
4.1.4 Deliverables.23
4.2 Process overview.24
4.3 Activity: define Message Components . 25
4.3.1 Common guidelines.26
4.3.2 Advanced guidelines.30
4.4 Activity : compose Messages. 34
4.4.1 Common guidelines.34
5 Technical design. 36
6 Naming conventions. 37
Annex A: Example. 38
A.1 Business analysis: funds industry Business Processes. 38
A.2 Requirements analysis: fund communication requirements . 42
A.3 Logical analysis: Business Transactions. 45
A.4 Message design: compose Messages . 47


© ISO 2004 – All rights reserved 3

---------------------- Page: 5 ----------------------
ISO/TS 20022-3:2004

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.
In other circumstances, particularly when there is an urgent market requirement for such documents,
a technical committee may decide to publish other types of normative document:
— an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical
experts in an ISO working group and is accepted for publication if it is approved by more than
50 % of the members of the parent committee casting a vote;
— an ISO Technical Specification (ISO/TS) represents an agreement between the members of a
technical committee and is accepted for publication if it is approved by 2/3 of the members of
the committee casting a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed
for a further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS
or ISO/TS is confirmed, it is reviewed again after a further three years, at which time it must either
be transformed into an International Standard or be withdrawn.
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/TS 20022-3 was prepared by Technical Committee ISO/TC 68 to complement ISO 20022-1,
Overall methodology and format specifications for inputs to and outputs from the ISO 20022
Repository, with detailed modelling guidelines to be used to construct ISO 20022 compliant business
transactions and message sets. This Technical Specification should be reviewed and considered for
publication as an International Standard once further experience has been gained in using these
guidelines and the use of the underlying technology has further stabilized.
ISO 20022 consists of the following parts, under the general title Financial services — UNIversal
Financial Industry message scheme:
 Part 1: Overall methodology and format specifications for inputs to and outputs from the
ISO 20022 Repository
 Part 2: Roles and responsibilities of the registration bodies
 Part 3: ISO 20022 modelling guidelines [Technical Specification]
 Part 4: ISO 20022 XML design rules [Technical Specification]
 Part 5: ISO 20022 reverse engineering [Technical Specification]
© ISO 2004 – All rights reserved 4

---------------------- Page: 6 ----------------------
ISO/TS 20022-3:2004


Introduction
The methodology described in this document focus on the development of standardized
Business Transactions and Message Sets. The objective of a standardized Business
Transaction is to define a commonly agreed solution for communication problems existing
among different organizations within the context of a given Business Process.
For a given communication problem in a given business context, several solutions can be
developed. The purpose of this document is to explain the different steps a modeller should
follow to ensure that ISO 20022 Business Components / Elements, Message Components /
Elements, Business Transactions and Messages are defined in a consistent way.
The ISO 20022 methodology is composed of a set of activities. These activities are grouped
into the following phases:
- business analysis
- requirements analysis
- logical analysis
- logical design (message design)
- technical design

For each of these activities, this document 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 modelling and other guidelines that should be followed or taken into account

It is not the intent of this document to describe what will be the allowed artefacts and/or
documents to be submitted to the Registration Authority. This information is described in
the ISO 20022 submission templates and their related guidelines.

Examples are provided only to illustrate the modelling methodology and should not be
regarded as definitive for the Business Areas described.
For the purpose of ISO/TS 20022-3, the terms and definitions given in ISO 20022-1 apply.
© ISO 2004 – All rights reserved 5

---------------------- Page: 7 ----------------------
ISO/TS 20022-3:2004

1 Business analysis
A small example of Business Analysis can be found in Annex A (Business analysis: funds
industry Business Processes).
1.1 Introduction
1.1.1 Purpose
The purpose of business analysis is to achieve a better understanding of the Business Area
and Business Processes for which ISO 20022 compliant Business Transactions and
Message Sets will be developed:
- Describing the Business Processes, including the Business Roles 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 (requirements analysis).
- Identifying Business Information manipulated in a Business Area is also important
because the Messages - that will be designed in later phases - will contain data elements
that are related to this Business Information. An explicit link between Business
Elements/Components and Message Elements/Components will be helpful for
interoperability, for later maintenance and for change management: if something
changes in a Business Area, it will be possible to identify the impact on previously
defined Messages.
1.1.2 Key topics
• To identify the business context of the communication problem to be solved.
• To understand the daily business in the Business Area and Business Processes with no
special focus on the Business Transactions and Message Sets to be developed.
• To capture the Business Information manipulated within the Business Processes.
• To ensure that all users, such as business experts and standards developers have a
common understanding of the Business Area and the Business Processes.
1.1.3 Deliverables
• Textual description of the Business Area (objectives, scope and boundaries)
• Models describing the Business Processes and the Business Information and Business
Roles involved in these Business Processes. All model elements are enriched with
textual descriptions, including a glossary of business terms.
© ISO 2004 – All rights reserved 6

---------------------- Page: 8 ----------------------
ISO/TS 20022-3:2004


1.2 Process overview
The below picture shows the different activities (shown as ovals) this process has to follow
and what the required inputs and outputs (shown as squares) are. These activities are further
detailed in the following paragraph.
<>
Project Scope & Requirements
<>
<>
Def ine business context
<>
<>
Business Actors&Roles
Business Components
Def ine Business Model
<>
<>
Business Component diagram
Business Activ ity diagram
<>
<>
Business Role diagram
Business Process diagram


© ISO 2004 – All rights reserved 7

---------------------- Page: 9 ----------------------
ISO/TS 20022-3:2004

1.3 Activities
1.3.1 Define business context
This activity consists of defining and refining:
- Business goal: global objectives and purposes for the considered Business Area.
- Scope: which Business Processes are in or out of scope, which financial instruments are
in or out of scope, which Business Actors and Business Roles need to be considered,
etc.
- Boundaries: key Business Components 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 Business Processes 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 Business Processes).
- Assumptions related to the Business Area.
- Business requirements (expected functionality) and constraints (e.g. market
infrastructures to be part of the solution, performance requirements (T+1),
interoperability requirements, Market Practices to be considered)
- Business terms will either be accompanied by a short and clear description to remove
possible ambiguities or - preferably - must refer to an existing glossary of business
terms.
1.3.2 Define Business Model
To define the Business Model, following steps are necessary:
1. Business Process diagram: produce a diagram of all Business Processes, starting from
the list of Business Processes that have been identified in the project scope. The
diagram should show the organization of the Business Processes, starting from a top-
level node (representing the overall business goal). Refinements can be made using
AND-decompositions, OR-decompositions, "include" associations and "extend"
associations.
2. Business Activity diagram: complement the Business Process diagram with one or
more activity diagrams for each Business Process. These activity diagrams will provide
a better and more detailed understanding of the various activities and Business Roles in
the Business Processes and on the interaction between the activities and Business Roles.
The activity diagrams should ideally describe the normal flows and the exception flows
within each Business Process.
The type of activity diagrams that is recommended is called "Swim Lanes". Indeed, for
each Business Role, there is a "swim lane" indicating the activities performed by that
Business Role and, optionally, major states that can be reached by that Business Role.
© ISO 2004 – All rights reserved 8

---------------------- Page: 10 ----------------------
ISO/TS 20022-3:2004

3. Describe for each Business Process and each activity within a Business Process:
- the definition (i.e. a description of the activity)
- the trigger (i.e. an event that causes the start of the activity)
- the pre-conditions (i.e. conditions that must be fulfilled in order to start the activity)
- the post-conditions (i.e. conditions that must be fulfilled when the activity is
completed)
- the arguments (i.e. information that is required, created or changed for the execution
of the activity)
- the roles (i.e. functions of Business Actors when they are involved in the activity).

4. Business Role diagram: produce a diagram of all Business Roles that are relevant for
the defined project scope (these roles have been defined during the previous steps). Go
through all existing roles in the ISO 20022 Data Dictionary (DD) and copy the required
ones in the Business Role diagram. Complete the diagram with those Business Roles
that have been identified and that don't exist yet in the DD. If Business Roles are
identified that exist "more or less" in the DD (i.e. there is a significant match but also
some important differences) they should be created as new roles and an association
should be added in the diagram to the related existing Business Role in the DD. All
these additional Business Roles will have to be submitted to the Registration Authority.
1
5. Business Component diagram: Produce a diagram of all Business Components
derived from the "arguments" in step three. It can contain inheritance, association and
aggregation relations. Go through all existing Business Components in the DD and
copy the required ones in the Business Component diagram. Complete the diagram with
those Business Components that have been identified and that don't exist yet in the DD.
If Business Components are identified that exist "more or less" in the DD (i.e. there is a
significant match but also some important differences) or new Business Elements need
to be added, create them as new Business Components and add an association in the
diagram to the related existing Business Component in the DD. All these additional
Business Components will have to be submitted to the Registration Authority.
6. Check the consistency of the Business Model by verifying following points:
• Are all Business Components and Business Roles that are used in the Business
Process descriptions and in the activity diagrams included in the Business Role
diagram and in the Business Component diagram?
• Are all Business Components and Business Roles that have been defined in the
diagrams referred to in at least one Business Process or activity (except possibly the
ones that have been copied from the DD as basis for a project-specific
"specialization")?
• Is the Business Process diagram consistent with the information in the project
scope?

1
Business Components are defined as classes in the Business Model. A Business Component is the
exhaustive definition of a business notion. Note that Business Components will never be used directly in
message models because they are generic and don’t take into account specific needs of the message context.
© ISO 2004 – All rights reserved 9

---------------------- Page: 11 ----------------------
ISO/TS 20022-3:2004

• Is the Business Component diagram consistent with the information in the project
boundaries?
• Is the lifecycle (create - update - delete) of the used Business Components correctly
2
covered by the Business Process and activity descriptions?
1.4 Guidelines
- Apply a "bird's eye view". At the business analysis level, we want to concentrate on the
business and avoid discussing the solution or even the communication problem. This
means that we assume there is no communication problem and each of the Business
Roles has a perfect knowledge of and access to all information manipulated in any of
the Business Processes. Remember always that a "good" Business Process must add
tangible business value.
- Focus mainly on Business Processes that provide a lot of added value, by eliciting
Business Components or Business Roles. Don't get into details, like "cancel", "modify"
or "create", etc. at this stage and don't bother about error handling either. For example,
the description of an "Interbank Transfer" Business Process will elicit concepts like
"Account", "Credit", etc. The description of the "Cancel Interbank Transfer" will have
no specific added value and shouldn't be considered at this stage. These details will be
elaborated during the logical analysis, when Business Transactions and Message Sets
are defined.
- Concentrate on functional roles, rather than on real-life actors. It's for instance
important at this stage to identify the role "Buyer", but it's 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 Business
Process into more detailed Business Processes.
- Normally, roles should only be associated to the most detailed Business Processes and
to the activities (i.e. the lowest level).
- Make sure to provide all required information (e.g. a proposed name and a definition)
for new Business Components and Business Roles.
- Be careful in the Business Component diagram to use aggregation ONLY to represent
real business containment (e.g. a party is NOT contained in an account and there should
therefore be no aggregation relation between account and party). Real business
containment means that in real life the contained element can never exist without the
container (e.g. an account balance cannot exist without an account).
- The Business Component diagram can contain information regarding multiplicity and
must indicate the type (represented by a Data Type or a Business Component) of each
Business Element.

2
This doesn't mean that all Business Components must necessarily be created, updated and deleted in the
described Business Processes, but that one is sure that it has been covered or that one knows why it doesn’t
have to be covered
© ISO 2004 – All rights reserved 10

---------------------- Page: 12 ----------------------
ISO/TS 20022-3:2004


2 Requirements analysis
A small example of requirements analysis can be found in Annex A (Requirements
analysis: fund communication requirements).
2.1 Introduction
2.1.1 Purpose
The purpose of the requirements analysis is to define the communication requirements
caused by the physical separation of the Business Actors that will execute the various
Business Roles in the Business Processes.
The requirements analysis will identify and specify all communication requirements that
exist within the agreed scope of Business Processes and activities. It will identify who
needs what kind of information, from whom, at what moment. As such, the requirements
analysis will provide the specifications for the solution (i.e. the Business Transactions and
Message Sets) that will be developed, without going into the actual definition of messages
and message flows.
2.1.2 Key topics
• Analysis of the results of the business analysis in order to discover the communication
requirements that arise.
• Precise definition of the expected properties of the Business Transactions and Message
Sets to be developed (functionality and interaction with the Business Roles).
2.1.3 Main activities
• Identification of the goals of the Business Transactions and Message Sets to be
developed (exchange of information and possibly enhanced performance of specific
Business Processes or activities).
• Specification of functional (= behavioural) requirements of the Business Transactions
and Message Sets to be developed.
• Specification of constraints (= imposed restrictions) of the Business Transactions and
Message Sets to be developed.
© ISO 2004 – All rights reserved 11

---------------------- Page: 13 ----------------------
ISO/TS 20022-3:2004

2.1.4 Deliverables
• Textual descriptions refining the scope and boundaries of the final solution
• Textual descriptions refining and completing the constraints.
• Requirements use cases describing the expected functionality of the Business
Transactions and Message Sets to be developed. The description of the use case must
include the definition, arguments, triggers, pre- and post-conditions.
• Business Component diagram describing the information used by each of the Business
Roles (possibly complemented with textual descriptions of some business related
Rules).

© ISO 2004 – All rights reserved 12

---------------------- Page: 14 ----------------------
ISO/TS 20022-3:2004

2.2 Process overview
The below picture shows the different activities (shown as ovals) this process has to follow
and what the required inputs and outputs (shown as squares) are. These activities are further
detailed in the following paragraph.
<> <> <>
Project Scope & Requirements Business Process diagram Business Activ ity diagram
<>
<>
<>
Define Final Scope & Boundary
<>
<>
Business Component
Business Role diagram
diagram
<>
<>
Def ine Communication
Requirements
<>
Requirements Use
Case diagram
<>
<>
Constraints
Complete Requirements &
Constraints

© ISO 2004 – All rights reserved 13

---------------------- Page: 15 ----------------------
ISO/TS 20022-3:2004


2.3 Activities
2.3.1 Define final scope & boundary
Define the Business Processes and activities that need to be supported by the Business
Transactions and Message Sets to be developed. This will be done based on the Business
Process and Business Activity diagrams that have been defined during business analysis
and based on the requirements and scope that have been defined for this project.
2.3.2 Define communication requirements
At this stage, the “bird's eye view” that was taken during business analysis is abandoned. It
is recognised that Business Roles involved in activities in Business Processes don’t have
access to all information (i.e. they have only a limited knowledge about Business
Components and/or a limited knowledge about the status of other activities in Business
Processes). The Business Processes cannot be completed due to this lack of knowledge. In
fact, this is the basic problem: we need to make sure that all activities in all Business
Processes (that are in the scope) get access to the knowledge they need to get completed.
The solution will therefore be to create one or more Business Transactions that take care of
all the necessary communication between the Business Roles that are involved in the
Business Processes. The Business Transactions will thus ensure that each activity in the
Business Processes gets access to the information it needs. The goal of the requirements
analysis is to identify and specify these communication requirements (i.e. what information
needs to be provided to whom under which conditions, etc.).
Following steps need to b
...