Last reviewed: · Curated by Ohmyfin Organisation editorial.
Field 121 is the UETR — the globally unique tracking ID mandatory on every SWIFT payment since November 2018. Track any UETR free on Ohmyfin → · Full UETR guide →
Field 121 appears inside block 3 (User Header) of the SWIFT MT message, formatted as {121:xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx}. The value is a UUID v4 — a Universally Unique Identifier version 4 — in the standard format of 8-4-4-4-12 hexadecimal characters separated by dashes (36 characters total including the dashes). The third group always begins with the digit "4", identifying it as UUID version 4. UUID v4 values are generated using random or pseudo-random bits, making them statistically unique across all banks worldwide without any central coordination.
The originating bank generates the UETR when the MT103 is first created. This UETR is then protected: every subsequent bank in the chain is required by the SWIFT GPI Rulebook to pass it through unchanged. No bank may alter, strip, or regenerate the UETR. If a bank translates the MT103 to ISO 20022 pacs.008 or vice versa during routing (using SWIFT's in-network translation service), the UETR is preserved in the UETR XML element of the pacs.008 message. This permanence makes field 121 the most reliable tracking key available for any SWIFT payment.
On the SWIFT GPI tracker, every bank that processes a payment with a given UETR must post a status update (one of: ACSP, ACSC, ACCC, ACWP, RJCT, CANC, PDNG) within minutes of processing it. These status updates, all keyed by the UETR, form the real-time tracking record that Ohmyfin queries. When you paste a UETR into Ohmyfin, Ohmyfin retrieves the latest available status from the SWIFT GPI network and shows: the current bank holding the payment, the status code, the value date, the currency and amount, and the fees deducted at each hop so far.
Field 121 (UETR) is distinct from field 20 (Sender's Reference / TRN): the TRN is assigned by and unique within the sending bank. The UETR is globally unique, generated by the originating bank, and identical at every bank throughout the chain. For end-to-end tracking, always use the UETR. The TRN (field 20) is useful only for looking up a payment at the specific bank that assigned that TRN.
UUID v4 collision resistance: the probability that two different banks independently generate the same UETR is astronomically small — approximately 1 in 5 × 10^36. In the history of SWIFT GPI since 2018, no UETR collision has been recorded. SWIFT GPI banks are required to reject any incoming payment that carries a UETR they have already seen (a replay-attack prevention mechanism). The originating bank must guarantee the uniqueness of the UETR it generates; most implementations use a cryptographically secure random-number generator or the OS-provided UUID generation library.
| Example value | :121:12345678-1234-4abc-9def-1234567890ab |
|---|---|
| Valid characters / format | 36-char UUID v4 hex 8-4-4-4-12 |
| Required on MT103 | Mandatory |
| Required on MT202 | Mandatory |
| Required on pacs.008 | Mandatory |
| Notes | UETR. Mandatory since November 2018 — primary tracking key on GPI / pacs.002. |
Look inside block 3 (User Header) of the MT103 for the tag {121:...}. The UETR is the 36-character UUID value after "121:". It looks like: a1b2c3d4-5e6f-4a7b-8c9d-0e1f2a3b4c5d. In a pacs.008 XML message, the UETR is in the <UETR> element inside CdtTrfTxInf.
Ask your sending bank for the SWIFT GPI payment confirmation. The UETR (field 121) is a 36-character code in the format xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx. Many online banking platforms now display it on the payment receipt as "GPI Reference" or "UETR". If your bank does not show it, request it explicitly — GPI member banks are obligated to provide it.
No — the UETR is immutable. Every bank in the chain is required by the SWIFT GPI Rulebook to pass the UETR through unchanged. If a bank alters or regenerates the UETR, it is in violation of GPI Rulebook obligations. This protection is what makes the UETR a reliable end-to-end tracking key.
The UETR value itself is identical — it is the same 36-character UUID regardless of whether the payment is an MT103 or a pacs.008. In MT103 it appears as {121:...} in block 3. In pacs.008 XML it appears as the <UETR> element inside CdtTrfTxInf. SWIFT's in-network translation service preserves the UETR when converting between formats.
UUID v4 (Universally Unique Identifier version 4) is a randomly generated 128-bit identifier formatted as 8-4-4-4-12 hexadecimal groups. It was chosen for UETRs because: (1) the format is an established standard with excellent library support in all programming languages; (2) UUID v4 requires no central coordination to generate — any bank can generate a unique value independently; (3) the collision probability is astronomically small (~1 in 5×10^36), making accidental duplication essentially impossible.
No card needed. Free for ordinary users — completely free for individuals — no daily limit, no card required. Track any international wire across 11,000+ banks.
Track a payment now — completely free Or try the tracker now →