Considering Reporting Formats in your TMS Choice
Blog Series: The Role of Onboarding in Your TMS Implementation
As you consider setting up bank reporting into your TMS, more choices must be made. Why, you may ask, should it matter to you in what format you receive your information reporting as long as your balances are there when you need them for your daily cash position? In actuality, there are many factors that should play into your choice. Let’s take a look at the most common syntaxes provided through SWIFT—MT and MX (ISO 20022).
The MT (message type) syntax, which is the most common, was developed in the 1970s when SWIFT was first formed. More messages were added over the years to form the complete group which we use today. Many corporates choose to implement MT messages because they are familiar and accepted by many banks. When sent through SWIFT’s FIN network, MT messages are validated by SWIFT, which proves to be a huge advantage for these messages. SWIFT creates the ACK and NCK which let you know if your message was filled out correctly and will be readable by your counterparty. No other form of messaging or syntax provides this level of validation within the network.
While MT messages are still being used by many banks, they are no longer being updated. Furthermore, they are becoming outdated with the introduction of ISO 20022 syntax and messages. All new messages are being created in the more flexible format of ISO 20022. New messages, such as payment initiation in the SEPA format, are in the XML format. Why does flexibility matter when it comes to messages? If there is a mistake in an MT message, treasury technology systems will not be able to integrate the message. With an XML/ISO 20022 message, the messages will often still be able to integrate and there will be an error in the specific field. This is helpful because valuable information is still available.
During this period of coexistence as banks are using MT and XML messages, SWIFT provides the Standards Translation Rules. This allows a corporate to send an XML message to their bank, if their bank accepts XML. Then, if their counterparty must receive the message in MT format, the bank can use these standards to map exactly, field for field, what the counterparty needs to see. More and more banks are adding XML capabilities every day. SWIFT also provides a guide (https://www.swift.com/topic/34641/certification/banks#topic-tabs-menu – put in this link) on their website to see which message types individual banks offer called the Bank Readiness Portal.
When approaching a bank, it is important to reference the Bank Readiness Portal as many bank employees may be unfamiliar with all message types and could misunderstand their capabilities—another tool in your kit as you move toward a successful and on time TMS implementation!
In our next blog, we’ll help you learn to completely understand SWIFT as an entity. Check back in so your project will stay on track and your budget won’t pop up with surprises for you!