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:
Payment Tracking & SLA’s
2021 and beyond.
Integrity & Availability.
Transaction Referencing (UETR). Business Service Levels and Quality Controls.
E2E Tracking & Insights. Controls.
SME and Consumers.
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.
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.
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.
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.
The movement from a linear process to a messaging platform is perhaps the most significant technological and process improvement on the SWIFT network. In a future article, we will examine the timeline for these changes and explore Verification, Validation and Prediction in more detail.
CTMfile take: The movement to a transaction management platform is a transformative change and something we would have expected from a fintech rather than SWIFT. With the growth in adoption of APIs and other purported SWIFT-killers this shows they are still very much in the transaction game. SWIFT gpi offered a small preview into greater visibility and this movement to a modern transaction platform means delivering on the value-added services on and around the platform should lead to greater innovation, security, visibility, and relevance over time. A major consideration for the success of this transformation will be whether SWIFT communicates the value of this platform in a way the market understands.
Like this item? Get our Weekly Update newsletter. Subscribe today