With the payments revolution continuing to gather momentum it’s not surprising it was one of the big themes at Sibos 2018, with SWIFT’s Global Payment Innovation service dominating discussions across the space.

SWIFT gpi brings several features to enable transparency and speed to classical cross border payments executed through the correspondent banking system – commonly known as “TTs” or “SWIFT payments”.

In practice, a SWIFT gpi service level agreement (gpi SLA) forces banks to credit funds to the beneficiary account on the same day. The agreement also mandates that all fees must be disclosed up front – no more mysterious deductions on cross border payments. A unique end-to-end transaction reference (UETR) enables payments to be tracked, and SWIFT provides a tracker software that banks can use to allow corporates to track the process of payments through the correspondent banking system, rather like parcel tracking from DHL and FedEx.

Most large banks now do gpi payments and many have switched all cross-border payments to gpi. However, not all of SWIFT’s 10,000-member banks are yet gpi enabled so tracking through smaller banks cannot yet be fully guaranteed. It is encouraging that SWIFT is pushing a speedy adoption of gpi across the network. As of this month it is mandatory for all MT103s (payment instructions) to carry (and not lose) the UETR. gpi adoption will be mandatory for all SWIFT members by 2020.

This is wonderful progress, and corporate treasurers are thrilled. Bank treasurers are envious and want gpi implemented for MT202 messages which are used for inter-bank payments. The conclusion of the corporate panel on gpi at Sibos was very clear: corporates love SWIFT gpi and UETRs and want them to be ubiquitous.

Gaps in the gpi roadmap

But therein lies the rub. Currently banks are not obliged to show the UETR on bank statements such as MT940 and ISO 20022 camt messages. This severely limits the benefits of gpi for beneficiaries – which was the core topic of the corporate panel at Sibos. Further, there is not yet any way for the beneficiary to track incoming payments – the tracker only works for payers. And not all banks are exposing gpi data to their clients.

Reconciling incoming payments (aka collections) is always a pain point for corporates, so addressing the beneficiary end of gpi must be a critical priority for SWIFT. Indeed, bankers discussing the prospective application of gpi to MT202s are primarily looking at the beneficiary side where identifying incoming payments will be facilitated by the beneficiary bank BIC code. For corporates, it is almost as easy using the beneficiary bank BIC code and the corporate account number (or the BIC code for corporate SWIFT members). Unfortunately, this obvious and critical functionality has not yet been confirmed on the gpi roadmap.

Some banks are not exposing gpi data to corporate clients, and some only expose it through their e-banking channel. It is clear that all but the smallest corporates need to receive gpi data messages such as SWIFT or host-to-host connectivity, since their payment volumes preclude manual processing on e-banking portals. Ultimately this will be through an API but for the moment MT199 and ISO messages are adequate.

Another big issue is remittance data, which corporates need to reconcile incoming payments to accounts receivable. The current gpi SLA mandates that remittance data is delivered in full to the beneficiary which is a big improvement on current practice where banks routinely truncate or simply remove payer to beneficiary information. There are many technical issues such as the capacity of intermediary clearing systems and so forth, but the gpi platform provides a route for larger remittance data to be transferred intact from payer to beneficiary, so this should be on the gpi roadmap for the near future.