ISO/FDIS 20022-3

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: Not Published
• ICS: 03.060 - Finances. Banking. Monetary systems. Insurance
• Technical Committee: ISO/TC 68/SC 9 - Information exchange for financial services
• Drafting Committee: ISO/TC 68/SC 9 - Information exchange for financial services
• Current Stage: 5020 - FDIS ballot initiated: 2 months. Proof sent to secretariat
• Start Date: 31-Dec-2025
• Completion Date: 31-Dec-2025

Relations

• Revises: ISO 20022-3:2013 - Financial services - Universal financial industry message scheme - Part 3: Modelling
• Effective Date: 06-Jun-2022

Overview

ISO/FDIS 20022-3 (ISO 20022-3) defines the modelling workflow for the ISO 20022 universal financial industry message scheme. It complements ISO 20022‑1 and ISO 20022‑2 by describing the required steps a modeller follows to develop and maintain standardized BusinessTransactions and MessageSets. The standard organizes modelling into progressive levels (scope, conceptual, logical, physical), provides conventions and UML guidance, and includes informative examples to illustrate the methodology (examples are non‑normative). ISO 20022‑3 does not prescribe the artefacts required by the Registration Authority - that is covered in ISO 20022‑7.

Key topics and requirements

• Modelling workflow and levels
  • Scope level: define business context and BusinessProcesses.
  • Conceptual level: define business model and BusinessTransactions.
  • Logical level: define MessageChoreography, MessageSet, MessageDefinitions, InterfaceDefinition and Operations; apply constraints and naming rules.
  • Physical level: create syntax‑specific message schemes and interface specifications.
• Deliverables and activities
  • Clear specification of deliverables at each modelling level (e.g., BusinessTransactions, MessageSets, InterfaceSpecification).
  • Activities include defining business context, composing MessageDefinitions, and creating SyntaxMessageScheme.
• Conventions and constraints
  • Naming rules, modelling constraints (inheritance, normalization, versioning), and guidelines for factorization, party neutrality and message granularity.
  • Use of UML diagrams with guidance on which diagram types to apply.
• Non‑normative examples
  • Illustrative examples are included to show methodology, but are not normative requirements.

Practical applications and who uses it

ISO 20022-3 is essential for anyone involved in designing, standardizing or implementing financial messaging standards:

• Enterprise architects and data modellers building interoperable financial message models.
• Standards bodies and registration authorities applying a consistent modelling process.
• Banks, payment systems, fintechs and market infrastructures creating or maintaining BusinessTransactions and MessageSets.
• Vendors and integrators mapping logical message definitions to physical message syntaxes and interface specifications.

Practical uses include developing standardized message definitions to improve interoperability across payment, securities, trade finance and corporate banking systems; ensuring consistent naming, versioning and reuse; and producing artefacts ready for registration and implementation.

Related standards

• ISO 20022-1 (general framework)
• ISO 20022-2 (methodology and metamodel)
• ISO 20022-7 (Registration Authority artefacts and submission rules)

Keywords: ISO/FDIS 20022-3, ISO 20022 modelling, financial messaging, BusinessTransactions, MessageSets, MessageDefinitions, MessageChoreography, InterfaceSpecification, modelling workflow.

Standards Content (Sample)

FINAL DRAFT
International
Standard
ISO/TC 68/SC 9
Financial services — Universal
Secretariat: AFNOR
financial industry message
Voting begins on:
scheme —
2025-12-31
Part 3:
Voting terminates on:
2026-02-25
Modelling
Services financiers — Schéma universel de messages pour
l'industrie financière —
Partie 3: Modélisation
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
FINAL DRAFT
International
Standard
ISO/TC 68/SC 9
Financial services — Universal
Secretariat: AFNOR
financial industry message
Voting begins on:
scheme —
Part 3:
Voting terminates on:
Modelling
Services financiers — Schéma universel de messages pour
l'industrie financière —
Partie 3: Modélisation
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© ISO 2025
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland Reference number
ii
Contents Page
Foreword .v
Introduction .vi
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 .7
6 Conceptual level . 7
6.1 General .7
6.1.1 Purpose .7
6.1.2 Key topics .7
6.1.3 Main activities .8
6.1.4 Deliverables .8
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 MessageChoreography . 13
7.2.2 Define the MessageSet . 13
7.2.3 Compose the MessageDefinitions . . 13
7.2.4 Define the InterfaceDefinition .18
7.2.5 Define the Operation(s) .18
7.3 Constraints.18
7.3.1 Inheritance .18
7.3.2 Normalized MessageDefinitions and Operations .18
7.3.3 Normalization .19
7.3.4 Non-Constraint preference .19
7.3.5 Sibling constraints .19
7.3.6 Value derivation .19
7.3.7 Versions versus flavours .19
7.3.8 Modelling associations between MessageComponent Types. .19
7.3.9 Variation, revision, minor version and draft .19
7.4 Guidelines . 20
7.4.1 BusinessTransactions. 20
7.4.2 MessageInstance style. 20
7.4.3 Party Neutral MessageInstance . 20

iii
7.4.4 MessageInstance granularity . 20
7.4.5 How to handle bi-directional relations .21
7.4.6 Factorize .21
7.4.7 How to define an ExternalSchema .21
7.4.8 How to enforce canonical form for date or time related user-defined DataTypes .21
8 Physical level .22
8.1 General . 22
8.1.1 Purpose . 22
8.1.2 Key topics . 22
8.1.3 Main activities . 22
8.1.4 Deliverables . 22
8.2 Activities . 22
8.2.1 Create SynatxMessageScheme . 22
8.2.2 Create InterfaceSpecification. 23
9 Conventions .24
9.1 Constraints.24
9.2 Naming .24
9.2.1 General .24
9.2.2 Generic rules applicable to all Repository Concepts .24
Annex A (informative) Applied UML diagrams: Correct UML diagram to use in different cases .26
Bibliography .27

iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 68, Financial services, Subcommittee SC 9,
Information exchange for financial services.
This second edition cancels and replaces the first edition (ISO 20022-3:2013), which has been technically
revised.
The main changes are as follows:
— changes:
— Updated all Figures to reflect the workflow changes as a result of the revised part 1 .
— Updated chapters 5, 6, 7 and 8
— clarifications:
— 7.4.4 MessageGranularity included minor version and draft.
— additions:
— Minor version properties (revision, variation) and draft were added to MessageDefinition
— InterfaceDefinitions comprising of Operations with Parameters.
— Version relationships amongst RepositoryConcept.
A list of all parts in the ISO 20022 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

v
Introduction
The ISO 20022 series defines a scalable, methodical process to ensure consistent descriptions of messages
throughout the financial services industry.
The purpose of the ISO 20022 series is to describe precisely and completely the externally observable aspects
of financial services messaging in a way that can be verified independently against operational messaging.
The trigger for the creation of the ISO 20022 series was the rapid growth in the scale and sophistication
of messaging within financial services during the 1990s using the ISO 15022 series. The financial services
industry (from here on referred to as "the industry") created the first version of the ISO 20022 series as the
successor to the ISO 15022 series in response to that trigger. Since the ISO 15022 series, the industry has
broadened the scope from securities to the entire industry for the ISO 20022 series.
The ISO 20022 series is based on open technology standards, which historically have evolved more rapidly
than the industry itself. Consequently, the ISO 20022 series adopted a model-driven approach where the
model of the industry's messaging can evolve separately from the evolution of the messaging technology
standards. The period during which the ISO 20022 series has emerged followed the widespread adoption
of the internet for business. The eXtensible Mark-up Language (XML) emerged as the de facto standard for
document representation on the internet and it became the first syntax for the ISO 20022 series.
The modelling process is further refined into three levels which, in addition to the messaging technology
standard, is why the ISO 20022 series is based on four levels: the scope level, the conceptual level, the
logical level and the physical level. This four-level approach is based on the first four levels of the Zachman
[4]
Framework. The remaining two levels of the Zachman Framework are equivalent to the implementations
and the operational levels, respectively.
This document defines a process by which these models can be created and maintained by the modellers.
The model artefacts are stored in an ISO 20022 Repository (hereafter referred to as "the Repository").
The Repository and physical level artefacts are exposed in a publicly accessible location, such as a website,
serviced by a Registration Authority. The name and contact information of the Registration Authority for
the ISO 20022 series can be found at www.iso.org/maintenance_agencies.
The Repository is organized into two areas:
— a DataDictionary containing the industry model elements likely to have further or repeated use;
— a BusinessProcessCatalogue that contains models describing specific message definitions and business
processes, and physical syntax implementations.
The ISO 20022 series is organized into the following parts:
— ISO 20022-1 describes the metamodel of all the models and the Repository according to ISO/IEC 19502:2005
(MOF).
— ISO 20022-2 covers the UML profile, a grounding of general UML into a specific subset defined for the
ISO 20022 series (to be used when UML is selected to define the models).
— This document describes a modelling method to produce models for the ISO 20022 series.
— ISO 20022-4 covers XML schema generation rules to transform a logical level model into a physical level
description in the syntaxes.
— ISO 20022-5 covers business concept model interoperability, and logical model alignment and reverse
engineering.
— 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.
vi
— ISO 20022-8 gives ASN.1 syntax generation rules to transform a logical level model into a physical level
description in ASN.1.
— ISO 20022-9 describes generic guidelines which are used to define schema generation rules for any
specific syntax.
The defined terms of this document are in PascalCase and will use PascalCase throughout the document.

vii
FINAL DRAFT International Standard ISO/FDIS 20022-3:2025(en)
Financial services — Universal financial industry message
scheme —
Part 3:
Modelling
1 Scope
This document 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 InterfaceDefinitions/MessageSets.
This document does not describe 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
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements 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-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
ISO 20022-9, Financial services — Universal financial industry message scheme — Part 9: Syntax Generation
Requirements and Rules
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 20022-1 and ISO 20022-2 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org
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 each 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 all
ISO 20022 items such as BusinessComponents and BusinessElements, MessageComponentTypes and
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 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 constraints and rules of modelling that should be followed or considered.
NOTE See Figure 1 for a visualisation of the various activities.
To model these activities using a UML tool, see Annex A.

Figure 1 — High level workflow

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 Conformant BusinessTransactions and MessageSets are developed. There are two main
purposes:
a) Describing the BusinessProcesses, including the BusinessRoles and their need for business information,
helps identify 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 are designed later, contain data elements that are related to the
BusinessConcepts. An explicit link between BusinessConcepts and MessageConcepts is helpful for
interoperability and change management. If something changes in a BusinessArea, it is 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 BusinessConcepts 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 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 BusinessRoles involved in these BusinessProcesses. (All
model elements are enriched with textual descriptions, referencing a draft set of key BusinessComponents
(or possibly other types of BusinessComponent.)

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 BusinessElements 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).
NOTE See Figure 2.
Figure 2 — Define Business context
5.2.2 Define BusinessProcesses
This activity defines the following elements:
a) 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.
b) 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 recommended 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 elicits
business terms like "Account", "Credit", etc. The description of the "Cancel Interbank Transfer" has no
specific added value and should not be considered at this stage. These details are 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 example, 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 or a
corporate or financial institution.
Depending on the useful level of detail, one can 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 are captured as key BusinessComponents (accompanied by a short and clear description,
to remove possible ambiguities), that are elaborated further at the Conceptual level or refer to existing
BusinessComponents in the ISO 20022 Data Dictionary.
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
when. As such, the Conceptual level provides the specifications for the solution (i.e. the BusinessTransactions)
that is 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 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 activity diagrams and 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 business model depicting the information used by each of the Participants (possibly complemented
with textual descriptions of some business-related rules);
— a BusinessTransaction model containing a description of a BusinessTransaction using activity diagram(s)
and sequence diagram(s).
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.
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 are submitted to the Registration Authority.
NOTE BusinessComponents are defined as classes in the Business Model. A BusinessComponent is the exhaustive
definition of a business notion. BusinessComponents are never used directly in MessageDefinitions because they are
generic and do not consider specific needs of the message context.
The BusinessComponent diagram can contain information regarding multiplicity and shall indicate the type
(represented by a DataType or a BusinessComponent) of each Business Element in case that BusinessElement
is a BusinessAssociationEnd. Following modelling guidelines, help define a consistent business model:
— 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. BusinessElements 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 Code)
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 1 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 2 A person has an address but so has a financial institution.
— Where the BusinessComponents are related and independent, both BusinessAssociationEnds have
their property aggregation set to "NONE".
EXAMPLE 3 A party is not contained in an account and there is therefore no aggregation relation between
account and party.
6.2.2 Define BusinessTransactions
6.2.2.1 Overview
Describe the way(s) in which the use case is realized by the Participants and what information flows are
required.
Considering the boundaries and Participants that have just been defined, refine the way(s) in which the
BusinessProcesses are realized and what information flows are required. The description(s) of the
BusinessTransactions provide(s) the following information about the information flows between them:
— the sequence in which these flows take place;
— exception handling;
— trigger;
— pre- and post-conditions related to each information flow.
Figure 3 illustrates the various steps to define a BusinessTransaction.

Figure 3 — Define BusinessTransaction
6.2.2.2 Define BusinessProcessTrace
Define the trace between each BusinessTransaction (which is modelled as an activity diagram and a sequence
diagram) and its corresponding BusinessProcess.
6.2.2.3 Define MessageTransportMode
For each BusinessTransaction define, where relevant, the parameters that constrain the
MessageTransportMode (see ISO 20022-6):
— BoundedCommunicationDelay;
— DeliveryAssuranceDurability;
— MaximumClockVariation;
— MaximumMessageSize;
— MessageCasting;
— MessageDeliveryOrder;
— MessageDeliveryWindow;
— MessageSendingWindow;
— MessageValidationLevel;
— MessageValidationOnOrOff;
— MessageValidationresults;
— ReceiverAsynchronicity;
— SenderAsynchronicity.
6.2.2.4 Define Participants
6.2.2.4.1 Overall principles
BusinessRoles (actors) of the BusinessProcesses (use cases) are refined into Participants in the derived
BusinessTransactions (activity diagrams and sequence diagrams). Each Participant is represented in the
BusinessTransaction diagram as a swimlane.
6.2.2.4.2 Establish whether there is a central system
Decide whether a central system (e.g. a central Transaction Flow Monitor or market infrastructure)
is involved. If this is the case, there is a Participant associated to each central system. Add an additional
swimlane to act as the central system in the BusinessTransaction diagrams.
6.2.2.5 Define BusinessRoleTraces
Trace each Participant to the BusinessRole identified in the BusinessProcess from which the
BusinessTransaction is derived.
6.2.2.6 Define the flow(s) using a activity diagram
For each activity within a BusinessProcess, define:
— 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 shall be fulfilled to start the activity;
— the post-conditions, i.e. conditions that shall be fulfilled when the activity is completed;
— the arguments, i.e. information that is required, created or changed for the execution of the activity.
Using an activity diagram, the Business Process is refined into individual activities which represent the
steps that leads to the realization of the use case.
The start and end nodes indicate the start and end of the BusinessTransaction.
Participants are represented as swimlanes and the various activities are assigned to the owning Participant,
connected by flows.
Flows that cross swimlanes are candidate MessageTransmissions that are added in the corresponding
sequence diagram.
6.2.2.7 Define the flow(s) using a sequence diagram
Now that the BusinessTransaction activities and the different actors that participate in the
BusinessTransaction have been identified, the exchange of information among the Participants to complete
the BusinessTransaction shall be shown as follows:
— For each information flow that crosses a swimlane, define a <>-stereotyped
Message. <> or <>-stereotyped Signals, identified at the
Logical level, is always traced to one of these <>.
— Repeat this activity for each identified information need.
— For each identified information flow, define the name of the MessageDefinition or Operations-to-be, the
required business content and, if possible, the high-level structure (i.e. what information should logically
be put together) using BusinessComponents. This information shall be documented in the sequence
diagram (linked to each information flow). The subsequent "MessageDefinition and/or Operation
content" can be identified by considering the information that is required and provided by the different
BusinessActivities.
6.3 Guidelines
Activity diagrams and sequence diagrams offer different views on the same transaction and as such
complement each other. An activity diagram provides the link with the associated BusinessProcess, a
sequence diagram with the associated Logical model(s).
The Business Model contains a defini
...

ISO/DISFDIS 20022-3(en)
Third edition
Final Draft International Standard

ISO/TC 68/SC 9
Secretariat: AFNOR
Date: 2025-08-2012-17
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
FDIS stage
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication
may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying,
or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO
at the address below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
E-mail: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents
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 . 7
6 Conceptual level . 7
6.1 General. 7
6.1.1 Purpose . 7
6.1.2 Key topics . 7
6.1.3 Main activities . 8
6.1.4 Deliverables . 8
6.2 Activities . 8
6.2.1 Define business model . 8
6.2.2 Define BusinessTransactions . 9
6.3 Guidelines . 12
7 Logical level . 13
7.1 General. 13
7.1.1 Purpose . 13
7.1.2 Key topics . 13
7.1.3 Main activities . 13
7.1.4 Deliverables . 14
7.2 Activities . 14
7.2.1 Define the MessageChoreography . 14
7.2.2 Define the MessageSet . 14
7.2.3 Compose the MessageDefinitions . 14
7.2.4 Define the InterfaceDefinition . 19
7.2.5 Define the Operation(s) . 20
7.3 Constraints . 20
7.3.1 Inheritance . 20
7.3.2 Normalized MessageDefinitions and Operations . 20
7.3.3 Normalization . 21
7.3.4 Non-Constraint preference . 21
7.3.5 Sibling constraints . 21
7.3.6 Value derivation . 21
7.3.7 Versions versus flavours . 21
7.3.8 Modelling associations between MessageComponent Types. . 21
7.3.9 Variation, revision, minor version and draft . 21
iii
7.4 Guidelines . 22
7.4.1 BusinessTransactions . 22
7.4.2 MessageInstance style . 22
7.4.3 Party Neutral MessageInstance . 22
7.4.4 MessageInstance granularity. 22
7.4.5 How to handle bi-directional relations . 23
7.4.6 Factorize . 23
7.4.7 How to define an ExternalSchema . 24
7.4.8 How to enforce canonical form for date or time related user-defined DataTypes . 24
8 Physical level . 24
8.1 General. 24
8.1.1 Purpose . 24
8.1.2 Key topics . 25
8.1.3 Main activities . 25
8.1.4 Deliverables . 25
8.2 Activities . 25
8.2.1 Create SynatxMessageScheme. 25
8.2.2 Create InterfaceSpecification . 25
9 Conventions . 27
9.1 Constraints . 27
9.2 Naming . 27
9.2.1 General. 27
9.2.2 Generic rules applicable to all Repository Concepts. 27
Annex A (informative) Applied UML diagrams . 28
A.1 Correct UML Diagram to use in different cases . 28
Foreword . vi
Introduction . viii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Workflow activities overview . 1
5 Scope level . 5
5.1 General. 5
5.2 Activities . 6
5.3 Guidelines . 9
6 Conceptual level . 9
6.1 General. 9
6.2 Activities . 10
6.3 Guidelines . 16
7 Logical level . 17
7.1 General. 17
7.2 Activities . 18
7.3 Constraints . 26
7.4 Guidelines . 27
8 Physical level . 30
8.1 General. 30
8.2 Activities . 31
9 Conventions . 33
iv
9.1 Constraints . 33
9.2 Naming . 33
Annex A (informative) Applied UML diagrams: Correct UML diagram to use in different cases . 34
Bibliography . 1

v
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent rights
in respect thereof. As of the date of publication of this document, ISO had not received notice of (a) patent(s)
which may be required to implement this document. However, implementers are cautioned that this may not
represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 68, Financial services, Subcommittee SC 9,
Information exchange for financial services.
This thirdsecond edition cancels and replaces the secondfirst edition (ISO 20022-3:2013), which has been
technically revised.
The main changes are as follows:
— changes:
— Updated all Figures to reflect the workflow changes as a result of the revised part 1 .
— Updated chapters 5, 6, 7 and 8
— clarifications:
— 7.4.4 MessageGranularity included minor version and draft.
— additions:
— Minor version properties (revision, variation) and draft were added to MessageDefinition
— InterfaceDefinitions comprising of Operations with Parameters.
— Version relationships amongst RepositoryConcept.
A list of all parts in the ISO 20022 series can be found on the ISO website.
vi
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
vii
Introduction
The ISO 20022 series defines a scalable, methodical process to ensure consistent descriptions of messages
throughout the financial services industry.
The purpose of the ISO 20022 series is to describe precisely and completely the externally observable aspects
of financial services messaging in a way that can be verified independently against operational messaging.
The trigger for the creation of the ISO 20022 series was the rapid growth in the scale and sophistication of
messaging within financial services during the 1990s using the ISO 15022 series. The financial services
industry (from hereonhere on referred to as "the industry") created the first version of this documentthe ISO
20022 series as the successor to the ISO 15022 series in response to that trigger. Since the ISO 15022 series,
the industry has broadened the scope from securities to the entire industry for this documentthe ISO 20022
series.
The ISO 20022 series is based on open technology standards, which historically have evolved more rapidly
than the industry itself. Consequently, the ISO 20022 series adopted a model-driven approach where the
model of the industry's messaging can evolve separately from the evolution of the messaging technology
standards. The period during which the ISO 20022 series has emerged followed the widespread adoption of
the internet for business. The eXtensible Mark-up Language (XML) emerged as the de facto standard for
document representation on the internet and it became the first syntax for the ISO 20022 series.
The modelling process is further refined into three levels which, in addition to the messaging technology
standard, is why the ISO 20022 series is based on four levels: the Scopescope level, the Conceptualconceptual
level, the Logicallogical level and the Physicalphysical level. This four-level approach is based on the first four
[5] [ ]
levels of the Zachman Framework. . 0 The remaining two levels of the Zachman Framework are equivalent
to the implementations and the operational levels, respectively.
This document defines a process by which these models can be created and maintained by the modellers.
The model artefacts are stored in an ISO 20022 Repository (hereafter referred to as "the Repository"). The
Repository and physical level artefacts are exposed in a publicly accessible location, such as a website, serviced
by a Registration Authority. The name and contact information of the Registration Authority for the ISO 20022
series can be found at www.iso.org/maintenance_agencieswww.iso.org/maintenance_agencies.
The Repository is organized into two areas:
— a DataDictionary containing the industry model elements likely to have further or repeated use;
— a BusinessProcessCatalogue that contains models describing specific message definitions and business
processes, and physical syntax implementations.
The ISO 20022 series is organized into the following parts:
— ISO 20022-1 describes in ISO/IEC 19502:2024 (MOF) the metamodel of all the models and the Repository.
according to ISO/IEC 19502:2005 (MOF).
— ISO 20022-2 covers the UML profile, a grounding of general UML into a specific subset defined for the ISO
20022 series (to be used when UML is selected to define the models).
— This partdocument describes a modelling method to produce models for the ISO 20022 series.
— ISO 20022-4 covers XML Schemaschema generation rules to transform a Logicallogical level model into a
Physicalphysical level description in the syntaxes.
viii
— ISO 20022-5 covers business concept model interoperability, and logical model alignment and reverse
engineering.
— ISO 20022-6 covers message transport characteristics that define the quality of service required by the
BusinessProcessbusiness process definitions so that they can operate successfully.
— ISO 20022-7 describes the process of managing the registration of models and physical syntax
implementations.
— ISO 20022-8 gives ASN.1 syntax generation rules to transform a Logicallogical level model into a
Physicalphysical level description in ASN.1.
— ISO 20022-9 describes generic guidelines which are used to define schema generation rules for any
specific syntax.
DefinedThe defined terms of this standarddocument are in PascalCase and will use PascalCase throughout the
standarddocument.
ix
Error! Reference source not found. Error! Reference source not found.

Financial services — Universal financial industry message
scheme —
Part 3:
Modelling
1 Scope
This part of ISO 20022document 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 InterfaceDefinitions/MessageSets.
This part of ISO 20022 isdocument does not intended to describe what are 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
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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-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
ISO 20022-9, Financial services — Universal financial industry message scheme — Part 9: Syntax
Generation Requirements and Rules
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 20022-1 and ISO 20022-2 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— — ISO Online browsing platform: available at https://www.iso.org/obphttps://www.iso.org/obp
— — IEC Electropedia: available at https://www.electropedia.orghttps://www.electropedia.org
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.
Error! Reference source not found.
For a given communication problem in each business context, several solutions can be developed. The
purpose of this part of ISO 20022document is to explain the different steps a modeller should follow to
ensure that all ISO 20022 items such as BusinessComponents and BusinessElements,
MessageComponentTypes and 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 20022document 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 considered.
NOTE See Figure 1 High level workflow0 for a visualisation of the various activities.
To model these activities using a UML tool, consult Annex A.see Annex A.
Error! Reference source not found.
Error! Reference source not found.
Figure 1 1 — High level workflow

Error! Reference source not found.
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 Conformant BusinessTransactions and MessageSets are
developed. There are two main purposes:
a) Describing the BusinessProcesses, including the BusinessRoles and their need for business
information, helps in the identification ofidentify 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 are designed later, contain data elements that are related to the
BusinessConcepts. An explicit link between BusinessConcepts and MessageConcepts is helpful for
interoperability and change management. If something changes in a BusinessArea, it is 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 BusinessConcepts 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 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 BusinessRoles involved in these BusinessProcesses.
(allAll model elements are enriched with textual descriptions, referencing a draft set of key
BusinessComponents (or possibly other types of BusinessComponent).)
Error! Reference source not found.
5.2 Activities
5.2.1 Define business context
The following steps are followed to define the business context (see Figure 2):0):
— 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 BusinessElements 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).
NOTE See also Figure 2 Define Business context

Error! Reference source not found.
Figure 2NOTE See 0.
Error! Reference source not found.
Figure 2 — Define Business context
5.2.2 Define BusinessProcesses
This activity defines the following elements:
a.a) 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.
Error! Reference source not found.
b.b) 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 also Figure 1 High level workflow
NOTE See 0.
5.3 Guidelines
Apply a "bird's eye view". At the Scope level, it is recommended 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 elicits
business terms like "Account", "Credit", etc.; the. The description of the "Cancel Interbank Transfer" has
no specific added value and should not be considered at this stage. These details are 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 instanceexample, 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, or a corporate or a financial institution.
Depending on the useful level of detail, one can 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 are captured as key BusinessComponents (accompanied by a short and clear description,
to remove possible ambiguities), that are elaborated further at the Conceptual level or refer to existing
BusinessComponents in the ISO 20022 Data Dictionary.
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 momentwhen. As such, the Conceptual level provides the specifications for the solution (i.e.
the BusinessTransactions) that is developed, without going into the actual definition of messages.
6.1.2 Key topics
The key topics of the Conceptual level are:
Error! Reference source not found.
— analysis of the business model 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 activity diagrams and 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;
— Aa business model depicting the information used by each of the Participants (possibly
complemented with textual descriptions of some business-related rules);
— Aa BusinessTransaction model containing a description of a BusinessTransaction using activity
diagram(s) and sequence diagram(s).

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.
Error! Reference source not found.
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 are submitted to the Registration Authority.
NOTE BusinessComponents are defined as classes in the Business Model. A BusinessComponent is the
exhaustive definition of a business notion. BusinessComponents are never used directly in MessageDefinitions
because they are generic and do not consider specific needs of the message context.
The BusinessComponent diagram can contain information regarding multiplicity and shall indicate the
type (represented by a DataType or a BusinessComponent) of each Business Element in case that
BusinessElement is a BusinessAssociationEnd. Following modelling guidelines, help define a consistent
business model:
— 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. BusinessElements
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
Code) qualifies the BusinessAttribute and gives it specific meaning.
— There are different relations possible between two BusinessComponents:
a)— 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 1 An account balance cannot exist without an account.
b)— Where a BusinessComponent is part of several BusinessComponents, the latter's
BusinessAssociationEnd (i.e. its associationDomain) has its property aggregation set to
"SHARED".
EXAMPLE 2 A person has an address but so has a financial institution.
c)— Where the BusinessComponents are related and independent, both BusinessAssociationEnds
have their property aggregation set to "NONE".
EXAMPLE 3 A party is not contained in an account and there is therefore no aggregation relation between
account and party.
1)
BusinessComponents are defined as classes in the Business Model. A BusinessComponent is the exhaustive
definition of a business notion. Note that BusinessComponents are never used directly in MessageDefinitions
because they are generic and do not consider specific needs of the message context.
Error! Reference source not found.
6.2.2 Define BusinessTransactions
6.2.2.1 Overview
Describe the way(s) in which the use case is realized by the Participants and what information flows are
required.
Considering the boundaries and Participants that have just been defined, refine the way(s) in which the
BusinessProcesses are realized and what information flows are required. The description(s) of the
BusinessTransactions provide(s) the following information about the information flows between them:
— the sequence in which these flows take place;
— exception handling;
— trigger;
— pre- and post-conditions related to each information flow.
Below Figure 3 Define BusinessTransaction0 illustrates the various steps to define a
BusinessTransaction:.
Error! Reference source not found.
Error! Reference source not found.
Figure 3 3 — Define BusinessTransaction

6.2.2.2 Define BusinessProcessTrace
Define the trace between each BusinessTransaction (which is modelled as an activity diagram and a
sequence diagram) and its corresponding BusinessProcess.
6.2.2.3 Define MessageTransportMode
For each BusinessTransaction define, where relevant, the parameters that constrain the
MessageTransportMode (see ISO 20022-6):
— BoundedCommunicationDelay;
— DeliveryAssuranceDurability;
Error! Reference source not found.
— MaximumClockVariation;
— MaximumMessageSize;
— MessageCasting;
— MessageDeliveryOrder;
— MessageDeliveryWindow;
— MessageSendingWindow;
— MessageValidationLevel;
— MessageValidationOnOrOff;
— MessageValidationresults;
— ReceiverAsynchronicity;
— SenderAsynchronicity.
6.2.2.4 Define Participants
6.2.2.4.1 Overall principles
BusinessRoles (actors) of the BusinessProcesses (use cases) are refined into Participants in the derived
BusinessTransactions (activity diagrams and sequence diagrams). E
...