SWIFT’s annual MT Standards release ensures that the message types (MTs) exchanged by SWIFT users remain suitable for the business areas in which they are used, by enabling new business functionality and compliance with changing regulations. 

This year's changes will come into effect from 22November 2020. And there has been a huge amount of focus on the two key changes affecting Payments categories 1,2,9 and the common group as these changes have a link to the ISO20022 program. 

-  Universal Payment Confirmation will become mandatory.

-  Validation changes to the format option F in fields 50 and 59.

Universal Payment Confirmations:

Members receiving an MT103 instruction message are mandated to provide confirmation on the outcome of customer payment to the SWIFT gpi Tracker within a maximum of two business days following the value date (though the same business day is the recommended practice). The confirmation must provide the originator bank identification code, amount, currency, and date/time of either the credit to the beneficiary account or the rejection, at a minimum. 

SWIFT is supporting this SWIFTgpi functionality with a range of manual and automated solutions. 

> Basic Tracker - This is a free and basic version to support even the non-gpi banks who can confirm manually. 

> Automated MT199 confirmations - gpi members confirm payments by sending an interbank payment message (MT 199) to a dedicated gpi Tracker BIC through their existing SWIFT interface. This message then triggers an update to the Tracker and provides payment confirmation to the ordering bank. 

-> Confirm via API calls - Using API calls to confirm payments is a fast and efficient way to update the gpi Tracker. 

-> ISO20022 - Migration to the standard will also deliver an ISO20022 compliant message to ease the burden on banks. 

-> Batch Confirmations - To further ease the process, SWIFT will pilot a CSV format in early 2020. Banks just need to assess that payment systems support the format, and can as well test it using MyStandards Readiness Portal. 

Validation changes to the format option F in fields 50 and 59:

Note: Free format options for F50 and 59 are Not Removed in SR2020. 

ISO20022 is all about ‘data’, validation of option F in fields 50 and 59 is a step towards the preparation of a migration from unstructured to structured data. 

Option 50F and 59F were introduced to meet the FATF recommendation 16, which requires information of ordering and beneficiary customers of payments is available to ordering, intermediary, and beneficiary financial institutions in order to facilitate both the identification and the reporting of suspicious transactions. However, the industry has not seen a significant shift to the structured format. 

Market Practice Guideline has suggested that the global community should target November 2023 as the end-date for unstructured customer information payments, regardless of their format (ISO20022, FIN or native clearing). The challenge should be given equal priority as that of the ISO20022 migration as there are strong reasons to support the change, few to mention:

  • Important market infrastructures TARGET2, FEDWIRE, CHAPS, and CHATS will move to ISO20022 in the next 2-3 years. TARGET will be a big bang migration on 22November 2022, FEDWIRE will be phased starting with ‘like to like’. 
  • CBPR+ usage guidelines require the usage of a structured address only. The unstructured address line element is expected to be used rarely only after November 2023 with total removal aimed for 2025. 
  • ISO20022 usage guidelines mandate the inclusion of addresses for debtor and creditor for cross-border payments with a minimum of country and town.

Option F: Party Identifier/Name and Address

Definition: Name and address in a structured format to facilitate straight-through processing.



The above clearly illustrates that the Address lines 1 – 4 in the unstructured option does not allow unambiguous interpretation of information due to the lack of qualified elements. The option F in the SWIFT FIN standard provides a certain level of the structure by the qualifiers (e.g. 1/ for the name). 

While the elements "Name" and "Country" can be unambiguously identified, the data in the address (2/...) and location (3/XY/...) line could contain multiple information such as Street Name, Building Number, Floor Number, Building Name, Town/City name, Postal Code, etc. which therefore is not easily identifiable. 


ISO20022 provides more structured and granular data for the identification of a “party” in the name and address component than the SWIFT FIN F option. Therefore, mapping from ISO20022 to MT address details will naturally lead to a loss of data structure. 
Image 2 illustrates the unstructured data which can be part of the structured ISO20022 message format.

There is no simple mechanism to map the formats, a dedicated project is required with an aim to eliminate unstructured data alongside the migration, consider: 

  • Review and redesign customer initiation channels.
  • Clean up existing party data.
  • Educate staff in branches and back-end teams to review the data being uploaded. 
  • Encourage, promote, and market usage of structured data. 
  • Initiate the ISO20022 migration with a smaller entity as it will give time to amend the plan and realign with the MI plan and ecosystem as such. 
We at Nth Exception collaborate with Banks and Financial Institutions to analyze, solutionize, and optimize cross-border payments processes. To complement our services and product we have partnered with companies in the payments space to deliver best-in-class payment solutions delivered by our partners.

Excerpts from PMPG