SWIFT et la migration du relevé de compte en XML : des promesses à tenir

La migration du relevé de compte bancaire vers les supports XML fait suite aux nombreux projets de standardisation et d’enrichissement des formats de communication bancaire. Tout d’abord avec la migration ETEBAC (Échange télématique banque-clients - protocole de télétransmission bancaire), la migration SEPA sur les virements et prélèvements (Single Euro Payments Area - espace de paiement en euro unifié), la migration du TIP (titre interbancaire de paiement) puis du télérèglement.

Le passage des relevés de compte en ISO20022(norme définissant le cadre d’utilisation du XML), semble désormais logique : après la migration des ordres de prélèvement et de virement SEPA, il répond au besoin d’enrichir et d’optimiser les flux de reporting, via le millier de balises proposées par le format XML.

Un besoin et des promesses

Encore peu mis en œuvre par le secteur bancaire, la promesse du relevé de compte XML est d’être cohérent avec les moyens de paiement SEPA. Ceci en garantissant l’unicité des pratiques, dans un contexte où les disparités locales sont nombreuses. Actuellement, banques et entreprises doivent adapter leurs systèmes à chaque pays ou tiers avec lequel elles opèrent.

En effet, dans l’attente de l’adhésion définitive au projet XML, deux options coexistent pour les entreprises :

• exploiter le format international MT940, dont le contenu est globalement harmonisé mais moins riche
• exploiter des formats locaux (Le CFONB120 – France, le AEB43 – Espagne, le MLC940 – Allemagne, par exemple) contenant plus d’informations, mais impliquant de maintenir autant de formats que de pays.

Face à ces difficultés dans la réconciliation bancaire, plusieurs membres de la zone Euro ont initié des programmes d’adoption et d’exploitation des formats Camt (Cash Management). Nombre d’entreprises ont adopté le format « camt.054 » pour le suivi de leurs paiements, en revanche, le chantier reste entier pour les relevés de compte au format « camt.053 ».

Une difficulté bien réelle de fédérer les pratiques autours du XML

Les clés de succès sont là, cependant la réussite de ce projet dépendra de l’adhésion de l’ensemble des acteurs (sociétés et banques). Il est à noter que cette migration ne s’appuie sur aucune contrainte règlementaire et dépend du « bon vouloir » des participants à se mobiliser dans ce projet.

Par ailleurs, la question se pose de savoir si la culture de chaque pays participant, va rejoindre les standards ISO220022 ou si les spécificités nationales vont perdurer. Plusieurs membres de la communauté SWIFT s’inquiètent de la mise en place du camt.053, dont les formats diffèrent selon les pays.

Par exemple, l’une des données majeures d’un relevé de compte, le « type d’écriture » (prêt, prélèvement, agios,…), appelée code opération bancaire en France, devrait disparaître, remplacée par le Bank Transaction Code. En l’occurrence, l’alignement de tous les acteurs sur ces nouvelles exigences n’est pas encore assuré.

Les chantiers actuels de développement du camt.053 sont menés en parallèle par les différentes communautés bancaires locales, et le CGI (Common Global Implementation Initiative). L’organisme ISO gérant la normalisation permet une diversité de 1425 codes pour l’identification d’une transaction via le BTC (Bank Transaction Code). Un travail d’harmonisation s’avère nécessaire, afin de limiter les spécificités locales, aussi variables que les interprétations possibles de la définition du code.

Au niveau national, le CFONB (Comité Français d’Organisation et de Normalisation Bancaires) propose plusieurs publications, ayant vocation à harmoniser les pratiques, en proposant notamment des tables de correspondances avec les anciens formats (CFONB120). Ce sera alors à la communauté internationale de trancher en adhérant à la restitution des standards proposés, pour enfin donner vie aux relevés de comptes XML.