What is SWIFT?

The acronym stands for Society for Worldwide Interbank Financial Telecommunications. SWIFT 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. SWIFT also acts as a United Nations sanctioned International Standards Body (ISO) for the creation and maintenance of financial messaging standards.

SWIFT 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 200 countries and more than 11,000 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 in November. The original network was superseded by an X.25 based network in 1990 to cope with the increasing message volumes, and in the early 2000’s the X.25 network was replaced by an IP based network known as SWIFTNet. The average daily network traffic in the full year 2020 was 37.7 million messages. About half of this traffic is for payment messages and half for securities messages.

Uniquely, SWIFT take full liability for each message once they have accepted it, and it is probably this fact, linked to the inbuilt security and robustness of the network (consistently better than 99.999% up-time every year), that has led to SWIFT's dominant position in the market.

Who uses SWIFT?

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 types of organisations 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
• Corporates

The Society is owned by its Members, and in order to become one the organisation must hold a Banking License. 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 a 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 institutions, and they have access to a limited set of messages and no ownership rights.

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, 750, or 1950 characters dependent on message type. The charges also vary depending on volume tier.

The pricing is calculated to cover all of SWIFT's costs and investments with users then receiving regular rebates after these are finalised.

SWIFT Services

SWIFT operates a number of services, primarily:

• GPA - General Purpose Application, which only allows system messages, i.e. messages from a user to SWIFT 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, SWIFT provides a number of services that are charged for over and above the normal fees. A few of these are:

• IFT (Interbank File Transfer) -For bulk file transfer of messages, for example low net value, high volume 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. CREST, CHAPSEuro) - Where SWIFT are either the carrier of the messages or the supplier of additional network services.

How does SWIFT work?

The SWIFT network has an architecture that supports the requirements for a fully redundant 24x7 secure operation that is also highly scalable. There are a number of components to this network.

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

• Session Management
• Software and database distribution
• Monitoring all SWIFT 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
• Safe-store Acknowledgements to Regional Processors
• Generation of reports
• Delivery and non delivery messages
• Processing retrievals and system messages
• Archiving, billing and statistics

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

The Regional Processors are the entry and exit point to SWIFT 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 the same country as the user and provide sequence number checking and message validation, temporary safe-storage, generation of Positive and Negative Acknowledgements and verification of checksums.

A Computer Based Terminal (CBT) that is also referred to as a SWIFT 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 SWIFT themselves have by far the largest market share. The following is a list of some of the more common ones. A full list is available at www.swift.com:

Vendors and CBT

• SWIFT - Alliance Access (Windows and Unix)
• SWIFT - Alliance Entry (Windows)
• IBM - Merva/ESA (Mainframe)
• Logica - Fastwire (Unix)
• Logica - Bess (Tandem)
• Mint - Mint
• Netik - TurboSWIFT (Windows and Unix)

The diagram below shows the high level architecture. (source: www.swift.com)

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) acknowledgement for each message after having safe-stored 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 SWIFT 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.

SWIFT Addresses

SWIFT addresses are used to not only indicate the final destination of the message but to also identify 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 (FIN) messages themselves. The term "SWIFT address" actually only relates to a subset of Business (formerly “Bank”) Identifier Codes (BICs), in other words you do not have to be a user of the SWIFT network to have a BIC and these can therefore be used over other networks. The BIC is an ISO standard, ISO9362, and SWIFT is 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 more than one, 2L and 22, 33 and 3N respectively.
• These characters, the first 8 (commonly referred to as BIC-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 provided by SWIFT to give its users to test new releases without interfering with live operations. When an organisation first joins SWIFT they must spend two months sending messages in test & training before they are allowed to go live. SWIFT monitors this!
• Optionally a three character branch code can be added at the end of the address. The BIC-8 plus the branch code is commonly referred to as the BIC-11. For example NWBKGB2BIR 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 SWIFT. SWIFT uses this for network addressing purposes; it is not part of the ISO9362 standard. 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 SWIFT addresses are therefore either 8 or 11 characters.
• The presence of a 1 in position 8 denotes that this is not a SWIFT 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 SWIFT to them.

SWIFT FIN MT Messages

SWIFT FIN messages are identified in a consistent manner. They all start with the literal "MT" which denotes Message Type. A 3-digit number then follows this. 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:

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:

Other common group messages are:

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 SWIFT or an OSN (Output Sequence Number) from SWIFT to the CBT. It is important to remember that terminology is always from the perspective of SWIFT 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 SWIFT it can be used for reconciliation purposes.

{1: Basic Header Block}

The Basic header block has the following format and is fixed length and continuous with no field separators:

{2: Application Header Block}

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

The Input (to SWIFT) structure is as follows is fixed length and continuous with no field separators:

The Output (from SWIFT) structure is as follows is fixed length and continuous with no field separators:

{3: User Header Block}

This has the following structure:

NOTE : In the MT Standards Release for 2018, header block 3 became mandatory for the following messages - MT 103, MT 103 REMIT, MT 103 STP, MT 202, MT 202 COV, MT 205 and MT 205 COV - and must contain field 121 Unique End-to-end Transaction Reference (UETR) in all messages. A UETR is a string of 36 unique characters featured in all payment instruction messages carried over SWIFT. UETRs are designed to act as a single source of truth for a payment and provide complete transparency for all parties in a payment chain, as well as enabling functionality from SWIFT gpi, such as the Payment Tracker (covered elsewhere).

{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:8861198-0706:<CrLf>
:23B:CRED:<CrLf>
:32A:000612USD5443,99:<CrLf>
:33B:USD5443,99:<CrLf>
:50K:GIAN ANGELO IMPORTS:<CrLf>
NAPLES:<CrLf>
:52A:BCITITMM500:<CrLf>
:53A:BCITUS33:<CrLf>
:54A:IRVTUS3N:<CrLf>
:57A:BNPAFRPPGRE:<CrLf>
:59F:/20041010050500001M02606:<CrLf>
1/DEPT OF PROMOTION OF SPICY FISH:<CrLf>
1/CENTER FOR INTERNATIONALISATION:<CrLf>
1/OF COMMERCE AND BUSINESS:<CrLf>
3/CN:<CrLf>
:70:/RFB/INVOICE 559661:<CrLf>
:71A:SHA:<CrLf>
:72:/ABCD/narrative:<CrLf>
//more narrative:<CrLf>
/EFGH/narrative:<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 MT103, Single Customer Credit Transfer. 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. The MT103 shown is an example of the format of an ISO 7775 message structure. These are gradually being replaced by the newer data dictionary standard ISO 15022 messages discussed later – and ultimately by the ISO 20022 standard (see separate paper).

The format of field tags is :nna: where

• nn - numbers
• a - optional letter which may be present on selected tags

e.g.

• :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 - SWIFT character set
• y - Upper case level A ISO 9735 characters
• z - SWIFT 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

e.g.

• 4!c[/30x] - fixed 4 uppercase alphanumeric, optionally followed by a slash and up to 30 SWIFT 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 dependent 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 SWIFT standards for Amount formats are, no thousand separators and a comma for a decimal separator.

Another example is field 58 that can appear with option A (BIC) or option D (name and address):

• :58A:NWBKGB2L - Beneficiary SWIFT 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.

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 SWIFT if they think that a message may have been transmitted previously
• DLM: Added by SWIFT if an Urgent message has not been delivered within 15 minutes or a Normal message within 100 minutes

ISO 7775, 15022, 20022 History and Current SWIFT MT and MX Standards

In the late 1990's SWIFT realised that the original ISO 7775 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 ISO 15022 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 ISO 7775 message types to be used for "off net" messaging outside of the SWIFT network. Typically, older legacy applications may generate or consume these message structures, and some firms’ private networks utilise specialised versions of these messages.

The major difference between ISO 7775 and ISO 15022 is in the structure of the tagged data in block 4 (note that all other blocks are unaffected). ISO 15022 introduced the concept of Generic Fields. This is aimed at uniquely identifying information. In the previous ISO 7775 messages the same tag could appear in a number of message types but with a different meaning. ISO 15022 removes this ambiguity by imposing the following structure.

where

• : Identifies the field as generic
• 4a Qualifier differentiates the business purpose of of the tag
• / Mandatory delimiter
• 8a - Issuer code, when not SWIFT defined these can contain market codes such as DTCY or CREST
• /- Mandatory delimiter
• data - The contents of the field

For example:

The ISO 15022 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 ISO 15022 2nd Edition (also known as SWIFTML or SWIFT XML). This evolved into ISO 20022 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 ISO 20022 standard has further evolved to incorporate lessons from the first implementations of ISO 20022 Funds messages. FpML, FIX, ACCORD, MDDL and others providing examples of successful best practice for ISO 20022 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 ISO 20022. It was rebranded the "ISO 20022 - UNIversal Financial Industry (UNIFI) message scheme", now referred to as just “ISO 20022”, 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 ISO 20022.

SWIFT was selected for the role of the Registration Authority (RA) for the ISO 20022 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 ISO 20022 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 ISO 15022 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 ISO 15022 standard, while the complete MT541 with blocks 1,2,3 and 5 is...well...the MT541. Similarly the SWIFT MX messages wrap the ISO 20022 payload or body inside the SWIFTNet Solution Application header and the SWIFTAlliance envelope.

Further developments in the ISO 20022 standards, their technical convergence with other standards, and the implementations in which they are used such as SWIFT MX and the Single European Payments Area (SEPA) are active areas of interest, concern and involvement for Incept5.

What Are The SWIFT Integration Issues?

Most users of SWIFT 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 of developing, sending and receiving SWIFT messages. 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, e.g.

• 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
• Ongoing maintenance

The approach to the automation of the process will also be driven by many variables, e.g.

• How many applications need to be interfaced?
• Should the applications be SWIFT enabled?
• Should an Integration Broker or Service-Oriented Architecture (SOA) 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 reformatting 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 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?

The above is only the tip of the iceberg and the SWIFT messaging landscape continues to evolve. Incept5 can help you to understand, manage and address these issues.