Explained: SWIFT gpi UETR – Unique End-to-End Transaction Reference

At the heart of the SWIFT gpi initiative is something called the UETR. In this post, i will share everything i know and likely you need to know about the UETR. So let’s jump straight into it…

What is SWIFT gpi?

Before we delve into the UETR, we need to know what the SWIFT gpi is. In a nutshell SWIFT gpi refers to SWIFT’s Global Payments Innovation initiative, enabling:

  • Faster payments – enabling same day use of funds
  • Transparency of fees
  • End to end visibility/tracking of payments
  • Complete and unaltered remittance information

As mentioned above, driving the SWIFT gpi initiative is the UETR….

What is the UETR – Unique End-to-End Transaction Reference?

As stated already the UETR is a Unique End-to-End Transaction Reference. The UETR is:

  • The SWIFT cross border payments equivalent of your parcel tracking number
  • Generated by the Payer and passed through, without modification, the SWIFT network and any intermediary banks through to the Payee (beneficiary)
  • Used within the SWIFT gpi Tracker to enable banks and corporates to track and monitor in real time the end to end progress of all gpi payments

Which Message Types Require the UETR – Unique End to End Transaction Reference?

The SWIFT Standard MT Release 2018 requires you to populate (it is currently optional) the UETR in the FIN user header (block 3) for the following MT messages:

  • MT103
  • MT103 REMIT
  • MT103 STP
  • MT202
  • MT202 COV
  • MT205
  • MT205 COV

What are the UETR SWIFT Format Requirements?

As stated above, the SWIFT Standard MT Release 2018 makes it mandatory for you to add the UETR in field 121 within block 3 of the FIN header.

The UETR (Unique End to End Transaction Reference) must be:

  • Unique – As the name of the field indicates this is intended to be a globally unique value, not just unique to your organisation
    • Adhering to the Universal Unique Identifier (UUID) or Globally Unique Identifier (GUID) which is compliant with IETF standard RFC4122, version 4 of the generation algorithm
    • Follow the link for further details about generating the UUID, Universal Unique Identifier
    • Check out this overview around how to generate a UUID compliant with RFC 4122
  • Assigned by the initiating party
  • Indicated in field 121 within block 3 of the MT header
  • 36 characters – made up to 32 hexadecimal characters, shown in  5 parts divided by hyphens/dashes as follows:
    • xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
    • Where:
      • x is any lowercase hexadecimal character
      • 4 – fixed value
      • y – either: 8, 9, a, b

Where to indicate the UETR Field 121 in the SWIFT Header Block 3

If you’re new to SWIFT formatting, i would recommend having a read of my earlier post The Structure Of A SWIFT Message, Explained! That post deals with a MT101 header, but the idea is the same. Note, below i have indicated in bold the message type (103). Here is what your existing MT103 header looks like:

{1:F01YOURCODEZABC1234567890}{2:I103YOURBANKXJKLU3003}{3:{113:SEPA}{108:ILOVESEPA}}{4: 

and now with the UETR you must generate something like this:

{1:F01YOURCODEZABC1234567890}{2:I103YOURBANKXJKLU3003}{3:{113:SEPA}{108:ILOVESEPA}{121:xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx}}{4: 

When SWIFT gpi is released to the broader corporate user base, you’ll indicate field 121 in your MT101 header in exactly the same way. Easy peasey, eh?

Thanks for stopping by – Take a look around…!!

What is the Service Type Identifier Field 111?

Field 111 is to be placed in the header section block 3, and is to be used as indicated below by SWIFT gpi members only:

{1:F01YOURCODEZABC1234567890}{2:I103YOURBANKXJKLU3003}{3:{113:SEPA}{108:ILOVESEPA}{111:001}{121:xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx}}{4: 

Couple of things to note:

  • Depending on whether you are a gpi-bank or not, you will either add or drop field 111
  • Values will be:
    • 001 – to be used for:
      • 001 – SWIFT gpi Customer Credit Transfer (gCCT)
      • 001- SWIFT gpi Cover services (gCOV)
    • 002 – will be used in the future for the SWIFT gpi Stop and Recall (gSRP) service
    • ??? – for future services

Okay, I have a generated the UETR – What Next?

  • For the above stated message types, you (banks, corporates, message initiator) must ensure the UETR is generated and indicated in the header (block 3), even if you are not a SWIFT gpi bank / registered institution
  • As a receiving bank you must be able to receive the UETR value in the header block 3 of the MT message
  • If you are an intermediary, you must pass on this UETR value unchanged to the next bank
  • The above requirements are available to test in the T&T (Test and Training) environment right now, and will go live on 18th November, 2018 (based on the annual SWIFT Standard MT Release schedule)

Good luck! 😉

 

Further information can be found at:

Leave a Reply