Can SWIFT's Global Payment Initiative ('gpi') Help With KPIs on Timing and Cost of Cross-Border Paym

On the face of it, SWIFT's Global Payment Initiative, or 'gpi', should make a major contribution to monitoring the cost and time expended on cross-border payments.

SWIFT claims that US$40 trillion of payments were sent over gpi in 2018, that 3,500+ banks have signed up to it, and that over US$300bn are now being sent every day in 148 currencies. These are meaningful percentages of all the customer payments going over SWIFT i.e. using the MT103 'Single Customer Credit Transfer' message.

SWIFT claims four major benefits of gpi for end-user customers:

"Speed � Your payment is credited same-day, usually in just minutes or seconds
Traceability � You can track your payment end-to-end in real time, like a parcel
Transparency � You can see all bank fees and FX rates
Certainty � You can be sure the remittance data remains unaltered�

The claim as regards timing is that, on average, 40% of SWIFT gpi payments are credited to end beneficiaries within 5 minutes, 50% are credited within 30 minutes, 75% within 6 hours, and almost 100% within 24 hours.

As regards traceability, gpi supposedly lets the user track the status of their payments from start to finish in real-time � like a parcel, although not one sent using UPS where one only gets an advice that the parcel is on the van and will be delivered before the end of the day.

There is transparency over the bank fees charged and FX rates applied, enabling assurance as to what the final amount is that is credited to the beneficiary. This is not quite the same as a known and controllable all-in, end-to-end charge where the sender can decide to pay all of it (OUR in Field 71A), none of it (BEN) or for the sender and beneficiary to each pay their own bank's charges (SHA). Using SHA runs into many difficulties, such as where it is not market practice to apply it in the currency centre of the payment, and in situations where more than one intermediary correspondent is involved.

Finally there is certainty that the remittance information included by the sender will reach the beneficiary unaltered.

Aficionados of the SWIFT world will treat these claims with some scepticism, because gpi has come about very quickly and without fundamental change to the SWIFT business model or the MT103 Message Reference Guide.

The normal pace of change in SWIFT is glacial, and so there has to be a suspicion that the gpi Service Level has been broadly enough drafted so that payments can be classed as going over gpi when their treatment differs not at all from before.

SWIFT gpi payments are MT103 payments and they go over the SWIFTNet FIN communications network. The definitions and usage guidelines for the fields in an MT103 are laid out in the Message Reference Guide that is updated every November coincident with the release of the updated message standards onto the FIN network.

The message handling and processing routines for MT103 are subject to policies and processes at each bank that are coded into the SWIFTNet FIN gateway, the interface between the gateway and the processing applications and into the applications themselves.

In an area with so much mandatory change deriving from laws and regulations, it surpasses belief that 3,500+ banks could create a business case for fundamental to change to enable gpi, where there is no extra revenue.

Rather the increased speed of the process, and the transparency offered over charges and FX rates, would depress revenue. One can conclude therefore that the gpi Service Level approximates to what banks were having to offer corporate � but not consumer � end-user customers already in the normal course of business.

The two points which banks would have had difficulty offering in the legacy environment are:

End-to-end tracking, because the standard MT103 process does not generate a confirmation of receipt and of processing back to the preceding bank in the chain;
Certainty that remittance information will reach the beneficiary unaltered, because banks might truncate the information, lose it or overwrite it with their own references.

The solutions to these issues in gpi are not described in detail in SWIFT�s publicity but can be surmised:

End-to-end tracking is delivered through a unique reference in the MT103 Message Header that must be repeated in the Message Header of all banks relaying the payment in the chain. SWIFT can then track the unique reference as it leaves each Sender BIC and arrives at each Receiver BIC, housed in both cases on a SWIFT FIN gateway computer. By being in the Message Header, the message content is unaffected and can be processed without IT changes at the interface or application level;
The Remittance Information can be copied by SWIFT out of Field 70 in the first MT103 and married up with the payment later by the Beneficiary Bank using the unique reference as the retrieval key.

Further issues with gpi�s claims would be:

Knowing a message has reached the Beneficiary Bank BIC via the end-to-end tracking is not the same as knowing it has been processed and credited to the beneficiary�s account: it might have missed the processing cut-off time for that day;
Knowing the payment has been credited to the beneficiary�s account today is not the same as knowing that the amount counts in today�s balance for calculation of interest (the value-dated balance) and/or that the beneficiary can use the money (because it is also counted within the available balance). Beneficiary banks may still be able to take remuneration in the form of value dates by delaying when the money is released to the beneficiary;
Knowing what the fees are does not eliminate fees, and does not exclude multiple banks taking a deduction along the way � a major issue with payments made in a series where several banks are handling an MT103;
If a payment involves a stage that is not over SWIFTNet FIN � e.g. a US$ serial payment made through Fedwire or CHIPS systems between US$ correspondents � does the unique reference in the original Message Header get transported intact through the Fedwire and CHIPS system and onto the next MT103?
If the unique reference is not transported intact, how would a Beneficiary Bank marry up an incoming MT103 with its Remittance Information, when that information had been stored and categorised by SWIFT using the unique reference as the retrieval key?

As regards the position of an end-user customer towards gpi:

Does an end-user customer have a choice when initiating a payment of whether the payment should be made via gpi or not?
Do all end-user customers of a gpi-subscribing bank enjoy gpi by default if their bank subscribes to it and so does the bank of their beneficiary?
Or does an end-user customer firstly have to be a corporate to access gpi, and also to be a SWIFT member itself, under SWIFT�s "Standardised Corporate Environment� membership status?

This level of detail does not appear to be publicly available, nor whether gpi only applies to MT103 payments made by the serial method or also ones made by the cover method where the settlement is done through correspondents using the MT202 COV message, and how the benefits of gpi are realised in that case.

Still it does not do to cavil overly much: gpi�s claims, if realised, would represent a step in the right direction and at least give end-user customers an information flow to check against their KPIs that they do not enjoy now, in two important areas:

The time taken for each SWIFT payment to reach the beneficiary bank�s BIC;
The fees payable by the sender and the fx rate applied, if any.

Bob Lyddon is an author for accountingcpd. To see his courses, click here.