UETR: the unique tracking reference

The Unique End to end Transaction Reference, known as the UETR, is the identifier that makes gpi tracking possible, and every analyst who works on cross border payments must understand it. The UETR is a thirty six character string in the format of a universally unique identifier, for example a string of letters and numbers separated by hyphens, and it is generated by the sending bank when the payment is created. The UETR stays with the payment through every bank in the chain, through every conversion, and through every return or recall, so that the payment can be identified at any point by a single reference. Unlike the sender's own reference, which can change as the payment passes through different systems, the UETR is never changed, and every bank must carry it forward. The UETR is carried in the SWIFT message, in the ISO 20022 pacs.008 message, and in the gpi tracker, so that all three views of the payment can be linked together. In the MT world, the UETR is carried in field 121 of the MT103, in the user header block. In ISO 20022, the UETR is carried in the UETR element of the pacs.008, in the pacs.002 status report, in the pacs.004 return, and in the pacs.009 COV for cover payments. When a customer asks where their payment is, the operations team searches the tracker by UETR and sees the full journey. When a bank needs to investigate a payment, it quotes the UETR, and every other bank can find the same payment in its own system. When a payment is returned, the return message carries the same UETR, so that the return can be matched to the original payment without ambiguity. The UETR is also used in the cover payment, where the pacs.009 COV carries the UETR of the customer payment it covers, so that the funds leg and the instruction leg can be matched. A business analyst must ensure that the system generates a UETR for every cross border payment, stores it, shows it to the customer, and includes it in every message and every report. The UETR must be generated as a version 4 universally unique identifier, using a random number generator, and it must be unique across all payments, because a duplicate UETR would cause two payments to be confused. The UETR is a simple idea with a large impact, because it solves the oldest problem in cross border payments. The payment changes its identity as it moves. Before the UETR, a payment could have one reference at the sending bank, a different reference at the intermediary bank, and a third reference at the receiving bank, and tracing it meant matching amounts and dates by hand. With the UETR, the payment has one identity from start to finish, and tracing it is a lookup, not a detective exercise. The analyst should treat the UETR as a first class field in the data model, not as an optional extra, and should test that it survives every transformation in the payment flow, including currency conversion, charge deduction, and repair. If a payment is repaired, for example because the beneficiary name was corrected, the UETR must not change, because the repaired payment is the same payment. If a payment is split into two payments, for example because of a limit, each part must get its own UETR, because they are now two payments. If a payment is returned and resent, the resent payment must get a new UETR, because it is a new payment, but the return must carry the original UETR so that it can be matched. If a cover payment is generated, it must carry the UETR of the customer payment it covers, not a new UETR. Each of these rules must be specified and tested, because a system that gets the UETR wrong will produce payments that cannot be traced, and a payment that cannot be traced is a payment that cannot be supported. The payment record must store the UETR, the sender's reference, the end to end reference, and the transaction reference, and must link them together. The UETR must be indexed so that a lookup by UETR is fast, even when the database holds millions of payments. The UETR must be shown on the customer portal, on the receipt, and in the operations screens, so that the customer and the operations team are using the same reference. The UETR must be included in the audit trail, so that every action on the payment can be traced back to the same identifier. And the UETR must be carried in every message, including the pacs.002 status report, the pacs.004 return, and the camt.056 recall, so that the exception messages can be matched to the original payment. The analyst should also know that the UETR is mandatory for gpi payments, and that SWIFT will reject a gpi payment that does not carry a UETR. For non gpi payments, the UETR is strongly recommended, and most banks now generate it for all cross border payments, because it costs nothing and it makes every payment traceable. The CBPR+ migration to ISO 20022 made the UETR a standard element of the pacs.008, and the market practice is to generate it for every payment, not just for gpi. The analyst who is designing a new payment product should specify that a UETR is generated for every cross border payment, without exception, and should test that it is present in every message the system generates. Finally, the UETR is the key to the customer experience. A customer who is given a UETR can track their payment on the bank's portal, can quote it when they call the bank, and can give it to the beneficiary so that the beneficiary can ask their own bank about the same payment. A customer who is not given a UETR must rely on the bank's internal reference, which the beneficiary's bank cannot use. The analyst should therefore ensure that the UETR is shown to the customer at the point of instruction, on the confirmation screen, and on the receipt, and that the portal allows the customer to search by UETR. That is a small design decision with a large impact on customer satisfaction.