— May 18, 2026 · 11 min read

How to migrate from MT to MX without breaking your nostro reconciliation

The SWIFT MT/MX coexistence period ended on 22 November 2025 for cross-border payments. Many tier-2 and tier-3 banks are still finalising the migration in 2026 — and the vast majority of post-switchover incidents involve nostro reconciliation. Technical breakdown.

Recap: the SWIFT roadmap

SWIFT (Society for Worldwide Interbank Financial Telecommunication) announced in 2018 the migration of correspondent payments from the old proprietary MT (Message Type, FIN protocol) format to ISO 20022 MX (UNIFI, XML). The schedule slipped several times (COVID impact, some banks lagging), but the coexistence window ended on 22 November 2025. Since that date, correspondent payments must be sent natively in MX, and SWIFT no longer provides MT↔MX translation service for this segment.

Messages first concerned by the payments migration: MT 103 (customer credit transfer) → pacs.008, MT 202/202COV (bank-to-bank, cover) → pacs.009, MT 192/292/195/295 (cancellation, request for cancellation) → camt.029/056, MT 900/910 (debit/credit confirmations) → camt.054.

Specific impact on nostro reconciliation

A nostro account is an account your bank holds at a foreign correspondent bank (e.g. BNP Paribas Paris holds a USD account at JP Morgan New York). Reconciling it daily means: comparing movements seen at the correspondent (EOD MT940 statement + intra-day MT942) with expected internal movements (sent payments, received payments). Any gap = immediate investigation.

The MT → MX shift changes:

MT940 → camt.053 (Bank-to-Customer Statement): EOD statement enriched with XML structure, ISO 20022 purpose codes, structured references (RmtInf), value date separated from booking date.
MT942 → camt.052 (Bank-to-Customer Interim Statement): intra-day statement, multiple per day possible.
MT900 / MT910 → camt.054 (Bank-to-Customer Debit/Credit Notification): individual debit/credit notifications (often used to notify large payments at-the-go).
MT950 (Statement Message) → camt.053 too, some banks used one, some used the other.

Five post-migration reconciliation pitfalls

1. Different transaction granularity

In MT940/950, many banks aggregated identical transactions into consolidated lines ("3 salary payments in one line of EUR 2 500"). In camt.053, the CGI-MP (Common Global Implementation - Market Practice) convention recommends, on the contrary, emitting one transaction per underlying operation. Direct consequence: your internal reconciliation engine, calibrated on N lines in MT940, must handle 3N to 10N lines in camt.053. Rules engines based on exact amount (1:1 payment→line matching) need revisiting.

2. ISO 20022 Bank Transaction Codes (BTC)

MT transaction nature codes (TRN/REL/CHQ/PMT/etc. from the structured :86: zone) are replaced by BankTransactionCode ISO 20022, a much more granular triplet Domain/Family/SubFamily (300+ combinations). MT→ISO20022 mapping is not 1:1: a single MT TRN may correspond to several camt.053 SubFamilies. This breaks client-side automatic classification rules.

3. Structured references (RmtInf)

In MT103, the partner reference went in the :70: field (free text, 4 lines × 35 chars). In pacs.008, it goes in the XML tag <RmtInf> which supports structured remittance (ISO 11649 RF reference, or detailed <Strd> field). If your nostro reconciliation process extracts the customer reference from the MT940 free text, you now need to extract it from the camt.053 XML structure. Regex is not enough.

4. Enriched AML/sanctions data

pacs.008/009 natively carry structured ordering party and beneficiary data (detailed postal addresses, LEI, national identifiers). Many receiving banks post-MX are starting to reject payments with incomplete data structures (CBPR+ Rulebook SWIFT). This creates pending or returned payments, appearing as reconciliation gaps. Prepare the pipeline to handle pacs.004 (Payment Return) and investigation messages camt.027/028 (Request for Payment Status / Reply).

5. EndToEndId vs TxId vs UETR

Three identifiers coexist in pacs.008: EndToEndId (client application reference, traverses the chain), TxId (unique identifier by the debtor), UETR (Unique End-to-End Transaction Reference, UUID assigned by SWIFT gpi, RFC 4122). UETR existed already in MT103 (optional :121: field) but becomes mandatory in MX. Your reconciliation engine must pivot on UETR as natural key, not on EndToEndId which may be altered mid-route by intermediate banks.

Typical 12-week switchover plan

W1-2: map all existing MT nostro flows, list TRN codes used, volumes by currency, correspondents.
W3-4: define MT↔ISO20022 mapping specific to each correspondent's conventions. Document in a matrix.
W5-8: parallel run. Receive both MT940 AND camt.053 from the correspondent, ingest both in separate pipelines, compare reconciliation outputs. Investigate every divergence (typically 0.5-2% in early weeks).
W9-10: tests on subset (e.g. a secondary correspondent) with read-only production switchover of camt.053.
W11: full switchover, but keep the MT pipeline on hot standby capable of resuming in minutes.
W12: MT pipeline decommissioned and cleaned up. Keep MT archives 7-10 years for audit.

Example: parsing camt.053 vs MT940

<!-- camt.053 movement fragment -->
<Ntry>
  <Amt Ccy="USD">125000.00</Amt>
  <CdtDbtInd>CRDT</CdtDbtInd>
  <Sts>BOOK</Sts>
  <BookgDt><Dt>2026-05-18</Dt></BookgDt>
  <ValDt><Dt>2026-05-18</Dt></ValDt>
  <BkTxCd>
    <Domn>
      <Cd>PMNT</Cd>
      <Fmly><Cd>RCDT</Cd><SubFmlyCd>STDO</SubFmlyCd></Fmly>
    </Domn>
  </BkTxCd>
  <NtryDtls>
    <TxDtls>
      <Refs>
        <UETR>3aa5d6dc-65d3-4f01-8a47-2e7c12a44b8b</UETR>
        <EndToEndId>INV-2026-12345</EndToEndId>
      </Refs>
      <RltdPties>
        <Dbtr><Pty><Nm>ACME SAS</Nm></Pty></Dbtr>
        <DbtrAcct><Id><IBAN>FR1420041010050500013M02606</IBAN></Id></DbtrAcct>
      </RltdPties>
      <RmtInf>
        <Strd>
          <CdtrRefInf>
            <Tp><CdOrPrtry><Cd>SCOR</Cd></CdOrPrtry></Tp>
            <Ref>RF18539007547034</Ref>
          </CdtrRefInf>
        </Strd>
      </RmtInf>
    </TxDtls>
  </NtryDtls>
</Ntry>

# Equivalent MT940 (before)
:61:2605180518C125000,00NTRFNONREF
:86:166?00FACT 2026-12345?20ACME SAS?32FR1420041010050500013M02606

References

SWIFT — CBPR+ Cross-Border Payments and Reporting Plus rulebook (mandatory since Nov 2025). swift.com/standards/iso-20022
ISO 20022 — financial message registry. iso20022.org
CGI-MP (Common Global Implementation - Market Practice): implementation guides for camt and pain messages. swift.com
SWIFT gpi (Global Payments Innovation) — UETR specification and tracker. swift.com/our-solutions/swift-gpi
ISO 11649:2009 — Structured Creditor Reference to Remittance Information. iso.org
RFC 4122 — A Universally Unique Identifier (UUID) URN Namespace (used for UETR). datatracker.ietf.org/doc/rfc4122

For global ISO 20022 context, see our foundation "EDI standards landscape". See also the pattern "Transactional Outbox" to publish reconciliation gaps to Kafka without 2PC.

Foundations

Standards

Flagship messages

Tools