gpi is based on the unique end-to-end transaction reference (abbr. UETR), which accompanies a payment throughout the sometimes long correspondence bank chain. The reference may be a monstrosity of 36 characters in a format defined by a universal algorithm (xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx), but that monstrosity ensures an end-to-end uniqueness without an "issuing authority". Though initially, the UETR was only used in a CUG (closed user group) for (corporate) customer payments in MT103 messages, by now all payments in the FIN network have such a reference – a reference that remains unchanged throughout the entire payment process chain.
The second substantial part of gpi is the so-called Tracker. The Tracker is a central database for all gpi payments and is hosted at SWIFT. It provides the participating banks with comprehensive information on the status of payments in the correspondent bank chain, on fees and on currency conversion rates. While the FIN transport reads this information directly from the transported messages, non-FIN banks can also actively inform the Tracker. Currently under discussion is the so-called confirmation – a notification on the credit arriving in the beneficiary's account at the end of the payment process chain. As of 2020, all FIN banks shall be obligated to use the confirmation.
But why all this effort? gpi tackles the two core challenges in correspondent banking – transparency and speed. The extensive use of the UETR has yielded statistical data: on average, 40 percent of the gpi credit transfers are booked on the account of the end beneficiary within five minutes, 50 percent within 30 minutes, 75 percent within six hours, and almost all of them within 24 hours. Such a statement was simply impossible to make before gpi. On the contrary, all treasurers have experienced cases of payments arriving too late or not at all, with high, inexplicable fees, and with unclear or missing purpose information.
In addition to technical details such the UETR and Tracker, gpi provides a rulebook that stipulates the preferably same-day forwarding of a payment with complete remittance information and specification of deducted fees and currency conversion details. As there is no global transparency guideline, these stipulations have to be enforced on the basis of multi-lateral contracts. And that is a good thing – it's about time.
The (corporate) customer shall receive better service in cross-border payments. Aside from speed and transparency, another aspect is the acknowledgement. Acknowledgements, or receipts, have so far been used in cash transactions only. In electronic payments, the motto was mostly "shoot and forget". If no complaints come in, the money must have reached its destination. Recent years have seen a remarkable development in the SEPA, and with instant payments according to the SCTinst scheme, electronic payments now have acknowledgements, too. With SWIFT gpi, such an acknowledgement can also be generated, even if it (still) requires a complete FIN chain in the settlement process. However, there is a long way left to go: so far, the broad, bank-internal implementations have been in the focus. The connection of customer systems for access to the information or even for forwarding of statuses and fee information to the customer system is still in its early stages. But alone the possibility to check on a payment's status via a central database in case of doubts shows considerable progress in the vast correspondent bank network.
Is this potential only applicable to FIN? Not at all. Current developments, e.g. the migration of real-time gross settlement systems (RTGS) such as TARGET2, EURO1 or CHAPS from MT to XML messages according to the ISO 20022 standard, are going in this direction. The (newer) ISO message formats contain dedicated fields for the UETR, meaning that the reference is transferred outside the FIN network, as well. Just recently, SWIFT made an announcement: "SWIFT trials instant cross-border gpi payments through TIPS"[1].
For the connection of gpi return messages to customer systems such as TMS or ERP, PSR messages (payment status reports, i.e. pain.002) are more efficient than manual processes. These self-services alone are already a significant step towards more transparency. By the way, the standards for these return messages, i.e. fields (tags) and codes, were made multi-bank compatible in the harmonisation initiative CGI-MP. PPI is now also actively partaking in this initiative.
Furthermore, the customers shall be enabled to initiate their reference in the payment as UETR – in the pain.001.001.03 within special fields according to the CGI-MP, or even in more current ISO versions within dedicated fields.
This customer-bank or bank-customer interface is where both customer payments and PSR return messages are often also transferred via EBICS. Which means that gpi and EBICS do not contradict each other, but are rather complementary concepts – as is often the case in payments.
Author: Dr. Mario Reichel
[1] Source: https://www.swift.com/news-events/press-releases/swift-trials-instant-cross-border-gpi-payments-through-tipshttps://www.swift.com/news-events/press-releases/swift-trials-instant-cross-border-gpi-payments-through-tips
0 comments:
Post a Comment