UETR

Before SWIFT GPI, tracing a cross-border payment across correspondent banks required each bank to query its own records using whatever reference it assigned to that leg. If you had three correspondents in a chain, you had three different references and no way to correlate them without phone calls. The UETR solves that.

What the UETR Is

A UETR is a UUID version 4 — 32 hexadecimal digits in the format xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, 36 characters including hyphens. It is set by the originating bank when the payment instruction is created and must remain unchanged through every hop: every intermediate correspondent, every CSM, every local clearing system the message touches. Banks in the chain are not permitted to modify it.

In the legacy MT world, the UETR was carried in block 3, field {121} of an MT103. In ISO 20022 pacs.008 messages (which replaced MT103 under CBPR+), the UETR lives in CdtTrfTxInf/PmtId/UETR. The field name and structure differ; the UUID is the same.

Why It Matters to Operators

It is the reference to quote. When you contact your bank about a missing or delayed cross-border payment, the UETR is the first thing the enquiry team will ask for — and with it, any GPI-enabled bank in the chain can pull the full status record in seconds. Without it, the investigation starts with the bank’s internal reference, which may not be visible to the beneficiary’s bank.

It enables real-time tracking. SWIFT GPI’s tracker service exposes the UETR’s status — which banks have processed the payment, what fees were deducted at each hop, and the current confirmation state. For operators with high-value or time-sensitive cross-border payments, surfacing the UETR to your treasury team means you can monitor payment status without calling your bank. The full tracking workflow is covered in the tracing SWIFT payments guide.

Point-to-point references change; the UETR does not. Your bank assigns an internal transaction reference (TxId or instruction reference) for its own leg of the payment. The beneficiary bank assigns a different reference for crediting the account. These are leg-level references. The UETR is the only constant across all legs — it is the cross-chain identifier.

What the UETR Is Not

The UETR is not a guarantee of payment arrival, a settlement confirmation, or a proof of credit. It is a reference identifier. Carrying a UETR does not mean the payment has been credited to the beneficiary — it means the payment can be tracked. If the UETR status shows the payment has been credited at the beneficiary bank but the beneficiary has not received the funds, the problem is likely in the beneficiary bank’s internal crediting process (a different investigation from the cross-border tracing problem).

The UETR is also distinct from the end-to-end ID (EndToEndId) in ISO 20022 messages. The end-to-end ID is typically set by the payment originator (the corporate customer, not the bank) and carries business references like invoice numbers. The UETR is set by the originating bank and is a pure tracking identifier. Both travel through the pacs.008; they serve different purposes.