— 18 mai 2026 · 11 min de lecture

Migrer de MT à MX sans casser votre réconciliation nostro

La période de coexistence SWIFT MT/MX a pris fin le 22 novembre 2025 pour les paiements transfrontaliers. Beaucoup de banques tier-2 et tier-3 finalisent encore la migration en 2026 — et la grande majorité des incidents post-bascule concernent la réconciliation nostro. Décomposition technique.

Rappel : la roadmap SWIFT

SWIFT (Society for Worldwide Interbank Financial Telecommunication) a annoncé en 2018 la migration des paiements correspondants de l'ancien format propriétaire MT (Message Type, FIN protocol) vers ISO 20022 MX (UNIFI, XML). Le calendrier a glissé plusieurs fois (impact COVID, retard de certaines banques), mais la fenêtre de coexistence s'est terminée le 22 novembre 2025. Depuis cette date, les paiements correspondants doivent être émis nativement en MX, et SWIFT ne fournit plus de service de traduction MT↔MX pour ce segment.

Les messages concernés en priorité par la migration paiements : 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.

Impact spécifique sur la réconciliation nostro

Un compte nostro est un compte que votre banque détient chez une banque correspondante à l'étranger (ex : BNP Paribas Paris détient un compte USD chez JP Morgan New York). Le réconcilier quotidiennement signifie : comparer les mouvements vus chez le correspondant (relevé MT940 EOD + intra-day MT942) avec les mouvements prévus internes (paiements émis, paiements reçus). Tout écart = investigation immédiate.

Le passage MT → MX change :

MT940 → camt.053 (Bank-to-Customer Statement) : relevé EOD enrichi avec structure XML, codes purpose ISO 20022, références structurées (RmtInf), data de valeur séparée de la date d'opération.
MT942 → camt.052 (Bank-to-Customer Interim Statement) : relevé intra-day, multiple par jour possibles.
MT900 / MT910 → camt.054 (Bank-to-Customer Debit/Credit Notification) : notifications individuelles débit/crédit (souvent utilisées pour notifier des paiements importants au fil de l'eau).
MT950 (Statement Message) → camt.053 aussi, certaines banques utilisaient l'un, certaines l'autre.

Cinq pièges de réconciliation post-migration

1. Granularité de transaction différente

En MT940/950, beaucoup de banques agrégeaient des transactions identiques en lignes consolidées (« 3 paiements salaires en une ligne 2 500 EUR »). En camt.053, la convention CGI-MP (Common Global Implementation - Market Practice) recommande au contraire d'émettre une transaction par opération sous-jacente. Conséquence directe : votre moteur de réconciliation interne, qui était calibré sur N lignes en MT940, doit gérer 3N à 10N lignes en camt.053. Les rules engines basés sur montant exact (matching 1:1 paiement→ligne) doivent être revus.

2. Codes Bank Transaction Code (BTC) ISO 20022

Les codes de nature de transaction MT (TRN/REL/CHQ/PMT/etc. de la zone :86: structurée) sont remplacés par BankTransactionCode ISO 20022, un triplet Domain/Family/SubFamily beaucoup plus granulaire (300+ combinations). Le mapping MT→ISO20022 n'est pas 1:1 : une seule TRN MT peut correspondre à plusieurs SubFamily camt.053. Cela casse les règles de classification automatique côté client.

3. Références structurées (RmtInf)

En MT103, la référence partenaire allait dans le champ :70: (texte libre 4 lignes × 35 chars). En pacs.008, elle va dans la balise XML <RmtInf> qui supporte le structured remittance (ISO 11649 RF reference, ou champ <Strd> détaillé). Si votre processus reconciliation côté nostro extrait la référence client du champ texte libre du MT940, il faut maintenant l'extraire de la structure XML camt.053. Les regex ne suffisent pas.

4. Données AML/sanctions enrichies

pacs.008/009 portent nativement les données ordonnateur et bénéficiaire structurées (adresses postales détaillées, LEI, identifiants nationaux). Beaucoup de banques receveuses post-MX commencent à rejeter les paiements dont les data structures sont incomplètes (CBPR+ Rulebook SWIFT). Cela crée des paiements en suspens ou retournés, qui apparaissent comme écarts de réconciliation. Préparer la pipeline pour gérer les retours pacs.004 (Payment Return) et investigations camt.027/028 (Request for Payment Status / Reply).

5. EndToEndId vs TxId vs UETR

Trois identifiants coexistent dans pacs.008 : EndToEndId (référence applicative client, traverse la chaîne), TxId (identifiant unique par le débiteur), UETR (Unique End-to-End Transaction Reference, UUID assigné par SWIFT gpi, RFC 4122). L'UETR existait déjà en MT103 (champ :121: optionnel) mais devient obligatoire en MX. Votre moteur de réconciliation doit pivoter sur l'UETR comme clé naturelle, et non plus sur l'EndToEndId qui peut être modifié en cours de route par les banques intermédiaires.

Plan de bascule type 12 semaines

S1-2 : cartographier tous les flux nostro existants MT, lister les codes TRN utilisés, les volumes par devise, les correspondants.
S3-4 : définir le mapping MT↔ISO20022 spécifique aux conventions de chaque correspondant. Documenter dans une matrice.
S5-8 : parallel run. Recevoir MT940 ET camt.053 du correspondant, ingérer les deux dans pipelines séparés, comparer les sorties de la réconciliation. Investiguer chaque divergence (typiquement 0,5-2 % les premières semaines).
S9-10 : tests sur sous-ensemble (par exemple un correspondant secondaire) avec bascule production en lecture seule de camt.053.
S11 : bascule complète, mais conserver le pipeline MT en hot standby capable de reprendre en quelques minutes.
S12 : déactivation du pipeline MT et nettoyage. Conserver les archives MT 7-10 ans pour audit.

Exemple : parsing camt.053 vs MT940

<!-- camt.053 fragment d'un mouvement -->
<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>

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

Références

SWIFT — CBPR+ Cross-Border Payments and Reporting Plus rulebook (obligatoire depuis nov 2025). swift.com/standards/iso-20022
ISO 20022 — base de registre des messages financiers. iso20022.org
CGI-MP (Common Global Implementation - Market Practice) : guides d'implémentation pour camt et pain messages. swift.com
SWIFT gpi (Global Payments Innovation) — UETR specification et 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 (utilisé pour UETR). datatracker.ietf.org/doc/rfc4122

Pour le contexte ISO 20022 global, voir notre fondation « Paysage des standards EDI ». Voir aussi le pattern « Transactional Outbox » pour publier les écarts de réconciliation vers Kafka sans 2PC.

Fondamentaux

Standards

Messages phares

Outils