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. This piece assumes you already know what each MT103 field means and want the ISO 20022 equivalent; for the field-level meaning itself — mandatory/optional status, format specs, and failure modes for each MT103 tag — see the MT103 field-by-field operator reference. Working a different MT message than MT103 — a cover payment, a return, a cheque advice? The MT to ISO 20022 equivalence lookup covers the full set, each pair marked with an honest equivalence tier rather than an assumed 1:1.

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 under the CBPR+ address rule, at minimum must have town and country — structured into their own dedicated elements rather than buried in free text. That rule's enforcement date was deferred on 27 August 2026; see below.

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.

CBPR+ Address Truncation and Structured Postal Addresses

The party fields above carry the piece of the migration that generates the most operator pain and the least attention: postal addresses. MT103 never had a dedicated address format — Dbtr and Cdtr address content lived in the same 4-line-by-35-character block as the name, inside :50a:/:59a: (and the equivalent D-option agent fields). pacs.008 replaces that free-text block with a typed PostalAddress structure, and under the CBPR+ address rule the free-text-only version of that structure is no longer accepted on the network. That rule was drafted to take effect on 14 November 2026; that date has been deferred, and this section covers both what the rule requires and where the timetable now stands.

Status: the cutover date was deferred on 27 August 2026. Swift delayed its November 2026 Standards Release, which carried this change. The Federal Reserve Financial Services notice records the decision as taken "based on the industry's request for additional time to prepare for the removal of the unstructured postal address format"; the Bank of England, deferring its own November 2026 RTGS release the same day, described that step as "consistent with Swift delaying the entire CBPR+ standards release". No replacement CBPR+ enforcement date has been announced. The requirement was not withdrawn — FRFS told institutions to continue preparing for unstructured-address removal — so what follows describes the rule as drafted, and it remains the format target. The date moved; the destination did not.

The rails did not move together. FRFS rescheduled the Fedwire Funds Service release from November 2026 to November 2027. The Bank of England deferred its November 2026 RTGS standards release in its entirety, including the messaging standards for CHAPS payments. The ECB said on 28 August that it was reassessing the planned November 2026 TARGET Services releases, and was exploring going ahead with them as originally planned while postponing the discontinuation of unstructured postal addresses; on 4 September it confirmed those releases for T2, T2S, TIPS and ECMS, moved their deployment from 14 November to 28 November 2026, and introduced a temporary measure letting fully unstructured postal addresses continue in T2 RTGS messages for a limited period it did not date. That is a TARGET deployment date and a T2 address concession, not a new industry-wide address deadline. The SEPA schemes run to a European Payments Council timetable that a Swift decision does not itself change — confirm each rail separately rather than assuming one global stay.

What truncates, and where. The MT-side constraint that produces most of the downstream address and remittance problems is the same shape everywhere it appears: four lines of 35 characters, roughly 140 characters total. It applies to the free-text name-and-address content in :50a:/:59a: and the D-option agent fields, and separately to the :70: remittance field — two different fields sharing the same structural limit, not one limit doing double duty. This article's companion piece, the MT103 field-by-field operator reference, covers the field 70 remittance truncation in detail; the concern here is the address side of that same 4×35 constraint and what happens to it in translation.

Three address states, not two. pacs.008 PostalAddress supports a spectrum, and CBPR+ guidance names three positions on it:

• Unstructured — the MT-style approach: free-text AdrLine elements only, with no TwnNm or Ctry broken out into their own fields. This is the state SWIFT's in-flow translation service produces from a legacy MT103, and it is the state being phased out.
• Hybrid — TwnNm (Town Name) and Ctry (Country, ISO 3166-1 alpha-2) populated in their own structured elements, with the remaining address detail (street, building, floor) carried in up to two free-text AdrLine elements of up to 70 characters each. Structured content must not be duplicated inside the AdrLine text.
• Fully structured — every component in its own element: StrtNm (street name), BldgNb (building number), PstCd (postal code), TwnNm, Ctry, with no free-text address lines at all.

What the rule actually requires. As drafted, CBPR+ payment messages that carry a fully unstructured address — AdrLine only, no structured TwnNm/Ctry — are rejected at the network level for the parties and agents in scope, with no contingency fallback. The floor requirement is narrower than "fully structured everywhere": at minimum, TwnNm and Ctry must be present in their own dedicated elements for the parties and agents covered by the rule. Hybrid addresses satisfy that floor and remain acceptable with no announced end-date — this is not a stepping stone to a later structured-only mandate on any published timeline. Fully structured addresses (with StrtNm, BldgNb, and PstCd also broken out) are recommended, not mandatory, and are the format banks with more advanced screening and reconciliation tooling are pushing toward regardless of the minimum.

Data loss in MT→MX translation is not recoverable. SWIFT's in-flow translation service converts a passing MT103 into pacs.008 automatically, but it operates on structure, not meaning — it cannot infer a country or town name out of free text it was never given as a discrete field. When an MT103's :50a:/:59a: content doesn't meet the preconditions for translation into a hybrid or structured address, the service does not silently degrade the output; it stops, and the payment fails translation rather than arriving with a guessed-at address. There is no downstream repair step that reconstructs a structured TwnNm/Ctry from a free-text string the originating system never captured as structured data in the first place — the loss happens at origination, not in flight, and origination is the only place it can be fixed.

Sanctions screening is where this stops being a formatting problem. Screening engines that fuzzy-match unstructured name-and-address strings against sanctioned-party and sanctioned-country lists generate false positives when an ordinary place name collides with a blacklisted term embedded in the same free-text block — a documented real-world example is "Cuba Street, Wellington, New Zealand," a legitimate street address that fuzzy unstructured matching flags as a hit against sanctioned Cuba. Separating TwnNm and Ctry into their own elements removes that class of false positive by construction, because the screening engine is matching a discrete country field against a discrete country list instead of scanning a blended string. Industry commentary on sanctions screening false-positive rates puts the share of alerts that turn out to be non-matches very high — one practitioner estimate runs as high as 99% of alerts in cross-border payment screening — and while that figure is a secondary, vendor-adjacent estimate rather than a published regulator statistic, the direction is not in dispute: poor address structure inflates false positives, and false positives are what drive manual case review, not the underlying risk. For the broader screening programme this sits inside — list sources, the strict-liability standard, and how to build a defensible screening control — see sanctions screening for payment operators.

Repair cost and reject behaviour. Ahead of the network-level cutover — which, with the date deferred, is where operators now sit for longer than planned — non-compliant address data mostly shows up as local or interface-layer validation failures: a bank's own gateway rejects the file before it reaches SWIFT, and someone repairs it manually and resubmits. Once the rule takes effect, a fully unstructured address on an in-scope party or agent is rejected at the CBPR+ network level itself, with no contingency processing option to fall back on the way MT contingency traffic still had one during the 2025–2026 coexistence window. Either way the operational pattern is the same: more manual repair queues, more resubmissions, missed cutoff times, and investigation cases opened for payments that failed on a data-shape problem rather than a settlement problem.

The fix is upstream, not in the payment layer. None of this is fixable by adding smarter mapping logic at the point the payment message is built. A bank, PSP, or corporate payment system can only populate a structured TwnNm/Ctry — or StrtNm/BldgNb/PstCd — if that data already exists as discrete fields somewhere upstream: the checkout form, the ERP customer master, the KYC/onboarding record. If the address was captured as a single free-text box at account opening or checkout, no amount of payment-layer engineering recovers the missing structure at the moment a pacs.008 message is assembled. The institutions least exposed to the address rule, whenever it lands, are the ones that restructured their address capture in onboarding, CRM, and origination systems well before the payment layer needed the output — treating this as a data-architecture project, not a SWIFT-connectivity one.

What to test before the deadline, and monitor after. Before cutover: inventory outbound MT and pacs.008 traffic and classify every party and agent address field by which of the three states it currently produces; trace any pattern that still resolves to fully unstructured back to its source system rather than patching it in the translation or gateway layer; and confirm with correspondents and market infrastructures in your active corridors that their hybrid/structured handling is aligned with yours, since a compliant outbound message can still surface a gap on a counterparty that isn't ready. After cutover: monitor rejection and NAK volumes for address-related causes specifically (rather than lumping them into generic message-validation failures), track investigation-case volume tied to address data rather than settlement issues, and watch for reconciliation breaks where a payment cleared but its Dbtr/Cdtr address arrived incomplete because a correspondent degraded a structured address on a leg still running MT-format processing internally.

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.

Treating the deferral as permission to keep sending unstructured postal addresses. The 14 November 2026 cutover was deferred on 27 August 2026 with no replacement date, but the requirement stands and the regulators that moved their own dates told institutions to carry on preparing. When the rule takes effect, fully unstructured addresses are rejected at the CBPR+ network level; hybrid (Town + Country structured, minimum) or fully structured formats are required. If your origination systems still produce unstructured Dbtr/Cdtr addresses (a single address line string), the deferral bought remediation time, not an exemption. See CBPR+ Address Truncation and Structured Postal Addresses above for what each format requires and why the fix has to happen upstream of the payment layer.

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). The CBPR+ enforcement date is deferred and unannounced, so plan to the remediation lead time rather than to a published date.
• 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. 14 November 2026 was the drafted structured-address enforcement date and is no longer operative: Swift deferred its November 2026 Standards Release on 27 August 2026, confirmed in first-party notices from the Bank of England, Federal Reserve Financial Services and the ECB, and no replacement date has been announced. The format floor is unchanged — hybrid, with Town and Country structured at minimum, remains acceptable with no announced end-date.

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
• ISO 20022 Investigation Messages: A camt Operator Reference — full field detail on the pacs.002 status, camt.056 recall, and camt.110/111 case-management messages introduced above
• camt.052, camt.053 and camt.054: The Account Reporting Operator Reference — post-settlement account reporting once the credit has landed

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