The 2018 Standards release comes with new operational requirements around UETRs, bringing the benefits of gpi to life
What are UETRs?
A UETR is a string of unique characters attached to payment messages, designed to provide complete transparency for all parties in a payment, and to facilitate new functionality from gpi such as the payment Tracker.
The payment Tracker allows gpi banks to trace and confirm their payments, and from 2019, a standard version of the Tracker will be available, enabling SWIFT customers – including non-gpi banks – to benefit from this functionality.
From 18 November this year all SWIFT users (including both gpi members and non-gpi members) originating payments need to provide a UETR as standard for all of the following message types:
- MT 103 STP
- MT 103 REMIT
- MT 202
- MT 205
- MT 202 COV
- MT 205 COV
Payment messages sent after the cut-off date without a UETR attached will receive a NAK error and be returned to the originator.
What changes do I need to make?
When ordering institutions generate a payment message, their internal systems will be required to generate and include a unique UETR for all of the above message types in the 121 field of the message. This code will be the single source of truth for the payment as it is passed through the chain, including payments routed via intermediary banks.
Banks should make adjustments to their payment systems to generate the code, and carry out testing with their interfaces to make sure the code can be processed correctly.
Intermediary institutions are not required to generate a new UETR when routing payments, but their internal systems must be able to receive, copy and pass on the code to other parties in the chain. Therefore, intermediary banks must make sure their systems are also ready to handle UETRs by 18 November.
Likewise, beneficiary banks (even if they are not gpi customers), must be able to receive and process UETRs to reconcile payments.
For institutions issuing cover payments, you must be able to create a copy of the original UETR and pass it over to the cover payment message.
What about interface customers?
For customers using Alliance Entry and Alliance Access (as of version 7.2.5), functionality is built into the software to automatically generate a UETR in the event one isn’t included by your internal systems, meaning you can continue to originate payments. However, you will still need to update your back office to receive UETRs and receive confirmations from messages you’ve sent out.
What are the benefits?
By implementing SR 2018 and being ready to accept UETRs, you will access a range of new functionality and for non-gpi customers, you will be a big step on the way towards accessing the functionality from the platform.
UETRs allow banks to easily trace their payments, no matter how complex or the number of counterparties, giving transparency over fees and the location of payments in real-time in a unified standard.
UETRs also remove the need for a chain of references between the originating, intermediary and beneficiary banks, ensuring all parties are using the same end-to-end reference. This reduces errors occurring and reduces the likelihood of conflicts, saving costly and time-consuming reconciliation issues and investigation of missing or incorrect payments.
Five steps to take before 18 November 2018
- Understand the impact of SR 2018 on your payment applications and SWIFT interfaces.
- Upgrade your payment applications to create, store and process UETRs.
- Upgrade interface systems to SR 2018 compliant version.
- With the correct version installed, test the full transaction chain in FIN Test & Training future mode and test your full transaction chain (note: even if you have a SWIFT interface, you still need to update your back office systems as they will be required to receive UETRs, and get confirmations from UETRs from messages you have sent out).
- Activate your upgraded system on 18 November 2018 for go live.