Norme ISO 20022 : fonctionnement, obligations, format... Réponses aux questions des trésoriers

A partir de novembre 2026, les messages de paiement initiés par les entreprises doivent devenir plus structurés, notamment en ce qui concerne l’adresse postale du bénéficiaire d’un virement. C’est l’un des principaux changements apportés par la migration ISO 20022.

Alors que le détail des adresses était principalement transmis dans des balises génériques notées <AdrLine>, il doit désormais être clairement séquencé et renseigné dans des balises dédiées telles que <StrtNm> pour la rue (street name), <TwnNm> pour la ville (town name), <PstCd> pour le code postal (postal code), <Ctry> pour le pays (country) ou encore d’autres plus spécifiques comme <BldgNm>, <Flr>, <PstBx>, <Room>, <TwnLctnNm> et <DstrctNm>.

Cette évolution répond aux obligations des banques, qui ne pourront plus traiter les messages contenant des adresses non structurées dans l’espace interbancaire à partir de novembre 2026 afin d’améliorer l’efficacité des contrôles de lutte contre le blanchiment d’argent et le financement du terrorisme (LCB-FT). Bien qu’il ne s’agisse pas d’une obligation règlementaire pour les entreprises, il est très vraisemblable qu’elles y soient contraintes par leurs partenaires bancaires en vue de faciliter les échanges. Elles sont donc invitées à se mettre en conformité en amont afin d’assurer la continuité des paiements vers leurs fournisseurs, leurs clients ou leurs salariés.

Les paiements concernés sont les paiements transfrontaliers à l’exception des paiements réalisés au sein de l’espace économique européen (EEE) en devises de l’EEE. L’obligation ne concerne donc ni les virements SEPA, ni les virements de gros montant en euro entre pays de l’EEE.

Format structuré et format hybride

Le nouveau standard retenu pour initier ses virements est le format pain.001.001.09, issu de la version 2019 de la norme ISO 20022. Il succède au format MT101 de la messagerie FIN. Bien que l’utilisation du pain.001.001.09 soit optionnelle par rapport aux versions 02 et 03 du pain.001, elle reste toutefois recommandée car elle introduit de nouvelles balises pour renseigner l’adresse d’un bénéficiaire.

Ce format introduit d’autres fonctionnalités : de nouvelles balises pour identifier les contacts, la possibilité d’indiquer l’heure d’exécution d’un virement instantané ou encore l’ajout d’un champ dédié pour fournir la référence UETR comme identifiant du paiement dans le cadre d’un virement international émis via SWIFT GPI.

Il sera également possible d’utiliser le LEI (legal entity identifier) comme identifiant possible des parties sans avoir à passer par une balise détournée. Bien qu’il n’existe pas encore de consensus en la matière, l’AFTE rappelle sa préférence pour l’utilisation du LEI comme identifiant du fait de son internationalisation.

Pour les entreprises dont le système de gestion intégré (ERP en anglais) ne dispose pas de la granularité nécessaire pour renseigner toutes les informations demandées, un entre-deux a été pensé : le format hybride. Disponible depuis novembre 2025, il requiert seulement les éléments indispensables aux règlements internationaux de façon structurées : la ville et le pays. Les autres informations disponibles (nom et numéro de rue, code postal, Etat, étage…) seront placées dans des balises non structurées <AdrLine>, réduisant la complexité liée à la structuration des messages. A noter, seulement deux balises <AdrLine> sont cependant autorisées.

Les entreprises pourront donc se contenter de transmettre des fichiers au format hybride dans un premier temps pour garantir la bonne continuité du traitement de leurs opérations, avant d’essayer de transmettre des fichiers structurés par la suite.

Recommandations

Pour assurer la continuité des paiements et bien orchestrer sa migration vers la norme ISO 20022, l’AFTE recommande ainsi de vérifier la complétude des données disponibles dans son ERP. Si toutes les informations obligatoires (rue, code postal, pays, Etat) n’y sont pas, il faut les collecter. Une fois collectées, il faut s’assurer de pouvoir les communiquer au sein de balises isolées dans les messages de paiement envoyés à sa banque.

Il s’agit ensuite de généraliser l’utilisation des messages ISO 20022 à l’ensemble de ses opérations : virements SEPA, virements internationaux, virements de trésorerie etc… Cette mise à jour offre l’opportunité de revoir la façon dont on transmet de l’information à ses contreparties en permettant à chacun de passer en revue la façon dont sont constitués les fichiers de paiement.

Les messages de paiement ne sont d’ailleurs pas les seuls à évoluer avec la migration ISO 20022 : les messages de reporting ont également leur équivalent. Les messages MT 940 (relevé de compte en fin de journée) et MT 942 (relevé intra-journalier) peuvent être respectivement remplacés par les messages camt.053 et camt.052. 

« L’adoption des formats camt.05x n’est pas une obligation pour les entreprises. Elles sont toutefois invitées à l’étudier, étant donné qu’ils permettent d’incorporer des références plus complètes, des identifiants et des références mieux véhiculés et offrent donc l’opportunité de retravailler ses règles de rapprochement en vue d’une meilleure automatisation. », conclut Brice Allignon, partner à Utsit.

Questions adressées à Brice Allignon

Peut-on envoyer un virement SEPA sans adresse du bénéficiaire ?

Oui.

Quels sont les virements concernés : uniquement ceux en devises et/ou en EUR hors UEE ou tout type de virement ? Qu’en est-il des banques en dehors de l’UE : sont-elles concernées ?

Tous les virements internationaux et certains virements domestiques, y compris en dehors de l’UE. Le caractère obligatoire de l’adresse dépend de chaque pays et du type d’opération (urgent ou non). Il est donc nécessaire d’analyser l’ensemble des vos flux pour en vérifier leur conformité.

Concernant le SDD, l’adresse du débiteur est-elle nécessaire ?

L’adresse du client prélevé est obligatoire uniquement si l’un des deux établissements (PSP) se situe dans un pays en dehors de l’espace économique européen. Par exemple : si j’émets un prélèvement depuis ma banque en France pour prélever un client en France, l’adresse n’est pas obligatoire (que ce soit pour le client prélevé ou le débiteur). Dans le cas où ce prélèvement est à destination d’un client dont le PSP est situé à Monaco (donc en dehors de l’EEE), mon fichier doit nécessairement inclure l’adresse, hybride ou structurée, du client.

La V9 de la norme ISO 20022 est-elle disponible auprès de toutes les banques ?

La V9 n’est pas encore disponible dans toutes les banques. Dans le cas où elle est disponible, il faut vérifier pour quelles opérations. Les banques ont d’abord assuré la migration pour leurs propres besoins, en novembre 2025, et engagent désormais la migration pour leurs clients entreprises. Elles n’avancent pas toutes au même rythme mais la V9 sera bientôt disponible partout.

S’il est recommandé de l’utiliser pour s’aligner avec la version des formats interbancaires, son utilisation n’est pas un pré-requis indispensable à la mise en conformité de vos instructions de paiement : les formats V2 ou V3 sont compatibles avec les exigences d’adresse. Attention néanmoins à bien identifier et anticiper l’obsolescence de l’une ou l’autre de ces versions avec tout ou partie de vos partenaires bancaires.

Quelles sont les adresses concernées : celles des bénéficiaires mais aussi celles des donneurs d’ordre ?

Oui, ainsi que les donneur d’ordre initial (ultimate debtor) et bénéficiaire final (ultimate creditor) lorsqu’ils sont utilisés.

Quels sont les champs obligatoires dans les adresses hybrides ?

Les balises « Pays » et « Ville ». Tout le reste des informations peut être transmis dans le champ <AdrLine> jusqu’à deux occurrences.

Ma banque dit « Les éléments de données « Pays » <Ctry> et « Nom de la ville » <TwnNm> sont obligatoires ainsi que le « Code postal » <PstCd>, si disponible. » Je sais que ma basede données de code postal n’est pas complète. La recommandation de mettre le Code Postal est-elle forte ? 

L’objectif est de transmettre un maximum de données en utilisant le format d’adresse structuré. Si cela n’est pas possible, il reste la possibilité d’utiliser le format hybride où les balises « Pays » et « Ville » constituent le strict minimum à transmettre pour permettre l’exécution de ses opérations. S’il s’agit de bénéficiaires de virements SEPA, la présence de l’adresse demeure optionnelle (mais si transmise, elle doit nécessairement l’être de façon hybride ou structurée).

Quelles que soient ses possibilités et ses contraintes, il est important de les vérifier avec ses différents partenaires bancaires au cas où l’un d’entre eux exige des informations complémentaires.

NB : Le code postal n’existe pas dans tous les pays du Monde (UAE par exemple) dans ce cas la balise ne doit pas être présente, y compris pour des adresses au format structuré. 
Pour le champ « Ville », pour les villes dont les noms se traduisent (ex : Varsovie (FR) / Warszawa (PL)...) : faut-il préférer l'anglais ou cela n'a-t-il aucune importance ?

S’il s’agit de virements domestiques : privilégier la langue locale « Warszawa » et s'il s’agit de virements internationaux : privilégier l’anglais «  Warsaw ».

Le format hybride sera-t-il amené à disparaître à l’avenir ?

Je n’ai évidemment pas de boule de cristal. Les investissements réalisés par les banques pour proposer ce format démontrent néanmoins qu’il s’agit d’une solution pérenne à moyen terme. Le PMPG (Payment Market Practice Group) a également rappelé dans sa Newsletter de Mai 2026 : « Hybrid postal address is here to stay. Unstructured is going away. Hybrid address remains an important and pragmatic model, in parallel with fully structured postal address, where available and feasible ».

Il complete : « To be clear: there is no intention to remove hybrid address. The industry objective is to increase data usability, interoperability and quality by using the most appropriate model for each use case. »

Concernant l’adresse du donneur d’ordre, faut-il passer au format hybride sur un paiement transfrontalier alors qu’il semble que les banques vont compléter l’adresse du donneur d’ordre ?

Que l’adresse soit optionnelle ou obligatoire, elle doit être renseignée de façon hybride ou structurée (y compris si elle est ensuite écrasée par les informations de la banque teneuse de compte).

Certaines banques prétendent qu’elles vont transformer les messages MT101 en XML pour nous, est-ce vrai ? Plus généralement, les fichiers seront-ils rejetés en cas de balises manquantes ?

Oui, à condition d’utiliser l’option 59F du MT101, qui permet de distinguer de façon explicite la raison sociale, la rue, la ville, le code postal et le pays du bénéficiaire. Seulement à cette condition la banque sera capable de faire cette conversion.

Les conversions effectuées depuis novembre 2025 (et avant pour certains) utilisent des adresses non structurées et ne seront plus possibles en novembre 2026 sans utilisation de l’option 59F.

Serait-il possible d'avoir un commentaire sur les capacités des éditeurs pour créer les XML avec des adresses structurées ?

Les versions à jour des principaux éditeurs de TMS/plateforme de paiement permettent de gérer correctement ces adresses à condition d’être correctement saisies/transmises par les ERPs. N’hésitez pas à prendre contact avec eux pour le vérifier. Les capacités des systèmes en amont (ERP, MDM…) doivent également être vérifiés.

L'utilisation du MT101 avec le champ 59F est aussi valable pour les virements au sein de l'EEE ?

Oui, sous réserve de faisabilité avec votre banque.

Bonjour est ce qu'il y a une date de fin de la version XML v2 ?

Non. Le retrait de cette version dépend de chaque établissement bancaire. On peut néanmoins observer que cette version ne figure plus sur le site du CFONB et on peut légitimement anticiper que les banques ne maintiendront pas trois versions simultanées d’un même format. Il est donc prudent de profiter de ces travaux pour anticiper ce changement plutôt que de le subir prochainement.

Il y a 3 statuts dans le fichier PMPG : Mandatory, Expected and Optional. Que signifie Expected selon vous ?

Expected renvoie généralement à une attente locale. C’est une façon un peu différente de dire qu’il s’agit d’une obligation.

Un contrôle cohérence du couple code postal ville est-il mis en place par ma banque ?

Les établissements en charge de l’exécution se contentent généralement de s’assurer de la présence des balises et que la valeur ne pose pas un problème de conformité. Le contrôle de cohérence ou de l’exactitude de la valeur incombe pourrait être effectué au niveau des banques bénéficiaires.

Quid des pays comme la Pologne, qui, selon ma banque, demande plus d’éléments ?

Certains pays profitent de ces changements pour renforcer leurs exigences et leurs contrôles. Il devient donc nécessaire d’identifier l’ensemble de ses opérations de paiement pour identifier et anticiper les changements à venir.

Dans le cas d’un virement domestique urgent en PLN, l’adresse est obligatoire. Cela est le cas dans d’autres pays comme la Suisse.

Faut-il renseigner systématiquement le code BIC et les champs adresses / pays / ville / code postal pour les adresses bancaires ou seulement le code BIC ?

La règle générale concernant l’identification des banques est la suivante : 

-    Si code BIC : Nom et adresse optionnels
-    Si autre identifiant (code ABA, CNAPS…) : ajouter le nom et l’adresse de la banque (ville + pays a minima)

Est-ce que l'enrichissement des adresses bancaires avec l'aide d'API permettant de confirmer l'adresse de la banque sur la base du BIC fourni est une bonne pratique ? Car souvent l'adresses bancaire du bénéficiaire n'est pas fournis ou complète.

Oui, à condition d’utiliser des bases de données fiables et à jour telles que SwiftRef. Néanmoins, transmettre l’adresse de la banque du bénéficiaire reste optionnel tant que celle-ci est identifiée par son code BIC.

Cet article est tiré d’une réunion organisée en mai 2026 par la commission « Cash management international ». Pour ne rien manquer des sujets de trésorerie, inscrivez-vous aux prochains évènements des commissions et délégations de l'AFTE.