SWIFT GPI on good tracks!
As you all probably know SWIFT GPI addresses some of the major pain points corporates currently experience when they initiate cross-border payments. For treasurers it is difficult to get visibility on what happens to their cross-border payment instructions, not knowing when and if payments have been credited or what sort of fees have been deducted. They don’t know why a payment has been rejected and every investigation can be time-consuming and costly. This can cause lots of problems with suppliers and counterparties as well as increasing financial risks resulting from payment delays or more and more frequently fraudulent actions.
For the first time SWIT bank users and corporate users met in London in end of November 2017. This ambitious project seems to be on good tracks. 125 banks have joined the initiative as of November 21017. There are 4 millions of messages exchanged. More than 200 countries are covered representing 75% cross-border payments. End of 2017, 40 banks roughly were “live”. There are more than 3 million payments executed at that moment and it keeps growing every day. Corporates and EACT remain convinced GPI will become soon the new norm of cross-border payments. The adoption curve will be exponential. Although they started with FIN messages on bank side (i.e. MT 101) later on they will cover FileAct (XML). There are even domestic payments on GPI. Who can do more can also do less, isn’t it? As 55 countries support GPI, they could cover domestic payments too. The next steps are to launch a pilot phase in order to standardize GPI flows between banks and corp’s, to provide a single GPI experience and to demonstrate efficiency of the GPI. One of the issue for IT vendors and corp’s will be to generate UETR (i.e. Unique End-To-End Transaction Reference) in order to track payments and to reconcile operations when confirmed and executed. The UETR (i.e. UUID) will be based on 36 characters (e.g. (111:001) (121; eb6305c9-1£7£-49de-aed0-16487c27b42d). The key question will be: would vendors be prepared and ready on time? Better to initiate discussions with them earlier than later.
The test phasing has started and SWIFT hopes to be ready and live with corp’s by October 2018 for SIBOS in Sydney. As mentioned, there are still issues to be sorted out regarding standards, types of formats to be used depending on types of operations (i.e. treasury or commercial). The cost element still has to be defined but highly depends on solutions applied. Corp’s will soon start talking to TMS vendors to check feasibility of UETR generation.
As all cop’s already expressed, we want a bank agnostic solution for the tracker and hope SWIFT will propose a multi-channel solution. We guess corp’s will invoke the exceptional character of tracking tools and the by exception management to check where payments stand. The idea is to avoid the overloading of data and information coming back from banks.
The speed of GPI should be an asset. According to first results and performances measured, it seems that one third is faster than half an hour, and 43% faster than two hours. The costs should be reduced as at the end of the day it also reduces costs for banks with tracking and corrections of errors. The consequent amount of time spent by back-offices to track payments would be easily compensated in our view. The corporates would like to know where a payment stands and if it is confirmed, rejected, on progress, on hold or delivered (when delivered to a non-GPI bank). This piece of information will be “pushed” by banks to corp’s.
Although there are still some key elements to be decided and defined, the group has progressed a lot. We are convinced that the excellent spirit around the bank-corp’s pilot project and dedication from teams involved will be key for achieving objectives on time. EACT fully supports this excellent and promising SWIFT project. We will keep you updated in the next months of progresses achieved.
We wanted to thank the pilots (i.e. bankers and corporates) who accepted to test and help finalizing this new product until “go-live”