A single identifier binding quote, pro forma invoice, incoming payment, settlement, allocation and the resulting document set to one instruction. It is issued by the seller when the quote is issued, before any money moves, which is what allows it to be quoted in the payment that follows. On a purchase funded from digital assets it is the value that lets a fiat settlement arriving from a licensed digital-asset platform post against one gold purchase instruction instead of landing as an unattributed credit. It is not a payment identifier: the payment rails issue their own, and none of them states what the money is for.
What the reference is attached to
The reference is not a field on one document. It is the value repeated across every document a single purchase produces, which is what makes those documents readable as one transaction rather than as correspondence from four parties.
| Stage | Document or record | What the reference establishes there |
|---|---|---|
| Quote | Executable quote | The instruction has an identity before it has an accepted price |
| Advance | Pro forma invoice for advance payment | States the value the payment must quote; the advance is bound to this instruction and no other |
| Payment | Gateway payment or bank transfer | Carries the reference into the payer’s leg of the chain |
| Settlement | Fiat settlement received | Lets the incoming amount be applied to the instruction rather than held |
| Price fixation | Fixed price recorded against the instruction | Fixes which instruction the fixation applies to, and therefore which advance determines quantity |
| Allocation | Allocation Record — serial number, weight, fineness, refiner | Ties identified bars to the instruction that paid for them |
| Placement | Brink’s placement confirmation | Records the placement of those bars against the same value |
| Title | Confirmation of title to the bars | Names the counterparty against identified metal |
| Invoicing | Commercial invoice on the bars actually allocated | Reconciles the final invoice to the advance received |
| Record | The assembled Evidence Set | One value across every output, so the set reconciles without interpretation |
The last row is the operative one. An Evidence Set whose components each carry a different identifier is a set of documents about a purchase; an Evidence Set in which every component carries one identifier is the purchase.
Who issues it, and when
The seller issues it, at the quote. That timing is the whole mechanism. A reference minted at settlement can only be applied backwards, which makes reconciliation a judgement about which instruction an amount most likely belongs to. A reference issued before the first payment can be stated on the pro forma, quoted by the payer, and carried forward by everyone downstream.
On a route funded from digital assets the backwards method has nothing to work with at all. The money that reaches the seller does not come from the buyer: the buyer pays a payment gateway in digital assets, the platform screens and converts under its own licence, and what arrives is a fiat remittance from a party the seller has no purchase contract with. Amount, date and sender are all consistent with a dozen possible instructions. The reference is the only thing that is not.
Three identifier spaces, and what each one can tell a reviewer
Each leg of the purchase issues identifiers of its own. Each is authoritative inside its own system and silent outside it.
The chain. A transfer on a public chain carries no field for a commercial reference. What it carries is a transaction hash, which identifies the transfer and says nothing about what the transfer pays for. For the assets used on this route, there is no invoice line to populate.
The gateway. The platform issues its own payment or session identifier. It resolves inside the platform’s records, is meaningful to the platform’s own compliance file, and is not a value the seller’s register is built around.
The bank leg. The remittance that settles the seller carries two identifiers, and they are not interchangeable — see below.
The metal. Bar serial numbers are issued by the refiner and stamped on the bar. The vault register entry belongs to the Vault Operator. The Allocation Record is the seller’s own record of which of those bars answer to which counterparty.
Alongside these sit the seller’s internal references, which are not the order reference and do not substitute for it. A verified counterparty is recorded as verified with a date and an internal reference; the screening report behind that decision stays internal. Under the Terms and Conditions, a claim is opened by a notice stating the instruction reference and is then assessed against the instruction log and the Evidence Set. Whatever value a counterparty’s documents actually carry is the value a claim will be reconstructed around years later, which is a reason to check it at issue rather than at dispute.
How the reference survives the bank leg
Since 22 November 2025 the coexistence period between MT and ISO 20022 messaging has ended for cross-border payments and reporting under CBPR+, and the MT messages those flows relied on are no longer accepted for in-scope traffic. Cross-border settlement now arrives in structured messages, which changes where a reference can sit and what happens to it in transit.
Two references travel with a cross-border credit transfer:
- The UETR — a 36-character identifier in UUID version 4 form, generated by the sending bank, mandatory on Swift payment instructions since November 2018, and passed unchanged through every correspondent in the chain. It locates the payment. It says nothing about its purpose.
- The end-to-end identification — the debtor’s own reference, passed unchanged along the chain and reported to the creditor. This is the field a commercial reference belongs in, and the only one of the two that can carry it.
Three properties of that field decide whether a reference arrives intact.
It is mandatory, and the standard has a codeword for its absence. Where the debtor supplies no reference, the debtor’s bank may populate NOTPROVIDED to satisfy the field. A settlement carrying that value is unattributable by construction at the receiving end: nothing was lost in transit, nothing can be recovered by investigation, and the amount is identified only by what the payer can later be asked to confirm.
Unstructured remittance information is capped at 140 characters in a single field, and in cross-border practice banks treat structured remittance as requiring bilateral agreement, which keeps its reach narrow. A reference written into a free-text narrative alongside other wording is therefore exposed to truncation and to whatever an intermediary does with the field. A reference placed in the dedicated reference element is not.
A reference can be machine-checkable. ISO 11649 defines a structured creditor reference for exactly this purpose: the letters RF, two check digits, and up to 21 alphanumeric characters, 25 in total, with the check digits computed under the same modulo-97 scheme used for an IBAN. Where a seller issues references in that form, a corrupted or mistyped reference fails validation instead of posting silently against the wrong instruction. The format the seller chooses is therefore a decision about whether an error is caught by a machine or by a person — the difference between a payment that bounces on day one and one that reconciles wrongly for a month.
What goes wrong
The payment arrives without a reference. It becomes an unattributed credit: held, not applied. The instruction stays exactly where it was, allocation does not begin, and the fixation the counterparty is waiting on has nothing to attach to. The delay is not administrative — under the Terms and Conditions, an instruction that depends on payment executes only once the contractual payment leg is recorded as completed.
The reference arrives damaged. Truncated at a field limit, merged into a narrative, or re-keyed by hand somewhere in the chain. Damage is recoverable, but only by asking the payer to confirm what was sent, which puts the timeline in a third party’s queue.
One reference covers two things. A second payment quoting the reference of a closed instruction, or one reference used across two instructions, ends the one-to-one relationship the whole mechanism depends on. Reconciliation reverts to judgement, and the document set stops being self-evidencing.
The reference is correct and the payer is wrong. A reference identifies the instruction, not the person paying. Funds arriving from a party other than the contracting counterparty raise source-of-funds and beneficial-ownership questions that no reference answers; the review is recorded against the reference, but it is not shortened by it.
A rejection the reference cannot prevent. From 14 November 2026, CBPR+ payment messages no longer accept fully unstructured postal addresses; non-compliant messages are rejected outright, with no contingency measure. That rejection happens at the network layer, before any reference is read. For a counterparty funding a purchase from its own bank, the structure of its address data held at that bank has become a settlement dependency in its own right.
The one identifier nobody who moves the money issues
Every other identifier in the chain is minted by a party performing a leg, and inherits that party’s boundaries. The transaction hash belongs to the chain. The gateway identifier belongs to the platform. The UETR belongs to the sending bank. The serial number belongs to the refiner. The register entry belongs to the Vault Operator. Each is authoritative about its own leg and mute about every other one, and none of them was created with the purchase in view, because on most of those legs the purchase is not the subject — the transfer is.
The order reference is the exception. It is issued by the seller before the first leg begins, by a party that moves neither the digital assets nor the fiat nor the metal, and it appears in all of them.
That is what makes the reconciliation possible without a hierarchy of trust. A reviewer does not have to decide whose system of record governs. The hash proves a transfer occurred. The settlement message proves an amount arrived. The vault register proves specific bars are named to a counterparty. The reference is what makes those three statements about the same purchase — and it does so from outside all three, which is precisely why none of them can be wrong about it in a way the others conceal.
It also outlives the arrangement. Platforms are replaced, correspondents change, operators are substituted under the third-party operator model, and each substitution retires a set of internal identifiers with it. The reference is the value that lets the file be read after all of them have gone, which is the state in which most evidence sets are eventually read.
Where the reference is issued and carried
The route that issues it, and the documents it appears on, are set out on Buy Allocated Physical Gold with Crypto. The screening and source-of-funds controls recorded against it sit under Compliance & Legal, and the Evidence Set those documents form is defined in the glossary.