Point-to-point versus end-to-end references

L0 Explain simply

Analogy: a parcel's internal note versus its tracking number. A courier depot might scribble its own handling note on a parcel — a shelf code, a route number — that means something only to that depot and gets replaced at the next one. But the tracking number printed on the label stays the same from the moment the sender books the parcel to the moment it is delivered, and it is the one thing every depot along the way can use to answer "where is this parcel, and is it the same one Asha Traders sent on Tuesday?" A payment carries both kinds of reference at once, and only one of them is safe to quote three banks later.

L1 Core concepts

A point-to-point reference, most importantly the instruction identification, is created fresh by whichever bank sends a given message and is meaningful only to that bank and its immediate receiver — the next bank in the chain is free to replace it with a reference of its own devising. Set against that are two end-to-end references that must travel unchanged through every hop: the end-to-end identification, assigned once by the debtor (or the debtor's bank, if none was given) and reported all the way to the creditor, and the UETR — the unique end-to-end transaction reference — a globally unique identifier in UUID format created for the payment and never reissued at any later hop.

Instruction identificationEnd-to-end identificationUETR

L2 Practitioner view

The practical split is: point-to-point references are for a bank's own bookkeeping between it and its immediate counterparty, and end-to-end references are for anyone asking "what happened to this specific payment" across the whole chain. An investigation into a delayed or misdirected payment leans on the end-to-end identification and the UETR precisely because those are the two things every bank in the chain saw and kept unchanged — asking a downstream bank for "the instruction identification" is asking a question that only makes sense for the one hop that created it. This is also why tracking services built on top of the network, which need to show a payment's status across every bank it has touched, are built around the UETR rather than any bank's internal reference.

L3 Technical details

Illustrative chain: Bank Alfa sends a pacs.009 to Meridian Bank with instruction identification ALFA-REF-0091, end-to-end identification ASHA-INV-4471 (set by Asha Traders and carried in from the original instruction), and UETR 7c1e2b9a-.... Meridian forwards the payment to Nordbank as a new message — it is free to assign its own instruction identification, say MRDN-OUT-0250, because that field is private to the Meridian-to-Nordbank hop. But the end-to-end identification ASHA-INV-4471 and the UETR 7c1e2b9a-... travel into Meridian's outbound message completely unchanged, and Nordbank reports the same end-to-end identification to the supplier. Three different instruction identifications existed across this chain; exactly one end-to-end identification and one UETR did.

L4 Standards & sources

CBPR+ usage guidance keeps the instruction identification to a maximum of 16 characters — the same length as field 20 in the equivalent MT message, so the two standards stay comparable during coexistence. The UETR must be generated as a version-4 UUID: if the debtor's own instruction never carried one, the debtor's bank is the one that has to create it, and every later hop is required to pass it on unchanged rather than generate a fresh one. Where a debtor gives no end-to-end identification at all, CBPR+ usage guidance directs the debtor agent to populate the fixed value NOTPROVIDED, since the element is mandatory even when the debtor supplied nothing meaningful to put in it.