ISO 20022 Adresses structurées : le calendrier évolue, l’enjeu de qualité des données reste entier
Synthèse des échanges, points de vigilance et compléments issus des publications officielles.
Publié le 29 septembre 2026 par Mehdi Yassine
La transition vers ISO 20022 a profondément transformé les paiements internationaux. Après la migration des messages de paiement vers ISO 20022, un nouveau chantier se prépare : la structuration des adresses des différentes parties intervenant dans les paiements.
Initialement prévue le 15 novembre 2026 dans le cadre de la Standards Release 2026, la suppression des adresses entièrement non structurées va constituer une étape majeure de cette transformation.
Fin août 2026, Swift a toutefois annoncé le report de cette échéance, à la demande de plusieurs acteurs de l’écosystème des paiements. Le niveau de préparation restant hétérogène selon les institutions, les régions et les infrastructures de marché, un délai supplémentaire a été accordé.
La nouvelle date d’application n’est, à ce jour, pas encore définitivement arrêtée.
Ce report ne remet cependant pas en cause la trajectoire engagée : les adresses entièrement non structurées sont amenées à disparaître au profit d’adresses structurées ou hybrides.
Pour les entreprises, l’enjeu dépasse largement une simple évolution du format XML. Il touche directement à la qualité des données de paiement, aux référentiels tiers et aux échanges entre ERP, TMS et banques.
Pourquoi les adresses deviennent-elles un enjeu pour les paiements ?
Pendant longtemps, les adresses ont principalement été considérées comme des informations descriptives.
Prenons l’exemple suivant :
82 Rue Villeneuve
92110 Clichy
France
Pour un utilisateur, cette adresse est parfaitement compréhensible.
Pour un système qui doit automatiquement analyser les données d’un paiement, la situation est différente.
Lorsque l’intégralité de l’adresse est contenue dans une ou plusieurs lignes de texte libre, les différents composants (rue, numéro, ville, code postal ou pays) ne sont pas nécessairement identifiables de manière fiable.
Or ces données sont utilisées tout au long de la chaîne de paiement, notamment pour les contrôles réglementaires, le filtrage des sanctions et l’automatisation des traitements.
La logique poursuivie avec ISO 20022 est donc simple : rendre la donnée plus explicite et directement exploitable par les systèmes.
C’est précisément l’objectif de la structuration des adresses.
Adresse structurée, hybride ou non structurée : quelle différence ?
Trois modèles d’adresse coexistent actuellement :
1. L’adresse entièrement structurée
Chaque composant de l’adresse est renseigné dans un champ dédié.
Par exemple :
-
Street Name : Rue Villeneuve
-
Building Number : 82
-
Post Code : 92110
-
Town Name : Clichy
-
Country : FR
Cette approche permet aux systèmes d’identifier immédiatement la nature de chaque information.
Elle représente le modèle cible privilégié lorsque les données nécessaires sont disponibles.
2. L’adresse hybride
Le format hybride permet de combiner des éléments structurés avec des lignes d’adresse conservées en texte libre.
Deux informations doivent notamment être renseignées dans leurs champs structurés :
-
Town Name
-
Country
Les autres informations peuvent, selon les règles applicables, être renseignées dans les champs structurés disponibles ou conservées dans des Address Lines (AdrLine).
Ce modèle facilite la transition pour les organisations dont les référentiels ne permettent pas encore de décomposer entièrement toutes les adresses.
3. L’adresse entièrement non structurée
Dans ce modèle, l’adresse est principalement transmise sous forme de texte libre.
Par exemple :
AdrLine : 82 Rue Villeneuve
AdrLine : 92110 Clichy, France
C’est ce modèle que la communauté Swift prévoit de supprimer à terme pour les messages concernés.
Il est important de distinguer deux notions : la présence d’une adresse et la manière dont cette adresse est structurée.
Les nouvelles exigences ne signifient pas qu’une adresse devient automatiquement obligatoire dans tous les paiements. En revanche, lorsqu’une adresse est requise et transmise dans un flux soumis à ces règles, elle devra respecter le format attendu.
Quels paiements sont concernés ?
La structuration des adresses doit avant tout être analysée dans le contexte des paiements cross-border utilisant les règles CBPR+.
Les exigences peuvent également concerner certaines infrastructures de paiement domestiques ayant adopté ISO 20022 et les recommandations (High Value Payments Systems Plus) HVPS+, selon leurs propres règles et leur propre calendrier.
Il faut donc éviter de considérer l’Address Compliance comme une règle uniforme applicable de la même manière à tous les paiements ISO 20022.
Pour une entreprise, l’analyse doit être réalisée flux par flux :
-
Quels paiements sont envoyés ?
-
Par quels canaux ?
-
Dans quels formats ?
-
Quelles parties comportent actuellement une adresse ?
-
Quelles règles sont appliquées par les banques et infrastructures concernées ?
-
Les données nécessaires existent-elles dans l’ERP ou le TMS ?
Cette cartographie constitue l’une des premières étapes du projet.
Le véritable enjeu : la qualité des données
Derrière cette évolution se cache un sujet beaucoup plus large : la qualité des référentiels.
Un ERP ou un TMS comme Kyriba ou Agicap, peut parfaitement être capable de produire un message ISO 20022 conforme sur le plan technique. Il ne pourra cependant pas créer une information qui n’existe pas dans les données sources.
Prenons deux bénéficiaires.
Bénéficiaire A
-
Rue renseignée
-
Numéro renseigné
-
Ville renseignée
-
Code postal renseigné
-
Pays renseigné
La génération d’une adresse structurée est relativement simple.
Bénéficiaire B
-
Adresse enregistrée sur une seule ligne de texte libre
-
Ville non identifiée dans un champ spécifique
-
Pays absent ou intégré à la ligne d’adresse
La situation devient beaucoup plus complexe.
Le système devra soit être capable de restructurer correctement l’information, soit récupérer les données manquantes à la source.
C’est pourquoi Town Name et Country occupent une place particulièrement importante dans la transition : ce sont les deux éléments structurés minimaux attendus dans le modèle hybride.
Le chantier ne commence donc pas au moment de générer le fichier XML.
Il commence dans le référentiel fournisseur, client ou bénéficiaire.
Pourquoi cette évolution ?
La richesse d’ISO 20022 ne réside pas uniquement dans l’utilisation du XML.
Son intérêt vient surtout de la possibilité de transporter des données plus précises et mieux structurées tout au long de la chaîne de paiement.
Une adresse structurée permet notamment de faciliter :
-
l’exploitation automatique des données ;
-
les contrôles réglementaires et le filtrage des sanctions ;
-
la qualité et la précision des informations transmises ;
-
le traitement automatique des paiements ;
-
la réduction des interventions et réparations manuelles ;
-
l’interopérabilité entre les différents acteurs de la chaîne de paiement.
L’objectif est donc de passer progressivement d’une donnée principalement lisible par un humain à une donnée également directement interprétable par les systèmes.
Pourquoi l'Address Compliance n'est-elle pas uniquement un projet Trésorerie ?
Un paiement est l’aboutissement d’une chaîne de données qui commence souvent bien avant le TMS.
Une adresse bénéficiaire peut par exemple être :
-
créée dans un référentiel fournisseur ;
-
stockée dans l’ERP ;
-
transmise à une interface ou à un TMS ;
-
transformée en données de paiement ;
-
intégrée dans un message ISO 20022 ;
-
transmise à la banque ;
-
puis utilisée tout au long de la chaîne de paiement.
Une information manquante dès la première étape ne pourra pas toujours être corrigée automatiquement à la cinquième.
Le sujet concerne donc plusieurs équipes :
- Master Data : pour la qualité et la gouvernance des référentiels
- ERP : pour la capacité à stocker et restituer les différents composants de l’adresse
- Trésorerie : pour identifier les flux concernés et les exigences opérationnelles
- IT : pour les interfaces, mappings et transformations de données
- TMS et éditeurs : pour la génération des formats attendus
- Banques : pour leurs spécifications, leurs contrôles et leurs dispositifs de test
L’Address Compliance doit donc être considéré comme un projet de données transverse, et non comme une simple modification de format bancaire.
Le calendrier est reporté : faut-il attendre ?
C’est probablement la question la plus importante depuis l’annonce de Swift.
Et le report ne signifie pas que les travaux déjà engagés doivent être interrompus.
Au contraire, ce délai supplémentaire offre aux entreprises l’opportunité de préparer la transition plus progressivement.
Swift encourage d’ailleurs les acteurs ayant déjà engagé leurs travaux à poursuivre leurs efforts : les adresses structurées et hybrides peuvent déjà circuler sur le réseau.
Les entreprises peuvent donc profiter de cette période pour :
-
cartographier les flux concernés et identifier les exigences applicables ;
-
auditer les référentiels fournisseurs, clients et bénéficiaires ;
-
identifier les adresses enregistrées uniquement en texte libre ;
-
contrôler en priorité la disponibilité de la ville et du pays ;
-
vérifier la manière dont les informations circulent entre le référentiel, l’ERP, le TMS et la banque ;
-
analyser les mappings et transformations actuellement appliqués ;
-
échanger avec les banques sur leurs propres exigences et calendriers ;
-
préparer des jeux de données et scénarios de test ;
-
mettre en place progressivement des règles de qualité pour éviter la création de nouvelles adresses incomplètes.
Le report peut ainsi être utilisé non comme une période d’attente, mais comme une période de préparation !
Une opportunité pour améliorer durablement la qualité des paiements
L’Address Compliance peut, à première vue, sembler être une évolution très technique : quelques nouveaux champs dans un message ISO 20022, des règles de validation supplémentaires et des adaptations dans les systèmes.
En réalité, le sujet est beaucoup plus structurant.
Il pose une question simple :
Les données utilisées pour générer nos paiements sont-elles suffisamment fiables, précises et structurées ?
La transition vers des adresses structurées ou hybrides oblige les entreprises à regarder au-delà du fichier bancaire et à s’intéresser à l’ensemble du cycle de vie de la donnée.
Le report annoncé par Swift offre davantage de temps pour mener ce travail. Il ne change toutefois pas la direction prise par l’industrie : des données de paiement plus riches, plus structurées et plus facilement exploitables.
Pour les entreprises, l’enjeu n’est donc plus seulement de savoir quand la nouvelle échéance entrera en vigueur. Il est de déterminer si leurs référentiels, leurs systèmes et leurs processus seront prêts lorsqu’elle le sera.
Car un paiement fiable commence avant tout par une donnée fiable.
92110 Clichy
France
- Les éléments ne sont pas séparés
- Plus difficile à analyser automatiquement
- Ne sera plus accepté, à terme, pour les paiements concernés
- Town Name (ville) obligatoire
- Country (pays) obligatoire
- Les autres informations peuvent être dans les lignes d'adresse (AdrLine)
- Chaque composant de l'adresse est séparé
- Facilite le filtrage réglementaire et le traitement automatique
- Modèle cible privilégié lorsque les données sont disponibles
Sources et ressources
-
Swift — Structured address deadline extended
Consulter la publication Swift -
Swift — Removal of unstructured address data
Consulter le guide Swift -
PMPG — Industry guidance on the Hybrid Postal Address
Consulter le guide PMPG -
HVPS+ — Terms of Reference
Consulter la documentation HVPS+
Le sommaire
- Pourquoi les adresses deviennent-elles un enjeu pour les paiements ?
- Adresse structurée, hybride ou non structurée : quelle différence ?
- Quels paiements sont concernés ?
- Le véritable enjeu : la qualité des données
- Pourquoi cette évolution ?
- Pourquoi l’Address Compliance n’est-elle pas uniquement un projet Trésorerie ?
- Le calendrier est reporté : faut-il attendre ?
- Une opportunité pour améliorer durablement la qualité des paiements
Flux concernés, référentiels, mappings ERP et TMS : identifiez ce qui doit être corrigé avant la nouvelle échéance.
Vos référentiels sont-ils prêts pour les adresses structurées ?
Nos experts vous aident à cartographier vos flux et à évaluer la qualité de vos données de paiement.
Vous recevrez nos articles sur l'univers ERP ou encore nos invitations aux événements !
(Une newsletter par mois environ)