La famille MT : messages de paiement et de cash reporting
Les messages MT (Message Type) sont le format historique du réseau Swift FIN, des messages texte structurés par des tags (:20:, :61:…) et classés en catégories : 1 = paiements clientèle, 2 = transferts entre institutions, 9 = cash management. Pour la réconciliation, la catégorie 9 est centrale, puisqu'elle transporte les relevés de compte.
| Message | Catégorie | Rôle | Équivalent ISO 20022 |
|---|---|---|---|
| MT101 | 1 | Ordre de virement transmis par un client (souvent relayé entre banques, request for transfer) | pain.001 |
| MT103 | 1 | Virement client interbancaire (le message qui « transporte » le paiement) | pacs.008 |
| MT900 | 9 | Confirmation de débit unitaire | camt.054 |
| MT910 | 9 | Confirmation de crédit unitaire | camt.054 |
| MT940 | 9 | Relevé de compte client de fin de journée | camt.053 |
| MT942 | 9 | Relevé intraday (écritures depuis le dernier rapport, tags :13D:, :90D:/:90C:) | camt.052 |
| MT950 | 9 | Relevé de compte interbancaire (comptes nostro, sans détail client :86:) | camt.053 |
Un « MT940 » reçu par une entreprise ne transite pas forcément par Swift. Le format s'est imposé comme lingua franca des relevés électroniques, et la plupart des banques le livrent en fichier via EBICS, sFTP ou FileAct. Le message est alors dépourvu des blocs d'en-tête réseau FIN, sans que la lecture des tags en soit affectée.
Structure du MT940, tag par tag
Un MT940 est une suite ordonnée de tags. Les soldes (:60F:, :62F:, :64:, :65:) suivent tous le même format compact : sens (C/D) + date AAMMJJ + devise ISO + montant à virgule décimale. Chaque écriture est portée par un couple :61: (données structurées) + :86: (libellé et informations complémentaires), le premier normalisé, le second laissé à la main de chaque banque.
| Tag | Nom | Format / contenu | Obligatoire |
|---|---|---|---|
:20: | Référence du message | 16x (identifiant attribué par la banque émettrice) | Oui |
:21: | Référence liée | 16x (référence d'un message associé) | Non |
:25: | Identification du compte | 35x (IBAN ou identifiant banque/guichet/compte) | Oui |
:28C: | Numéro de relevé / séquence | 5n[/5n] (ex. 132/1) ; permet de détecter un relevé manquant | Oui |
:60F: / :60M: | Solde d'ouverture | 1!a6!n3!a15d ; F = initial, M = intermédiaire (relevé multi-messages) | Oui |
:61: | Ligne d'écriture | Champ composite (voir dissection ci-dessous), 1 par mouvement | Non (0-n) |
:86: | Informations pour le titulaire | 6×65x (libellé, contreparties, références) ; structure propre à chaque banque | Non |
:62F: / :62M: | Solde de clôture comptable | Même format que :60F: ; doit égaler ouverture + somme des :61: | Oui |
:64: | Solde disponible | Solde en valeur, utilisable en trésorerie | Non |
:65: | Solde disponible prévisionnel | 1 ligne par date de valeur future | Non (0-n) |
:60F: + Σ des montants signés des :61: = :62F:, et le :62F: du jour J doit égaler le :60F: du jour J+1. Combiné au séquencement :28C:, cela garantit qu'aucun relevé ni aucune écriture ne manque.Dissection du champ :61:
Le champ :61: concentre toute l'information structurée d'une écriture en une seule ligne dense. Sa grammaire Swift s'écrit 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x][34x], notation compacte que seule la décomposition d'une ligne réelle rend lisible.
:61:2607100710C12500,00NTRFPAYOUT-ADYEN-42//BNK7593012
260710 1. Date de valeur (6!n, AAMMJJ) -> 10 juillet 2026
0710 2. Date comptable (4!n, MMJJ, option) -> 10/07 ; l'annee est implicite
C 3. Sens (2a) : C credit, D debit,
RC/RD contre-passation credit/debit
(absent) 4. Code fonds (1!a) : 3e lettre de la
devise, rarement utilise
12500,00 5. Montant (15d) : virgule decimale
obligatoire, AUCUN separateur de milliers
NTRF 6. Type d'operation (1!a3!c) :
N + code proprietaire Swift (TRF ici)
PAYOUT-ADYEN-42 7. Reference pour le client (16x) :
"NONREF" si la banque n'en a pas
//BNK7593012 8. Reference de la banque ([//16x])
(ligne suivante) 9. Details supplementaires ([34x]), option| Code | Signification |
|---|---|
NTRF | Virement (transfer) |
NDDT | Prélèvement débité (direct debit) |
NCHG | Frais et commissions (charges) |
NCHK | Chèque |
NSTO | Ordre permanent (standing order) |
NRTI | Opération retournée / impayé (returned item) |
NINT | Intérêts |
NFEX | Opération de change |
NMSC | Divers (miscellaneous), la catégorie fourre-tout |
EndToEndId SEPA de 35 caractères ne tient pas. Cette limite est la première raison de migrer vers camt.053.Exemple complet de MT940 annoté
Relevé du 10/07/2026 d'un marchand e-commerce : deux payouts PSP en crédit, un prélèvement fournisseur et des frais bancaires en débit. Les lignes commençant par # sont des annotations pédagogiques, ajoutées ici pour la lecture et absentes du fichier réel.
# En-tete reseau FIN (simplifie) : present si le message transite par Swift,
# absent quand le MT940 est livre en fichier via EBICS / sFTP.
{1:F01BNPAFRPPAXXX0000000000}{2:O940AGRIFRPPXXXN}{4:
:20:AC940260710-0132
# :20: reference unique du message, attribuee par la banque emettrice
:25:FR7630004008120002345678928
# :25: compte concerne (ici l'IBAN)
:28C:132/1
# :28C: releve n° 132 de l'annee, page 1 -> controle de sequence
:60F:C260709EUR98425,12
# :60F: solde d'ouverture : Credit, 09/07/2026, EUR, 98 425,12
:61:2607100710C12500,00NTRFPAYOUT-ADYEN-42//BNK7593012
:86:/ORDP/ADYEN N.V./REMI/SETTLEMENT BATCH 42 ACME FR
# Ecriture 1 : payout Adyen 12 500,00 en credit. Le :86: identifie le
# donneur d'ordre (/ORDP/) et le motif (/REMI/) - codage propre a la banque.
:61:2607100710C8420,00NTRFSTRIPE-PO-1PAB77//BNK7593013
:86:/ORDP/STRIPE TECHNOLOGY EUROPE/REMI/STRIPE PAYOUT
# Ecriture 2 : payout Stripe 8 420,00. La reference client (16x max)
# a ete tronquee : l'identifiant complet est po_1PabQ2KiAcme7731.
:61:2607100710D1840,50NDDTLOYER-2026-07//BNK7593044
:86:/MARF/RUM-FONCDOCKS-0042/CRED/FR12ZZZ556677/REMI/LOYER JUILLET
# Ecriture 3 : prelevement SEPA debite. /MARF/ = reference de mandat (RUM),
# /CRED/ = identifiant creancier SEPA (ICS).
:61:2607100710D25,00NCHGNONREF//BNK7593101
:86:COMMISSION DE TENUE DE COMPTE JUILLET 2026
# Ecriture 4 : frais bancaires, NCHG, pas de reference client -> NONREF.
:62F:C260710EUR117479,62
# :62F: solde de cloture : 98 425,12 + 12 500,00 + 8 420,00 - 1 840,50 - 25,00
:64:C260710EUR117479,62
# :64: solde disponible en valeur (identique ici : tout est en valeur du jour)
:65:C260711EUR117479,62
# :65: solde previsionnel au 11/07
-}- Contrôle 1 (arithmétique) : 98 425,12 + 12 500,00 + 8 420,00 − 1 840,50 − 25,00 = 117 479,62 =
:62F:. ✔ - Contrôle 2 (séquence) : le relevé 132/1 suit le 131/x de la veille, et son
:60F:égale le:62F:de la veille. - Contrôle 3 (matching) :
PAYOUT-ADYEN-42se rapproche du batch 42 du settlement report Adyen ; la troncature de la référence Stripe impose un matching de secours par montant + date.
Le BIC : identifier les banques
Le BIC (Business Identifier Code, ISO 9362) identifie chaque établissement sur le réseau Swift et dans les messages SEPA. Il existe en version 8 caractères (BIC8, l'établissement) ou 11 caractères (BIC11, avec code d'agence).
| Positions | Contenu | Exemple | Remarque |
|---|---|---|---|
| 1-4 | Code établissement | BNPA | Attribué par Swift |
| 5-6 | Code pays ISO 3166 | FR | |
| 7-8 | Code localisation | PP | Un 0 en 8e position signale un BIC de test |
| 9-11 | Code agence (optionnel) | XXX | XXX ou absent = siège / toutes agences |
Côté back-office, le BIC apparaît dans les en-têtes FIN, dans les coordonnées des contreparties (RltdAgts en camt) et dans le paramétrage des canaux bancaires. Depuis le règlement SEPA 260/2012, l'IBAN seul suffit pour les virements et prélèvements intra-UE (« IBAN only »), mais le BIC reste indispensable pour le paramétrage multi-banques et l'international.
Migration ISO 20022 : CBPR+ et l'avenir du MT940
Le programme CBPR+ (Cross-Border Payments and Reporting Plus) organise la migration des paiements transfrontières Swift des messages MT vers les messages MX (ISO 20022). La coexistence s'est ouverte en mars 2023. Les MT des catégories 1 et 2 ont été retirés des échanges interbancaires FIN en novembre 2025, terme de la coexistence pour ces deux catégories.
La troncature en cascade désigne la perte d'information subie par un paiement lorsqu'il change de format en cours de route. Un virement reçu en pacs.008 riche en données peut être restitué dans un MT940 appauvri, où les références longues et les parties structurées ne trouvent plus de place. Les banques gèrent pour cela des tables de correspondance MX→MT avec perte d'information documentée (concept de data truncation CBPR+), ce qui pèse dans le choix de recevoir les relevés en ISO 20022.