Ever Pro Stack
// tool

UETR Generator

Generate a valid Unique End-to-end Transaction Reference for SWIFT gpi and ISO 20022 payments. A UETR is a UUID version 4 in canonical lowercase: this tool produces it in the exact form MT103 field 121 and pacs.008 will accept, and shows you where to put it.

Generated in your browser with the Web Crypto API. Nothing is sent to a server, nothing is logged. Reload for a completely different set.

Output

–

Anatomy of the first UETR

// how to use

How to use this tool

  1. Leave the case on lowercase. SWIFT’s specification is explicit about this, and some validators reject uppercase outright even though the value is otherwise identical.
  2. Set how many you need. One per payment instruction: a UETR is never reused across transactions.
  3. Pick an output shape: a plain list for testing, MT103 field 121 for the Block 3 header form, or pacs.008 XML for the ISO 20022 element.
  4. Check the Anatomy panel. The version nibble must be 4 and the variant nibble must be 8, 9, a or b: those two positions are what a receiving validator checks first.
  5. Copy the batch. Nothing here is stored, so keep your own record of which UETR went with which instruction.

A UETR: Unique End-to-end Transaction Reference, is the 36-character string that makes a cross-border payment traceable. The originating institution mints one, and every intermediary in the chain must carry the same value forward untouched. That single rule is what makes SWIFT gpi tracking work: any party holding the reference can locate the payment at any point in the chain, because the identifier never changes.

Structurally a UETR is nothing exotic. It is a UUID version 4 as defined in RFC 4122: 32 hexadecimal characters arranged in five groups of 8-4-4-4-12, separated by hyphens, written in lowercase. Two positions are not random. The first character of the third group is always 4, marking the version, and the first character of the fourth group is always 8, 9, a or b, marking the RFC 4122 variant. The remaining 122 bits are random. That is the whole specification.

Because it is an ordinary UUIDv4, a generic UUID generator will usually produce something acceptable: which is exactly why people reach for one. The failure modes are in the details rather than the algorithm. Uppercase output is the most common: many UUID tools default to uppercase or offer it as a toggle, and while the value is mathematically the same, SWIFT’s canonical form is lowercase and some validators reject the uppercase variant. Braces and dash-stripped formats, both common options in general-purpose tools, are straightforwardly invalid here.

The second trap is reuse. A UETR identifies one payment instruction for its entire life. Generating a batch and recycling them across test runs will produce confusing results in any system that keys on the reference, and in production it breaks traceability outright. Intermediaries must never mint a fresh UETR when routing: their systems are required to receive, copy and pass on whatever arrived.

Where the value physically sits depends on the message format. On an MT103 it lives in the Block 3 user header as field 121. On a pacs.008 under CBPR+ it is the UETR element at CdtTrfTxInf > PmtId > UETR, and it is mandatory on every cross-border message. The value is identical across both layouts, which is precisely what allows gpi tracking to survive the ISO 20022 migration: an MT103 converted to pacs.008 keeps its reference, and the payment stays traceable across the format boundary.

// faq

Frequently asked questions

Is a UETR just a UUID?

Yes: a UETR is a UUID version 4 with additional conventions applied. The generation algorithm is identical. What differs is the presentation and usage rules: lowercase only, hyphenated 8-4-4-4-12 form only, one per payment instruction, and never regenerated by an intermediary. A generic UUIDv4 will satisfy the format; it is the conventions that trip people up.

Can I use a UUID v7 as a UETR?

No. The specification requires version 4 specifically, and a validator checks the version nibble: the first character of the third group. A v7 UUID carries 7 there and will be rejected. v7’s embedded timestamp would also leak payment creation time, which is not something you want in a reference that travels across every intermediary in the chain.

Does uppercase actually matter?

Often yes. The value is the same hexadecimal number either way, but SWIFT’s canonical representation is lowercase and implementations vary in how strictly they enforce it. Some accept either; some reject uppercase at the schema level. Since lowercase is always accepted and uppercase sometimes is not, there is no reason to send uppercase. This tool warns you if you switch.

Where exactly does the UETR go in the message?

On an MT103 it is field 121 in the Block 3 user header, written as {3:{121:...}}. On a pacs.008 it is the UETR element inside PmtId, with the full path CdtTrfTxInf > PmtId > UETR. Under CBPR+ it is mandatory on every cross-border pacs.008. Switch the output mode above to see either form.

Should I generate UETRs in advance?

Generally no. Mint one at the point you create the payment instruction and record the pairing immediately. Pre-generating a pool invites reuse, and a reused UETR corrupts traceability for both payments involved. For testing this matters less, but keep test and production references clearly separated.

Are these generated on your server?

No. Every value is produced inside your browser using the Web Crypto API, which draws from your operating system’s cryptographic random source. Nothing is transmitted, logged or stored. Reload the page and you get a completely different set.

// related

Related tools