Overview of SWIFT

SWIFT - Society for Worldwide Financial Telecommunication, a communication platform that allows members to connect and exchange financial messages securely and reliably. SWIFT acts as the catalyst that brings the financial community together to work collaboratively to share market practice, define standards and consider solutions to issues of mutual interest.

SWIFT - a member-owned cooperative through which the financial world conducts its business operations with speed, certainty and confidence.  SWIFT enables customers to automate and standardise financial transactions, thereby lowering costs, reducing operational risk, and eliminating inefficiencies from their operations.

SWIFT is solely a carrier of messages. It does not hold funds, nor does it manage accounts on behalf of its members, nor does it store financial information on an on-going basis. As a data carrier, SWIFT transports messages between two financial institutions. This activity involves the secure exchange of proprietary data while ensuring its confidentiality and integrity.

There are four key areas that SWIFT services fall under within the financial marketplace. They are Securities, Treasury and Derivatives, Trade Services, and Payments & Cash Management.

SWIFT, being a member-owned organisation, has two broad mandates. One is to provide a platform for exchange or control transactions between our members and their customers and the other, the mandate of setting the standard for the language with which people speak on that platform. SWIFT, on behalf of the international organisation of standardisation (ISO), supports and acts as a registration authority for a variety of financial standards. So, one is in the areas of security standards, and another is business identifier codes.

To summarise, SWIFT is a combination of three things:- 

• a community of financial institutions
• a network of the highest security and reliability
• a standard setting body for electronic financial messaging

SWIFT has its headquarters in Belgium and has offices in the world's major financial centres and developing markets. SWIFT was founded in the 1970s, based on the ambitious and innovative vision of creating a global financial messaging service, and a common language for international financial messaging.

Today, goods and services move more quickly and across greater distances than ever before, so value needs to move further and faster too. Towards that, SWIFT has designed standard message formats across transaction lifecycle.

SWIFT – History

SWIFT established itself in 1973 with 239 members in 15 countries and set up rules for security and reliability in 1975. Went live with 518 banks in 22 countries in 1977.

SWIFT in Figures

SWIFT Address

Each member is identified by a unique code called BIC Code. The acronym BIC stands for Business Identifier Code. It is also referred to as Swift Address/Bank Swift Code. BIC is the International ISO standard ISO 9362:2014. This standard specifies the elements and structure of a universal identifier code, the business identifier code (BIC), for financial and non-financial institutions, for which such an international identifier is required to facilitate automated processing of information.

The BIC is used for addressing messages, routing business transactions, and identifying business parties.

SWIFT in its role as ISO registration authority issues BICs to financial and non-financial institutions. The BIC is used in financial transactions, client and counterparty databases, compliance documents and many others, but not all BICs are connected to the SWIFT network used by banks and other institutions for financial messaging. Non-connected BICs, by definition, have no rights or authorization to connect and exchange messages over the SWIFT network.

There are two kinds of BIC. They are the eight-character BIC (briefly called "BIC 8") and the eleven-character BIC (called "BIC 11"). A BIC 8 can identify a particular financial or non-financial institution in a country or a location. A BIC 11 is used to identify the branch of the institution.

BIC 8 is identified as follows:-

• The first 4 alphanumeric represents Business Party Prefix or Institution Identifier
• The second 2 alphabetic represents the Country Code of the Institution
• The Third 2 alphanumeric represents the business party suffix or the Location code

BIC 11 consists of an additional 3 characters which is an optional element that will supplement the 8 BIC, used to identify specific location or departments or service units of the business entity represented by the first 4 alphanumerics.

For eg. CITIUS33 

CITI – represents CITIBANK

US – represents the Country Code

33 – represents the Location Code (New York)

SBINUS33LCD

SBIN – represents SBI

US – represents Country Code

33 – represents the Location Code (New York)

LCD – represents Loans & Credit Department*

*A Business Institution may have many 3 alphanumerics within a BIC Code for different departments or branches within an Institution to ensure that the messages are directed to the appropriate department for efficient Straight Through Processing (STP).

SWIFT Standards

SWIFT provides the network that enables financial institutions worldwide to send and receive information about financial transactions in a secure, standardized and reliable environment. SWIFT has its own set of standards for financial messages.

Let’s look at few SWIFT Standards

*gpi - ‘Swift gpi Instant’ is instantly processed, can be tracked end-to-end and the sender gets complete clarity on the receipt of funds by the beneficiary.

ICICI Bank is the first bank in Asia-Pacific and second globally to offer the facility, called ‘SWIFT gpi Instant’, for cross border inward payments.

SWIFT Message Types & Structure

SWIFT messages consist of five blocks of data including three headers, message content, and a trailer. They are identified in a consistent manner. They all start with the literal ‘MT’ which denotes ‘Message Type’. This is followed by a 3-digit number that denotes the message category, group, and type. 

SWIFT Message Structure

A SWIFT MT message consists of the following blocks or segments:

• {1:} Basic Header Block
• {2:} Application Header Block
• {3:} User Header Block
• {4:} Text Block
• {5:} Trailer Block

SWIFT has standard formats for each type of message across transaction lifecycle. 

SWIFT Message are categories under:

Category n – Common Messages found across the above Categories:-

• MTn90 – Advice of Charges, Interest and other Adjustments
• MTn91 – Request for Payment of Charges, Interest and other Expenses
• MTn92 – Request for Cancellation
• MTn95 – Queries
• MTn96 – Answers
• MTn98 – Proprietary message – messages defined and exchanged between users
• MTn99 – Free format message – often used by banks 

ISO 20022 – a Global and open standard for information exchange

ISO 20022 is an evolution of the SWIFT MT messages. It’s the next generation of financial standards that were defined close to 15 years ago. It was born out of the need for two things, something that was future proof and that was rich and structured and consistent across business domains.

Now, why is ISO20022 being used in the first place? 

Well, because it is a richer format. Because of SWIFT MT messages, the older formats are limited in space. And they’re commonly being used without structure. People just use this kind of email, put in whatever they think is appropriate for the counterparties. It can be an inefficient way to communicate with financial institutions. There’s room for missing information, misinterpretation, delays in processing because people must interpret it differently, and ultimately poor customer experience. Yet, with ISO 20022 an attempt has been made in defining new message types, also working with the banking industry on how ISO20022 should be used specifically in the context of cross border payments. 

SWIFT MX/ISO 20022 – Message Definitions

MX/ISO 20022 is a newer SWIFT message standard using an XML format based on ISO 20022. ISO 20022 or Universal Financial Industry (UNIFI) message scheme is the ISO Standard for Financial Services Messaging. The ISO 20022 scheme includes five financial business domains: payments, securities, trade services, cards, and foreign exchange. The chart below shows payments messages supporting cash account management, payments initiation, clearing and settlement, and cash management, etc.

Brief Introduction to MX Swift Message Types

An MX message consists of 4 parts –  ssss.eee.ppp.aa – where:

• 4 alpha characters – ssss – identifying the Message Type
• 3 alphanumeric characters – eee – identifying the Message Number
• 3 numeric characters – ppp – highlighting the Message Variant
• 2 numeric characters – aa – denoting the Version Number 

SWIFT – Operational Controls – RBI

SWIFT is another application being used by banks to send/receive financial messages. There are instances that a message has been transmitted without corresponding accounting entries or recovery of funds from the customer. Both the accounting (core banking) application and the SWIFT application are operating in isolation. Absence of integration between two applications will result in multiple times of data entry and may result in amending the data fields independently in any one of the applications. It is a high-risk proposition for banks in the absence of controls over SWIFT operations. Many banks have a separate SWIFT administrator whose responsibility is to authenticate the swift messages and reconcile the swift messages with core banking applications. But still many banks are encountering mistakes/frauds leading to losses through the mechanism of unauthorised or unaccounted swift messages transmission – a major operational risk. Many of such frauds have happened in Trade Finance transactions.

Post Nirav Modi’s case, RBI has instructed banks to implement operational & process controls to ensure such frauds do not recur and to find a permanent solution to fix such operational bugs, whether perpetuated by process or people.

Few issues in the absence of integration:

• Several banks have decentralised setup for SWIFT operations, which entailed multiple SWIFT nodes at various branches and significantly high number of users (in some cases, number of users were in excess of one thousand). The existence of such a high number of user IDs increased the probability of compromise of credentials, which in turn exposed the bank to heightened risk of fraudulent activities as well as potential malware attacks. 
• Several banks did not have robust oversight on SWIFT operations, even under decentralised setup. Although administration of SWIFT was delegated to junior level officers and the financial powers exercised by such officials was much above those delegated to similar level officials at branches or in other operational areas, commensurate oversight was lacking. 
•  In several banks, excessive dependence on vendors for all matters related to SWIFT was observed. Reliance on the vendor was observed even for simple activities such as generation of list of authorised SWIFT users. 
• Most of the banks did not have straight through processing from CBS for trade finance transactions such as Letters of Credit/Comfort etc. There was no mechanism to verify whether every outward trade finance related SWIFT message had a corresponding accounting entry. 
• Banks had not attempted to reconcile SWIFT messages issued for trade finance with the outstanding for payment on due date, thus missing out any anomalies arising out of fraudulent transactions. 

In view of the aforementioned concerns, banks are advised to initiate, with the approval of their respective Boards, the following steps as applicable to their respective business model: 

• To verify all SWIFT messages pertaining to any forex transaction, to ensure that all such transactions are captured in the books of accounts and are supported by genuine underlying transactions. 
• To institute appropriate control framework to ensure that SWIFT messages pertaining to documentary credit/ trade finance are transmitted only after accounting for the transactions in their books / CBS / accounting software. 
• To strengthen the control framework in respect of all outward SWIFT messages pertaining to documentary credit/trade finance by introducing reconciliation of such messages through concurrent audit. 
• To explore Straight Through Processing between CBS and SWIFT messaging systems so as to avoid potential fraudulent messages. 

It may be added that the suggestions made above are illustrative only and further safeguards may need to be implemented appropriately on the use of SWIFT framework, workflow design and business profile of the bank.

Written by :  Mr Nagaraj Susurla RamasubbaRao, Banking Consultant & Trainer. Mr Nagaraj held various assignments in SBI in India and at foreign offices. He also occupied the  position of Director, SBI’s Regional Training Institute. The article is based upon the lecture delivered by Mr Nagaraj SR in Foreign Exchange Training Program organised by Banking Quest.