In every communication activity, the greater the number of handoffs, the greater the messaging problems. Dropped information, distorted messaging, and more opportunities for confusion abound as the other party must repeat what was communicated. SWIFT is often thought of as a stodgy but reliable financial messaging service provider and a body that helps set format standards. The perception as ‘stodgy’ appears to be changing as they work on rolling out a new transaction platform. The changes in technology being deployed by SWIFT offer a way to radically transform financial communication from limited linear messages to a transaction platform.

SWIFT: History of Messaging

In various presentations, SWIFT provides a summarized historical view of the major phases of messaging on their network along with the timeframes and select services that correspond to these phases. This timeline provides historical context before we discuss the recent transformation:

Messaging	Payment Tracking & SLA’s	Transaction Management
1970’s -2017	2017-2020	2021 and beyond.
Standard. Secure. Integrity & Availability. Community Reach.	Transaction Referencing (UETR). Business Service Levels and Quality Controls. STP Enhancements. E2E Tracking & Insights. Controls.	Frictionless Payments. Instant Processing. SME and Consumers.

Linear Messaging

In the nearby drawing, you can see the row associated with legacy messaging moving from left to right with separate messages and numerous handoffs. This is reflective of the FIN services as messages (MT stands for Message Type). An originator starts a request to send money from here to there using this format through this bank. The request passes through SWIFT to other counterparties until it reaches the final recipient. This is an environment that often leads to numerous issues, including:

• Data Transformation and Data Loss. These messages may be altered through adding data or transforming the message to another format. Transforming data to another format may create a ‘data loss event.’ Other counterparties or the end recipient may not receive all of the data causing a messaging defect that must be corrected.
• Fail and Restart. When a message moves through a linear process and is stopped for some reason (e.g., missing information to support compliance requirements), the conversation typically stops for good in this channel. Communicating the reason for the stoppage back to the initiator can be manual and delayed, absorbing excessive staff time to restart the process.

Invisibility

In the chart below, most parties have a thoroughgoing lack of visibility to the message. Party 1 knows when they sent it but not where it is in the stream other than when it hit Party 2’s system. After that, there is no visibility. The final receiving party, Party 6 in this case, may only know they didn’t receive the message or funds.

 

 

Source & Copyright©2021 CTMfile/Strategic Treasurer.

 The above drawing is only meant to convey some of the key concepts between the historical or legacy SWIFT messaging platform (FIN) and the new transaction platform model. MT = Message Type; PACS = ­Payment Clearing and Settlement; PAIN = Payments Initiation.

Transaction Platform

In contrast to a linear process of handoffs, the new SWIFT transaction platform has a single message that all counterparties can access or interact over centrally. Leveraging current API technology with backward compatibility, this central version of the message can be accessed throughout the process and data retrieved via different formats. There are some notable process changes in this move to a transaction platform for interactions, visibility or missing information:

• Single Source of Data. Messages live on the platform, and everyone can pull any or all of the data they need into their system. Data isn’t lost in handoffs, as handoffs don’t exist, thus eliminating that source of problems.
• Repair in Flight. If a message is found to be missing information while in transit, this issue can be communicated. Then the nearest counterparty or even the originator can add the required information, making the transaction compliant. A correction is made on the platform, and the message is ready to continue on its flight.
• Visibility. In contrast to the hidden nature of the linear messages, the transaction platform allows for all counterparties to have clean visibility at all points in the process. By clearly exposing those counterparties who are performing ‘slowly,’ this visibility motivates them to make their processes better.

 

Platform Implications

The platform concept allows for both the improvement of existing (optional) services and the development of new capabilities and services. For example:

• Improvement. Pre-validation means a user on the network can validate information before payment messages are inserted into the communication stream, improving quality.
• New Services. Transaction orchestration and tracking. This allows for improved interaction on a transaction by all parties instead of a message disappearing from view once sent.

---