WHITEPAPER

SWIFT MESSAGING
The testing journey

LIAM SHERLOCK
Principal Consultant
liam.sherlock@sqs.com
Liam Sherlock holds a degree in Applied Computing and has been with SQS
since 2005. His key responsibilities are test management, consultant coaching, and programme / project management. Programme / project delivery is
backed up with the certications PRINCE 2 and PMI PMP, as well as test
management. His experience spans 14 years of professional testing across a
wide range of industry sectors, managing geographically dispersed test and
vendor teams.

SWIFT Messaging

Page 2

1 MANAGEMENT SUMMARY
The Society for Worldwide Interbank Financial
Telecommunication (SWIFT) was founded in 1973,
with the mission of creating a shared worldwide
data processing and communications link and
a common language for international nancial
transactions. Starting with the support of a modest 239 banks in 15 countries, SWIFT now boasts
8,468 live users across 208 countries. (')

sure. As volumes of trafc increase, there will be a

greater need for performance testing of processing platforms and trade life-cycle management
applications.

Another area of growth is XML messaging (i.e. ISO

20022 or MX format). This message format was
published for the rst time in 2004 and therefore
still is in its infancy. Trafc for this format over
In recent years, there has been an increase in the last ve years (as published by SWIFT) has alinterest in Straight-Through Processing (STP, most doubled. This trafc increase along with the
(()) with
withregard
regardtotonancial
nancialservice
servicetransactransac- support of major clearing houses in Europe and
tions. SWIFT messaging can help facilitate STP. pending restrictions being placed on its predecesThis offers nancial service organisations the op- sor standard (ISO 15022) means that the growth
portunity to reduce costs and increase volumes of this message format looks set to continue at
of nancial transactions. This area has huge some pace.
growth potential as it is easy to demonstrate the
return on investment to potential clients. With This paper aims to advise on what contributes to
STP, manual intervention and paper processing making SWIFT messaging a success, especially
are removed thereby reducing costs but increas- with regard to message ows and straight-through
ing the risk of nancial transactions being com- processing. It looks at the interaction between the
pleted with inaccurate or out-of-date information. messages, how they are linked, and gives examTherefore, it is vital that the messaging solution ples of the testing challenges that organisations
is tested thoroughly in order to reduce risk expo- working with SWIFT messaging have to face.

2 INTRODUCTION
2.1 SETTING THE SCENE
ISO (International Organization for Standardization) is the worlds largest developer and publisher of international standards, a network of the national standards institutes of 162 countries. This
network makes it possible to reach a consensus
on solutions that meet both the requirements of
business and the broader needs of society. (3)
The standards for electronic messaging in the
nancial industry have been developed by ISO.
However, while ISO has dened the standards, a

dictionary of data elds and a catalogue for messages have been kept outside these standards.
They are made available by the Registration Authority (RA). SWIFT is the RA for the following ISO
standards that will be mentioned:
ISO 15022 Securities This standards message
scheme includes a set of syntax and message
design rules, a dictionary of data elds, and a
catalogue for securities (i.e. MT) messages.
ISO 20022 Financial Services This standard includes a universal nancial industry
message scheme. It is a repository contain-

SWIFT Messaging

ing descriptions of messages (i.e. MX) and

business processes for the nancial industry,
and a maintenance process for the repository
content. The messages themselves are an
XML-based syntax and are the successor to
the ISO 15022 standard.

In addition to the above standards containing the

two main message suites, SWIFT users will also
come across other standards to use within the
messages themselves:
ISO 9362 This is also known as the BIC (Business Identier Code). This code unambiguously identies both nancial and non-nancial
institutions. It is used primarily for international wire transfers and the exchange of other
messages between banks. The BIC can have
either eight or eleven characters.
ISO 13616 IBAN stands for International Bank
Account Number. It is the international standard for numbering bank accounts. It allows
exchanging account identication details in a
machine-readable form. The IBAN structure
is dened in ISO 13616-1 and consists of a
two-letter ISO 3166-1 country code, followed by
two check digits and up to thirty alphanumeric
characters for a BBAN (Basic Bank Account
Number). (4)
ISO 6166 This standard provides a uniform
structure for a number known as the International Securities Identication Number (ISIN),
which uniquely identies securities. (+) The
ISIN consists of a total of twelve characters.

Page 3

2.2 THE CHALLENGE

With SWIFT message testing, the challenges are
many, but understanding how to interpret the
SWIFT standards and understanding the exibility within these standards is key. The need to
understand how the messages are linked to form
message ows is imperative to reaching straightthrough processing. Finally, SWIFT makes regular
updates to its message formats, and any user
of SWIFT messaging needs to keep informed of
these changes. An assessment of the updates is
required to see whether any changes to message
congurations have become necessary.
2.3 GETTING STARTED
In order to get started with SWIFT messaging, there
are a number of prerequisites that need to be in
place before you can send and receive messages.
A quick overview of the following terms used when
talking about SWIFT messaging will be helpful:
Message service(s)
Message format(s)
Message types

Knowing these prerequisites is vital to the success of any SWIFT messaging project, so they
should be known and agreed before delving into
any details of the messages themselves.

2.3.1 MESSAGE SERVICE(S)

SWIFT provides an Internet protocol-based
messaging platform called SWIFTNet, which
offers four messaging services to SWIFT
Note: There are other, alternative numbers that customers (-):
can be used to identify a security, e.g. CUSIP 1 FIN This service enables the exchange of
messages formatted with the traditional
(used in the US and Canada, cf. (,)) or SEDOL
SEDOL
SWIFT MT (message type) or ISO 15022 stand(used by securities registered with the London
ards. It works in store-and-forward mode and
Stock Exchange).

SWIFT Messaging

Page 4

functionality (see Figure 1), such as message

copy, broadcasts, and online retrieval of previously exchanged messages. This standard of
messaging currently is by far the most used.
2 InterAct This service enables the exchange of
messages formatted with the new XML-based
SWIFT MX or ISO 20022 standards. As well as
offering store-and-forward messaging, it also
supports real-time messaging and real-time
query-and-response messaging (see Figure 2).

3 FileAct This service enables the transfer of

les. It can be used for the transfer of large
batches of messages, such as bulk payment
les, very large reports, or operational data.
4 Browse This service allows users to browse
securely on nancial websites available on
SWIFTNet using standard Internet technologies and protocols such as HTTP-S and HTML.

SWIFTNet
Message
Institution
A

Message

Ack

Ack
CENTRAL
STORAGE

Institution
B

STORE-AND-FORWARD MESSAGING

Figure 1: Store-and-forward messaging

SWIFTNet

Institution
A

SWIFTNet

Message

Query

Acknowledgement

Response

REAL-TIME MESSAGING

Institution
B

Institution
A

Institution
B

REAL-TIME QUERY-AND-RESPONSE MESSAGING

Figure 2: Real-time messaging and real-time query-and-response messaging

SWIFT Messaging

It is important to note that a mix of services can

coexist in the overall SWIFT messaging solution.
This is especially true if there are a number of
communicating parties involved. For example,
communication between client and transfer agent
could be done using InterAct while the communication between transfer agent and custody could
be FIN. This means that the transfer agent must
be able to send and receive both the MT and MX
message formats.
The service choices available may be impacted by
the age of the systems being interfaced. In our experience, the older and more established legacy
custody systems are almost always FIN-enabled
and do not yet support InterAct. Migration to the
InterAct service and the new XML-based MX message format is gaining speed, especially as the
time when restrictions will apply to FIN Fund Templates draws nearer.
The other advantage of InterAct is real-time
messaging. Delays in the settlement of nancial
transactions are no longer acceptable. Speed of
processing and therefore automation of the messaging process becomes increasingly important.
2.3.2 MESSAGE FORMAT(S)
The choice of a messaging service directly impacts the message format to be used. As with the
choice of service, facts suggest that the more established MT format (ISO 15022) is more popular
and used most frequently. For someone unaccustomed to the format, it is more difcult to understand, but because of its popularity, many people
within the nancial services industry refer to this
format as SWIFT and are unaware that another
format even exists.
The MT format uses a series of tags followed by
the actual information. The following subset of an
MT502 Order to Buy or Sell message shows the
order details section of the message:

Page 5

:16R:ORDRDET
:22H::BUSE//SUBS
:22F::TOOR//MAKT
:22H::CAOP//CASH
:22F::TILI//GTCA
:22H::PAYM//APMT
:98A::EXPI//21001231
:16R:TRADPRTY
:95R::BUYR/CLIENT1234
:70E::DECL///CERT/Y/BYOO/1234
:16S:TRADPRTY
:16R:TRADPRTY
:95Q::INVE//BANK1
:16S:TRADPRTY
:19A::ORDR//EUR/50000
:35B:ISIN GB0123456789
:16S:ORDRDET
This will be explained further below. A user unfamiliar with the MT format will nd it difcult to
know what this subset is talking about.
The format of an MX message sample (ISO 20022)
is more familiar to people accustomed to XML:
<IndvOrdrDtls>
<OrdrRef>ORDERREF001</OrdrRef>
<FinInstrmDtls>
<Id>
<ISIN>GB0123456789</ISIN>
</Id>
</FinInstrmDtls>
<GrssAmt>50000</GrssAmt>
<SttlmMtd>APMT</SttlmMtd>
<PhysDlvryInd>false</PhysDlvryInd>
<ReqdSttlmCcy>EUR</ReqdSttlmCcy>
<ReqdNAVCcy>EUR</ReqdNAVCcy>
</IndvOrdrDtls>

SWIFT Messaging

2.3.3 MESSAGE TYPES

Within each message format, there is a suite of
message types. For ISO 15022, these are broken
into categories:
Category 1 Customer Payments
Category 2 Financial Institution Transfers
Category 3 Treasury Markets, Foreign
Exchange
Category 4 Collections and Cash Letters
Category 5 Securities Market
Category 6 Treasury Markets, Precious
Metals
Category 7 Treasury Markets, Syndication
Category 8 Travellers Cheques
Category 9 Cash Management and Customer
Status

Each message type is given its own unique ID, e.g.

MT502, MT509 or MT515. The rst digit after the
MT indicates the category that the message type
belongs to. Each message type will have its own

Page 6

denition as detailed by SWIFT. This message definition will have a number of optional, mandatory
and conditional elements to it. It is important to
understand what message types are going to be
tested, before going into the more detailed denition piece.
For ISO 20022, the message types are broken
down into ve business domains:
Payments
FX
Securities
Trade Services
Cards and Related Retail Financial Services

It should be noted that the suite of supported

message types needs to be agreed between the
sender (nancial institution or bank) and the receiver (nancial institution or bank) prior to going
into a lower level of detail with regard to message
denition and testing.

3 MARKET CURRENT STATUS

AND OUTLOOK
According to the article IT Spend by Industry
Worldwide by Jeff Roster, the Financial services
industry spent $ 558.4 billion worldwide in 2008
on IT (hardware, software, IT services, internal
services and telecommunications). (.)
that
Current forecasts from Gartner (/) predict
predict
that
IT spending will remain around the $ 500 billion
mark into 2015 and have a CAGR (Compound Annual Growth Rate) in excess of 5 % over the veyear period from 2009 to 2015.

SWIFT messaging enables more than 9,000 nancial service organisations in 209 countries (according to SWIFT, July 2011) to exchange millions
of standardised messages daily. ('&)
SWIFT makes annual updates to its standard message formats and this, together with changes in how
SWIFT messaging is being used, means that there is
constant change and growth in the area of testing.
Figure 3 shows the average daily volumes of trafc (messages and les) over the last ve years
(YTD).

SWIFT Messaging

20,000,000

Page 7

FIN (15022 messages)

File Act (files)
InterAct (20022 messages)

15,000,000

10,000,000

5,000,000

0
2007

2008

2009

2010

2011

July 2007

July 2008

July 2009

July 2010

July 2011

13,408,802

15,207,924

14,789,382

15,933,049

17,428,600

10,669

22,366

27,825

39,383

50,907

675,583

924,243

981,183

1,169,999

1,229,840

Figure 3: SWIFT Messaging Average Daily Trafc YTD (Information obtained from www.swift.com)

As can be seen from the gures above, there has

been a steady growth in the SWIFT message trafc across the three services over the last ve
years, and all indications are that this is set to
continue. With the increase in SWIFT trafc and

continued investment in IT in the nancial services sector, it is logical to conclude that the need
for people with SWIFT messaging knowledge will
be in greater demand than ever.

4 UNLOCKING THE MYSTERY OF SWIFT

MESSAGING
There are a number of challenges in getting messages from source (nancial institution or bank)
to destination (nancial institution or bank), but
by meeting these challenges and testing accordingly, we can overcome them. The key considerations in this context are the following:

Understanding the MT message structure

Understanding the MX message structure
Sequencing the messages and linking them in
the quest for STP
SWIFT compliance with published standards
Migration from MT to MX

SWIFT Messaging

4.1 UNDERSTANDING THE MT MESSAGE

STRUCTURE
The message structures for MT and MX are very
different. With this in mind, they need to be
treated separately here. For MT, the messages
are broken down into four or ve blocks (block 3
is optional). The header block tells us where the
message is coming from (sender BIC) but the majority of the information is contained in block 4,
i.e. the text block or body.
{1: Basic Header Block} Contains the senders
BIC address
{2: Application Header Block} There are two
options here, input or output
{3: User Header Block} Optional block
{4: Text Block or Body} Contains main body
of information for the message type (specied
in the application header) and must obey the
rules outlined in the SWIFT standards governing this type
{5: Trailer Block} Contains Message Authentication Code (MAC) and Checksum (CHK), and
indicates whether the message is a duplicate
of a previously sent message

As previously mentioned, the main body or block

4 of the message is where all the message information is contained.
There are a number of key points to understand
about the message type denition:
It is broken into sequences and subsequences,
some of them mandatory (e.g. Sequence A
General Information) and some optional (e.g.
Sequence C Additional Information).
Each sequence and subsequence is broken
further into line items with tags. Again, some
are mandatory (M) and some optional (O).
It is important to note that mandatory tags are
only mandatory if the sequence or subsequence that contains them is included; i.e. if an

Page 8

optional sequence or subsequence is included

in the message, then the mandatory tags
associated with that sequence must also be
included.
Each sequence and subsequence has a beginning tag (16R) and an end tag (16S).
Each line item in the denition has
an allowed format. The usual pattern is: <Tag><Qualier><Content>, e.g.
:20C::SEME//12345
Each tag may have an option / letter, e.g. 16 can
have R or S. R means start and S means end.
After the tag, the item may or may not have a
qualier. There may even be multiple qualiers: it is possible to recognise these instances
by a lower-case letter, e.g. 22a. In this case, 22
can have the options F or H, as mentioned in
the Content / Options column.
The Detailed Field Name column sometimes
gives a description of the line item, and sometimes it will include a hyperlink to further rules
or options:
16R Shows a description Start of Block;
whereas
23G has a hyperlink to further options for
the Function of the Message. If we go to the
page, we see that there are three options:
CAST, INST or REST. In addition, there are a
further three optional sub-functions that this
item could have: CODU, COPY or DUPL.
The Content / Options column shows the
format displayed as a series of symbols (like
BNF), with each symbol given rules for what
this symbol can be replaced with, e.g. ! = Fixed
length, a = Upper case, or n = Numeric (0-9).

The use of optional tags in mandatory sequences / subsequences and the use of optional sequences / subsequences should be agreed between the message sender and receiver. It is
recommended that a template message is agreed
upon by both parties prior to commencement of

SWIFT Messaging

testing. The sender and receiver should try to limit

the options within tags. For example, in an MT509
message type, the status of order (IPRC) can have
all the following codes: CAN1, CAN2, CAN3, CAND,
CANO, COSE, DONE, DONF, EXCH, EXSE, INTE,
NOTC, OPOD, OVER, PACK, PAFI, PART, REJT,
REPR, SESE, or SUSP. The receiver may not be
interested in receiving all of these status updates
and therefore can agree with the sender a subset
of codes, thus reducing the number of messages
to be sent over and back during testing.
Some of the other nuances and behaviours within
the MT standard are discussed in another whitepaper, Transformer and SWIFT MT Messages by
Trace Financial Limited. ('')
The next step is to ensure that the message template is SWIFT-compliant. By sending a sample
message across the SWIFT network, the sender
will quickly know whether the message meets the
SWIFT denition guidelines. If the message is not
compliant, a NACK (Negative Acknowledgement
Message) is returned. SWIFT applies charges for
messages that are not SWIFT-compliant. There-

Page 9

fore, this approach of dening message templates

and proving their compliance prior to testing variations of the template will save on cost (by avoiding charges) and testing effort (reduced rejection
messages).
4.2 UNDERSTANDING THE MX MESSAGE
STRUCTURE
The MX structure is very different from the MT
structure. In MX (ISO 20022), the structure is XMLbased. However, the MX standard also has a header record and then the main body of the message.
The header will include the Distinguished Name
(DN) of the sender and the receiver, a unique message ID and the service being used.
The DN is used in the same way as a BIC in ISO
15022. An example is: ou=abc, o=bankbebb, o=swift,
in which bankbebb is the eight-character BIC, and
the other elements form the optional extension.
This extension allows a detailed identication by
department, geographical location, application, or
individual. The following is a sample header:

<Header>
<Message>
<MessageIdentier>MESSAGE ID</MessageIdentier>
<Format>MX</Format>
<Sender>
<DN>ou=example,o=aibkie2d,o=swift</DN>
</Sender>
<Receiver>
<DN>ou=funds,o=deutdeff,o=swift</DN>
</Receiver>
<NetworkInfo>
<Service>swift.if.ia!p</Service>
</NetworkInfo>
</Message>
</Header>

[Message ID: Sample MX setr.010.001.03]

[MX is used for 20022 messages]
[Sender of message details]

[Receiver of message details]

[This is the Test Service]

SWIFT Messaging

Page 10

Note: In ISO 20022, there are separate services

for live and test messages. swift.if.ia for product
network messages and swift.if.ia!p for test and
training messages.

Note: SWIFT provides a free tool called Simulation Testing and Qualication Service (STaQS)
Message Validation for verifying that MX messages are compliant. ('))

For each message type in MX, there is a dened

XML schema and Message Denition Report
(MDR) available from ISO. ('() The
TheMDR
MDRcontains
contains
the following information for each message type:
Message Functionality
Message Rules and Guidelines
Structure
Message Items Description
Business Example

4.3 SEQUENCING MESSAGES AND

LINKING

As with the MT standard, some information in

each MX message type is mandatory and some is
optional. Where the MT standard had sequences /
subsequences, the MX standard has what it refers
to as building blocks. In the MDR, the Outline
subsection under the Message Functionality section mentions which blocks are mandatory and
which are optional. The Structure section of the
MDR provides further detail on the available tags
within each block. As with XML, the MX standard
uses the slash / to signify the closing of a tag.
For example, <MsgId> opens the Message Identication tag and </MsgId> closes it.
The same lessons learned when testing the MT
standard should be applied when examining the
MX standard. The sender and receiver should:
Agree on the use of optional blocks and on
optional tags within mandatory blocks for each
message type under test;
Limit the scenarios for testing by agreeing on a
subset of the available options within the tags;
Remove the risk of sending multiple noncompliant messages by dening a template for
each message used and testing this template
before extending the test to all variations of the
template.

Once the message service(s), format(s) and types

have been agreed and the message templates
dened, the next key step to achieving STP is
to identify the message sequencing. The latter
should be aligned with the business scenarios /
processes the messaging is aiming to support.
Business analysts, or better still, members of the
current business-as-usual team(s) (e.g. operations
or product) should be closely involved in deciding on message sequencing. Thought should be
given to each business scenario and the sequence
of events. The tester can be useful in these discussions to ensure that even non-happy day scenarios are thought of:
What happens when an order is cancelled?
How does the messaging for a cancellation
work, i.e. are there additional messages?
What happens when an order is late or received after the cut-off time?
What happens when an order incurs a commission charge?
What happens when the order is for an asset /
fund not supported by the transfer agent it is
submitted to?
What happens when a payment has been made
for an order that is subsequently cancelled?

It is OK to begin with the common happy day

scenarios and start building from there, as long
as the other scenarios are not forgotten. Model
diagrams, like those in the documentation for ISO
20022, can be very useful for this purpose (see
Figure 4).

SWIFT Messaging

Instructing Party 1:
Financial Inst. Application

Page 11

Instructing Party 2:
Financial Inst. Application

Intermediary Party:
Financial Inst. Application

Executing Party:
Financial Inst. Application

Subscription Order

Subscription
Order

Subscription
Bulk Order

Request for Order

Status Report

Request for
Order Status
Report

Order
Instruction
Status Report

Order Instruction
Status Report

Figure 4: The use case Manage Order Status

In order to facilitate sequencing of messages,

it is necessary to understand how SWIFT messages are linked. In ISO 15022/MT, this is done
using the 20C::SEME from the original message
in the 20C::PREV or 20C::RELA elds (within
the optional linkage sequence) in follow-on
messages.

Figure 5 shows the interaction between a client

placing an order for a trade, and the transfer
agent responding to the order in the form of a
status update (MT509) and then an order conrmation (MT515). This example can become
even more complicated when further interaction
points are added.

SWIFT Messaging

Page 12

In ISO 20022/MX, a similar approach can be

adopted using <MsgId> from the original message
and linking to this using the <OthrRef> or <RltdRef> tags in follow-on messages.

one who is developing new capabilities around

ISO 20022 messaging but has not yet signed up a
potential client. However, testing would still have
to be repeated when on-boarding new clients.

The sequencing of messages becomes extremely

important when implementing STP (StraightThrough Processing). The ability to sequence the
messages in alignment with the agreed business
ows is critical to the success of any STP implementation.

4.4 STAYING SWIFT-COMPLIANT

Once all the hard work is done and an organisation achieves SWIFT compliance for its message
set, the next challenge is to stay compliant. SWIFT
makes annual updates to the MT standard, and
next year they are planning two updates to the
MX standard. Any organisation that adopts SWIFT
messaging should have a process in place to assess SWIFT updates and be in a position to test
any changes as they occur. In some cases, no updates are needed, but the assessment has to be
done every time an update to the message standard is released.

The STaQS tool from SWIFT can be used to test

message sequencing for ISO 20022 messages,
using its Business Order Flow Validation service.
This service does incur a charge. It allows users
to test the ow of messages over and back across
the SWIFT network simulating how it will happen
in the real world. This is a useful service for any-

1
MT502
20C::SEME//CL-01

TRANSFER
AGENT

2
MT509
20C::SEME//TA-01
20C::RELA//CL-01
3

CLIENT

Figure 5: Message sequencing example for MT

MT515
20C::SEME//TA-02
20C::RELA//CL-01

SWIFT Messaging

Page 13

4.5 MIGRATION FROM MT TO MX

SWIFT will begin to apply restrictions on the use

of MT fund templates.

The next big challenge facing the nancial services industry is the quest to achieve straightthrough processing and a fully automated solution to messaging.

The need to migrate is real and approaching fast.

SWIFT is offering incentives to users who migrate
early, as well as disincentives to users who are
slow to migrate. The growth in ISO 20022 fund
trafc has already begun (see Figure 6).

In 2001, the funds industry mandated SWIFT to

develop a set of message templates to be used for
the subscription / redemption process, leveraging the existing MT messages used for securities
transactions (MT502, MT509 and MT515). With
an eye on the future, in 2003 the funds industry
and SWIFT collaborated to develop a full set of
messages using the ISO 20022 standard. The aim
was to go beyond the order process and enable
the industry to automate and standardise the entire funds transaction ow including transfers,
statements, account management, price reports
and cash forecasts. ('*)

SWIFT provides documentation and support for

this process. While the mapping from an old MT
message type to a new MX message type helps, it
does not fully explain the nuances and differences
between the two catalogues of messages. For example, in the MT standard there is one message
type (MT502) for placing an order whether it is a
subscription, redemption or switch trade type. In
the MX standard, there are three separate message types (MX setr.010.001.03, setr.004.001.03
and setr.013.001.03), i.e. one for each trade type.

The migration to funds ISO 20022 has already

begun with the rst wave to be completed by the
end of 2012, when existing ISO 20022 fund users
must use MX messages with counterparties that
are ISO 20022 ready. The real deadline comes
with the second wave from January 2013, when

With regard to testing, the same rules apply for

the MX standard as for the MT standard. The format of the message templates should be agreed
between the sender and receiver. The options
within the message templates should also be
agreed, and limited where possible.

5.4 %

13.3 %

21 %

25 %

2008

2009

2010

YTD 2011
(May)

Figure 6: ISO 20022 volume versus total fund trafc volume on SWIFT ('+)

SWIFT Messaging

Page 14

5 CONCLUSION AND OUTLOOK

There is no doubting that SWIFT messaging is
very popular in the world of electronic messaging.
All signs are that its use will grow with the nancial service institutions and banks striving to reduce operational costs by increasing automation
in their communication with each other. Efforts to
achieve STP mean that there will be lots of testing
opportunities over the coming years.
The key testing messages in this paper hopefully
will help understand some of the potential pitfalls
and how to avoid them:
Familiarise yourself with the message standard
being tested and ensure you are aware of the
nuances in the message denition.
Agree on the use of the optional items (sequences, blocks, tags) within the standard and
document these in templates for each message type used.
Know the sequence of messages and link messages in a way that supports the business and
operational processes.
Stay SWIFT-compliant by keeping informed of
the changes to the message denitions, and
assess these updates against the message set
in use. Update respective templates and test
as required.
Organisations messaging in the funds industry
should act now and begin migration to the MX
standard.
Seek help and assistance from industry
experts and test professionals to de-risk the
introduction of messaging and achieve the ROI
that successful implementation can bring.

SQS has been working with many of the major

banks and nancial services institutions across
Europe to assist them with their SWIFT messaging projects. The software specialists experience
in software testing and quality assurance for the
entire range from simple messaging projects
through to the more complicated ones means
that SQS is ideally positioned to help organisations with the next challenges of messaging with
their clients.

Bibliographical References

'

SWIFT. About SWIFT History. SWIFT. [Online] 2011. http://www.swift.com/

about_swift/company_information/swift_history.page?lang=en.

Kjell Nordgard. Straight-Through-Processing: Prot through efciency. Jour nal of Financial Services Technology. [Online] 2007. http://www.jfst.com.au/
author/10656209.

ISO. About ISO. International Organization for Standardization. [Online] 2011.

http://www.iso.org/iso/about.htm.

4 SWIFT. IBAN Registry. SWIFT. [Online] 2011. http://www.swift.com/dsp/re sources/documents/IBAN_Registry.pdf.

+

ANNA.
ANNA.ISINs
ISINs&&ISO
ISO6166.
6166.ANNA
ANNA(Association
(Associationof
ofNational
NationalNumbering
NumberingAgenAgencies). [Online] 2011. http://www.anna-web.com/index.php/home/isinsaiso6166.

, Investopedia. CUSIP Number. Investopedia. [Online] 2011. http://www.investopedia.com/terms/c/cusipnumber.asp.

-

SWIFT. Messaging Services. SWIFT. [Online] 2011. http://www.swift.com/dsp/

resources/documents/factsheet_messaging_services.pdf.

. Jeff Roster. IT Spend by Industry Worldwide. Gartner Blogs. [Online] 2009.

http://blogs.gartner.com/jeff_roster/2009/02/11/it-spend-by-industry-worldwide/.
/ Gartner. Enterprise IT Spending by Vertical Industry Market, Worldwide,
2009 2015, 3Q11 Update. Gartner. [Online] 2011. http://www.gartner.com/
technology/research/it-spending-forecast/.
'& SWIFT.
SWIFT.About
AboutSWIFT
SWIFT Company
CompanyInformation.
Information.SWIFT.
SWIFT.[Online]
[Online]2011.
2011.http://
http://
www.swift.com/about_swift/company_information/index.page?lang=en.
''

Trace Financial Limited. Transformer and SWIFT MT Messages. Trace

Financial Limited. [Online] 2011. http://www.tracenancial.com/hres/transformer%20and%20swift%20mt%20messages.pdf.

'(

ISO. Catalogue of ISO 20022 Messages. ISO 20022. [Online] 2011. http://
www.iso20022.org/catalogue_of_uni_messages.page.

')

SWIFT. SWIFT STaQS for Funds. SWIFT. [Online] 2011. www.swift.com/solutions/solutions/funds/SWIFT_STaQSforFunds.pdf.

Page 15

Bibliographical References

'* Funds ISO 20022 Migration: The industry moves towards a full messaging
solution. SWIFT. [Online] 2011. http://www.swift.com/solutions/funds/documents/SWIFT_InfoPaper_Funds_Migration.pdf.
'+ Migration to ISO 20022. SWIFT. [Online] 2011. http://www.swift.com/solutions/funds/migration.page.

Page 16

SQS Software Quality Systems AG

Phone: +49 (0)2203 9154-0
Stollwerckstrasse 11
51149 Cologne / Germany
www.sqs.com