The end-to-end transaction reference is a reference assigned by the party that initiates a payment, normally the debtor (the payer) or its software, which must be passed unchanged through every bank in the chain to the creditor (the payee). In ISO 20022 messages it is the EndToEndId element, a text field of up to 35 characters, found in the customer's initiation message (pain.001), the interbank transfer (pacs.008) and related status, return and reporting messages.
Its purpose is to let the payer and payee recognise the payment in their own terms, for example by an invoice or payroll batch number. It is often confused with the Unique End-to-End Transaction Reference (UETR), a machine-generated global identifier used for tracking. The two have similar names and both stay constant from end to end, but they are set by different parties for different jobs, and a payment normally carries both.
End-to-end transaction reference in plain terms
Imagine posting a cheque to a supplier with a sticky note saying "Invoice 4471". The note is your own label. Every post office that handles the envelope must leave it alone, so that when the supplier opens it they know exactly what the money is for.
The end-to-end transaction reference is that sticky note on an electronic payment. The postal service may also print its own barcode on the envelope so it can track where the letter is; that is closer to the UETR. The barcode is for the carriers, the sticky note is for the sender and the receiver. Both survive the journey, but they answer different questions.
Rules for use
- Set once. The initiating party chooses the value. Banks must not change it, though they may fill it with
NOTPROVIDEDwhen the customer gave none, a convention used in several market guidelines. - Carried unchanged. Each agent, including any intermediary bank, must copy it into the next message, even when it creates new message headers and its own references.
- Returned with the money. If the payment is rejected or a returned payment is sent back, the original value is quoted so the payer can match the return.
- Uniqueness. ISO 20022 does not require it to be globally unique. The payer is expected to keep it unique within its own records, which is why it cannot replace the UETR for tracking.
How it differs from other payment references
An ISO 20022 credit transfer carries several references, each with its own scope:
| Reference | Set by | Scope | Main use |
|---|---|---|---|
Instruction ID (InstrId) | Each instructing party | One hop, point to point | Link between sender and next party |
End-to-end ID (EndToEndId) | Debtor or initiating party | Whole chain, unchanged | Payer and payee identification |
Transaction ID (TxId) | First instructing agent | Interbank chain | Interbank identification |
| UETR | Usually the debtor's bank | Whole chain, globally unique | Tracking, for example in SWIFT GPI |
The business message identifier in the ISO 20022 Business Application Header (BAH) is different again: it identifies one message, not the transaction, and changes at each hop.
Uses in practice
For a corporate payer, the end-to-end reference is the key that ties the bank's status reports and statements back to its own payment run. When the debtor's bank sends a pacs.002 status report or a camt.054 notification, the reference lets the company's system mark exactly which payment succeeded or failed. For the creditor, it supports payment reference matching and cash application, especially in business-to-business flows where the payer puts its invoice or remittance number in the field.
It also helps with a payment investigation: a customer who asks "where is my payment?" can quote their own reference rather than a bank-generated code. In practice banks combine it with the UETR, which drives tracking tools, and with the beneficiary bank's statement entries.
History and migration
The SWIFT MT103 had no dedicated field for a customer end-to-end reference. Banks carried such references in free-text fields, where they were often truncated or dropped, which made matching difficult. ISO 20022 made the reference a mandatory, named element. The European SEPA schemes adopted it early, and its use has spread as large systems migrated: Swift's coexistence period for cross-border payment instructions ended on 22 November 2025, and real-time schemes such as FedNow use ISO 20022 natively. Validation rules in many schemes now reject a credit transfer with the field missing, so it is checked as part of payment message validation.
Firms that build payment files should therefore generate a meaningful value for every transaction, such as the invoice or payroll reference, rather than leaving it blank or repeating one batch number across many payments. A repeated or empty value still passes most schemes but makes the reference useless for matching and investigation.