MT103 to pacs.008 Field Mapping: The Operator Reference

The FI-to-FI cross-border MT/ISO 20022 coexistence period ended on 22 November 2025. MT payment instructions are no longer delivered as MT on FIN for those flows. A qualifying MT103 sent on FIN can still undergo Swift's limited contingency processing and, if it passes validation and conversion, reach the receiver as pacs.008 on FINplus. That is distinct from the in-flow service, which derives an MT representation from an ISO 20022 message. Operators still face legacy MT archives, investigations that refer to MT field numbers and different treatment of reference and free-text fields across implementations.

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. For other message types, the MT to ISO 20022 equivalence lookup is a starting point; confirm each mapping against the applicable network and bank guidance.

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 MT103 field 70's 140-character maximum. Addresses can be structured into dedicated elements. The drafted CBPR+ minimum would require town and country in separate elements for in-scope addresses, but Swift deferred its enforcement date; see below.

The correspondent banking relationships and payment parties do not change merely because the message format does. A UETR in MT103 block 3 field 121 maps to the ISO 20022 UETR element and remains the payment-tracking reference. Settlement timing and fee outcomes still depend on the route, banks and agreements, not on the message syntax alone.

What the migration did not fix: unstructured source data. Swift's MT-sender contingency conversion cannot add rich ISO 20022 data that the sender did not supply. A converted message may therefore lack structured details available to a native ISO 20022 sender. NOTPROVIDED in EndToEndId means a usable end-to-end reference was not supplied in that message; it does not, by itself, prove MT conversion.

Post-migration contingency: qualifying FI-to-FI MT instructions sent on FIN are automatically checked against additional validation rules. A failing message is NAKed; even one that passes validation can be aborted if conversion fails. Successful messages are delivered as ISO 20022 on FINplus. Swift introduced charges from 1 January 2026 and describes this as a short-term measure, not an alternative to native ISO 20022 adoption. Market Infrastructure Closed User Groups can have separate MT uses outside this CBPR+ FI-to-FI scope.

Field Mapping Table

If the immediate problem is a payment the recipient cannot see, use the payment-tracing workflow to choose the evidence to request. A field mapping alone does not establish where the funds are.

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

• Direct — a close field-role correspondence in the cited mapping, subject to the applicable implementation
• Split/combined — field content redistributed or merged
• No MT equivalent — pacs.008 field exists with no MT103 source
• Approximate — structural correspondence is conditional or depends on the bank's implementation

Scope caveat: The authoritative CBPR+ field restrictions and translation rules are published in Swift MyStandards; this guide does not quote a current message-specific guideline. The table uses public bank implementation examples and Swift material to explain field roles. It does not establish a universal conversion rule for every bank, field option or message version. Confirm consequential mappings against the applicable implementation and actual converted output.

1. Tracking referenceBlock 3 {121}
   ↳UETRCdtTrfTxInf/PmtId/UETR

   The synthetic UETR is carried unchanged as the tracking reference. Its presence alone does not prove beneficiary credit.

   Synthetic input: {121:123e4567-e89b-42d3-a456-426614174000}

2. Instruction reference:20:
   ↳InstrIdCdtTrfTxInf/PmtId/InstrId

   REF20261028A illustrates the correspondence in the cited bank and Swift examples. A later bank may assign a different instruction reference.

   Synthetic input: :20:REF20261028A

3. Customer referenceNo dedicated MT103 field
   ↳EndToEndIdCdtTrfTxInf/PmtId/EndToEndId

   Unknown until the bank’s mapping and converted output are checked. A bank may derive a reference from :70:, but this input does not guarantee EndToEndId = INV-EXAMPLE-42. NOTPROVIDED does not prove MT origin.

   Synthetic input: :70:INV-EXAMPLE-42

Conceptual correspondence only. Bank, message-version and field-option rules govern the actual output.

Back to the full field mapping table

Sources: Swift CBPR+ example · Bank of America formatting guide. Scope checked 27 October 2026.

Identity Fields: Which Reference to Quote When

Using the wrong identifier can slow a bank enquiry. The PmtId structure can carry several references, each with a different purpose; check which ones the bank actually populated:

UETR (Unique End-to-end Transaction Reference): The payment-tracking key, represented as a UUID. Swift made block 3 field 121 mandatory on MT103 and several other payment instructions in its 2018 standards release. Quote the UETR when requesting a Tracker status or asking a bank to investigate a stalled payment. See SWIFT payment tracing and UETR for the investigation runbook.

InstrId (Instruction Identification): A point-to-point instruction reference. A subsequent bank may assign a different value; do not assume it persists across the payment chain. Swift's CBPR+ example and Bank of America's mapping use a 16-character limit and show an MT103 :20: correspondence. Quote the reference your own bank provides when it asks for its instruction identifier.

EndToEndId: A customer-level end-to-end reference, such as an invoice or purchase-order identifier. MT103 has no dedicated EndToEndId field, but a bank mapping can draw an ordering-customer reference from MT103 :70: when one is supplied. If no usable reference is supplied, the ISO message may carry NOTPROVIDED; a native ISO message can carry that value too. It is not a reliable test of MT origin. For reconciliation, ask the originator and its bank which reference they actually populate.

TxId (Transaction Identification): A transaction reference where populated. Ask the bank whether it appears in the relevant message and whether its enquiry process accepts it; do not infer that every payment record contains one.

For an investigation: Start with the UETR if available, then supply your bank's own reference and the last available Tracker information. Ask the bank which additional identifiers it needs for that case; a Tracker update does not by itself prove where funds are held.

Worked review: references agree, business context does not

This is a constructed teaching case with selected reference fields, not a complete MT103, an executable conversion, a validated CBPR+ payload or a bank-tested transaction. Cedar Supply and every reference below are fictional. The two observations are from different points in a hypothetical payment chain; they are not a universal input/output mapping rule.

The source ERP entry does not establish that its invoice identifier was transmitted in an MT field. Nor does the recipient's report establish what was present in the underlying pacs.008. Separate those evidence boundaries before blaming conversion.

Three separate questions: is the message correct under the applicable implementation; do these records identify the same transfer; and can the business allocate the credit to an invoice? Passing one does not answer the others. Use the existing bank enquiry checklist to assemble the investigation, keeping the missing facts explicit. No selected field here substitutes for the bank's implementation or usage guideline.

Parties and Agents

pacs.008 separates payment parties, agents and the banks sending a particular message leg. The cited bank mapping illustrates their correspondence to MT fields, but an individual route needs its own message evidence:

Payment-party roles: Dbtr (debtor), DbtrAgt (debtor agent), CdtrAgt (creditor agent) and Cdtr (creditor) identify distinct roles. Do not treat the debtor agent as the sender of every leg or assume that all correspondent messages reproduce these fields unchanged.

Leg-specific agents: InstructingAgt and InstructedAgt describe the agents sending and receiving the message leg being examined. Read them in the context of that leg, not as substitutes for DbtrAgt and CdtrAgt.

Intermediary and reimbursement agents: Bank of America's public example places MT103 :56a: in IntrmyAgt1 and :53A: in GrpHdr/SttlmInf/InstgRmbrsmntAgt. That does not establish a rule for every :53a: option or prove that every such payment has a cover leg. Check the option, settlement method and bank implementation before interpreting the route.

Additional party roles: UltmtDbtr and UltmtCdtr can identify ultimate parties distinct from the immediate debtor and creditor. Whether to populate them in a payment-on-behalf-of or other arrangement depends on the bank's applicable requirements and the actual parties; MT103 has no dedicated equivalent fields.

LEI in party identification: pacs.008 can carry Legal Entity Identifiers in party-identification elements. MT103 had no dedicated structured LEI field. Check the applicable usage rules and bank support before relying on an LEI being present.

CBPR+ Address Truncation and Structured Postal Addresses

Postal addresses remain a migration challenge. Some MT103 name-and-address options combine details in short text lines; pacs.008 has a typed PostalAddress structure. CBPR+ planned to remove fully unstructured addresses in its November 2026 standards release, but Swift deferred that release on 27 August 2026. The format target and its effective date must be distinguished.

Status: the cutover date was deferred on 27 August 2026. Swift delayed its November 2026 Standards Release after industry requests for more preparation time. The Federal Reserve Financial Services and Bank of England announced related changes to their own release plans. 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. MT103 :70: allows four lines of 35 characters. Some free-text name-and-address field options also impose short line limits, but the format differs by option; a BIC-only option is not four free-text address lines. Check the specific :50a:, :59a: or agent-field option before calculating what can survive translation. The MT103 field-by-field reference covers :70: in detail.

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

• Unstructured — free-text AdrLine elements only, with no TwnNm or Ctry broken out into their own fields. A converted MT103 may have this shape when the source contains only free-text address data; it is the format slated for removal.
• 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 — Town and Country in their dedicated elements, with any other available details such as street, building number or postcode in their own elements; no free-text AdrLine.

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 addresses 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. Fully structured addresses can carry additional components, but the cited minimum does not require every optional address element.

Conversion has limits. Swift's MT-sender contingency service applies additional FIN validation. A failing MT is NAKed; a message that passes can still be aborted if it cannot be translated. Conversion does not add rich structured data that was absent from the MT source. Address remediation should start in the source system, and operators should test actual converted outputs rather than assume that a free-text address will become a valid hybrid address.

Sanctions screening is also affected. A free-text address can make it harder to distinguish a street or town name from a country or party name during screening. Separating town and country gives a screening system more specific fields to evaluate, although it does not eliminate false positives. Check how your provider uses those fields and handles uncertain matches. For the broader control programme, see sanctions screening for payment operators.

Repair and rejection. Ahead of the network-level change, a bank may reject an address locally under its own validation rules. Once Swift implements the deferred CBPR+ change, fully unstructured addresses on in-scope parties and agents are expected to fail the network rule. Test the specific validation result, repair the source record and resubmit through the bank's process; do not infer a settlement failure from an address-format rejection.

Address remediation starts before network submission. Capture town and country as discrete fields where possible, and check legacy customer or ERP records that still hold only free text. Swift's separate address-structuring model can infer town and country from some unstructured debtor/creditor data before a message is sent, with confidence scores and a recommendation to validate uncertain results. Swift says its message translator does not itself infer those fields. Model-based repair is a preprocessing aid, not a reason to skip source-data quality controls or bank testing.

What to test before the deadline, and monitor after. Before cutover: inventory outbound MT and pacs.008 traffic and classify each populated party or agent PostalAddress by format; record BIC-only agents and absent addresses separately. Trace fully unstructured output back to its source system rather than assuming translation will repair it. Confirm hybrid/structured handling with banks in active corridors. After cutover: monitor address-related validation failures and investigate any incomplete address data in the payment messages actually received; do not infer a settlement failure or correspondent degradation from an address-format result alone.

Charges, Settlement, and Remittance Information

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

These codes describe the charge-bearer instruction, not a guarantee of an exact net credit. For B2B invoice settlement, confirm fee handling with the banks and reconcile the beneficiary's actual receipt. See OUR, SHA, and BEN: SWIFT charge options.

ChrgsInf can carry individual charge amounts and charging agents in ISO 20022 messages. It is not proof that every fee along the route was captured or that the beneficiary received the instructed amount. Compare the bank's fee information with the actual credit and the applicable charge instruction.

RmtInf (Remittance Information) can carry more structured invoice detail than MT103 :70:, but conversion may route parts of the source field elsewhere. The MT103 :70: field allows 4 × 35 characters. pacs.008 RmtInf supports both:

• Ustrd (unstructured): free text; Bank of America's mapping sends ordinary :70: remittance text here but routes a /ROC/ reference to EndToEndId
• Strd (structured): machine-readable invoice references (CreditorReference), tax IDs (TaxRmtInf), document references (RfrdDocInf)

Operators expecting structured remittance data for auto-reconciliation must inspect the actual Strd content supplied through their bank. Do not assume that MT103-to-ISO conversion reconstructs structured invoice fields from free text, or that every :70: code stays in Ustrd.

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): An interbank status message, including a rejection where applicable. A bank's gpi Tracker view is a separate tracking service. Swift's April 2026 cover-payment guidance distinguishes a Tracker update through API, trck or MT299 from a pacs.002 reject sent to the previous institution. Ask for the last available Tracker update and, where relevant, the interbank rejection; do not assume one is a copy of the other. If settled funds are sent back, look for the linked pacs.004 return. See the status-versus-return operator reference.

camt.056 (FI-to-FI Payment Cancellation Request): An interbank request to cancel or recall a payment, broadly corresponding to MT192/292 cancellation requests. The bank can receive a camt.029 response to that request. A request is not proof that settled funds came back: the return of funds uses pacs.004 where applicable. The reason codes and time limits depend on the governing scheme and case; ask the bank which rules apply.

camt.110 / camt.111 (Exceptions and Investigations): A structured investigation request and response pair available through Swift Case Management. Banks' adoption and the route exposed to customers vary. Ask your bank whether it supports these messages for the case at hand; do not assume that every investigation follows the same message path.

How the flows connect: Obtain the UETR and the last available Tracker status. Ask the bank whether there is an interbank rejection, a confirmed beneficiary credit, or a linked return. If the payment is unresolved, the bank can choose an enquiry route it supports; camt.110/111 adoption is phased. A request to cancel or recall uses a different route, camt.056/camt.029, and a positive outcome does not by itself replace evidence that funds actually returned. This is a decision by purpose, not a fixed four-message sequence.

gpi overlay: gpi uses the UETR to connect tracking information across a payment. Tracker updates can be supplied by different supported channels; they are not all pacs.002 messages. pacs.002, pacs.004 and the camt investigation/cancellation messages have separate interbank purposes. Banks differ in the services they expose to customers.

Common Operator Mistakes Post-Migration

Quoting EndToEndId for investigation when it shows NOTPROVIDED. That value is not a usable customer reference or proof of MT conversion. Ask the bank to search by UETR or its own instruction reference.

Assuming conversion created structured remittance data. Swift says conversion cannot add rich structured data absent from the MT source. Bank of America's mapping also routes a :70: /ROC/ reference to EndToEndId rather than leaving all :70: content in Ustrd. Inspect the actual RmtInf/Strd and PmtId output before building automatic reconciliation.

Treating InstrId as a guaranteed persistent identifier. A subsequent bank may assign a different InstrId. Use the UETR for Swift payment tracking when available and retain any other references the banks provide for reconciliation; do not infer downstream InstrId values from the originating bank's record.

Confusing DEBT/SHAR/CRED with OUR/SHA/BEN in payment instructions. These code sets correspond in the cited bank mapping, but an operator must check which values its own initiation interface accepts and how that bank translates them. Do not send an MT code to an MX field without confirming the interface contract.

Assuming :72: content survived intact in pacs.008. MT-to-ISO conversion can handle different codewords differently. Audit processes that parse :72: and compare representative converted outputs with the source MT and the bank's applicable mapping before relying on an ISO field.

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 when available. For in-scope Swift payment instructions, retain the UETR supplied by your bank so a later investigation can use it. Ask the bank how the reference is exposed in its portal or API.

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 and check the effect on reconciliation. Do not classify those records as translated MT103s on that value alone.
• :72: migration inventory: Identify internal processes that parse MT103 :72: /CODEWORD/ patterns. For native pacs.008, determine which structured element, if any, carries each business purpose; bank mappings differ, and the possible destinations extend beyond instruction, purpose and regulatory-reporting fields.
• Address format review: Audit populated debtor, creditor and agent addresses and identify unstructured MT field options. Record BIC-only agents and absent PostalAddress separately. Target structured or hybrid addresses where applicable; the CBPR+ enforcement date is deferred and unannounced.
• 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, agree with the bank and counterparty which business reference belongs in EndToEndId and confirm that it survives to their reconciliation feed.

Bank Enquiry Checklist

When raising a payment investigation, assemble the information your bank can use to locate the transaction:

Download the blank payment investigation evidence sheet (one-page PDF) to record the references, observed status and question for your bank. The sheet does not confirm payment or replace the bank's own records.

Provide if available:

• UETR from the bank's payment confirmation or Tracker view
• Your bank's instruction or sender reference
• Value date and amount/currency as recorded by the bank
• Debtor and creditor agent identifiers shown for the investigated payment

For stalled payments, also provide:

• Last available gpi Tracker status and any separate pacs.002 rejection
• BIC of last correspondent to update the Tracker
• Timestamp of last Tracker update
• Whether the bank has evidence of beneficiary credit or a linked return

For a cancellation or recall:

• Ask whether a camt.056 request was sent and which scheme or bank reason applies
• Ask what any camt.029 response reported and whether there is evidence of beneficiary credit or a linked pacs.004 return

For an unresolved enquiry:

• Ask which exceptions-and-investigations route your bank supports for this case

What to ask for by message type:

• For a stalled payment: request the Tracker history for the UETR and ask separately about any pacs.002 rejection.
• For a cancellation: ask whether a camt.056 request is available and which reason applies.
• For an unresolved case: ask which enquiry route the bank supports and what information it needs.

---

Scope Note

Source boundary: Swift MyStandards contains the authoritative CBPR+ usage and translation rules, but this guide does not rely on a current message-specific rule text from it. Public Swift material and named bank implementation guides support the specific examples above. A bank example should not be used as a universal rule for another bank, MT option, corridor or version.

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) — supported here by named public bank examples; check the applicable message-specific Swift guideline in MyStandards for production use
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

Date and scope note: Swift confirms that FI-to-FI cross-border coexistence ended on 22 November 2025, while limited MT-sender contingency conversion continues for qualifying messages. The proposed 14 November 2026 CBPR+ unstructured-address cutover was deferred; no replacement date is stated in the cited notices. Confirm current network rules before changing production validation.

In flux: Case Management support and bank population of optional pacs.008 fields vary. Ask the relevant banks for their current implementation and the actual output for the payment being investigated.

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.