Standards

Standards MX

Development and Maintenance Processes

This document outlines the processes that Standards follows for the development of new MX messages and for the
maintenance of existing MX messages.

29 April 2011
Standards MX

Table of Contents
Table of Contents ...............................................................................................................................2
Preface .................................................................................................................................................3
1 Development .............................................................................................................................4
1.1 Summary .................................................................................................................................4
2 Origination.................................................................................................................................5
2.1 Business Opportunities and Market Demands .......................................................................5
2.2 Business Case ........................................................................................................................5
2.3 Standards Pilot Organizations ................................................................................................5
2.4 Project Status Updates ...........................................................................................................6
3 Project Initiation and Requirements Formulation.................................................................7
3.1 Develop Project Plan...............................................................................................................7
3.2 A Note on the ISO 20022 Methodology ..................................................................................7
3.3 Business Modelling .................................................................................................................7
4 Message Development .............................................................................................................9
4.1 Set up Testing Environment ....................................................................................................9
4.2 Logical Modelling ....................................................................................................................9
4.3 Development Approval ..........................................................................................................10
5 Piloting .....................................................................................................................................11
5.1 Pilot Testing ..........................................................................................................................11
5.2 Pilot Maintenance ..................................................................................................................11
6 Packaging ................................................................................................................................12
6.1 Packaging Documentation for User Handbook .....................................................................12
6.2 Implementation and Roll-out .................................................................................................12
6.3 Community Feedback ...........................................................................................................12
7 ISO 20022 Submission and Approval...................................................................................13
7.1 Submission of ISO 20022 Business Justification ..................................................................13
7.2 Submission of the Candidate ISO 20022 Messages ............................................................13
8 Maintenance ............................................................................................................................14
Appendix A........................................................................................................................................15
A.1 RACI ......................................................................................................................................15
Legal Notices ....................................................................................................................................16

2 MX development and maintenance processes

 Preface

Preface
Purpose of this document
The creation and maintenance of message standards is a critical aspect of SWIFT’s role in the
financial community.
This document describes in detail the process used by the SWIFT Standards Department
(Standards) to create and maintain MX message standards. The intended audience is anyone
with an interest in SWIFT standards: from those that would initiate standards development, or
collaborate as pilot users, to those that oversee the process from a governance standpoint.
The development process attempts to reconcile the need for a new standard to be complete in
terms of analysis and coverage with the needs of users, who expect standards to be practical
and economic to implement, and adapted to business realities. To this end, the process specifies
an iterative approach to development, which requires the active participation of pilot
organizations committed to using the finished messages.
All new MX messages are developed in accordance with the ISO 20022 methodology. The ISO
20022 methodology uses the Unified Modeling Language (UML) to capture definitions for
business areas, business transactions, message flows and messages in a form which is
independent of any particular implementation technology or syntax. The present document
explains how the ISO 20022 development methodology is implemented by SWIFT. For a
complete picture, readers should also refer to the documentation of the methodology in the ISO
20022 standard itself, which is available from the International Organization for Standardization
(ISO), www.iso.org. More general information about ISO 20022 can be found at
www.iso20022.org.
MX messages are deployed on the SWIFT network in closed user groups (CUGs). This
arrangement requires users to opt in to use a new message; users that do not, will not receive
the new message and need not make any provision for it. The MX development process takes
advantage of this fact to develop messages that satisfy the needs of the pilots, without affecting
the wider community.
In general, SWIFT aims to have all MX messages approved and registered by ISO as ISO 20022
compliant messages. SWIFT submits a Business Justification 1 for approval by the ISO 20022
Registration Management Group (RMG), once board approval for the development is granted. At
the end of the pilot development process, when messages have been deployed and maintained
as necessary so as to demonstrably satisfy the requirements of the pilot group, SWIFT submits
the candidate messages to the ISO 20022 Registration Authority (RA) for technical quality review
prior to submission to the relevant ISO 20022 Standards Evaluation Group (SEG) for business
review and approval. The SEG may request changes to the messages, to make them applicable
to the broader market. SWIFT works with the SEG to define and implement any necessary
changes, then resubmits the messages to the ISO 20022 RA for final SEG approval and
registration. After registration, SWIFT consults with the users of the messages to plan the switch
to the ISO version. According to the needs of the users, SWIFT may opt to continue to carry the
pre-registration version of the messages, in order not to force existing users to upgrade.

1
When SWIFT is developing the MX messages for or on behalf of a third party, the business justification may be submitted by this
third party or jointly by SWIFT and this third party.

29 April 2011 3
Standards MX

1 Development
1.1 Summary
The MX Standards Development Process is summarized in the following diagram:

MX Development Process

Business case development

(out of scope)
Origination

Approved
Business
Case

Develop Project Submit ISO

Plan 20022
Business
Requirements formulation

Justification

Set-up test
environment

Business
modeling
Message development

Logical
modeling

Development
approval

Pilot testing
Piloting

Pilot
maintenance

Package
documentation
for UHB
Packaging

SWIFTNet
implementation
ISO submission

Submit candidate
messages to SEG

Implement SEG
requirements (if
any)
Approval

ISO 20022
Approval

4 MX development and maintenance processes

 Origination

2 Origination
Standards development requires prior approval of a business case, which generally takes place
with only limited involvement from Standards.
This section describes the steps of the origination phase of a Standards project.

2.1 Business Opportunities and Market Demands

Development projects originate from identified business opportunities or market demand.
Requests for development can come from inside SWIFT (including from Standards) or from the
SWIFT community. Members of the SWIFT community that wish to propose new standards
development should initially approach their SWIFT account manager(s).
When a proposal for development of new message(s) is received, SWIFT will:
• work with the requestor to define the scope and high level requirements of the proposed
messages
• identify other parties interested in the proposed messages, to pilot the completed message
set

2.2 Business Case

When the scope and initial high-level requirements have been defined and pilot organizations
identified, the business case for development will be completed and presented for approval.
Approval may be granted by the SWIFT Board or Executive, depending on the size and cost of
development and deployment.
In addition to the scope, high-level requirements, and identification of pilot organizations,
business cases will also contain information such as:
• Strategic fit
• Business rationale
• Estimate of the overall effort required (including Standards)
• Origin of the request (e.g. a user group)
• Priority
• Consultation process details (e.g. what organizations/industry associations were consulted)
• Driver(s) (e.g. regulatory)
• Timeline

Note There may be exceptional circumstances under which ISO 20022 registration for new
messages will not be sought. In such cases, a clear justification for this decision will
be submitted for board or executive approval, at the same time as the business case.

2.3 Standards Pilot Organizations

When the business case has been approved, SWIFT will begin the development of the proposed
messages.
SWIFT develops new or enhanced messages with the help, and according to the requirements,
of the organizations that will be the initial users (the ‘pilots’) of the messages. A standards pilot
group is a required prerequisite for any new development. Pilots agree to participate in
requirements collection, requirements validation and message testing as part of the development
process, and must be committed to using and promoting implementation of the developed
messages. The standards pilot group must also be sufficiently diverse to represent the market to
which the development applies.

29 April 2011 5
Standards MX

Active participation of pilots is critical to the success of the development process. If a pilot
organization does not demonstrate sufficient commitment to the development project in terms of
participation in meetings, review of documents and testing/validation of draft messages, there is
a risk that the finalized message set will not meet the requirements of the pilot group.

Note If a lack of commitment on the part of a pilot(s) organization occurs, Standards will
raise this as an issue with the organization’s SWIFT account representative, and, if
the issue cannot be resolved, may ultimately remove the organization from the group.
In cases where the entire group is not functioning, Standards may opt to suspend the
project until new pilot organizations can be identified.

The pilots are responsible for approving various outputs of the development process, as
described in the sections that follow.
The names of pilot organisations are published in a password protected area of swift.com
(individual members may opt not to be included in the published list).

2.4 Project Status Updates

The status of approved projects is reported on a quarterly basis in the Standards Quarterly
Review (SQR) which is available to both SWIFT Board Members and SWIFT national user
groups. The SQR contains information regarding the scope and purpose of new and ongoing
projects, the project status and the timeline for completion of the project and delivery of the
message documentation.

6 MX development and maintenance processes

 Project Initiation and Requirements Formulation

3 Project Initiation and Requirements

Formulation
Once a business case is approved, a development project is initiated.

3.1 Develop Project Plan

Standards creates the project plan, including:
• Development and deployment milestones and expected dates
• Detailed resource requirements
This plan is shared with the pilots.

3.2 A Note on the ISO 20022 Methodology

The ISO 20022 methodology makes a distinct separation between the information required to
describe a business process (the business model), and the way that that information is
exchanged in messages (logical message models). The first step is to define the concepts and
relationships required to describe the business. This information is captured formally in the
business modelling phase of the project. Message definitions are defined in logical message
models that refer to the definitions in the business model. The message documentation and XML
schemas that are the ultimate outputs of the development are derived automatically from these
logical message models. The message development phase of the project is referred to as logical
modelling.

3.3 Business Modelling

The pilots are consulted on the scope and requirements for the development of the new
messages. SWIFT Standards arranges meetings with the pilots, which, depending on the project,
may be one-to-one conversations, email exchanges or “working group” type meetings (virtual or
in person) in which all the pilots are brought together.
SWIFT Standards is responsible for defining and documenting complete requirements through
consultation with the pilots. The detailed requirements must be approved by the pilots, in writing,
before development can proceed to the next stage.
The requirements document is submitted to the pilot group for approval, or rejection with
comments. The length of the review period is specified by SWIFT Standards when the document
is submitted and will vary according to its length and complexity, but will not be less than three
weeks. At the end of the review period, if no comments have been received, the pilots will be
notified that the document is approved. If comments are received, then a new version of the
document is prepared by Standards, either immediately or, if the comments are too difficult to
address without participation, after a virtual or in-person meeting in which the changes are
discussed. The new document is again circulated for approval or rejection with comments, with a
specified review period. This process is repeated until no more comments are received, and the
document is formally approved by every member of the pilot group. If unanimity cannot be
achieved, and a compromise acceptable to Standards and all the pilots cannot be reached,
Standards may escalate the issue(s) to the appropriate SWIFT Board Committee for resolution.
The Standards Advisory Council (SAC) may also be consulted.
When the requirements document is agreed by the pilots, SWIFT Standards creates a business
model. The business model is a formal representation of the static (data) and dynamic (business
process) content of the business requirements. The complete business model is reviewed
internally to ensure that it correctly reflects the content of the requirements document, and that it
conforms to best practice for the representation of business information according to the ISO
20022 standard. The business model is not submitted to the pilot group for approval, because

29 April 2011 7
Standards MX

ISO 20022 business modelling is a technical exercise and in most cases pilots will not have the
necessary skills. Pilots may review the business model on request.

8 MX development and maintenance processes

 Message Development

4 Message Development
4.1 Set up Testing Environment
SWIFT sets up a dedicated message testing environment, to be used by the pilot group to
experiment with draft message definitions during the development process. This test
environment remains available through to the end of the development process and is only
accessible to the pilot group and SWIFT.
The test environment is a web-based tool, accessible through a standard web browser, which
allows draft messages to be tested using a Graphical User Interface (GUI). The GUI displays the
message structure, allowing it to be explored, and also allows sample messages to be captured,
validated, stored and downloaded in the form of XML files for local testing.
Users can also upload messages created locally, and edit, validate, store and share them. Each
test message is marked with the ID of the user that created it, and each pilot member is allocated
a user ID, so it is possible for pilots to exchange test messages with one another and with SWIFT
Standards, and for Standards to track testing activity.
Training in the use of the test environment is provided by SWIFT to the pilots as part of the
project preparation.
Expectations about the quantity and nature of testing required for the pilots to adequately review
the messages are discussed and agreed.

4.2 Logical Modelling

Formal logical modelling activities start when the business model, which is derived from the
approved requirements, is completed.
Standards prepares initial logical models that implement the detailed requirements, and auxiliary
documents, including diagrams, that describe message the flow of messages between the
business partners that participate in the transaction.
This material is used to produce documentation and XML schemas 2 that can be used by the
pilots to evaluate the messages. The draft documentation includes, for each new message:
• a spreadsheet that sets out the full structure of the message
• detailed definitions of each element
• an annotated XML Schema that adds textual element definitions to the basic XML schema,
allowing it to be used as a processable message reference, and for the message definition
to be visualized using GUI-based XML tools
The logical models are also used to provision the testing environment described above.
At this point, Standards works closely with the pilots to ensure that the messages meet the
agreed business requirements, and also that they are practical from a technical implementation
standpoint. Standards monitors the use of the test environment to ensure that the agreed level of
testing is maintained by the pilots.
The testing feedback process is controlled:
• pilots submit their comments and change requests to Standards
• Comments and change requests are discussed at scheduled virtual meetings at which a list
of new implementation changes is agreed.
Agreed changes are documented by SWIFT Standards and submitted to the pilots for approval
or rejection with comments. The length of the review period is specified by SWIFT Standards

2
An XML Schema is formal definition of the structure of an XML document (or message). See http://www.w3.org/XML/Schema

29 April 2011 9
Standards MX

when the document is submitted and will be no less than three weeks, but will vary according to
its length and complexity. At the end of the period, if no comments have been received, the pilots
are notified that the document is approved. If comments are received, then a new version of the
document is prepared by Standards, either immediately or, if the comments are too difficult to
address without participation, after a virtual or in-person meeting in which the changes are
discussed. The new document is again circulated for approval or rejection with comments, with a
specified review period. This process is repeated until no more comments are received, and the
document is formally approved by every member of the pilot group.
If unanimity cannot be achieved, and a compromise acceptable to Standards and all the pilots
cannot be reached, Standards may escalate the issue(s) to the appropriate SWIFT Board
Committee for resolution. The Standards Advisory Council (SAC) may also be consulted.
Once implementation changes are approved, Standards makes the necessary logical model
changes and will ensure traceability by formally tracking which change to the model implements
which requirement. If the changes to the logical model necessitate changes to the business
model, these are made at the same time. On completion of the changes:
• the test environment is updated with the new definitions
• the documentation and XML schemas are re-generated and distributed to the pilots.
All meeting minutes and derived requirements documentation and traceability information are
maintained by Standards and shared with the pilot organizations via a secure web-site.
Ideally, only one iteration of this feedback process is required. In practice, and depending on the
complexity of the project and the number of messages, more may be needed. Standards works
with the pilot group to set a realistic delivery and meeting schedule, to ensure that the process is
managed and predictable.

4.3 Development Approval

The full documentation set includes:
• draft final versions of the message spreadsheets
• annotated XML schemas (as described in the previous section)
• a formal Message Reference Guide in PDF format
Standards updates the test environment with the draft final message definitions, and sends the
draft final documentation to the pilots for validation.
The pilots validate the finalized messages and documentation. Standards leads this process
through a combination of face-to-face meetings and/or conference calls, as appropriate. It may
be necessary to make modifications to the messages following this review. This step completes
with the pilots’ written approval of the messages and documentation.
The approval process requires that an 80% majority of those voting approve, where votes are
counted per member organization, rather than per individual member, and those that do not vote
are required to accept the decision of the voting members. All votes must be formally registered
by an email sent by the voting organization to SWIFT Standards. A deadline for voting is
communicated by SWIFT Standards after the final review meeting, along with the updated
document if any changes were agreed at the meeting. The deadline is typically set for two weeks
after the final meeting.
In cases where there are irreconcilable differences of opinion between pilot organizations that
prevent the majority required for formal approval being achieved, Standards may instead seek
approval to move on to the Pilot Testing phase of the project from the appropriate SWIFT Board
Committee, using a message design agreed by the majority of participants.

10 MX development and maintenance processes

 Piloting

5 Piloting
5.1 Pilot Testing
Once approved, the developed messages are provisioned on the SWIFTNet Pilot Test service,
which allows users to exchange test messages in an environment that simulates live traffic on
SWIFTNet. All pilot participants are invited to take part in pilot testing using this service. Other
organizations interested in using the new messages may also be invited to take part in pilot
testing, as long as this does not delay the process.
The purpose of pilot testing is to ensure that messages work correctly on the SWIFTNet network,
and to evaluate the messages in the context of an overall business solution. SWIFT Standards
works with the pilot test participants and SWIFT solution managers to formulate test scenarios in
which each tester plays the role they would play in a live business process with the aim of
ensuring that the messages meet the needs of all participants.

5.2 Pilot Maintenance

Requirements for minor modifications may emerge from the pilot testing phase. Standards takes
into account all feedback, and may update the requirements document, business model, logical
models and message definitions accordingly. If modifications are required, the new standards are
again submitted to the pilots for approval, as described in section 5.2.
In cases where the new requirements would require major rework to implement, but the
messages are still viable for the expected initial use cases, Standards may propose that changes
be postponed to a future version of the standard; Standards would formulate agreed changes in
terms of Change Requests, and submit them as input to a future maintenance process.

29 April 2011 11
Standards MX

6 Packaging
6.1 Packaging Documentation for User Handbook
Complete documentation for the new messages is handed over to the SWIFT department
responsible for publications, to be included in the Standards MX Message Reference Guides and
XML schemas (User Handbook).

6.2 Implementation and Roll-out

SWIFT Solution Managers organize implementation of the messages on SWIFTNet. New
messages are deployed on the network in Closed User Groups (CUG), to which SWIFT
members need to opt in. In this way, the impact of the new messages on the user community is
limited to those that are interested in using them (although over the longer term the existence
and adoption of the new messages may have some impact on adjacent value chains and
message flows). Once the CUG is set up, eligible members may immediately apply to join.

6.3 Community Feedback

As soon as message definitions are published in the Standards documentation set, in the User
Handbook Online, the community at large is encouraged to review the new message definitions
and submit feedback to SWIFT Standards. Standards may use this feedback to formulate
Change Requests, to be submitted as input to a future maintenance process.

12 MX development and maintenance processes

 ISO 20022 Submission and Approval

7 ISO 20022 Submission and Approval

7.1 Submission of ISO 20022 Business Justification
Standards prepares and submits the ISO 20022 Business Justification that requests the ISO
20022 Registration Management Group (RMG) to approve that the messages be considered
candidate ISO 20022 messages. Normally the Business Justification is submitted to the RMG
immediately after the approval of the business case. Feedback from the RMG, if any, will be
taken into account either during the initial development or at the occasion of the first
maintenance of the message set.
In some cases - for example when the MX messages are developed by SWIFT for or on behalf of
a third party, or in partnership with other standards development organisations - the Business
Justification may be submitted by this third party or jointly with the other submitting organisations.
In exceptional cases – for example, where messages are designed for use in a SWIFT-
proprietary service – SWIFT may develop messages according to the ISO 20022 methodology,
but without the intention of submitting them for ISO registration (see section 3.3). In these
instances, a business justification is not submitted to the RMG.

7.2 Submission of the Candidate ISO 20022 Messages

After RMG approval of the Business Justification is obtained, the new messages, when
completed, are submitted to the ISO 20022 Registration Authority for quality review and
production of the documentation that will be submitted to the Standards Evaluation Group (SEG)
for the relevant business area for evaluation.
The role of the SEG is to ensure that submitted messages are suitable for adoption by the
international financial community. Given that the message design process up to this point has
focused on the business needs of the pilot group only, it is possible that when messages are
submitted, the SEG will request changes intended to broaden their appeal to the wider
community.

Note The SEG review process, including the approval mechanism and appeals procedure,
is formalized in the ISO 20022 Registration and Governance Procedures, which can
be found on the ISO 20022 website.

Standards makes changes to the message models and business model to implement any
business changes required by the SEG, and then applies for formal SEG approval. Once
approval is granted, the ISO 20022 Registration Authority (RA) formally registers the MX
messages as ISO 20022 messages and publishes them on the ISO 20022 website.
SWIFT will work with the users of the messages to plan any switch to the ISO version. According
to the needs of the users, SWIFT may opt to continue to carry the pre-registration version of the
messages, in order not to force existing users to upgrade.
Before they are registered, candidate messages are identified using a SWIFT namespace 3.
Registered ISO 20022 messages are identified using an ISO namespace. If the only difference
with the pre-registration version is the ISO name space, SWIFT Market Managers will decide at
what time (if at all) to switch to the ISO namespace, and communicate with the users of the
messages accordingly.

3
XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language. An
ISO 20022 or candidate ISO 20022 message definition is uniquely identified by the combination of its name and its namespace.
See http://www.w3.org/TR/REC-xml-names/.

29 April 2011 13
Standards MX

8 Maintenance
Before their approval as ISO 20022 messages, candidate messages already implemented on
SWIFTNet follow a SWIFT maintenance process, which is aligned with the ISO 20022 and MT
maintenance process. Change requests may be submitted by User Group Chairpersons (UGC),
by representative market practice groups in which there are SWIFT members or by Closed User
Groups (CUG) administrators. Change requests are received by SWIFT Standards and validated
by a maintenance working group composed of specialists in the business area.
Once messages have been approved as ISO 20022 messages, their maintenance follows the
ISO 20022 maintenance process described on www.iso20022.org, in which change requests are
submitted directly by the users to the ISO 20022 Registration Authority for evaluation by the
relevant SEG.
If the community of SWIFT users of the messages indicates that it does not want to implement
the new ISO versions, exceptionally, and with the approval of the appropriate Market Managers
and the STC, SWIFT may opt to create SWIFT-specific versions of the messages for deployment
on the SWIFT network, which would be maintained according to a parallel maintenance process
similar to the pre-ISO approval process described above.
The MT maintenance process MT Development and Maintenance Processes available at
swift.com > Support > Documentation (User Handbook)

14 MX development and maintenance processes

 Appendix A

Appendix A
A.1 RACI
Responsible Responsible to perform the task
Accountable Accountable for the task being completed
Consulted Consulted/involved prior to completion
Informed Informed that the task has been completed

Pilot ISO ISO ISO

Step Activities Markets Standards Pilots Users RMG SEG RA Users Comments
Standard Development
1 Process (MX)
1.1 Develop business case R,A I Out of scope for this document
1.2 Requirements formulation I R,A R
1.3 Develop project plan I R,A I
1.4 Set up testing environment R,A I
1.5 Business Modelling R,A C
1.6 Logical Modelling R,A R
1.7 Development Approval A R
1.8 Pilot Testing A R
1.9 Pilot Maintenance R,A C
1.10 Package Documentation R,A I
1.11 SWIFTNet Implementations R,A I I Managed by Market Managers
Develop ISO 20022 Business
1.12 Justification R,A I C C RMG approves BJ
1.13 Submit candidate messages R,A I C C SEGs approve candidate messages
1.14 ISO 20022 Maintenance I R R,A C ISO process

29 April 2011 15
Standards MX

Legal Notices
Copyright
SWIFT © 2011. All rights reserved.
You may copy this publication within your organisation. Any such copy must include these legal notices.

Confidentiality
This publication contains SWIFT or third-party confidential information. Do not disclose this publication outside your
organisation without the prior written consent of SWIFT.

Disclaimer
This publication constitutes advance information only and is not to be considered the final and complete standards
documentation for the subject matter published herein. The information in this publication may change from time to
time. You must always refer to the latest available version on www.swift.com.

SWIFT Standards Intellectual Property Rights (IPR) Policy - End-User License Agreement
SWIFT Standards are licensed subject to the terms and conditions of the SWIFT Standards IPR Policy - End-User
License Agreement, available at www.swift.com > About SWIFT > Legal > SWIFT Standards IPR Policy.

Translations
The English version of SWIFT documentation is the only official and binding version.

Trademarks
SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: SWIFT, the SWIFT
logo, 3SKey, Innotribe, Sibos, SWIFTNet, SWIFTReady, and Accord. Other product, service, or company names in
this publication are trade names, trademarks, or registered trademarks of their respective owners.

16 MX development and maintenance processes