EndToEndId vs UETR: ISO 20022 Payment References

An ISO 20022 payment carries six identifiers, and they differ by who assigns them and how far they travel: MsgId names a message and PmtInfId a batch inside it, InstrId covers one hop, EndToEndId is yours and is meant to cross the whole chain, TxId belongs to the first bank, and UETR is a universally unique tracking key. Only EndToEndId is both written by you and designed to come back on the statement. The textbook stops there. In practice every one of them is optional in the statement, the party being paid does not reconcile on any of them, and the reference that matters to the creditor sits in a different block altogether — the remittance information.

Everything below is taken from the ISO 20022 message definition reports and schemas, the EPC's SEPA Credit Transfer documents and SWIFT's own UETR pages. Where I could not open a primary source, I say so.

The six references at a glance

What comes back, and under which tag:

Two things stand out. The bank adds references of its own on the way back: AcctSvcrRef and ClrSysRef exist in both the pain.002 transaction block and the statement's Refs, each 0..1. And on the statement side every reference is optional in the schema — nothing in ISO forces a bank to return any of them.

One payment, hop by hop

Follow one supplier payment. You send a pain.001 with all the references you control:

<!-- Illustrative fragment, not a bank-ready file -->
<PmtId>
  <InstrId>ACME-20261004-0001-017</InstrId>
  <EndToEndId>INV-4711</EndToEndId>
</PmtId>
...
<RmtInf>
  <Strd>
    <CdtrRefInf>
      <Tp>
        <CdOrPrtry><Cd>SCOR</Cd></CdOrPrtry>
        <Issr>ISO</Issr>
      </Tp>
      <Ref>RF4220260004711</Ref>
    </CdtrRefInf>
  </Strd>
</RmtInf>

pain.001 to your bank. MsgId and PmtInfId have done their job once the bank has the file; they return in the pain.002 status report at group and batch level. InstrId is, in ISO's words, a point-to-point reference between the instructing party and the instructed party — by definition it makes no promise beyond that hop.

Your bank to the next bank. The bank builds a pacs.008 — the interbank credit transfer — with a new MsgId of its own. The payment identification now looks like this:

<!-- Illustrative fragment, not a real interbank message -->
<PmtId>
  <InstrId>BANKA-HOP1-000981</InstrId>
  <EndToEndId>INV-4711</EndToEndId>
  <TxId>BANKA-2026100400042</TxId>
  <UETR>7a562c67-ca16-48ba-b074-65581be6f011</UETR>
</PmtId>

EndToEndId is copied: ISO defines it as "passed on, unchanged, throughout the entire end-to-end chain", and the pacs.008 definition adds that where technical limitations prevent passing multiple references, the end-to-end identification is the one that must be passed on. TxId is new — assigned by the first instructing agent and passed unchanged through the interbank chain. The pacs.008 carries a rule that TxId or UETR must be present; both may be.

To the beneficiary's bank and account. The remittance information travels alongside the references. In SEPA, the rulebook requires it to be forwarded "in full and without alteration" by every institution in the chain and delivered the same way to the beneficiary.

Back to you. Your debit appears in the camt.054 notification and on the camt.053 statement, where the transaction details can carry EndToEndId, PmtInfId, InstrId, UETR and TxId next to the bank's AcctSvcrRef. The creditor's statement has the same structure, with the same optionality, plus the remittance information.

EndToEndId vs UETR

EndToEndId guarantees one thing by definition: whatever the initiating party wrote is meant to arrive unchanged at every party in the chain. It guarantees nothing about uniqueness beyond your own discipline. It is 35 characters of free text, and two companies can use the same value on the same day.

UETR is the opposite trade. It says nothing about your business — it is 36 characters in a fixed pattern that the schemas name UUIDv4Identifier — but it is universally unique, so any bank in the chain can find the payment by it. On the SWIFT MT side it sits in field 121, in block 3 of the message, and since 18 November 2018 every SWIFT user originating an MT 103, MT 103 STP, MT 103 REMIT, MT 202, MT 205, MT 202 COV or MT 205 COV must provide one. SWIFT's instruction is that the ordering institution generates it, intermediaries pass it on rather than generating a new one, and a cover payment carries a copy of the original. That is the mechanism behind SWIFT gpi tracking, and why the MT 103 and MT 202 COV of one payment share a key.

Note who is missing from that list: the corporate. In pain.001.001.09 and .10, UETR is an optional element you may fill; in pain.001.001.03 the element does not exist — its payment identification holds only InstrId and EndToEndId. On a .03 file the UETR is something the bank creates, not something you issue. As MT messages give way to MX in the ISO 20022 migration, the element simply becomes native. Whether CBPR+ makes UETR mandatory in pacs.008 is a question for SWIFT's usage guidelines, which I could not open for this page; the base ISO schema keeps it 0..1.

When EndToEndId is not provided. The element is 1..1 in pain.001, so a file without it fails validation. Payments that start elsewhere — with no originator reference at all — still need a value between banks. The SEPA rulebook gives the originator's reference the default value "Not provided", and the EPC inter-PSP guidelines turn that into a literal: in the event that no reference was given, NOTPROVIDED must be used. The string is not in the ISO message definition reports; it is a scheme convention. A statement line that shows NOTPROVIDED means the bank that built the interbank message had no reference to pass on — either none was assigned, or it did not survive an earlier leg. Check which before blaming the bank.

Remittance information is not a reference

The six identifiers describe the payment. Remittance information describes what the payment is for, and it is the creditor's data, not yours. ISO defines RmtInf as information supplied to enable the matching of an entry with the items the transfer is intended to settle.

• Unstructured, <Ustrd> — free text, up to 140 characters per occurrence. ISO allows repetition; SEPA allows one occurrence.
• Structured, <Strd> — typed fields, including referred documents and the creditor reference in CdtrRefInf: a type code and a Ref of up to 35 characters, defined as a unique reference assigned by the creditor. SEPA allows either structured or unstructured, in a single occurrence, accepts SCOR as the only type code, and caps the structured block at 140 characters counting the tags inside it.

The ISO 11649 creditor reference is the standardised form of that Ref. Its structure, as Finance Finland's guideline describes it: the identifier RF, two check digits calculated with the same algorithm as IBAN check digits, then up to 21 alphanumeric characters formed freely by the creditor. RF4220260004711 in the fragment above is a valid one. In SEPA, the issuer element is mandatory for such a reference and the guidelines say ISO should be stated — conversely, if the issuer is ISO, the reference must be an RF reference — and the receiving bank is not required to validate the check digits. The EPC recommends it as the preferred convention for a payment that settles a single invoice. I did not open the ISO 11649 standard text itself.

This is why the two sides of a payment reconcile on different fields. The debtor matches on EndToEndId because the debtor wrote it. The creditor cannot: the SEPA rulebook says outright that the originator's reference "can only be expected to be meaningful to the Originator". The creditor matches on the remittance information it asked for. ISO does leave one bridge: if only one identifier can pass through the chain, the creditor's reference should be quoted in the end-to-end identification.

Which reference to reconcile on

My working rule, by job:

• Outgoing payments against the statement: EndToEndId, with amount, date and counterparty account as the fallback when it is missing.
• Status reports against the file: MsgId, then PmtInfId, then EndToEndId — one per level of the pain.002.
• Incoming payments against open items: the creditor reference or remittance text. Never the payer's EndToEndId.
• Duplicate detection between camt.054 and camt.053: the bank's AcctSvcrRef, after testing that it is the same in both.
• "Where is my payment?": UETR. Quote it to the bank.

What I see go wrong, repeatedly:

• EndToEndId reused or meaningless. A payment-run number copied onto every transaction satisfies the schema and matches nothing. Make it unique per payment and resolvable to a document.
• One reference stretched over two jobs. The invoice number goes into EndToEndId and the remittance information stays empty, so your side reconciles and the supplier calls asking what was paid.
• Batch booking hides the detail. The statement shows one debit for the whole PmtInfId; the per-payment references are in the camt.054 or nowhere.
• Match rules built on the schema. Every statement reference is 0..1. A rule written from the XSD and not from the bank's real files works in the test bank and fails in the next one.
• Storing too little. If the UETR and AcctSvcrRef are dropped at import, the investigation three weeks later starts with a phone call.

The matching logic itself, and where a human still has to decide, is in the bank reconciliation teardown.