You are on page 1of 27

Collectively, Progress has over 25 years' experience of S.W.I.F.T.

by virtue of involvement in

the design and implementation of S.W.I.F.T. integration solutions for major banking, broking

and fund management firms. We have worked on over 100 S.W.I.F.T. related projects in 22

countries and had experience of integrating with most of the common interfaces. Having

worked closely with both end-users and IT strategists to define the most effective way of

linking disparate back-office environments into the S.W.I.F.T. network, we are well qualified

to assist and advise not just on S.W.I.F.T., but on any similar requirement involving

integration with external networks. The rest of this page gives a short description of the

network itself, describes the message structures, some history and acronym context, and

discusses some of the integration issues.

If you're reading this to understand the background to S.W.I.F.T FIN message formats to

write your own message parsers, then we invite you to read our White Paper on "Just how

hard can it be to write your own SWIFT parser?" You should be able to knock one up in a

week or so no trouble right? Wrong!

What is S.W.I.F.T.?

The acronym stands for Society for Worldwide Interbank Financial Telecommunications.

S.W.I.F.T. is a co-operative society. According to Article 3 of its Articles of Association.

"The object of the Company is for the collective benefit of the Members of the Company, the

study, creation, utilisation and operation of the means necessary for the telecommunication,

transmission and routing of private, confidential and proprietary financial messages"

The Society's headquarters are situated in La Hulpe, on the outskirts of Brussels. S.W.I.F.T.

also acts as a United Nations sanctioned International Standards Body (ISO) for the creation

and maintenance of financial messaging standards.

S.W.I.F.T. was formed when seven Major International Banks met in 1974 to discuss the

limitations of Telex as a means of secure delivery of payment and confirmation information,

primarily in the Treasury and Correspondent banking areas. Telex suffered from a number of

limitations due to its speed (50 Baud or approximately 8 bytes per second), its free format

(that made automation at the receiving end almost impossible), and the lack of security,

with Testkeys only being calculated on a subset of the message content.


The decision was taken at that time to form the society and three years later in 1977, 230

banks in 5 countries went live. New countries and users were and indeed still are, added 4

times a year with recent figures showing over 184 countries and 6700 institutions

connected.

Over the years message type coverage has been greatly expanded to cover a much greater

range of financial transactions, and new message types are added to the system once a

year between September and November. The original network was superseded by an X.25

based network in 1990 to cope with the increasing message volumes which now stand at

around 3,000,000 per day. Uniquely, S.W.I.F.T. take full liability for each message once they

have accepted it, and it is probably this linked to the inbuilt security and robustness of the

network (consistently better than 99.99% up time every year) that has led to S.W.I.F.T.'s

dominant position in the market.

Who uses S.W.I.F.T.?

Although originally the network was designed to support the requirements of Treasury and

Correspondent banking operations, it has over the years allowed other institutions access to

the services, albeit in some cases only to a limited degree. Currently the following

categories of organisation can access the service:

• Banks
• Trading Institutions
• Money Brokers
• Securities Broker Dealers
• Investment Management Institutions
• Clearing Systems and Central Depositories
• Recognised Exchanges
• Trust and Fiduciary Service Companies
• Subsidiary Providers of Custody and Nominees
• Treasury Counterparties
• Treasury ETC Service Providers

The Society is owned by its Members, and in order to become one the organisation must

hold a Banking Licence. In return Members own shares in the society and have voting rights.
There are a further two classes of user. Sub - members must be >90% owned by member

and are typically branches. Whilst they have full access to the system they do not have

voting rights or shares. Participants are usually other types of financial institution, and they

have access to a limited set of messages and no ownership.

All classes of member pay an initial joining fee and an annual support charge, although the

amounts differ for each class.

In addition users are charged on a per message basis by Unit lengths of 325 or 1950

characters dependant on message type. The charges also vary depending on Volume tier

and Route with the amounts reducing for high volume users and those messages passing

along the most common routes such as U.K. to U.S.A..

The pricing is calculated to cover all of S.W.I.F.T.'s costs and investments with users then

receiving regular rebates after these are finalised.

S.W.I.F.T. services

S.W.I.F.T. operates a number of services, primarily:

GPA General Purpose Application, which only allows system messages, i.e.. messages from a
user to S.W.I.F.T. and vice versa, not from one user to another
FIN Financial Application, which is the user to user service comprising, System Messages
MT0nn, User to User Messages MT1nn through 9nn and Service Messages such as
Acknowledgements

Additionally, S.W.I.F.T. provide a number of services that are charged for over and above the

normal fees. In summary these are:

IFT (Interbank File For bulk file transfer of messages, for example low net value, high volume
Transfer) Retail payments
ACCORD A centralised confirmation matching bureau service
Directory Services An automated and centralised Standard Settlement Instruction service for
message enrichment that at present is limited to Treasury and Payment
information
RTGS (Y-copy) Mostly used for sending a copy of a message or parts thereof to a third party,
for example a Central Bank
Country Specific (e.g. Where S.W.I.F.T.are either the carrier of the messages or the supplier of
CREST, CHAPSEuro) additional network services

How does S.W.I.F.T. work?


The S.W.I.F.T. network has an architecture that supports the requirements for a fully

redundant 24 x 7 secure operation that is also highly scalable.

There are a number of components to this X.25 protocol based packet switched network.

The System Control Processors are responsible for the operation of the entire system. This

includes:

• Session Management
• Software and database distribution
• Monitoring all S.W.I.F.T. hardware and software
• Failure diagnostics and recovery
• Dynamic allocation of system resources.

These are located at Operating Centres, 2 in the US centre and 2 at the centre in the

Netherlands.

The Slice Processors are responsible for:

• routing and safe storage of messages & history


• safestore Acknowledgements to Regional Processors
• generation of reports
• delivery and non delivery messages
• processing retrievals and system messages
• archiving, billing and statistics.

All messages are safestored on two media. The SP's are located in the operating centres.

The Regional Processors are the entry and exit point to S.W.I.F.T. and they support Leased

line, Dial up or Public Data Network connection. The most common method is primary

leased line with dial-up backup. They are usually in same country as the user and provide

sequence number checking and message validation, temporary safestorage, generation of

Positive and Negative Acknowledgements and verification of checksums


A Computer Based Terminal (CBT) that is also referred to as a S.W.I.F.T. interface is then

located at each user site. These terminals support the connectivity to the local regional

processor and facilitate both manual entry of messages and the bridge to originating

applications. Some more detail on the latter facility will be covered later. There are many

vendors of these interface devices although S.W.I.F.T. themselves have by far the largest

market share. The following is a list of some of the more common ones. A full list can be

provided by S.W.I.F.T.:

Vendors CBT
S.W.I.F.T. Alliance Access (NT and Unix)
S.W.I.F.T. Alliance Entry (NT)
S.W.I.F.T. ST400 (VMS)
IBM Merva/ESA (Mainframe)
IBM(S.W.I.F.T.) Merva/2 (OS/2)
IBM(S.W.I.F.T.) Merva/AIX (AIX)
Logica Fastwire (Unix)
Logica Bess (Tandem)
Mint Mint
Netik TurboSWIFT (NT and Unix)

The diagram below shows the high level architecture.


As stated above, access to the network is via the CBT and Smart Card technology is used to

access secure functions. Many functions require dual user and password input.

Initially a User will LOGIN to the GPA service and receive a GPA Acknowledgement. The User

then SELECTS the application or service that they wish to use, for example FIN. The user can

then send FIN messages to other users and the Regional Processor will either send back a

Positive (ACK) or Negative (NAK) acknowlegement for each message after having safestored

it.

The session then remains open for sending and receiving messages until the User QUITS.

The Fin service will acknowledge this before the User LOGOUT is selected. It is a

requirement of S.W.I.F.T. that the CBT is logged in to at least receive messages for at least 7

hours per business day. All of the terms in upper case represent messages.

S.W.I.F.T. addresses

S.W.I.F.T. addresses are used to not only indicate the final destination of the message but to

also indicate parties within the individual message. It is the use of strictly codified addresses

that enables the automation of Straight Through Processing in conjunction with the fixed tag

format of the messages themselves. The term "S.W.I.F.T. address" actually only relates to a

subset of Bank Identifier Codes (BICs), in other words you do not have to be a user of the

S.W.I.F.T. network to have a BIC and these can therefore be used over other networks such

as Telex. S.W.I.F.T. are, however, the recognised ISO (International Standards Organisation)

body for assigning these.

The following shows the general format of a BIC address.

AAAA BB CC (D) (EEE)


Bank Country Location LT Branch

The first four characters represent the Bank code, for example NWBK (NatWest), DEUT

(Deutsche Bank).

The next two characters represent the ISO Country code, for example GB (United Kingdom),

DE (Germany).

The next two characters are the location code with some larger financial centres such as

London and New York having two, 2L and 22, 33 and 3N respectively.

These characters, the first 8, represent the mandatory portions and commonly within the

body of a message this will be the normal format, for example NWBKGB2L (NatWest

London), DEUTDEFF (Deutsche Bank Frankfurt).

The presence of 0 (zero) in position 8 indicates that this is a test & training address. Test &

Training is a facility which S.W.I.F.T. gives its users to test new releases without interfering

with live operations. When an organisation first joins S.W.I.F.T. they must spend two months

sending messages in test & training before they are allowed to go live. S.W.I.F.T. monitor

this!

Optionally a three character branch code can be added at the end of the address. For

example NWBKGB2LBIR might be the Birmingham branch. These codes are primarily used

for internal routing purposes within the bank, as the branches themselves do not have direct

connection. Usage is often more common in some countries than others such as the heavy

use by Italian banks.

The Logical Terminal ID in position 9 will be present in the header of the message and

identifies a logical channel connection to S.W.I.F.T.. Some organisations may run more than

1 LT on the same CBT and these will be referred to as A, B, C, etc. For example

NWBKGB2LA. These are not published in the BIC directory and so all addresses within a

message identifying the sender or other parties will not contain this character.
LTs will therefore always be padded out to 12 Characters by X's and S.W.I.F.T. addresses are

therefore either 8 or 11 characters.

The presence of a 1 in position 8 denotes that this is not a S.W.I.F.T. address but the

organisation has requested that an ISO identifier be allocated to them. For example

NWBKGB21. Therefore, this address can be included in the body of a message but you

cannot send a message via S.W.I.F.T. to them.

The presence of an X in position 8 denotes that the CBT which is processing traffic for this

address is not physically in the same country as the Country Code states.

S.W.I.F.T. FIN MT messages

S.W.I.F.T. messages are identified in a consistent manner. They all start with the literal "MT"

which denotes Message Type. This is then followed by a 3 digit number. The first digit

represents the Category. A category denotes messages grouped together because they all

relate to particular financial instruments or services. The full list is as follows:

MT0nn System Messages


MT1nn Customer Payments
MT2nn Financial Institution Transfers
MT3nn FX, Money Market & Derivatives
MT4nn Collections and cash letters
MT5nn Securities Markets
MT6nn Precious Metals & Syndications
MT7nn Documentary Credits & Guarantees
MT8nn Travellers Cheques
MT9nn Cash Management & Customer Status

The second digit represents the Group denoting that the messages are related to similar

parts of a transaction's lifecycle. For example:

MT200 Financial Institution Transfer, Own Account


MT202 Financial Institution Transfer, Third Party
MT521 Receive (Securities) Against Payment
MT523 Deliver (Securities) Against Payment

The last digit is the Type and denotes the individual message. There are several hundred

message types across the categories in total.


A special subset of Messages is known as the Common Group because the last two digits

represent the same message in each category. For example:

MTn99 Free format


MT299 Free format relating to transfers
MT599 Free format relating to securities
MT999 General free format

Other common group messages are:

MTn90 Advice of charges, interest, etc


MTn91 Request for Payment of Charges, etc
MTn92 Request for Cancellation
MTn93 Directory Services
MTn95 Query
MTn96 Answer
MTn98 Proprietary Message Envelope

Each message is assigned unique identifiers. A 4 digit session number is assigned each time

the CBT logs in. Each message is then assigned a 6 digit sequence number. These are then

combined to form an ISN (Input Sequence Number) from the CBT to S.W.I.F.T. or an OSN

(Output Sequence Number) from S.W.I.F.T. to the CBT. It is important to remember that

terminology is always from the perspective of S.W.I.F.T. and not the user.

The Logical Terminal Address (12 character BIC), Day, Session and Sequence numbers

combine to form the MIR Message Input Reference and MOR Message Output Reference

respectively.

SWIFT MT message structure

We will concentrate on the structure of FIN messages as they are by far the most important

for the end user. They have the following general structure:

{1: Basic Header Block}

{2: Application Header Block}

{3: User Header Block}

{4: Text Block or body}

{5: Trailer Block}


Blocks 3, 4 and 5 may contain sub blocks or fields delimited by field tags.

Block 3 is optional. Many applications, however, populate this with a reference number so

that when the Acknowledgement is returned by S.W.I.F.T. it can be used for reconciliation

purposes.

{1: Basic Header Block}

The Basic header block has the following format:

{1: F 01 BANKBEBB 2222 123456}

(a) (b) (c) (d) (e) (f)

Fixed Length, continuous with no field separators

a) Block ID - always '1:'

b) Application ID - F = FIN, A = GPA or L = GPA (logins, etc)

c) Service ID - 01 = FIN/GPA, 21 = ACK/NAK


d) LT address - 12 Characters, must not have 'X' in position 9

e) Session number - added by the CBT, padded with zeroes

f) Sequence number - added by the CBT, padded with zeroes

{2: Application Header Block}

The application header has a different format depending on whether it is being sent to or

from S.W.I.F.T..>/p>

The Input (to S.W.I.F.T.) structure is as follows:

{2: I 100 BANKDEFFXXXX U 3 003}

(a) (b) (c) (d) (e) (f) (g)

Fixed Length, continuous with no field separators From user to S.W.I.F.T.

a) Block ID - always '2:'


b) I = Input

c) Message Type

d) Receivers address with X in position 9 and padded with X's if no branch

e) Message Priority - S = System, N = Normal, U = Urgent

f) Delivery Monitoring - 1 = Non Delivery Warning (MT010)

2 = Delivery Notification (MT011)

3 = Both Valid = U1 or U3, N2 or just N


g) Obsolescence Period - when a non delivery notification is generated

Valid for U = 003 (15 minutes)

Valid for N = 020 (100 minutes)

The Output (from S.W.I.F.T.) structure is as follows:

{2: O 100 1200 970103BANKBEBBAXXX2222123456 970103 1201 N}

(a) (b) (c) (d) (e) (f) (g) (h)

Fixed Length, continuous with no field separators From S.W.I.F.T. to user

a) Block ID - always '2:'

b) O = Output
c) Message Type

d) Input time with respect to the Sender

e) MIR with Senders address

f) Output date with respect to Receiver

g) Message priority

{3: User Header Block}

This has the following structure:

{3: {113:xxxx} {108:abcdefgh12345678} }

(a) (b) ( c)
This is an optional block and is similar in structure to system messages.

a) Block ID - always '3:'

b) Optional banking priority code

c) Message User Reference MUR used by applications for reconciliation with ACK

Other tags exist such as 119 which can contain the code ISITC on an MT521 or 523 providing

the sender and receiver are registered to do so with S.W.I.F.T.. This forces additional code

word and formatting rules validation of the body of the message as laid down by ISITC

(Industry Standardisation for Institutional Trade Communication).

{4: Text Block or body}

This block is where the actual MTnnn message is specified and is what most users will see.

Generally the other blocks are stripped off before presentation. The format is as follows:

{4:<CrLf>

:20:PAYREFTB54302<CrLf>
:32A:970103BEF1000000,<CrLf>

:50:CUSTOMER NAME<CrLf>

AND ADDRESS<CrLf>

:59:/123-456-789<CrLf>

BENEFICIARY NAME<CrLf>

AND ADDRESS<CrLf>

-}
The symbol <CrLf> is a control character and represents Carriage Return/Line Feed (0D0A

in ASCII hex, 0D25 in EBCDIC hex). It is a mandatory delimiter in block 4.

The example above is an MT100, Customer Transfer with only the mandatory fields

completed. Fields must be in the order as specified in the appropriate volume of the user

handbook, there is one or more for each message category. It is an example of the format of

an ISO7775 message structure. These are gradually being replaced by the newer data

dictionary standard ISO15022 messages discussed later.

The format of field tags is:

:nna:

nn - numbers

a - optional letter which may be present on selected tags


eg - :20: Transaction Reference Number

:58A: Beneficiary Bank

The length of a field is designated thus:

nn - maximum length

nn! - fixed length


nn-nn - minimum and maximum length

nn * nn - max number of lines times max

line length

The format of the data is designated thus:

n - Digits

d - Digits with decimal comma

h - Uppercase hexadecimal

a - Uppercase letters
c - Uppercase alphanumeric

e - Space

x - S.W.I.F.T. character set

y - Upper case level A ISO 9735 characters

z - S.W.I.F.T. extended character set

Some fields are defined as optional and if not required they must not be present as no blank

fields must be present in the message.

/,word - Characters as-is

[â?¦] - optional element


For example:

4!c[/30x] - fixed 4 uppercase alphanumeric, optionally followed by a slash

and up to 30 S.W.I.F.T. characters

ISIN1!e12!c - code word followed by a space and fixed 12 uppercase alphanumerics

In some message types certain fields will be defined as conditional, i.e. if a certain field is

present then another field may change from optional to mandatory or forbidden. Certain

fields may contain sub fields in which case there is no CrLf between them.

Certain fields have different formats dependant on the option which is chosen, which is

designated by a letter after the tag number, for example:

:32A:000718GBP1000000,00 Value Date, ISO Currency and Amount

:32B:GBP1000000,00 ISO Currency and Amount


It is important to note that the S.W.I.F.T. standards for Amount formats are, no thousand

separators and a comma for a decimal separator.

:58A:NWBKGB2L Beneficiary S.W.I.F.T. address

:58D:NatWest Bank Beneficiary full name and address

Head Office

London

{5: Trailer Block}

A message always ends in a trailer with the following format:

{5: {MAC:12345678}{CHK:123456789ABC}

It contains a number of fields that are denoted by keywords such as:


MAC: Message Authentication Code calculated based on the entire contents of the message

using a key that has been exchanged with the destination and a secret algorithm. Found on

message categories 1,2,4,5,7,8, Most 6's and the 304.

CHK: Checksum calculated for all message types

PDE: Possible Duplicate Emission added if user thinks that they may have sent the message

previously

PDM: Possible Duplicate Message added by S.W.I.F.T. if they think that a message may have

been transmitted previously.

DLM: Added by S.W.I.F.T. if an Urgent message has not been delivered within 15 minutes or

a Normal message within 100 minutes.

ISO 7775, 15022, 20022/UNIFI history and current SWIFT MT and MX standards

In the late 1990's S.W.I.F.T. realised that the original ISO7775 messages were too restrictive,

did not reflect the full complexity of modern trading instruments and were still too

ambiguous to ensure that full Straight Through Processing could be achieved.

Thus was born the ISO15022 standard based on a data dictionary approach. Initially (in

1997) these were applied to the Securities message category as this represented the fastest

growing usage of the network. Old message types were replaced and many new ones

introduced. Trade Initiation and Confirmation messages were introduced in 1997 and

Settlement and Reconciliation in 1998. There was no standards release in 1999 due to Y2K

distractions, and the old message types were removed from the network in 2002.

It is still common for the original ISO7775 message types to be used for "off net" messaging

outside of the S.W.I.F.T. network. Typically older legacy applications may generate or

consume these message stuctures, and some firms private networks utilise specialised

versions of these messages.


The major difference between ISO7775 and ISO15022 is in the structure of the tagged data

in block 4 (note that all other blocks are unaffected). ISO15022 introduced the concept of

Generic Fields. This is aimed at uniquely identifying information. In the previous ISO7775

messages the same tag could appear in a number of message types but with a different

meaning. ISO15022 removes this ambiguity by imposing the following structure.

Field Tag Field Format

:2n1a: :4a/8a/data

Where:

: Identifies the field as generic


4a Qualifier differentiates the business purpose of of the tag
/ Mandatory delimiter
8a Issuer code, when not S.W.I.F.T. defined these can contain market codes such as DTCY or CREST
/ Mandatory delimiter
data The contents of the field

For example:

Field Tag Qualifier Explanation


98a TRAD Trade date
Date/Time SETT Settlement date
generic field VALU Value date

The ISO15022 messages also introduced much more complexity with the concept of many

iterating repeating groups. These groups in turn can be nested and designated as

mandatory, optional or conditional. For example, :16R: Denotes start of a block or sequence,

:16S: Denotes end of a block or sequence, therefore 16R with contents SETPRTY denotes the

start of the Settlement Parties Sequence. 16S with SETPRTY denotes the end.

With the evolution of XML technology in the late 1990's work began on what was called

ISO15022 2nd Edition (also known as SWIFTML or SWIFT XML). This evolved into ISO20022

using an enhanced approach to standards based on business entity interaction behavioral

models and XML Schema based message data models for the transactional messages

supporting these models. The ISO20022 standard has further evolved to incorporate lessons

from the first implementations of ISO20022 Funds messages, FpML, FIX, ACCORD, MDDL and
others providing examples of successful best practice for ISO20022 to converge with. ISO

has published a series of standards such as ISO 15000 ebXML that overall ISO standards

should become consistent with.

In 2004 a significant increase in scope was agreed for ISO20022, it was rebranded the

"ISO20022 - UNIversal Financial Industry (UNIFI) message scheme", and expanded from

Securities and related financial instruments to the broader scope of all Financial Services.

Ownership of the standard itself moved to ISO/TC68 (the Financial Service technical

committee) from its SC4 (Securities and Related Financial Instruments sub-committee).

TC68 created WG4 (Working Group Four), to revise ISO20022.

SWIFT then assumed the role of the Registration Authority (RA) for the ISO20022/UNIFI

standards with responsibility to ensure compliance of developed Repository items with the

approved technical specifications and to publish the Financial Repository

on www.iso20022.org, on behalf of ISO.

SWIFT also introduced, or in the case of SWIFTNet Funds reintroduced, the "SWIFTNet

Solutions" products and standards covering specific business domains. The SWIFT

implementations of the ISO20022/UNIFI standards became known as the MX standards as

compared to the older SWIFT FIN standards being the MT standards. The SWIFT MX

Standards are conceptually the same as the ISO15022 standards, in that the respective ISO

standard specifies the message payload and then wraps this inside SWIFT specific

header/footer envelope. For example the SWIFT FIN MT541 block 4 body part is the

ISO15022 standard, while the complete MT541 with blocks 1,2,3 and 5 is...well...the MT541.

Similarly the SWIFT MX messages wrap the ISO20022/UNIFI payload or body inside the

SWIFTNet Solution Application header and the SWIFTAlliance envelope.

The further developments of the ISO20022/UNIFI standards, their technical convergence

with other standards, and the implementations in which they are used such as SWIFT MX,

TWIST, the Single European Payments Area (SEPA) are active areas of ongoing IONA

development and participation with the standardisers themselves. We remain very much

involved in meeting the requirements of the consumers of these standards.


The Artix Data Services technology is designed to bridge from the historical legacy

standards, to the current, and the next, all based on the same open model driven

integration approach.

What are the integration issues?

Most users of S.W.I.F.T. have operations large enough in terms of transactional volumes that

the manual keying of data is not viable, even if the potential for human error is ignored. The

main challenge for organisations is therefore how best to automate the process. This

broadly speaking involves two main areas. Firstly how do you physically gain access to the

transactional data that underlies the message, in other words what is the transport going to

be. Secondly, how best to format the data.

The selection of transport will often be dictated by a number of variables.

• What the Interface Vendor supports


• Proprietary protocols and API's such as Alliance Developer Kit
• Standard protocols such as File transfer, FTP, IBM MQ Series
• Access to application source code
• Security
• Reliability
• Throughput
• Scalability
• Ability to support
• On going maintenance

The approach to the automation of the process will also be driven by many variables:

• How many applications need to be interfaced?


• Should the applications be S.W.I.F.T. enabled?
• Should an Integration Broker approach be adopted?
• Who is going to maintain the message formats as they change?
• Is all of the data required available in one place or not?
• Are settlement instructions held in each application or centrally?
• What reformating is required?
• What enrichment is required?
• How easy is it going to be to replace existing systems?
• How easy is it going to be to add new existing systems?
• What will be the impact of merger and acquisition activity?
• What reconciliation tasks can be automated and how?
• What matching tasks can be automated and how?
• How can exceptions be handled?
• How can other delivery channels be supported by the same architecture?
• What message types should be automated by cost justification?
• Is there a need to adopt other standards such as SMPG best practice rules?
• What are my exception monitoring requirements?
• Is there a requirement for a transaction lifecycle monitor?
• What are the Audit trail requirements?
• Does statistical information need to be collated?
• How should ACKs and NAKs be processed?
• How should MT010, MT011 and MT019 messages be processed?

You might also like