SWIFT Messaging Types

What are the upcoming changes to guarantee messages?

SWIFT Messaging Types

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.

Disclaimer: The views that have been expressed on this page are that of the author, which may or may not be in line with Trade Finance Global, or, Nordea’s view.


SWIFT Messaging Types – An Introduction


Deepesh Patel (DP): Why is structured data important for trade finance, and what is Nordea’s approach to digitalised trade?

Olli Jääsaari (OJ): The standard formats for exchanging bank guarantees and standby letters of credits between banks are going to become more structured. While the changes proposed by SWIFT – the Society for Worldwide Interbank Financial Telecommunication ­– bring many benefits, they also come with certain problems.

As product manager for guarantees and standbys at Nordea, a leading financial services group in the Nordic region and one of the biggest banks in Europe, I have had an excellent opportunity to deep dive into the message formats and their usage. These views have been enriched in a discussion with members of Standardised Trust, which is a community co-operating and contributing towards digitalisation in global trade, with members not only from banks, but from corporates, FinTechs and software vendors alike.

While the general consensus is very positive towards structured data, we see the following main issues:

  • The upcoming split between demand guarantee and dependent undertaking messages requires special handling in processes
  • The mismatch between interbank and bank-to-corporate message formats in dependent undertakings lead to troublesome situations

Both issues could be solved by permitting the use of the structured formats for dependent undertakings as well.

Nordea’s approach to digitalised trade

Podcast – Messaging Types Explained and Key Changes for Guarantee MTs

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.

swift bank messaging

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?Main changes for trade messages

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.

MT 798 request for guarantee & standby

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.

MT 798 advise of guarantee & standby

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.

bank-to-corporate SWIFT messages

As the Category 7 message changes have been postponed to November 2021, there would still be time to see if there is support for doing a change to the formats. In any case, the discussions in Standardised Trust have shown the value of collaborating not only between banks, but keeping corporates involved as well, together with software vendors for banks and corporates alike.

Key Resources for Download

Main changes for trade messages

Main Changes on the New SWIFT Messaging Formats

MT 798 request for guarantee & standby

MT 798 request for guarantee & standby

MT 798 advise of guarantee & standby

MT 798 advise guarantee & standby

Download our free Letters of Credit guide by filling in the form below:


Access trade, receivables and supply chain finance

We assist companies to access trade and receivables finance through our relationships with 270+ banks, funds and alternative finance houses.
Get started

Speak to our trade finance team

About the Author

Deepesh Patel is Editorial Director at Trade Finance Global (TFG). In this role, Deepesh leads efforts in developing TFG’s brand, relationships and strategic direction in key markets, including the UK, US, Singapore, Dubai and Hong Kong.

Deepesh regularly chairs and speaks at international industry events with the WTO, BCR, Excred, TXF, The Economist and Reuters, as well as industry associations including ICC, FCI, ITFA, ICISA and BAFT.

Deepesh is the host of the ‘Trade Finance Talks’ podcast and ‘Trade Finance Talks TV’. He is co-author of ‘Blockchain for Trade: A Reality Check’ with the ICC and the WTO, alongside other industry research.

In addition to his work at TFG, Deepesh is a Strategic Advisor for WOA, and works closely with ITFA. He also sits on the Fintech Working Group of the Standardised Trust.

Prior to TFG, Deepesh worked at Travelex where he was responsible for the cards business and the Travelex Money app in Europe, NAM, UK and Brazil. Deepesh is Chair of Governors and co-opted LA Governor of the Wyvern Federation, which has responsibility for 5 primary schools in South London.

Back to Top