Skip to main content
  • English
    Discover SWIFT
  • Español
    Descubra nuestros contenidos en español
  • Français
    Découvrez notre contenu disponible en français
  • 中文
  • 日本語
What are UETRs and are you ready to process them?

What are UETRs and are you ready to process them?

31 October 2018 | 3 min read

With the 2018 Standards release came new operational requirements around UETRs, bringing the benefits of gpi to life.

Swift Standards release 2018 came with a range of new functionality around gpi, facilitated by new Unique End-to-end Tracking Reference codes, or UETRs for short.

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 is available, enabling Swift customers – including non-gpi banks – to benefit from this functionality.

From 18 November 2018 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:

  • MT103
  • MT 103 STP
  • MT 103 REMIT
  • MT 202
  • MT 205
  • MT 202 COV
  • MT 205 COV

Payment messages sent without a UETR attached receive a NAK error and are returned to the originator.

What changes do I need to make?

When ordering institutions generate a payment message, their internal systems are required to generate and include a unique UETR for all of the above message types in the 121 field of the message. This code is 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 since November 2018.

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 still need to update your back office to receive UETRs and receive confirmations from messages you’ve sent out.

What are the benefits?

By being ready to accept UETRs, you can 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.