What is Swift Messages
SWIFT messages are standardized messages used for international financial transactions between banks and financial institutions. SWIFT, which stands for Society for Worldwide Interbank Financial Telecommunication, provides a secure platform for transmitting these messages.
Structured data and standard formats for exchanging information around bank guarantees and letters of credit are key for the digitisation of trade finance. Interbank and bank-to-corporate messaging remains a challenge, and whilst the industry welcomes moves towards structured data and SWIFT’s new messaging types, there are still challenges. TFG heard from Olli Jääsaari, Standardised Trust expert and Nordea’s Trade Finance & WCM Product Manager.
Key Types of SWIFT Messages
- MT103: Used for single customer credit transfers (remittances).
- MT202: Used for bank-to-bank transfers, often for settlement between financial institutions.
- MT940: Provides bank account statements, detailing transactions for a specific period.
- MT950: Used for end-of-day balances and statements.
SWIFT Messaging Types for Guarantees and Its Uses
DP: What are the current uses for messaging types when it comes to Bank Guarantees? What is SWIFT MT 760, 767 and 798?
OJ: Anyone who has worked with bank guarantees transmitted between banks will be well aware of the current MT 760 guarantee issuance and MT 767 guarantee amendment formats: there are a couple of fields for applicable rules and a date, but the main content of the message is in a single, free format narrative field. Regardless of who pays the fees, what the guarantee text is or which rules and which law is applied, it’s all in field 77C: Details of Guarantee.
Using a free format field is of course very convenient. Any scenario ranging from a simple request to advise an issued guarantee, requesting advise and confirmation of a standby, right up to a chain of multiple counter guarantees leading to local issuance of an undertaking, is easily sent using MT 760 or MT 767.
The downside of this free format flexibility is that automation is difficult. Picking out the parties in the transaction, the guaranteed commitment or even the guarantee amount or expiry date requires that the information in the narrative is parsed.
The bank-to-corporate channel used, utilising MT 798, however, manages to solve this in the message flow between corporate and bank by using an index message with a structured format. However, this is always accompanied by the unstructured narrative.
Implementation of the New SWIFT Messaging Standards
DP: What are the proposed changes for SWIFT messaging standards (MT 760 and MT 767) and when is this changing?
OJ: The upcoming SWIFT message standards, which are set to go live in November 2021, attempt to solve the current issues by using structured fields in the bank-to-bank messages MT 760 and MT 767. Such fields would include the guarantee amount, expiry date and parties, among other things.
Going forward, the MT 760 and MT 767 can only be used for demand guarantees and standbys. All sureties, accessory guarantees and other dependent undertakings will need to be sent in MT 759 ancillary trade messages, which continue the use of a single large narrative field. My opinion is that this split causes more harm than good, especially when combined with the suggested MT 798 standards – but this will be elaborated on later.
Additionally, some messages receive minor tweaks which don’t have a big impact on usage, and some new message types are introduced for demand for payment and amendment responses.
Benefits of New MT 760 and MT 767 Formats
DP: Can structured messages bring automation benefits to trade?
OJ: The development of the new MT 760 and MT 767 formats is appreciated, as they enable easier process automation in many areas, such as compliance screening, or sorting incoming messages to different handling depending on whether they’re standbys to be advised without any risk, or requests to issue a local undertaking against a counter guarantee.
However, building separate handling for dependent undertakings in MT 759 is an additional cost. If only the code DEPU – for dependent undertakings – was allowed in the MT 760 and 767 formats, the same handling could be utilised!
DP: What do these changes mean for corporates, and which guarantee text is the corporate requesting?
OJ: As mentioned before, the current message standards for MT 798 messages between corporates and banks already contain a large part of this data in structured format, detailing the data which is also included in the free-text narrative field of today’s guarantee messages.
This means that the change will not be that big for corporate-to-bank communication, as long as we consider only demand guarantees and standbys. Dependent undertakings, unfortunately, are a whole other story.
First of all, the guarantee request message, and response thereto, must contain a message structured like an MT 760, despite the instrument being issued as an MT 759. This means that the corporate must think about how their bank will treat the different fields in the request, and the bank must also carefully consider what the customer wants, in order ensure correct content is populated into the MT 759 narrative field.
Then, once the MT 759 is sent, the bank must inform the customer of the issued guarantee. Usually one would do this by sending a copy of the outgoing message, but for some reason the message standard makes it mandatory to translate this 759 message into the 760 format. And note that this is the very same format, which explicitly disallows dependent undertakings in bank-to-bank communication!
If only the code DEPU – for dependent undertakings – was allowed in the bank-to-bank MT 760 and 767 formats, the mismatch would be avoided!
New SWIFT Messaging Formats – Issues for Advising Banks
DP: In your opinion, what are the main issues for advising banks?
OJ: The very same issue is encountered when a bank is requested to advise a surety to a corporate without taking any risk. Ideally, the advising bank would forward the incoming guarantee text to the corporate as is, without any changes.
The incoming message will be an MT 759, so the bank has two options:
- Forward the MT 759 to the corporate as a free format message. The bank is happy, but the corporate is not as they cannot automate their process.
- Translate the MT 759 into the structured MT 760 format (which still disallows sureties in bank-to-bank communication). The corporate is happy, but the forwarded guarantee message contains a lot of information that the bank has had to parse from the free-format narrative field; which begs the question about liability in case of a mismatch in data between fields, or between the advise message and the incoming 759.
If only the code DEPU – for dependent undertakings – was allowed in the MT 760 and 767 formats in bank-to-bank communication, there would be no issue to discuss here
SWIFT’s new messaging types and structured formats – a silver lining for digital trade?
The structured message formats bring clear benefits for banks and enable wider automation of processes. The split between dependent undertakings in free-format MT 759 and demand guarantees in structured MT 760 should, however, be removed.
Allowing sureties and accessory guarantees to be sent by MT 760 would follow current market practice, reduce work in building parallel handling in banks, and remove the mismatch between the bank-to-bank and bank-to-corporate SWIFT messages
The structured message formats bring clear benefits for banks and enable wider automation of processes. The split between dependent undertakings in free-format MT 759 and demand guarantees in structured MT 760 should, however, be removed.
Allowing sureties and accessory guarantees to be sent by MT 760 would follow current market practice, reduce work in building parallel handling in banks, and remove the mismatch between the bank-to-bank and bank-to-corporate SWIFT messages