ISO/TS 20022-3:2004

Financial services - UNIversal Financial Industry message scheme - Part 3: ISO 20022 modelling guidelines

ISO/TS 20022-3:2004 explains 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, ISO/TS 20022-3:2004 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.

Services financiers — Schéma universel de messages pour l'industrie financière — Partie 3: Lignes directrices pour la modélisation ISO 20022

General Information

• Status: Withdrawn
• Publication Date: 01-Dec-2004
• Withdrawal Date: 01-Dec-2004
• ICS: 03.060 - Finances. Banking. Monetary systems. Insurance
• Technical Committee: ISO/TC 68 - Financial services
• Drafting Committee: ISO/TC 68 - Financial services
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 07-May-2013
• Completion Date: 13-Dec-2025

Relations

• Revised: ISO 20022-3:2013 - Financial services - Universal financial industry message scheme - Part 3: Modelling
• Effective Date: 22-Aug-2009

Standards Content (Sample)

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 2004
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 [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2004 – All rights reserved

(Blank page)
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
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

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]
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.
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.
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
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.
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.
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?
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.
• 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
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.
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
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.
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).
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
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 be followed:
- Identify, in the Business Activity diagram, the activities that are in the scope and the
Business Roles that take part in these activities.
- Define, for each activity to be executed, what information is required. This information
consists of the input arguments, possibly information that triggers the activity (e.g. the
fact that another activity is terminated) and possibly information necessary to check the
pre-conditions.
- Define which information (from the above-defined set of required information) is not
available to the Business Role executing this activity (i.e. which information is not
owned by the Business Role).
- Create a "requirements use case" for each set of information that needs to be
communicated as part of the Business Transactions to be developed and identify which
Business Role is able to provide this information. In some cases, multiple Business
Roles may provide (parts of) this information (possibly at different moments in the
execution of the overall Business Process). Remark that the requirements use case may
already exist (if it is needed by another activity).
Describe each requirements use case with following information :
- Definition: the goal and functionality of the use case, i.e. which information is it
providing to which activity and between which Business Roles.
- Trigger: the event that will start the execution of the use case.
- Pre-conditions: the conditions that must be fulfilled in order to be able to execute the
use case.
- Post-conditions: the conditions that must be met when the use case has been executed.
- Arguments: the information that is used and produced by the use case.
2.3.3 Complete requirements and constraints
- Based on the analysis done in the previous steps and based on the project scope, write
down systematically all constraints (e.g. constraints pertaining to a specific
implementation).
- Verify whether there is no impact of these constraints on the functional requirements
that have been described in the requirements use cases and adapt these uses cases if
necessary.
2.4 Guidelines
- When specifying the requirements, it may be necessary/useful to combine a number of
potential requirements use cases (e.g. because they all deal with the same Business
Information or because they are always executed together by the same Business Roles)
or to zoom in/out of potential requirements use cases (e.g. in order to have a
manageable level of detail).
Note that this information in the Requirements Use Case may be based on the corresponding information in
the Business Processes or activities, but is not exactly the same.
3 Logical analysis
A small example of logical analysis can be found in Annex A (Logical analysis: Business
Transactions).
3.1 Introduction
3.1.1 Purpose
The purpose of the logical analysis is to specify the details of the Business Transactions and
Message Sets to be developed.
The focus is therefore on defining the Message Flows and Message Definitions that are
needed to get the required information at the right time to the right Business Role. The
Business Transactions and Message Sets are still looked at from a pure business
perspective, meaning that the focus still remains on the semantics (i.e. the underlying
business meaning) and not yet on the syntax (i.e. how to physically represent a Message
and a set of Rules). All decisions are driven by the requirements (functional requirements
and constraints) that have been identified and specified during the requirements analysis.
The logical analysis is said to be "logical" because it deals with the description of the
Business Transactions and Message Sets from an abstract point of view versus a concrete,
technical point of view. This abstract approach is needed to allow interoperability between
different technical representations.
3.1.2 Key topics
- What is the overall architecture of the solution? What are the subsystems taking part in
the exchange of Messages? Do we go for a user-to-user or for a centrally co-ordinated
solution?
- What are the Business Transactions? The different Messages can be exchanged
according to a number of admissible message flows that need to be identified.
- What are the Messages in terms of their business content? The exchanged information
should have a business value. Message Components/Elements are defined from and
traced to Business Components/Elements that were identified during the business
analysis and requirements analysis.
- Which rules apply to the various Business Transactions and Messages and what is the
scope of each rule? If the scope is the Message only, the rule refers only to the content
of the Message. If the scope is the Business Transaction, the rule checks the Message
content against the overall Business Transaction information (e.g. the information
contained in the previously exchanged Messages).
3.1.3 Main activities
- Identify the overall architecture of the solution.
- Refine the requirements use cases into concrete Business Transactions. Based on the
Business Transactions, identify Messages and major message flows and rules related to
these message flows.
- Design the Messages i.e. identify the business content, overall structure and
organization of the Messages and the rules that apply to the Messages.
3.1.4 Deliverables
- A Business Transaction diagram (containing a structured description of the Business
Transactions.
- A textual description of the architecture of the system (subsystems) in case of a
centrally co-ordinated system
- Sequence Diagrams (i.e. the typical exchanges of Messages in the context of a Business
Transaction.
3.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.
<>
<> <>
Requirements Use
Business Act ors &Roles Constraints
Case diagram
Define "architecture"
<>
<> <>
<>
Subsystems Business Component
Business Role diagram
diagram diagram
<>
Define Business Transactions
<>
Business Transaction
diagram
<> <>
Message Sequence Message Collaboration

3.3 Activities
3.3.1 Define “architecture”
- Defining the architecture of the solution means identifying the various "subsystems"
that will be involved in the Business Transactions. Subsystems are the boundaries of the
Business Transactions, meaning that the standards developer will not attempt to
standardize the details of the applications that take place at these subsystems. The
standards developer is only standardizing the communication (interface) with these
applications. Defining the subsystems and the activities they will perform will help to
define the required message flow.
- How to identify these subsystems? Although we're not looking for individual Business
Actors, it's a fact that there is a relation with the type of Business Actors that will play
the Business Roles in the Business Transaction. It's therefore good practice to combine
at this point the definition of subsystems and the definition of types of Business Actors:
• Decide whether central systems (e.g. TFM, market infrastructure) will be involved.
If this is the case, there will be a subsystem associated to each central system.
• Associate a subsystem to each type of Business Actors that will play one or multiple
related Business Roles.
In some cases, it will be possible to combine multiple Business Roles into one
subsystem. This will have to be decided on a case-by-case basis, based on
fundamental similarities or differences in the behaviour of the subsystems. It will
also be influenced by the fact that the same Business Actor always plays these
various Business Roles or not.
In other cases, it may be necessary to foresee multiple subsystems for a single
Business Role. This will be the case if multiple types of Business Actors can play
the same Business Role and if there is a significant influence of the type of Business
Actor on the behaviour of the subsystem and on its communication requirements.
- The subsystems can be documented in a class diagram.
3.3.2 Define Business Transactions
- Taking into account the subsystems that have just been defined, describe the way(s) in
which the requirements use cases will be realized by the subsystems (i.e. how the
subsystems will interact) and what information flows are required for this.
- The Business Transactions will at least be described by text and by a sequence diagram,
showing the information flow between the subsystems. Optionally, one can add a
collaboration diagram (note that the latter can be derived automatically from the
sequence diagram). The description(s) of the Business Transactions will provide
information about the information flows (= messages) that need to happen between the
subsystems, the sequence in which these flows will take place, exception handling,
trigger, pre- and post-conditions related to each information flow.
- For each identified information flow, define the name of the Message, the required
Message content and the high-level Message structure (i.e. what information should
logically be put together). This information must be documented in the sequence
diagram (linked to each information flow). The "Message content" can be identified by
taking into account the information that is required and provided by the different
Business Activities. At this stage, one can also specify information regarding
multiplicity, choices and textual descriptions of rules. Where necessary, one should also
identify whether information flows are synchronous or asynchronous, push or pull, etc.
- Refine the subsystems class diagram, if necessary.
3.4 Guidelines
3.4.1 General
- The decision of the basic architecture (i.e. user-to-user or centrally co-ordinated) will in
most cases be dictated by the initial requirements.
- Typical examples of types of Business Actors in the financial industry include banks,
agents (like brokers, investment managers, etc), corporates, etc.
- Like the Business Roles, the Business Actors will be part of the DD. Within the project
they will be added in the Business Role diagram (but with a clear indication that they
are Business Actors). The diagram will also show the links between Business Actors
and the Business Roles that are played.
- In general each requirements use case can (and will) be realized according to multiple
scenarios: for each scenario a separate Business Transaction must be defined and
described.
- The Business Transactions must also take into account (and thus describe) the
exception handling, the error handling, the acknowledgements, etc. These may result
into additional Sequence Diagrams.
- Note that a Business Transaction describes only one possible solution for a single set of
requirements. There can be multiple solutions for the same problem. In that case there
would be multiple Business Transactions for the same requirements use case.
- When identifying Business Transactions, one might identify that some Business
Transactions are specializations, extensions or combinations of others. For that purpose,
the Include, Extend, and Generalization relationships can be used.
3.4.2 Message granularity
Initial decisions concerning Message granularity must be taken (following rules will
consequently have an impact on 4.4.1.1. Granularity message modelling guidelines):

• Messages need to be precise and fit-to-specific purposes. Having very specific
Messages will lead to a higher number of Messages and will therefore require some
help for selecting the right Message to use in any particular case. This can be
achieved by following the same top-down approach that has been used in the
methodology, leading sequentially to the identification of the relevant Business
Area, Business Process, Business Transaction and Message.
The proposed approach leads to Messages that support limited but accurate business
functionality. These Messages will have less optional fields. It also results in shorter
messages, since a number of elements that are in a message to further define the
message functionality, can be removed. All of this simplifies implementation,
maintenance and will finally result in higher STP rate.
Example:
We don’t need the same information when buying a security or selling a security.
The returned confirmations will also be different. This should therefore result in
different Messages.
• The minimal guideline is to have separate Messages for different functionality (e.g.
separate Messages for create, modify, cancel; separate Messages for instructions
and reporting).
• With regard to different types of financial instrument, the guideline is to cover them
by the same Message unless the distinction is not only in the description of the
financial instrument (e.g. other parties must be identified in the Message if another
financial instrument is used).
• With regard to "Market Practices", the guideline is to concentrate first on a Market
Practice independent Message (i.e. a Message containing all the commonalties).
Next we can focus on a specific Market Practice and identify the specific
information and the need for more specific multiplicity, data typing and rules.
Depending on the required level of differentiation, Market Practices may therefore
result in different “variants” of the same Message Definition and/or in Message
Definitions covering the needs of multiple Market Practices.
• With regard to multiple subsystems that play the same Business Role, the guideline
is similar to the guideline concerning the Market Practices. Concentrate first on the
commonalties across the subsystems and identify afterwards the differences in
information needs, multiplicity, data typing and rules.
...