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

IN ONE LINE

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.

WHAT IT ACTUALLY IS

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.

HOW IT WORKS

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.