De quoi parle-t -on ?
Il s’agit de l’usage de balises permettant de détailler chaque composant d’une adresse postale afin de normaliser celle-ci dans les flux de paiements ou connexes. Aujourd’hui, les adresses postales sont renseignées de manière hétérogène en fonction de multiples éléments :
-
Le niveau de granularité d’informations prévu par le format d’échange des flux ( ex-formats dits « plats » qui permettent de saisir des adresses complètes en chaines de caractères sans spécificité) que ce soit sur la partie acquisition client-banque ( ex-format CFONB) ou dans les échanges interbancaires (via message FIN par exemple) .
-
La finesse des informations gérées par les SI et DATA des clients CORPORATES et des banques .
-
Le degré de précision de la conception des solutions éditées par les acteurs du marché des outils de gestion bancaires coté corporate ou des plateformes de corebanking ou de payment engine.
De ce fait, même les formats dits structurés (XML) contiennent des adresses qui ne le sont pas, par l’usage de données de type Ligne d’adresses.
Cette situation rend les process de KYC complexes et n’aident pas à fiabiliser les flux, enjeu majeur pour favoriser l’interopérabilité et l’interconnexion des paiements pour les années à venir.
A cette difficulté, s’ajoute celle de l’absence d’universalité de la gestion des adresses au niveau international.
Pour aller plus loin
En France, c’est la norme NF Z 10-011 qui s’applique, détaillée sur 7 lignes :
[Image] Tableau structuration des adresses 1
Ce que prévoit la norme ISO20022, pour les adresses ( ex-paiement de type virement interbancaire en vigueur - xsd pour un pacs.008.001.08) – type 24 :
< xs:complexType name ="PostalAddress24">
< xs:sequence >
< xs:element maxOccurs ="1" minOccurs ="0" name =" AdrTp " type="AddressType3Choice"/>
< xs:element maxOccurs ="1" minOccurs ="0" name ="Dept" type="Max70Text"/>
< xs:element maxOccurs ="1" minOccurs ="0" name =" SubDept " type="Max70Text"/>
< xs:element maxOccurs ="1" minOccurs ="0" name =" StrtNm " type="Max70Text"/>
< xs:element maxOccurs ="1" minOccurs ="0" name =" BldgNb " type="Max16Text"/>
< xs:element maxOccurs ="1" minOccurs ="0" name =" BldgNm " type="Max35Text"/>
< xs:element maxOccurs ="1" minOccurs ="0" name =" Flr " type="Max70Text"/>
< xs:element maxOccurs ="1" minOccurs ="0" name =" PstBx " type="Max16Text"/>
< xs:element maxOccurs ="1" minOccurs ="0" name ="Room" type="Max70Text"/>
< xs:element maxOccurs ="1" minOccurs ="0" name =" PstCd " type="Max16Text"/>
< xs:element maxOccurs ="1" minOccurs ="0" name =" TwnNm " type="Max35Text"/>
< xs:element maxOccurs ="1" minOccurs ="0" name =" TwnLctnNm " type="Max35Text"/>
< xs:element maxOccurs ="1" minOccurs ="0" name =" DstrctNm " type="Max35Text"/>
< xs:element maxOccurs ="1" minOccurs ="0" name =" CtrySubDvsn " type="Max35Text"/>
< xs:element maxOccurs ="1" minOccurs ="0" name =" Ctry " type=" CountryCode "/>
< xs:element maxOccurs ="7" minOccurs ="0" name =" AdrLine " type="Max70Text"/>
xs:sequence >
xs:complexType >
On voit ici que ce format permet l’usage de lignes d’adresses de 70 caractères (jusqu’à 7), on peut donc se trouver face à plusieurs possibilités de contenu (ex d’un flux de virement émis par le client, pain.001) :
[Image] Tableau structuration des adresses 2
Dans une adresse structurée, il n’y a plus de zone « Ligne d’adresse », tout est décomposé en sous éléments.
Enjeux majeurs
Le but est de d’harmoniser les adresses dans différent domaines qui l’utilisent (paiements, factures électroniques, lutte anti-fraude, …) car l’imprécision des adresses non structurées est un frein à la bonne intégration des services mais aussi à l’automatisation des traitements.
C’est aussi un outil important d’amélioration des contrôles de la lutte contre la fraude.
Dates clés
L’obligation de structurer les adresses de manière complète, prévue initialement en novembre 2025 a été assouplie compte-tenu de l’ampleur des travaux à mener pour arriver à la cible.
Les adresses non structurées vont encore être acceptées jusqu’en novembre 2026, remplacées progressivement par des adresses dites hybrides à partir de novembre 2025.
L’obligation de structuration intégrale est, à date, reportée (pas de date de fin prévue à ce jour pour les adresses hybrides).
[Image] Tableau structuration des adresses 2
A partir de novembre 2026, les messages contenant des adresses non structurées seront rejetés (par Swift pour CBPR+). Seuls les messages de restitution camt.052, camt.053 and camt.054 ( statements and notifications) pourront encore en contenir.
Qu’est une adresse hybride ?
C’est une adresse qui contient à la fois des données structurées et non structurées, avec à minima la présence des informations structurées Ville (« Town Name ») et Pays (« Country » ).
Exemple :
< Cdtr >
< PstlAdr >
< PstCd >75001 PstCd >
< TwnNm >PARIS TwnNm >
< Ctry >FRANCE Ctry >
< AdrLine >21, RUE EIFFEL AdrLine >
PstlAdr >
Cdtr >
Impacts pour nos clients
Toute la chaîne des paiements est impactée. Le full structuré implique donc des investissements importants afin de rénover et faire évoluer leur SI pour
-
Transformer leurs bases clients (et dérivées) pour permettre d’avoir le détail nécessaire
-
Analyser l’impact sur l’ensemble des traitements (données intermédiaires, archivage etc ) et mener les travaux nécessaires
-
Mettre en place les bons formats d’acquisition des données de paiement sur tous les canaux et gérer la conduite du changement client (rarement rapide notamment pour les clients Corporate notamment de petite taille)
Concernant l’usage du format hybride, même s’il paraît déjà partiellement compatible avec les systèmes existants (un grand nombre de traitements ont déjà besoin d’avoir ces informations isolées), une analyse est à minima à effectuer pour s’en assurer avant la EndDate du format non structuré ( Nov 2026).
Références Bibliographiques :
CFONB : Guide des Règles de transposition en adresse structurée ISO 20022 – V1.0 – 06/2021
Par SKAIZen Advise [Lien vers la page “SKAIZen Advise ”]