MT103 Viewer SWIFT
Déposez un MT103 et lisez-le champ par champ — blocs 1 à 5, donneur d’ordre, bénéficiaire, frais et UETR. Entièrement dans votre navigateur.
Qu’est-ce qu’un MT103 et est-il encore utilisé en 2026 ?
Un MT103 est le « Single Customer Credit Transfer » de SWIFT : le message texte qu’une banque envoie pour transférer de l’argent d’un client vers un autre, et l’ordre de virement le plus répandu au monde. C’est une chaîne de blocs entre accolades — {1:} en-tête de base, {2:} en-tête applicatif, {3:} en-tête utilisateur, {4:} le message lui-même, {5:} trailer — le paiement étant porté par le bloc 4 sous forme de champs balisés (:20: référence, :32A: date de valeur, devise et montant, :50a: donneur d’ordre, :59a: bénéficiaire, :71A: frais). Depuis la fin de la coexistence MT / ISO 20022 sur CBPR+, le 22 novembre 2025, le MT103 est retiré du trafic interbancaire transfrontalier sur ce rail, où le pacs.008 le remplace — mais il reste produit et consommé chaque jour en domestique, en banque-à-entreprise et en host-to-host, soit exactement le trafic que lit cette visionneuse hors ligne et gratuite.
À propos de la visionneuse MT103
Le MT103 est un message texte à plat, pas du XML, et c’est précisément ce qui le rend illisible à l’œil nu : une ligne comme « :32A:261120USD125000,00 » comprime une date de valeur, une devise et un montant en une seule chaîne ininterrompue, et « :50K: » et « :50A: » désignent deux choses radicalement différentes — un nom et une adresse dans un cas, un BIC dans l’autre. Cette visionneuse démonte le fichier pour vous : elle sépare les cinq blocs SWIFT, lit l’en-tête de base (le terminal logique et le BIC de l’émetteur), l’en-tête applicatif (entrant ou sortant, type de message, priorité), l’en-tête utilisateur (l’identifiant de type de service et l’UETR du tag 121), puis liste chaque champ du bloc 4 dans son ordre d’apparition, chacun avec un libellé en clair.
Au décodage s’ajoutent les contrôles qui peuvent honnêtement être menés hors ligne. L’outil vérifie la présence des six champs obligatoires (:20:, :23B:, :32A:, :50a:, :59a:, :71A:), que le :32A: a bien la forme d’une date de valeur suivie d’une devise sur trois lettres et d’un montant, que le :71A: porte l’un des trois seuls codes de frais qui existent (OUR, SHA, BEN), qu’un BIC donné en option A est bien formé, que l’UETR du tag 121 est un véritable UUID de version 4, et — parce que c’est de l’arithmétique pure et qu’un échec est donc certain — qu’un compte bénéficiaire qui ressemble à un IBAN passe le contrôle mod-97. La règle de taux de change énoncée par la documentation de la BCE est appliquée elle aussi : si le :33B: est dans une devise différente du :32A:, alors le :36: doit être présent.
Ce qu’il ne fait pas, il le dit. Les Network Validated Rules de SWIFT (C1 à C18) — la façon dont le :71A: interagit avec le :71F: et le :71G:, le moment où le :33B: devient obligatoire dans l’EEE, ce que le :23B:=SPRI autorise en :56a: et :57a: — sont publiées dans le SWIFT User Handbook, qui n’est pas librement accessible ; elles ne sont pas implémentées, et cet outil ne revendique jamais une conformité réseau qu’il ne peut pas vérifier. Les restrictions propres à TARGET2 ne sont pas appliquées non plus, délibérément : elles rejetteraient des messages parfaitement valides émis sur d’autres rails. Rien n’est envoyé — le fichier est lu dans votre navigateur et n’en sort jamais.
Ce qu’il faut savoir du MT103 en 2026
- La coexistence MT / ISO 20022 sur CBPR+ a pris fin le 22 novembre 2025 : les virements interbancaires transfrontaliers circulent désormais en pacs.008, plus en MT103.
- Le MT103 n’a pas disparu pour autant. Il reste produit dans les schémas domestiques, dans le reporting banque-à-entreprise et dans les échanges de fichiers host-to-host et de trésorerie — et ces fichiers doivent toujours être lus.
- Chaque champ du MT103 a son pendant direct dans le pacs.008 : le :20: devient l’instruction identification, le :32A: la date, la devise et le montant de règlement interbancaire, le :71A: le charge bearer, et le tag 121 devient l’UETR — le seul élément que les deux formats partagent déjà.
- La migration ne perd rien sur le plan structurel, et gagne beaucoup : le pacs.008 porte des parties structurées et une communication structurée là où le MT103 n’offre que quatre lignes de texte libre en :70:.
- Un MT103 contient des numéros de compte, des noms et des adresses. Le décoder localement dans le navigateur évite d’envoyer un ordre de virement à un service tiers.
MT103 vs pacs.008 : champ par champ
| Champ MT103 | Ce qu’il porte | Équivalent pacs.008 (ISO 20022) |
|---|---|---|
| :20: | La référence propre à l’émetteur pour ce virement | InstrId / PmtId |
| :23B: | Le code d’opération bancaire (CRED, SPAY, SPRI, SSTD, CRTS) | Pas d’équivalent direct — exprimé via le service level et le local instrument |
| :32A: | Date de valeur, devise et montant réglé en interbancaire | IntrBkSttlmDt + IntrBkSttlmAmt |
| :33B: | La devise et le montant instruits par le donneur d’ordre | InstdAmt |
| :36: | Le taux de change, quand les deux devises diffèrent | XchgRate |
| :50a: | Le donneur d’ordre (nom et adresse, ou un BIC) | Dbtr + DbtrAcct |
| :52a: | La banque du donneur d’ordre | DbtrAgt |
| :57a: | La banque du bénéficiaire | CdtrAgt |
| :59a: | Le bénéficiaire et son compte | Cdtr + CdtrAcct |
| :70: | Le motif du paiement, en quatre lignes de texte libre au plus | RmtInf — qui peut être structurée |
| :71A: | Qui paie les frais : OUR, SHA ou BEN | ChrgBr : DEBT, SHAR ou CRED |
| {3:{121:}} | L’UETR, la référence de bout en bout de la transaction | UETR — identique, et transporté par les deux formats |
Cette correspondance est le pont concret dont la plupart des équipes ont besoin quand une banque bascule un flux du MT103 vers le pacs.008. La sémantique des champs est issue des TARGET2 User Detailed Functional Specifications de la Banque centrale européenne, Book 1, v15.0 (26 mars 2021), §9.1.2 — la seule spécification publique et gratuite de la structure du MT103.
Questions fréquentes
Qu’est-ce qu’un MT103 ?
Un MT103 est le « Single Customer Credit Transfer » de SWIFT : le message par lequel une banque ordonne un paiement d’un client vers un autre. C’est un fichier texte fait de blocs entre accolades, le paiement lui-même se trouvant au bloc 4 sous forme de champs balisés comme :20: (référence), :32A: (date de valeur, devise et montant), :50a: (donneur d’ordre), :59a: (bénéficiaire) et :71A: (frais).
Le MT103 est-il encore utilisé en 2026 ?
Oui, mais plus partout. La coexistence MT / ISO 20022 sur le rail transfrontalier CBPR+ a pris fin le 22 novembre 2025 : les virements interbancaires transfrontaliers utilisent désormais le pacs.008. Le MT103 reste largement employé dans les schémas domestiques, dans les échanges banque-à-entreprise et dans les intégrations host-to-host — d’où le besoin quotidien de savoir en lire un.
Qu’est-ce qui remplace le MT103 ?
Le pacs.008 (FIToFICustomerCreditTransfer), le message XML ISO 20022. Chaque champ du MT103 s’y projette : le :20: devient l’instruction identification, le :32A: la date, la devise et le montant de règlement interbancaire, le :71A: le charge bearer, et l’UETR du tag 121 est repris tel quel. Le tableau comparatif MT103 → pacs.008 de cette page donne la correspondance complète.
Quels champs sont obligatoires dans un MT103 ?
Six : :20: (référence de l’émetteur), :23B: (code d’opération bancaire), :32A: (date de valeur, devise et montant réglé), :50a: (donneur d’ordre), :59a: (bénéficiaire) et :71A: (détail des frais). Cette visionneuse refuse de lire un message auquel il en manque un, et vous dit lequel.
Que signifient OUR, SHA et BEN dans le :71A: ?
Ils disent qui paie les frais du virement. OUR : le donneur d’ordre les paie tous, le bénéficiaire reçoit donc le montant intégral. BEN : le bénéficiaire les supporte, ils sont déduits du montant reçu. SHA : chaque partie paie les frais de sa propre banque. Ces trois codes constituent toute la liste — tout autre valeur est invalide, et l’outil la rejette.
Qu’est-ce que l’UETR d’un MT103 ?
L’« Unique End-to-end Transaction Reference » : un UUID de version 4 porté par le tag 121 de l’en-tête utilisateur, au bloc 3. Il identifie un paiement de bout en bout, à travers toutes les banques qui le touchent, et c’est le même identifiant dans le monde ISO 20022 — ce qui en fait la clé naturelle lorsqu’un paiement passe du MT103 au pacs.008. Cette visionneuse contrôle qu’il s’agit bien d’un UUID v4 correctement formé, en hexadécimal minuscule.
Cet outil valide-t-il un MT103 contre les règles réseau de SWIFT ?
Non, et il ne fera pas semblant. Les Network Validated Rules (C1 à C18) figurent dans le SWIFT User Handbook, qui n’est pas librement accessible. Cette visionneuse contrôle la structure, les champs obligatoires, le format du :32A:, la liste fermée des codes de frais du :71A:, la forme d’un BIC en option A, l’UETR et la clé de contrôle IBAN — tout ce qui est vérifiable hors ligne à partir de documentation publique. Ce qu’elle ne peut pas contrôler, elle l’affiche à l’écran plutôt que de le cacher derrière un badge vert.
Mon fichier de paiement est-il envoyé quelque part ?
Non. Le MT103 est lu et décodé entièrement dans votre navigateur, en JavaScript. Aucune partie du message — aucun numéro de compte, aucun nom, aucun montant — n’est jamais transmise à un serveur.
Source
La structure de champs utilisée par cette visionneuse est issue de la Banque centrale européenne, TARGET2 User Detailed Functional Specifications (UDFS), Book 1, v15.0 (26 mars 2021), §9.1.2 — un document public et gratuit. Seule la colonne « SWIFT standard » est appliquée ; les restrictions propres à TARGET2 de la colonne « SSP Specifications » sont délibérément ignorées, car elles rejetteraient des messages valides émis sur d’autres rails. TARGET2 UDFS Book 1 v15.0 (PDF, ecb.europa.eu)
Mentions légales
ValidateFin est un outil indépendant, sans affiliation ni lien avec Swift, et qui n’est pas approuvé par Swift. « SWIFT » est une marque de S.W.I.F.T. SC, citée ici à titre nominatif, uniquement pour désigner le format de message lu. Cette visionneuse ne vérifie pas la conformité au réseau SWIFT : les Network Validated Rules publiées dans le SWIFT User Handbook ne sont pas implémentées, et aucun texte du SWIFT MT Message Reference Guide n’est reproduit ici — toutes les descriptions de champs de cette page ont été rédigées de façon indépendante, à partir des TARGET2 UDFS publiquement disponibles de la Banque centrale européenne.