Introduction — Why This Matters
Every payment that moves through the financial system carries a story. A corporate in Spain initiates a payment. It travels through a Debtor Bank, an Intermediary Bank, a Clearing System, and finally reaches a Creditor Bank in the Netherlands or the United States. Along that journey, multiple parties handle the same transaction — each generating their own records, their own logs, their own reconciliation entries.
Now ask yourself: how do all these parties know they are talking about the same payment?
The answer lies in Payment Identifiers — a structured set of reference fields within ISO 20022 messages, each serving a precise purpose, owned by a specific party, and governed by clear rules about when it changes and when it must not.
This article covers every Payment Identifier in ISO 20022 payment messages — what it is, who creates it, which messages carry it, whether it changes across the payment chain, and what happens to it in each payment scenario. By the end, you will have complete clarity on a topic that trips up even experienced payments professionals.
The Identifier Landscape — A Quick Orientation
Before going field by field, it helps to understand the three distinct perspectives that identifiers serve:
Message-level — uniquely identifies the ISO 20022 message itself (the envelope).
Batch Instruction-level — uniquely identifies a group of transactions or a single payment instruction within a message.
Transaction-level — uniquely identifies one individual credit transfer, from origin to final destination.
Each level has its own identifier. And some identifiers are designed to survive the entire journey — from the corporate who initiated it, to the bank at the far end of the world.
The Payment Identifier Family — An Overview
Within the ISO 20022 messages, you will find a structured family of identifiers. Each one operates at a different scope — some cover the full message, some cover a batch of transactions, some track a single payment from the corporate all the way to the Creditor.
Before going through each one, keep this mental model:
- Point-to-Point identifiers — created fresh at each hop. They identify the current sender’s instruction to the next party. They are not designed to travel end-to-end.
- End-to-End identifiers — created once and must not change, no matter how many banks or systems the payment passes through.
- Scope-limited identifiers — only meaningful at a specific point in the chain (e.g., inside a PAIN.001 file or inside a clearing system).
The table below summarises the full family before we go deep into each one.
Identifier | XML Tag | Assigned By | Changes During Payment? | Appears In |
| Message ID | MsgId | Sender of each message | Yes — new at every hop | PAIN.001, PACS.008, PACS.009 |
| Payment Information ID | PmtInfId | Corporate / Initiating Party | Not propagated beyond Debtor Agent | PAIN.001 only |
| Instruction ID | InstrId | Sender of each message | Yes — changes at every hop | PAIN.001, PACS.008, PACS.009 |
| End-to-End ID | EndToEndId | Corporate / Debtor | Never changes | PAIN.001, PACS.008, PACS.009 |
| Transaction ID | TxId | First Instructing Bank (Debtor Agent) | No — unchanged after assignment | PACS.008, PACS.009 |
| UETR | UETR | Debtor Agent (or Corporate via GPI) | Never changes | PAIN.001, PACS.008, PACS.009 |
| Clearing System Reference | ClrSysRef | Clearing Infrastructure | No — generated once at clearing | PACS.008, PACS.009 |
Each Identifier Explained
Message Identification (MsgId)
What it is: The unique reference assigned to the ISO 20022 message as a whole — the identifier for the envelope that carries all content within it.
Who creates it: The sender of each message — whether a corporate, a bank, or a payment system — assigns their own MsgId to every message they create.
Where it appears: In the Group Header (GrpHdr) of all ISO payment messages — PAIN.001 (CustomerCreditTransferInitiation), PACS.008 (FIToFICustomerCreditTransfer), and PACS.009 (FinancialInstitutionCreditTransfer).
What it covers: The entire message — which may contain multiple payment batch instructions and multiple individual transactions.
Key rule: The MsgId is a point-to-point reference. Because each bank creates a new message when forwarding a payment to the next party, the MsgId changes at every hop. It is not designed to travel end-to-end across the full payment chain.
Example: When ABC Manufacturing Ltd sends a PAIN.001 to Barclays Bank containing payment instructions for 10 suppliers, one MsgId covers that entire file. When Barclays forwards the first payment onward to Citi as a PACS.008 (individual or group), it creates a brand new MsgId for that message.
Payment Information Identification (PmtInfId)
What it is: A batch-level reference that identifies a group of payment instructions within a PAIN.001 file that share the same payment characteristics — such as the same Debtor, same payment date, or same payment method.
Who creates it: The Corporate or Initiating Party — assigned at the point of payment initiation in the PAIN.001.
Where it appears: In the Payment Information block (PmtInf) of PAIN.001 only. It does not appear in PACS.008 or PACS.009.
What it covers: A subset of transactions within the PAIN.001 — the batch or payment group. A single PAIN.001 can contain multiple PmtInf blocks, each with its own PmtInfId.
Key rule: The PmtInfId is not propagated beyond the Debtor Agent. Once the payment leaves the Debtor Bank and enters the interbank chain, this identifier has no further relevance. In CBPR+ cross-border flows, batches are not permitted — so per CBPR+ Usage Guidelines, the same value is typically used across MsgId, PmtInfId, and InstrId in the PAIN.001 for a single-transaction initiation.
Example: ABC Manufacturing sends a PAIN.001 to Barclays Bank with two payment groups — one batch of EUR payments and one batch of USD payments. Each group carries its own PmtInfId. When Barclays processes and forwards the individual payments as PACS.008 messages, neither PmtInfId appears again.
Instruction Identification (InstrId)
What it is: The reference that identifies the specific instruction a sender is sending to the next party in the chain. It operates at the transaction level — one InstrId per transaction, per hop.
Who creates it: The sender of each message — the corporate assigns one in PAIN.001, and each bank assigns a new one in every PACS.008 they send.
Where it appears: In the transaction-level blocks of PAIN.001, PACS.008, and PACS.009.
What it covers: A single transaction, in a single bilateral exchange between two parties.
Key rule: The InstrId is a point-to-point reference — it changes at every hop. It identifies the instruction from the current sender to the immediate next party. The Clearing System does not assign an InstrId.
Example: ABC Manufacturing sends a PAIN.001 to Barclays with InstrId = I1 for a payment to a US supplier. Barclays forwards it to Citi as a PACS.008 with InstrId = I2 — Barclays’ own instruction to Citi. Citi then sends it to the Creditor Bank with InstrId = I3. The value changes at every step; each bank’s instruction to the next party is distinct.
End-to-End Identification (EndToEndId)
Who creates it: The Corporate or Debtor — assigned in the PAIN.001 at the point of initiation.
Where it appears: In the transaction-level blocks of PAIN.001, PACS.008, and PACS.009. It is the only identifier that appears in all three message types and remains constant across all of them.
What it covers: One individual transaction, tracked across the full payment journey from Debtor to Creditor — through every bank, correspondent, and clearing system.
Key rule: No bank, intermediary, or clearing system is permitted to alter the EndToEndId. It passes through every hop exactly as the corporate assigned it. Of the three transaction-level identifiers in PAIN01, this is the only one created by the corporate rather than a financial institution.
Example: ABC Manufacturing sends a payment to Tanaka Electronics with EndToEndId = PAY-2025-INV-4471. The payment travels through Barclays, Citi, and MUFG Tokyo. When MUFG credits Tanaka’s account and sends a CAMT.054 notification, EndToEndId = PAY-2025-INV-4471 appears in that notification — unchanged. Tanaka’s ERP automatically matches the credit against invoice INV-4471.
Transaction Identification (TxId)
Who creates it: The first instructing bank — the Debtor Agent. This is a key distinction: the TxId is not assigned by the corporate. It enters the picture only when the payment moves into the interbank space.
Where it appears: In the transaction-level blocks of PACS.008 and PACS.009 only. It does not appear in PAIN.001.
What it covers: One individual transaction, across the interbank payment chain — from the Debtor Agent onward.
Key rule: Once the Debtor Agent assigns the TxId, it is passed unchanged through every subsequent bank in the chain. Unlike MsgId and InstrId, the TxId does not change at each hop. Every bank that receives and forwards the PACS.008 carries the same TxId forward.
Example: Barclays (Debtor Agent) sends a PACS.008 to Citi with TxId = T1. Citi forwards it to MUFG Tokyo — also with TxId = T1. MUFG delivers the payment to the Creditor Bank — still with TxId = T1. The value assigned by Barclays travels unchanged through the entire interbank chain.
Unique End-to-End Transaction Reference (UETR)
Who creates it: Typically the Debtor Agent (first bank in the SWIFT chain). However, with SWIFT GPI for Corporates, an advanced corporate system can assign the UETR directly in the PAIN.001. If the Corporate assigns a UETR, the Debtor Agent must honour it and forward it unchanged. If the Corporate does not assign one, the Debtor Agent creates it and communicates it back to the Corporate.
Where it appears: In the transaction-level blocks of PAIN.001, PACS.008, and PACS.009.
What it covers: One transaction, tracked globally across the full SWIFT correspondent banking chain — and even through clearing systems in mixed-flow scenarios.
Key rule: The UETR never changes once assigned — through every correspondent bank, every intermediary, and every clearing system the payment passes through. It is immutable by design. The UUID format guarantees global uniqueness without any central coordination.
Example: Barclays (Debtor Agent) assigns UETR = 550e8400-e29b-41d4-a716-446655440000 to a payment from ABC Manufacturing to Tanaka Electronics. This exact value appears in every PACS.008 across the chain — Barclays to Citi, Citi to MUFG. When Tanaka’s bank settles via local clearing, the UETR still travels unchanged. Any party in the chain — or on the SWIFT gpi Tracker — can locate this payment using that single UUID.
Clearing System Reference (ClrSysRef)
Who creates it: The Clearing Infrastructure — not a bank, not a corporate. This identifier is owned entirely by the clearing system.
Where it appears: In the transaction-level blocks of PACS.008 and PACS.009 only. It is absent in PAIN.001 and in pure cross-border flows where no clearing system is involved.
What it covers: One transaction, within the scope of a specific clearing and settlement system.
Key rule: The ClrSysRef is generated once, at the point the payment enters the clearing system, and does not change thereafter. The clearing system communicates this reference to all participating banks — the sending bank receives it via acknowledgements or reporting messages, and the receiving bank receives it in the PACS.008 delivered by the clearing infrastructure.
Example: Barclays submits a payment into the SEPA clearing system. SEPA assigns ClrSysRef = C1 to the transaction. Barclays receives C1 in the acknowledgement back from SEPA. The Creditor Bank receives the PACS.008 from SEPA carrying ClrSysRef = C1. Both banks record C1 internally — and when the nostro CAMT.053 statement arrives, Barclays uses C1 to match the settled entry against their internal payment record.
How the Identifiers Behave Across Three Real Payment Flows
Flow 1 — Domestic Scheme (Spain to Netherlands)
| Party | Message | MsgId | PmtInfId | InstrId | EndToEndId | TxId | ClrSysRef |
| Corporate | PAIN.001 | M1 | B1 | I1 | E1 | NA | NA |
| Debtor Bank | PACS.008 | M2 | NA | I2 | E1 | T1 | NA |
| Clearing System | — | NA | NA | NA | E1 | T1 | C1 |
| Creditor Bank | PACS.008 (from clearing) | M3 | NA | I3 | E1 | T1 | C1 |
Key observations:
- MsgId is created fresh at every hop. The Clearing System does not create a new MsgId as it is infrastructure, not a bank.
- PmtInfId is batch-relevant at the corporate level only — it does not flow beyond the Debtor Bank.
- InstrId changes at each bank hop. The Clearing System does not assign an InstrId.
- EndToEndId (E1) remains unchanged from Corporate through to Creditor Bank.
- TxId (T1) is assigned by the Debtor Bank and stays unchanged — including through the Clearing System.
- ClrSysRef (C1) is generated when the payment enters the Clearing System and is carried through to the Creditor Bank in the outgoing PACS.008.
- UETR is not shown here as this is an exclusively domestic flow — UETR is primarily a cross-border tracking identifier.
Flow 2 — Cross-Border CBPR+ (Spain to United States)
| Party | Message | MsgId | PmtInfId | InstrId | EndToEndId | TxId | UETR |
| Corporate | PAIN.001 | M1 | B1 | I1 | E1 | NA | UUID1 |
| Debtor Bank | PACS.008 | M2 | NA | I2 | E1 | T1 | UUID1 |
| Intermediary Bank | PACS.008 | M3 | NA | I3 | E1 | T1 | UUID1 |
| Creditor Bank | PACS.008 | M4 | NA | I4 | E1 | T1 | UUID1 |
Key observations:
- MsgId is new at every hop (M1 → M2 → M3 → M4).
- PmtInfId exists in the PAIN.001 at the corporate level but is not propagated into the interbank chain.
- InstrId changes at every hop (I1 → I2 → I3 → I4) — each bank’s instruction to the next party.
- EndToEndId (E1) is unchanged across all four parties.
- TxId is assigned by the Debtor Bank (first instructing bank) as T1 and passes through every subsequent bank unchanged.
- UETR (UUID1) is assigned by the Corporate in this scenario (with GPI for Corporates) or by the Debtor Bank, and it travels unchanged through all four parties.
- No ClrSysRef — there is no clearing system in this pure cross-border flow.
Flow 3 — Mixed Flow (Cross-Border + Domestic Clearing)
| Party | Message | MsgId | PmtInfId | InstrId | EndToEndId | TxId | UETR | ClrSysRef |
| Corporate | PAIN.001 | M1 | B1 | I1 | E1 | NA | UUID1 | NA |
| Debtor Bank | PACS.008 | M2 | NA | I2 | E1 | T1 | UUID1 | NA |
| Correspondent (Sender) | PACS.008 | M3 | NA | I3 | E1 | T1 | UUID1 | NA |
| Clearing System | — | NA | NA | NA | E1 | T1 | UUID1 | C1 |
| Creditor Bank | PACS.008 | M4 | NA | I4 | E1 | T1 | UUID1 | C1 |
Key observations:
- MsgId and InstrId change at every bank hop, as always.
- EndToEndId, TxId, and UETR all remain constant from their point of assignment through to the Creditor Bank — even across the clearing system.
- ClrSysRef is generated when the payment enters local clearing and is carried through to the Creditor Bank.
- This flow illustrates the critical design principle: end-to-end identifiers survive infrastructure boundaries — they pass through clearing systems, correspondent banks, and payment scheme gateways without change.
Common Misconceptions — Cleared Up
This is incorrect. The TxId is assigned by the first instructing bank — the Debtor Agent — and remains unchanged through the entire interbank chain. Only the MsgId and InstrId are point-to-point references that change at each hop.
- “The UETR is always assigned by the Debtor Agent.”
Usually, yes. But with SWIFT GPI for Corporates, an advanced corporate system can assign the UETR in the PAIN.001. When this happens, the Debtor Agent must honour and forward that same UETR. If the Corporate does not assign one, the Debtor Agent creates it.
- “The EndToEndId and the UETR serve the same purpose.”
They do not. The EndToEndId is a business reference created by the Corporate to reconcile the payment against an invoice or order — it serves the corporate treasury or ERP system. The UETR is a tracking reference created within the banking network to trace a cross-border payment across SWIFT. Different ownership, different scope, different audience.
- “The PmtInfId travels through the payment chain.”
It does not. The PmtInfId is scoped to the PAIN.001 file and the relationship between the Corporate and the Debtor Bank. It has no existence beyond the Debtor Agent.
- “The Clearing System Reference is only relevant for settlement.”
The ClrSysRef is also critical for payment operations and reconciliation. Both the sending bank and the receiving bank in a clearing-settled payment receive and use the ClrSysRef — the sending bank via acknowledgement or reporting messages, the receiving bank in the PACS.008 it receives from the clearing infrastructure.
Summary — Key Takeaways
- ISO 20022 uses a structured family of seven payment identifiers. Each has a defined owner, scope, and behaviour across the payment chain.
- MsgId and InstrId are point-to-point references — they change at every hop. They serve bilateral tracing, not end-to-end tracking.
- PmtInfId is a batch identifier, scoped to PAIN.001. It does not propagate beyond the Debtor Agent. In CBPR+ cross-border flows, batches are not permitted.
- EndToEndId is the corporate’s unchanging reference — it travels from Debtor to Creditor, untouched, through every bank and every system.
- TxId is the interbank transaction reference, assigned by the Debtor Agent (first instructing bank) and passed unchanged through the rest of the chain. It does not appear in PAIN.001.
- UETR is the globally unique cross-border tracking reference, assigned by the Debtor Agent — or by the Corporate when using SWIFT GPI for Corporates. It never changes once assigned, even in mixed domestic-cross-border flows.
- ClrSysRef is owned by the clearing infrastructure. It is generated at the point of clearing entry and communicated to all participating banks. It does not exist in pure cross-border flows with no clearing system.
