MT103 to pacs.008 Field Mapping: The Operator Reference

MT103 retired from the SWIFT FINplus cross-border network on 22 November 2025. pacs.008.001.08 (ISO 20022 FI-to-FI Customer Credit Transfer, CBPR+ ruleset) is now the live format. For most payments, the transition happened without operator intervention — SWIFT’s translation service handled it during the coexistence period. But the migration created a layer of data-quality and reconciliation issues that operators are still working through in 2026: legacy archive records in MT format, investigation teams accustomed to MT field numbers, NOTPROVIDED placeholders polluting EndToEndId, and unstructured :72: data now scattered across multiple pacs.008 elements.

This reference is for operators working in that environment — investigating payments against MT-era records, reading bank pacs.008 outputs, structuring escalation requests correctly, and understanding which identifier to quote in which context. For the broader picture of how SWIFT payment processing works — including correspondent chain mechanics, gpi, and fee structure — see that article first.

What Changed and What Didn’t

The format changed. The mechanics did not.

pacs.008 carries structured XML instead of MT’s colon-delimited free text. Party information (debtor, creditor, agents) is now in typed XML elements rather than 35-character text lines. Remittance data can carry structured invoice references, tax identifiers, and multiple line items instead of 140 characters of free text across four fields. Addresses can be — and from November 2026, must be — structured with separate street, city, postal code, and country elements.

What did not change: the correspondent chain topology, settlement timing, charge-bearer logic, or the underlying meaning of each payment party. The UETR, mandatory on all SWIFT cross-border messages since November 2018, remains the same UUID v4 identifier and still occupies the same role — now as a native XML element rather than field 121 in Block 3.

What the migration did not fix: unstructured data quality. Banks and corporates arrived at November 2025 at different stages of ISO 20022 readiness. SWIFT’s in-flow translation service converts passing MT messages to pacs.008, but only at the cost of richness — unstructured names and addresses remain unstructured, :72: free text is redistributed across purpose elements, and the EndToEndId field carries NOTPROVIDED whenever the originating MT103 had no equivalent. These translation artifacts persist in the payment archives of every institution that used SWIFT’s contingency translation rather than native MX.

Post-migration contingency: banks still sending MT instructions from 22 November 2025 face contingency processing fees (SWIFT introduced charges from 1 January 2026). Market Infrastructure Closed User Groups (MI CUG) may continue exchanging MTs for domestic infrastructure purposes, but cross-border CBPR+ traffic is MX-only.

Field Mapping Table

This table covers the materially significant MT103 fields and their pacs.008.001.08 equivalents. The mapping tiers are:

• Direct — one-to-one structural equivalence; meaning preserved exactly
• Split/combined — field content redistributed or merged
• No MT equivalent — pacs.008 field exists with no MT103 source
• Approximate — structural difference; translation inserts data or uses a placeholder

Scope caveat: The canonical field-level mapping rules, CBPR+ restrictions (character limits, allowed values, conditional logic), and translation rules live in the CBPR+ Usage Guidelines on SWIFT MyStandards — a gated publication requiring SWIFT member access. The mappings below are drawn from publicly documented bank implementation guides (J.P. Morgan, BNY, Standard Chartered, ING, Goldman Sachs developer portal) and widely reproduced secondary references. Where bank implementation varies from conceptual mapping, this is noted.

Identity Fields: Which Reference to Quote When

The single most common operator mistake post-migration is quoting the wrong identifier to a bank. pacs.008 carries four distinct payment references in PmtId — each serves a different purpose:

UETR (Unique End-to-end Transaction Reference): The gpi tracking key. A UUID v4 (36 characters, RFC 4122) generated by the originating bank and passed unchanged through every correspondent. Mandatory on all SWIFT cross-border messages since November 2018. Quote this when: requesting a gpi Tracker status update, raising a formal investigation case, asking about a stalled or delayed payment. The UETR is the fastest single reference for a bank to locate a specific payment. See SWIFT payment tracing and UETR for the full investigation runbook.

InstrId (Instruction Identification): The sending bank’s internal point-to-point reference for this instruction. Changes at each bank in the chain — Bank A’s InstrId is not the same as Bank B’s InstrId for the same underlying payment. Restricted to 16 characters in CBPR+. Equivalent to MT103 field :20:. Quote this when: your bank asks for your payment reference in their system, or when correlating the pacs.008 GrpHdr/MsgId back to a bank confirmation. Do not use for end-to-end reconciliation.

EndToEndId: The ordering customer’s own reference — an invoice number, purchase order, or contract ID — that should persist unchanged through the entire chain. New in ISO 20022 with no MT103 equivalent. The critical caveat: any pacs.008 message that originated as an MT103 (whether directly or via SWIFT translation during the coexistence period) will carry NOTPROVIDED in EndToEndId because there was no source field in MT103 to populate it. In practice, NOTPROVIDED is widespread in any payment archive that includes coexistence-period traffic. For native pacs.008 originators: populate EndToEndId with the business reference your counterparty needs for reconciliation — leaving it blank or as NOTPROVIDED breaks auto-matching at the receiving end.

TxId (Transaction Identification): A transaction-level reference, conceptually finer-grained than InstrId but the distinction is bank-implementation dependent and was not universally populated in early CBPR+ rollouts. Not relevant for most operator investigation workflows; primarily used in clearing and settlement system-to-system references.

The investigation hierarchy: For any stalled payment, request these in this order: (1) UETR — for gpi Tracker status, (2) your bank’s InstrId for the payment — to correlate their records, (3) the BIC and InstrId of the last correspondent that updated the Tracker — to identify where the payment is held.

Parties and Agents

pacs.008 carries the same party roles as MT103 but in named, typed elements rather than field tags. Understanding the static vs. dynamic roles prevents misreading intermediary agent fields:

Static throughout the chain (same in every leg): Dbtr (debtor, the ordering customer), DbtrAgt (the debtor’s bank), CdtrAgt (the creditor’s bank), Cdtr (creditor, the beneficiary). These do not change as the message passes through correspondents.

Dynamic per leg (change at each hop): InstructingAgt (the bank sending this leg) and InstructedAgt (the bank receiving this leg). These are populated at each correspondent processing step and represent the bilateral relationship for that specific leg.

Intermediary agents: IntrmyAgt1, IntrmyAgt2, IntrmyAgt3 — correspondents in the serial payment chain. MT103 :56a: maps to IntrmyAgt1. MT103 :53a: (sender’s correspondent) does NOT map here — a common reading error. :53a: is a settlement-side field: it identifies the bank that will reimburse the receiver on the sender’s behalf, and in pacs.008 CBPR+ it maps to GrpHdr/SttlmInf/InstgRmbrsmntAgt (for cover-payment flows where SttlmMtd = COVE) or GrpHdr/SttlmInf/SttlmAcct (:53B: account variant). If you are looking for the sender’s correspondent in the IntrmyAgt slots, you will not find it — it lives in the Group Header settlement block, not in CdtTrfTxInf. The exact population of IntrmyAgt2 and IntrmyAgt3 in CBPR+ is bank-implementation specific and varies by corridor.

New party types with no MT103 equivalent: UltmtDbtr (the economic party behind the immediate debtor — needed for payment-on-behalf-of structures) and UltmtCdtr (the economic ultimate beneficiary). These are new ISO 20022 capabilities that operators handling pass-through payments, PSP payouts, or multi-party settlement flows should actively populate.

LEI in party identification: pacs.008 supports Legal Entity Identifiers for Dbtr and Cdtr in the OrgId block. MT103 had no structured LEI field. Whether your counterparties and bank populate LEIs depends on their readiness; mandatory LEI inclusion in CBPR+ messages is not yet universally enforced but is the direction of travel.

Charges, Settlement, and Remittance Information

ChrgBr (Charge Bearer) — the direct successor to MT103 :71A: — controls who pays correspondent transit fees:

The logic is identical to MT103; only the encoding changed. For B2B invoice settlement where the recipient must receive the full invoiced amount, DEBT (formerly OUR) is the correct instruction. For the full mechanics of charge-bearer impact on settlement economics, see OUR, SHA, and BEN: SWIFT charge options.

ChrgsInf supersedes MT103 :71F:/:71G: and is structurally richer — it is an array where each element carries the fee amount and the BIC of the bank that charged it. gpi member banks are required to populate ChrgsInf for fee transparency; this is how the gpi Tracker surfaces per-hop fee data. In practice, ChrgsInf population varies by bank and is not universal on non-gpi legs.

RmtInf (Remittance Information) is where the biggest operational upgrade lives for high-volume invoice processing — and where translation artifacts are most visible. The MT103 :70: field was 4 × 35 characters of unstructured text. pacs.008 RmtInf supports both:

• Ustrd (unstructured): backward-compatible free text; MT103 translation drops :70: content here
• Strd (structured): machine-readable invoice references (CreditorReference), tax IDs (TaxRmtInf), document references (RfrdDocInf)

Operators expecting structured remittance data for auto-reconciliation against open invoices must verify that both the originator and their bank are sending native pacs.008 with populated Strd elements — not relying on translation from MT103 or populating Ustrd with free text that previously lived in :70:.

Status and Investigation Flow: pacs.002, camt.056, camt.110/111

Post-migration, a stalled payment investigation involves up to four ISO 20022 message types — each serving a different purpose:

pacs.002 (FI-to-FI Payment Status Report): The status update message. In the gpi Tracker, every processing step generates a pacs.002 update with the payment status code (ACSP, ACCC, RJCT) and sub-codes. When you request a gpi Tracker status, the Tracker is surfacing aggregated pacs.002 updates from each correspondent. This is the first thing to pull for any stalled payment — before raising a formal case.

camt.056 (FI-to-FI Payment Cancellation Request): The recall/cancellation message. Used when you or your bank need to request return of funds — for duplicate payments, fraud, or erroneous payments. Replaces the MT192/MT103 RETN series. Your bank sends camt.056 to the correspondent holding the payment; the correspondent responds with camt.029 (positive) or a negative camt.029 (with reason code NOOR/ARDT/LEGL). The window for bank-initiated recall (DUPL/TECH/FRAD) is 10 banking business days from execution; FRAD extends to 13 months.

camt.110 / camt.111 (Exceptions and Investigations): The structured investigation message pair, available opt-in on SWIFT FINplus since November 2024 via the Case Management Closed User Group. camt.110 is the claim/enquiry request (replaces MT199 free-format enquiry); camt.111 is the bank’s investigation response. As of early 2026, adoption is still limited — 7 banks live as of April 2025, with broader rollout ongoing. Full E&I migration to camt.110/111 is targeted for November 2027. Until then, expect your bank to use a mix of camt.110, MT199, and free-form correspondence depending on their implementation stage.

How the flows connect: For a stalled payment, the investigation sequence is: (1) obtain UETR → (2) pull pacs.002 status history from gpi Tracker → (3) if stalled past value date, ask your bank to raise a camt.110 enquiry → (4) if funds need to be recalled, escalate to camt.056. The UETR links all four message types — every pacs.002 status update, every camt.056 cancellation request, and every camt.110 enquiry should reference the same UETR.

gpi overlay: gpi does not replace these messages — it provides the tracking layer on top of them. The UETR in every pacs.008 is what makes the gpi Tracker work. pacs.002 messages are what the Tracker aggregates. camt.056 and camt.110 are raised through the gpi Stop and Recall / Case Management services. For operators, the practical implication is: gpi is the visibility layer; pacs.002/camt.056/camt.110 are the action messages.

Common Operator Mistakes Post-Migration

Quoting EndToEndId for investigation when it shows NOTPROVIDED. The NOTPROVIDED placeholder is not an anomaly — it is the correct translation behaviour for any payment that originated as MT103. Using it as an investigation reference will return nothing. Switch to UETR or InstrId.

Expecting structured remittance data from translated payments. If your payment originated as MT103, the RmtInf/Strd element will be empty. Only native pacs.008 originators who populated structured invoice references at source will produce Strd content. Verify with your counterparty and banking partner what they actually send before building auto-reconciliation on pacs.008 Strd content.

Treating InstrId as a persistent identifier. InstrId changes at every bank in the chain. A bank further down the correspondent chain will have a different InstrId for the same underlying payment. If you are trying to correlate payment records across institutions, UETR is the only stable identifier.

Confusing DEBT/SHAR/CRED with OUR/SHA/BEN in payment instructions. Post-November 2025, if your payment initiation system still sends MT-format charge codes (OUR/SHA/BEN) to a bank that expects pacs.008 (DEBT/SHAR/CRED), the translation should handle it — but verify with your bank. Some bank APIs still accept both; others have moved to MX-only input.

Assuming :72: content survived intact in pacs.008. Legacy :72: free-text (routing instructions, purpose codes, /REJT/, /RETN/ codewords) was redistributed across multiple pacs.008 elements during translation. Any downstream process that parses :72: content for specific codewords will not find them in a translated pacs.008 — they may be in InstrForNxtAgt/Ustrd, or lost entirely if the translation did not recognise the /CODEWORD/ format. Audit your reconciliation and compliance screening logic for any dependency on :72: parsing.

Sending unstructured postal addresses past November 2026. Hybrid or structured addresses are required from November 2026; unstructured address format will be rejected. If your origination systems still produce unstructured Dbtr/Cdtr addresses (a single address line string), that is a 2026 compliance risk — not a future option.

Not capturing the UETR at payment initiation. Any payment that leaves your bank after November 2018 carries a UETR. If your payment management system or ERP does not record the UETR at the point of payment confirmation, you are blind if that payment stalls. Configure your banking portal or API to return the UETR in the payment confirmation response.

Migration and Cleanup Checklist

For operators managing systems that span the MT-to-MX migration boundary:

• Archive correlation: Cross-reference MT-era archives (pre-November 2025) using UETR and :20: (InstrId equivalent) where available. UETR has been present in MT103 Block 3 121 since November 2018 — it is the bridge identifier.
• NOTPROVIDED audit: Query your incoming pacs.008 records for EndToEndId = NOTPROVIDED. Any record carrying this is a translated MT103. Decide whether your downstream reconciliation processes need to treat these differently.
• :72: migration inventory: Identify any internal process that relies on parsing MT103 :72: /CODEWORD/ patterns. These patterns will not appear in native pacs.008 — map each /CODEWORD/ use case to the correct pacs.008 element (InstrForNxtAgt, RgltryRptg, Purp).
• Address format review: Audit outbound Dbtr and Cdtr postal addresses. Identify any still using the 4 × 35 unstructured line format. Target structured (or minimum hybrid: TwnNm + Ctry) before November 2026 deadline.
• ChrgBr field verification: Confirm that your payment systems are sending pacs.008 ChrgBr values (DEBT/SHAR/CRED), not MT103 :71A: codes (OUR/SHA/BEN), if you are sending native pacs.008. If your bank’s API translates automatically, verify the translation is applying the correct value.
• EndToEndId population: For new native pacs.008 payment flows, ensure EndToEndId is populated with your business reference (invoice number, PO, subscription ID) — not left as NOTPROVIDED or blank. This is what your counterparty’s bank will use for auto-reconciliation.

Bank Enquiry Checklist

When raising a payment investigation or escalating to your bank, the structured information package that gets fastest resolution:

Always provide:

• UETR (UUID v4, 36 chars — from gpi Tracker or payment confirmation)
• InstrId / Sender’s Reference (your bank’s :20: equivalent for this payment)
• Value date (IntrBkSttlmDt)
• Exact settlement amount and currency (IntrBkSttlmAmt)
• Debtor Agent BIC (DbtrAgt — your bank)
• Creditor Agent BIC (CdtrAgt — beneficiary’s bank)

For stalled payments, also provide:

• Last gpi status code and sub-code (from pacs.002/Tracker)
• BIC of last correspondent to update the Tracker
• Timestamp of last Tracker update
• Whether the payment has exited the gpi network (ACSP/G001)

For recalled or recalled-and-returned payments:

• Instruction type: camt.056 recall or camt.110 E&I enquiry?
• Recall reason code (DUPL / TECH / FRAD for bank-initiated; CUST / AM09 / AC03 for customer-initiated RFRO)
• Whether a camt.029 response has been received and its content

What to ask for by message type:

• “Please provide the current pacs.002 status for UETR [xxx]” — to get the full gpi Tracker status chain
• “Please raise a camt.056 recall for UETR [xxx] with reason FRAD” — for fraud-origin recall
• “Please raise a camt.110 E&I enquiry for UETR [xxx]” — if your bank supports Case Management CUG

---

Scope Note

Gated primary source: The authoritative CBPR+ Usage Guidelines — the canonical SWIFT document defining permitted field values, conditional rules, character restrictions, and MT-MX translation logic for cross-border pacs.008 — are published on SWIFT MyStandards and require a SWIFT member subscription. They were not quoted directly. All CBPR+ field-level details in this article (InstrId 16-char cap, NbOfTxs fixed to 1, business service codes, ChrgBr allowed values) are sourced from public bank implementation guides (J.P. Morgan, BNY, Goldman Sachs developer portal, Standard Chartered FAQ, ING FAQ) and publicly accessible secondary references. Where these secondary sources agree, confidence is high; where a specific bank’s implementation may deviate, this is noted.

Four tiers throughout this article:

1. Conceptual mapping (the structural correspondence between MT103 fields and pacs.008 elements) — high confidence, widely documented
2. CBPR+ usage guidance (specific restrictions, conditional rules, allowed values in cross-border SWIFT traffic) — sourced from bank implementation guides; canonical source is gated
3. Bank/API implementation variation (how specific institutions populate fields, what their APIs accept) — explicitly noted as bank-dependent throughout
4. Operator runbook advice (what to do, what to quote, what to avoid) — based on aggregated public operator documentation and the field structure itself

Verified dates: 22 November 2025 (CBPR+ coexistence end, MT103 retirement) — confirmed via multiple public sources (Red Compass Labs, PaymentExpert, ING, State Street). November 2024 (camt.110/111 Case Management opt-in go-live) — confirmed via SWIFT Case Management page and Red Compass Labs. November 2026 (structured address mandatory deadline) — confirmed via J.P. Morgan and SWIFT public guidance.

In flux: camt.110/111 adoption is still in early rollout as of June 2026 (7 banks live as of April 2025 per SWIFT Case Management data). Not all banks support the Case Management CUG. Bank-implementation variation on pacs.008 field population (especially IntrmyAgt slots, TxId, LEI, UltmtDbtr/CdtrAgt) is expected to normalise as the post-migration period continues.

Related References

• SWIFT Payment Processing: MT103, ISO 20022, and gpi Explained — the pillar reference for SWIFT mechanics, correspondent chain, and the ISO 20022 migration context
• Tracing a SWIFT Payment: UETR, gpi, and Where It Gets Stuck — investigation runbook: UETR, gpi status codes, stall triage, and bank enquiry
• OUR, SHA, and BEN: Why SWIFT Payments Arrive Short — charge-bearer mechanics, correspondent fee deduction, and reconciliation impact
• Real-Time Payment Rails Comparison Matrix — for corridors where local rail alternatives to SWIFT apply

For term definitions — SWIFT, IBAN — see the Payments Glossary.