
Conformité des adresses ISO 20022 : ce que les banques préparent réellement pour novembre 2026

Par
Guillaume Metman
VP Product Management - Payments & Bank ConnectivityFrédérique Dupas
Senior Product ManagerShare
Dans nos deux précédents articles sur la gestion des adresses ISO 20022, nous avons abordé ce qui change avec l'échéance de novembre 2026 et ce qu'une grande entreprise mondiale a appris de sa migration ISO 20022. Le constat était clair : les lacunes dans les données sont réelles, le calendrier est serré et la complexité organisationnelle est systématiquement sous-estimée.
Mais il manquait une voix à cette conversation : celle des banques.
Que prévoient-elles concrètement lorsqu'un paiement arrive avec une adresse non structurée ou incomplète ? Le rejetteront-elles, le corrigeront-elles ou le laisseront-elles passer ? Comment gèrent-elles les formats legacy tels que MT101 et AFB320 ? Et les règles sont-elles identiques partout, ou varient-elles selon la banque et le corridor de paiement ?
Pour le savoir, nous avons interrogé un panel de banques* avec lesquelles nous travaillons en étroite collaboration. Les réponses reçues confirment la direction générale, mais révèlent des divergences opérationnelles significatives que chaque équipe trésorerie doit comprendre avant novembre 2026.
Le constat clé : vos données, votre responsabilité
Commençons par l'enseignement le plus important.
Les banques s'accordent largement sur le fait que les paiements contenant des adresses invalides seront rejetés. Le principe général est le suivant : si une adresse figure dans un message de paiement, elle doit être valide. L'inclusion d'une adresse qui ne répond pas aux nouvelles exigences structurelles constitue, dans la formulation de la plupart des banques, un motif de blocage.
Cela est important car une idée reçue, répandue parmi les équipes trésorerie, est que les banques jouent le rôle de filet de sécurité : elles détecteraient et corrigeraient les données erronées avant que cela ne pose problème. Dans certains cas précis, cette hypothèse a quelque fondement. Mais en tant que principe opérationnel général, elle est dangereuse.
Le diable est dans les détails, et les détails varient considérablement.
Le niveau de non-conformité reste préoccupant
Avant d'examiner comment les banques réagiront aux adresses non conformes, il convient de dresser un état des lieux.
Deux des banques interrogées indiquent qu'environ 60 % des adresses qu'elles reçoivent actuellement sont invalides ou non conformes. Une autre s'appuie sur des données de marché montrant que près de la moitié des adresses ISO 20022 observées sur le réseau SWIFT restent non structurées : environ 46 % pour les adresses débiteurs et 48 % pour les adresses créanciers dans certains marchés au printemps 2026. Ce constat est cohérent avec nos propres données, qui montrent que 79 % des transactions ISO 20022 XML que nous traitons contiennent au moins une adresse invalide.
Les banques en sont conscientes. Elles communiquent. Mais la prise de conscience ne s'est pas encore traduite par une mise en conformité à la hauteur de ce que l'échéance exige. Une banque a soulevé un point qui mérite d'être souligné : toutes s'inquiètent du faible niveau de retour de la part de leurs clients. La plupart des équipes trésorerie d'entreprise n'ont pas encore confirmé leur état de préparation, et beaucoup n'ont pas répondu aux sollicitations reçues.
Si votre banque vous a communiqué des informations sur l'échéance de novembre 2026 et que vous n'avez pas encore agi, vous faites partie de la majorité. Ce n'est pas rassurant.
Les banques communiquent, mais pas de manière uniforme
Toutes les banques interrogées confirment avoir commencé à informer leurs clients des nouvelles exigences en matière d'adresses. Les canaux utilisés sont globalement similaires : lettres d'information, newsletters, pages web dédiées, guides pratiques, webinaires et communications ciblées auprès des clients clés.
Mais l'intensité varie. Certaines banques adoptent une approche généraliste, mettant des documents à la disposition de l'ensemble de leurs clients sans engagement différencié. D'autres prévoient des actions plus ciblées pour les clients à fort volume ou à enjeu stratégique. Plusieurs renforcent leur communication au second semestre 2026, avec des rappels et des prises de contact directes à l'approche de l'échéance.
Ces communications génériques sont un signal, non un plan d'action. Il est possible que vous ne receviez pas de votre banque des conseils suffisamment précis pour agir. Il vous appartient d'engager directement la conversation sur ce que votre banque acceptera ou non dans vos corridors et formats de paiement spécifiques.
Sur le rejet des paiements : le principe est partagé, le périmètre ne l'est pas
Les banques s'accordent sur le fait que les adresses invalides entraîneront des rejets de paiement. Là où elles divergent, c'est sur la question de quelles adresses, pour quelles parties et dans quelles circonstances.
Certaines banques adoptent une approche relativement ciblée. Le rejet s'appliquerait principalement aux adresses du créancier, du créancier ultime et du débiteur ultime. Pour le débiteur, généralement client de la banque, elles peuvent substituer des données d'adresse conformes issues de leur référentiel client interne.
D'autres banques adoptent une position plus large : toute adresse présente dans un message de paiement, quelle que soit la partie concernée, doit être conforme. Il n'existe pas de mécanisme de substitution pour les données de tiers qu'elles ne détiennent pas.
Cette distinction est d'une importance capitale en pratique. Si votre adresse débiteur est non conforme mais que votre banque dispose de vos coordonnées et peut les substituer, vous éviterez peut-être le rejet sur cet élément. En revanche, si l'adresse de votre créancier est incomplète, faute du nom de la ville, aucune banque ne pourra corriger cela à votre place. Elles ne disposent pas des données de vos bénéficiaires.
La règle la plus sûre est de considérer chaque adresse dans chaque message de paiement comme relevant de votre responsabilité, et d'y veiller avant que le paiement ne quitte vos systèmes.
Sur l'adresse d'agent contenant uniquement le pays : un risque précis et sous-estimé
Une des questions de notre enquête a mis en évidence une divergence à laquelle peu d'équipes trésorerie ont réfléchi.
Considérons un message de paiement dans lequel un agent, c'est-à-dire une banque intermédiaire, dispose d'une adresse postale ne contenant que le tag Pays, sans nom de ville. Il s'agit d'un cas fréquent dans les données legacy.
Trois des banques interrogées considèrent cela comme un motif de rejet. Selon leur interprétation, si une adresse est fournie et qu'elle ne satisfait pas aux exigences structurelles, notamment la présence du nom de ville, elle ne passe pas la validation, que l'adresse soit obligatoire ou non.
D'autres banques adoptent une lecture plus contextuelle. Si l'agent est identifié par un BIC, une adresse contenant uniquement le pays peut ne pas être bloquante. En revanche, si l'agent est identifié par un code de routage ou un code de compensation plutôt que par un BIC, alors le nom et l'adresse, incluant au minimum la ville et le pays, deviennent obligatoires, et une adresse limitée au seul pays ne suffirait pas.
Il s'agit d'une distinction subtile mais importante. Elle signifie que les mêmes données, dans le même champ, pourraient être acceptées par une banque et rejetées par une autre selon la manière dont l'agent est identifié. Si vos modèles de paiement utilisent des adresses d'agent sans BIC, ce point doit figurer explicitement sur votre liste de vérification.
Sur les formats legacy : des signaux contradictoires quant à leur pérennité
Pour les équipes trésorerie qui opèrent encore sur les formats MT101 ou AFB/CFONB 320, la question de ce qui se passera après novembre 2026 est critique. Les réponses des banques sur ce sujet sont les plus divergentes de l'enquête.
Sur le Swift MT101, la tendance générale est prudemment favorable au maintien de l'acceptation, sous réserve que les adresses fournies soient structurées de manière à permettre l'extraction sans ambiguïté des éléments requis, à savoir la ville et le pays. Plusieurs banques précisent que l'adresse doit être fournie en format F (la variante avec balises structurées), plutôt qu'en champs texte libres de l'ancien format.
Sur l'AFB/CFONB 320 en France, le tableau est moins encourageant. Certaines banques prévoient de continuer à accepter le format si les adresses sont pré-formatées selon les règles attendues. D'autres orientent activement leurs clients vers une migration XML avant novembre, notant que les versions qualifiées du format AFB320 permettant une meilleure structuration des adresses n'ont pas été largement déployées en pratique. Cela signifie que le format existe en théorie, mais que la capacité à structurer les adresses n'est pas opérationnellement établie.
Dans notre prochain article, nous examinerons en détail l'impact de cette transition sur les différents formats de paiement.
Tous les contrôles ne se valent pas
Une autre divergence que nous souhaitons souligner concerne les équipes trésorerie qui travaillent sur la conformité technique.
La plupart des banques ont confirmé que leurs contrôles porteront principalement sur la présence des balises requises. Si TownName et Country sont présents dans le message, la validation est satisfaite, indépendamment du fait que les valeurs aient un sens géographique.
Moins de banques prévoient de valider à la fois la présence et le contenu. Le système vérifiera si le nom de la ville correspond à un lieu réel, si le code pays est valide et si la combinaison est cohérente.
Cela peut sembler une distinction technique mineure. En pratique, elle a des implications concrètes. Un paiement contenant les mêmes balises pourrait passer un contrôle de présence mais échouer à un contrôle de contenu. Un paiement où le nom de la ville est rempli avec un code postal pourrait passer chez une banque et être rejeté chez une autre.
Si votre stratégie de migration repose sur le remplissage des champs obligatoires avec des valeurs fictives, sachez que cette approche peut ne pas fonctionner de manière universelle. Les banques qui appliquent une validation de contenu ne se satisferont pas de données techniquement présentes mais dépourvues de sens.
Il n'existe pas de norme universelle
Enfin, et c'est peut-être le point le plus important pour les opérations de trésorerie mondiales : les contrôles que les banques mettent en place ne sont pas toujours appliqués de manière uniforme.
Certaines banques ont confirmé que leurs contrôles seraient génériques, avec des règles cohérentes appliquées à tous les types de paiements et tous les corridors. D'autres ont indiqué que les exigences varieraient selon le pays, la devise, le type de paiement ou la combinaison origine-destination.
Dans notre précédent article consacré aux enseignements tirés de l'interview client, nous avons vu un exemple concret de cette réalité. Dans plusieurs pays asiatiques, TownName dans la norme ISO est mappé à un district, tandis que la ville elle-même est renseignée dans CountrySubDivision, rendant ces deux champs obligatoires dans ces corridors, au-delà du minimum global.
Les banques appliquant des règles spécifiques par corridor auront des variations régionales similaires. Un paiement qui passe les contrôles de votre banque pour un corridor européen peut ne pas passer pour un corridor asiatique ou latino-américain. Tester dans un corridor à faible risque avant un déploiement global n'est pas seulement une bonne pratique : c'est le seul moyen de détecter ces variations avant qu'elles ne provoquent des rejets en production.
Ce que cela signifie pour votre plan d'action
Les conclusions de cette enquête ne modifient pas l'échéance de novembre 2026. Mais elles précisent ce que « conforme » signifie concrètement en pratique.
Le tableau d'ensemble est cohérent avec ce que nous observons au sein de notre base clients : la direction est claire, l'échéance est ferme, et le niveau de préparation de l'ensemble du secteur est encore en deçà de ce qui est nécessaire.
Les banques s'accordent sur le fait que les adresses structurées deviennent une exigence opérationnelle incontournable. Elles communiquent activement. Elles planifient des contrôles de rejet. Mais leurs mises en œuvre diffèrent sur des points qui ont des conséquences directes pour les entreprises.
Voici les points essentiels à retenir :
Ne comptez pas sur votre banque pour compléter vos adresses. Les banques peuvent substituer des données pour leurs propres clients dans certains cas précis, mais elles ne peuvent pas corriger vos données bénéficiaires. Ce sont vos données, c'est votre responsabilité.
Testez avec chaque partenaire bancaire dans chaque corridor concerné. Une conformité générique ne suffit pas si vos banques appliquent des règles spécifiques par corridor ou valident le contenu plutôt que la seule présence des champs.
Contactez directement vos banques au sujet de l'acceptation des formats legacy. Ne supposez pas que MT101 ou AFB320 continueront à fonctionner à l'identique. Obtenez une confirmation écrite sur ce qui est acceptable, à quel niveau de structuration des adresses, et dans quels délais.
Évitez les valeurs fictives. Si votre mise en conformité consiste à renseigner les champs du nom de ville avec « N/A » ou une valeur équivalente, vérifiez auprès de chaque banque si cela passe leurs contrôles. Certaines l'accepteront, d'autres non.
Anticipez un durcissement progressif des contrôles de présence. Les banques qui appliquent aujourd'hui une validation de contenu ont une longueur d'avance. D'autres suivront. Construire des données propres dès maintenant évite d'avoir à tout reprendre plus tard.
La suite
Nous recevons régulièrement des questions sur l'impact de la transition vers les adresses structurées sur les formats de paiement, notamment EDI 820, MT101, AFB320 et les standards locaux tels que DTAZV et CBI. Dans notre prochain article, nous examinerons en détail ce qui change dans chaque format, ce qui reste identique et la manière dont les paramètres de format de Kyriba gèrent la conversion.
Si vous avez des questions sur votre migration spécifique, contactez-nous. Le moment de détecter les lacunes, c'est avant novembre, pas après. Et nous sommes là pour vous accompagner.
*Cet article s'appuie sur les réponses à un questionnaire structuré adressé à un panel de banques en préparation de l'échéance ISO 20022 de novembre 2026. Les positions individuelles des banques sont agrégées et anonymisées.
Written By
Guillaume Metman
VP Product Management - Payments & Bank Connectivity
Guillaume Metman est VP Product Management, Payments & Bank Connectivity chez Kyriba, où il pilote la stratégie produit sur le traitement des paiements, la connectivité bancaire et la prévention de la fraude. Fort de plus de 20 ans d’expérience en développement logiciel, product management et opérations IT, Guillaume apporte une expertise approfondie des paiements, de la transformation Agile et de la livraison de solutions à l’échelle entreprise. Expert reconnu des paiements et leader d’opinion sur des sujets tels que la migration vers ISO 20022 et la transaction banking transfrontalière, il se concentre sur la construction d’une infrastructure de paiement évolutive et sécurisée répondant aux besoins changeants des équipes mondiales de trésorerie et de finance.
Frédérique Dupas
Senior Product Manager
Ressources connexes


