Estimated reading time: 6 minutes
Overview of SWIFT
SWIFT, the Society for Worldwide Interbank Financial Telecommunication, is 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 Standards
SWIFT provides a network that enables financial institutions worldwide to send and receive information about financial transactions in a secure, standardized, and reliable environment. In order to do this, SWIFT have its own set of standards for financial messages.
The following are a few SWIFT Standards
Standard | Owner | Stakeholders | Purpose and Use |
MT | SWIFT | Banks & Corporates | MT is the original message standard developed by SWIFT for carrying information over the SWIFT network between financial institutions. |
MX | SWIFT | Banks & Corporates | MX is a newer SWIFT message standard using an XML format based on ISO 20022. This is the standard SWIFT has chosen to migrate its MT messages to. |
gpi | SWIFT | Banks & Corporates | SWIFT global payments innovation (gpi)* initiative ensures that customer credit transfers are processed faster, with greater transparency regarding fees, and with full end-to-end tracking. The SWIFT gpi has a specific rulebook, which must be followed by the banks who belong into the gpi closed user group. |
ICICI Bank the first bank in Asia-Pacific and the second globally to offer the facility, called ‘SWIFT gpi Instant’, for cross border inward payments.
SWIFT Message types and structure
SWIFT messages are comprised of five blocks of data including three headers, message content, and a trailer. They are identified in a consistent manner. All SWIFT messages start with the literal ‘MT’ which denotes ‘Message Type’, followed by a 3-digit number that denotes the message category, group, and type.
SWIFT has standard formats for each type of message across the transaction lifecycle.
SWIFT Message categories
Category | Message Category | Description |
0 | MT0xx | System Messages |
1 | MT1xx | Customer Payments & Cheques |
2 | MT2xx | Financial Institution Transfers |
3 | MT3xx | Treasury Markets – Foreign Exchange, Money market and Derivatives |
4 | MT4xx | Collection & Cash Letters |
5 | MT5xx | Securities Market |
6 | MT6xx | Treasury Markets – Metals & Syndications |
7 | MT7xx | Documentary Credits & Guarantees |
8 | MT8xx | Travellers Cheques |
9 | MT9xx | Cash Management & Customer Status |
n | MTnxx | Common Group Messages |
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
It is advocated that SWIFT users utilise the structured messages across the transaction life cycle, as these can be beneficial for users.
Advantages of structure messages across the transaction life cycle
- Easier routing is the major advantage of the use of structured messages instead of MT n99
- Automated system driven responses
- Fewer errors, faster response time and improved STP
Disadvantages of SWIFT messages
In the absence of a prescribed structured message, free format messages may have to travel across desks and will require manual intervention, if they require a response. Another disadvantage is the communication tonality written in the free format messages differ from region to region and country to country, which may become difficult to understand and interpret in the manner it is intended for.
Example of a collection category message
Here is an example of a collection category message to highlight the benefit of automation through structured messages.
In an export bill collection transaction, when a remitting bank receives an MT410:
- the system extracts field No. 20 (transaction reference number of the collecting bank)
- maps it to the record shown in field No. 21 (transaction reference number of the remitting bank)
- captures the acknowledgement event, collecting the bank’s reference number which will be useful for further correspondence.
Transaction Life Cycle of a Documentary Credit
A Documentary credit transaction will originate with the issue of a Letter of Credit (LC) through MT 700. Let’s start with this.
In MT 700 the field length is pre-defined and standard. The users may face the field length limitations in respect to filed No. 45A – Description of goods, Field No. 46A – Documents Required and Field No. 47A – Additional Conditions. Few Banks use free format messages (MT 799) to provide full details of fields 45A,46A and 47A which is not correct. When the field length is exceeded, the users must use MT701 as a continuation of these three fields.
Amendments to Letters of Credit are very common. These are addressed under Article 10 of UCP and transmitted through MT707 – if, stated in the original Letter of Credit, reimbursement is provided through MT740 and if the amendment affects the contents of MT740, an MT747 must be sent to the reimbursing bank.
The MT700 receiving bank (advising bank) is expected to acknowledge the receipt / advise of LC and such acknowledgement is transmitted through MT730 wherein they incorporate their reference number in Field No.20 with the corresponding issuing bank reference number in Field No. 21.
Issuing banks depending on their internal policies and trade practices, incorporate reimbursement instructions on how they will reimburse the negotiating bank. In non-confirmed LCs, banks will often offer to remit the proceeds under LC complying presentation as per the instructions of the negotiating bank. In confirmed LCs, however, the confirming bank will seek a reimbursement claim. In such cases, the issuing bank will incorporate and authorise the negotiating bank to claim from the reimbursing bank. In such instances, the issuing bank must send the Reimbursement Authorisation to the reimbursing bank.
Discrepant documents
When discovering discrepant documents, the issuing bank must send a MT 734 – Advice of Refusal and may, in its sole judgement approach the applicant for a waiver of discrepancies. If the applicant accepts (waives) the discrepancies, the issuing bank will need to send an MT732 – Advice of Discharge.
If the presentation falls under the definition of complying presentation and the issuing bank has provided the Reimbursement Instructions, the negotiating bank must forward the Reimbursement claim vide MT742 to the Reimbursing Bank.
In the absence of reimbursement instructions, the negotiating bank will forward the credit complying documents to the issuing bank with a request to remit the proceeds. The issuing bank, subject to examination and confirming that the documents ‘comply’ must honour the presentation and remit the proceeds via MT202 as per the negotiating bank’s covering schedule and advise the negotiating bank about the payment via MT756.
If the negotiating bank, during the examination of the presentation, finds discrepancies and chooses to advise the discrepancies to the issuing bank even before dispatching the documents, it can send an MT750 seeking the approval to honour the documents presented that are not in accordance with the terms and conditions of the credit. The issuing bank, may, after obtaining the acceptance of the applicant, forward MT752(Authorisation to Pay, Accept or Negotiate), advising the negotiating bank that the presentation of the documents may be honoured, notwithstanding the discrepancies, provided they are otherwise in order.
The negotiating bank, handling the negotiation of complying presentation, must send a MT754 advising the issuing bank that the documents have been presented in accordance with the terms of a documentary credit and are being forwarded as instructed.
Conclusion
Structured messages enable the efficient and direct processing of documentary credits with minimum manual intervention. Furthermore, they help to minimise errors or gaps in the interpretation of the content with well-defined fields and field contents in SWIFT messages.