How do I read a UETR and use it to track a payment?

What it means

A UETR looks like 03a264a8-0c0a-4b2f-965e-658907f96da2: 32 hexadecimal characters in five groups of 8, 4, 4, 4 and 12, separated by hyphens, 36 characters in total. It follows the UUID version 4 layout (RFC 4122): the first character of the third group is always 4, and the first character of the fourth group is always 8, 9, a or b. Everything else is random. The letters are lower case: the ISO 20022 schema pattern for the UETR only accepts a to f.

In MT the UETR is not in block 4 with the business fields. It is field 121 in the user header, block 3: {3:{121:03a264a8-0c0a-4b2f-965e-658907f96da2}}. Since the November 2018 standards release, block 3 with field 121 is mandatory in the MT103, MT103 STP, MT103 REMIT, MT202, MT202 COV, MT205 and MT205 COV. In ISO 20022 it is an element of the payment identification, next to the instruction, end-to-end and transaction references, and status and return messages point back to it with OrgnlUETR.

The rule for passing it on is short. A bank that receives a payment with a UETR and sends it on must copy the UETR unchanged into its own message. Only the bank that starts the payment creates a new one. In the cover method the MT202COV carries the UETR of the underlying MT103, and its field 21 carries the MT103’s field 20; that is how the cover and the customer payment are tied together. See the cover and serial flow guide.

The UETR is what the Swift Tracker indexes. The MT103 reference guide makes a confirmation to the Tracker (BIC TRCKCHZZ) mandatory for the receiver of an MT103 when it credits the beneficiary or rejects the payment, so the Tracker can show the last bank that acted on it. Customers do not query the Tracker themselves: they give the UETR to their bank, which looks it up.

Common causes

• Upper case letters: a system that converts every field to upper case changes the UETR. The ISO 20022 schema pattern rejects it, and lookups that compare exact strings no longer find the payment.
• An intermediary generated a new UETR instead of copying the one it received. The Tracker then shows two unconnected payments and the trail stops at that bank.
• The MT202COV carries its own new UETR instead of the one from the MT103, so the cover cannot be matched to the customer payment.
• A value that is not a version 4 UUID: a random 36-character string, a version 1 UUID, or a GUID with braces or without hyphens.
• The UETR was placed in block 4 (for example in field 70 or 72) instead of block 3 field 121, or block 3 is missing altogether.
• The customer quotes the field 20 reference or the end-to-end reference to the bank instead of the UETR, so the bank searches the wrong key.

How to fix it

1. Find the UETR: on an MT103 copy look for {121: in the header; on a pacs.008 look for PmtId/UETR; on a camt.053 statement entry look for TxDtls/Refs/UETR.
2. Check its shape: 36 characters, hyphens after characters 8, 13, 18 and 23, a 4 as character 15, one of 8, 9, a or b as character 20, and only lower case 0-9a-f.
3. Give the UETR (not field 20 or the end-to-end reference) to the bank that sent the payment, or look it up yourself if your bank gives you Tracker access. The status shows which bank last confirmed the payment.
4. If the trail stops at a bank, ask that bank directly, quoting the UETR, the amount and the value date. The payment is either still with it or was passed on under a different UETR.
5. If you are a bank passing a payment on, copy field 121 (or PmtId/UETR) from the incoming message without change, and in the cover method put the same UETR in the MT202 COV or pacs.009 COV.
6. Fix the source of a broken UETR: generate version 4 UUIDs in lower case, and exclude field 121 from any upper-case conversion in your interface.

Where the UETR appears. MT locations from the Swift MT reference guides (field 121, user header); MX paths from the ISO 20022 schemas of the versions shown.

Example

ZagTrader Test Bank pays USD 40,000.00 for a customer to a beneficiary at BANKGB2LXXX, using the cover method. The MT103 went straight to BANKGB2LXXX with UETR 03a264a8-0c0a-4b2f-965e-658907f96da2 and reference ZT2610200021. This is the matching MT202 COV to the correspondent BANKUS33XXX: same UETR in field 121, the MT103’s field 20 in field 21.

{1:F01ZAGTAEADAXXX0000000000}{2:I202BANKUS33XXXXN}{3:{119:COV}{121:03a264a8-0c0a-4b2f-965e-658907f96da2}}{4:
:20:ZTC2610200021
:21:ZT2610200021
:32A:261022USD40000,00
:58A:BANKGB2LXXX
:50F:/AE070331234567890123456
1/GULF TRADING LLC
2/OFFICE 1204 BUSINESS BAY TOWER
3/AE/DUBAI
:59F:/GB42BANK40051587654321
1/ACME COMPONENTS LTD
2/1 HIGH STREET
3/GB/LONDON
:70:/INV/2026-0470
:33B:USD40000,00
-}

{119:COV} in block 3 marks the MT202 as the COV variant.

Field 121 holds the UETR: 36 characters, a 4 at position 15 and 9 at position 20, all lower case.

Field 21 repeats the MT103’s field 20, so the two messages can be paired even without the UETR.

BICs, names, IBANs and the UETR are made up; the IBANs carry valid check digits.

Questions

What is a UETR?

A Unique End-to-end Transaction Reference: a 36-character identifier in UUID version 4 format that stays the same from the first bank to the last bank of a payment, so every bank (and the Tracker) can identify the same payment.

Where is the UETR on an MT103?

In the user header block (block 3), field 121, before block 4. For example {3:{121:03a264a8-0c0a-4b2f-965e-658907f96da2}}. It is not one of the numbered fields in the message text.

Is the UETR the same as the end-to-end reference?

No. The end-to-end reference (EndToEndId in pacs.008, up to 35 characters) is chosen by the customer or the first bank and can repeat across payments. The UETR is a generated UUID that must be unique per payment.

Can I track a payment myself with the UETR?

The Tracker is a service for banks. Give the UETR to your bank: it can see which bank last confirmed the payment and whether it was credited or rejected.

Why is my UETR rejected as invalid?

Usually because it contains upper case letters, has no 4 at position 15, has something other than 8, 9, a or b at position 20, or is not 36 characters long. Generate a lower case UUID version 4.

Messages involved

• MT103Single Customer Credit Transfer
• MT202General Financial Institution Transfer
• MT202COVGeneral Financial Institution Transfer (cover payment)
• pacs.008FI to FI Customer Credit Transfer
• pacs.009Financial Institution Credit Transfer
• pacs.002FI to FI Payment Status Report
• pacs.004Payment Return
• camt.053Bank to Customer Statement

Related problems

• MT103 NAK and error codes
• pacs.002 reason codes
• camt.053 vs MT940
• MX to MT truncation