L'industrie bancaire est bavarde. Très bavarde. Oh, il ne s'agit pas d'un bavardage très poétique, il s'agit de messages électroniques leur permettant de traiter leurs opérations, des indications sèches sur les flux de paiements ou la mise en place d'un contrat pour des flux futurs, par exemple. Il s'agit d'un distributeur de billets qui vérifie le statut d'un compte en banque d'un particulier, d'une banque transmettant le contenu de son portefeuille à une autorité de tutelle ou d'un hedge fund envoyant un ordre d'achat d'actions à son représentant bancaire.

Et ce n'est qu'une partie de l'iceberg : chaque institution financière a aussi un immense monologue intérieur pour traiter les opérations effectuées, des paiements à la comptabilité en passant par les risques ou la gestion client. Chaque seconde, c'est ainsi des millions de ces petites conversations sont initiées, traitées, confirmées et clôt dans les serveurs protégés des banques.

Forêt d'interfaces artisanales

Le problème est qu'il n'existe pas une langue commune à tous ces bavardages, même pour un sujet identique, même pour le monologue intérieur. Un foisonnement impressionnant de normes, d'interfaces, de standards définissent le vocabulaire, la syntaxe, les processus, la technique de ces messages.

Il y a d'abord l'immense forêt des interfaces artisanales, souvent en interne, souvent pour un objet unique. Une application comptable doit communiquer avec une application gérant le portail de restitution à l'équipe de compliance ? On bricole rapidement un fichier simple expédié quotidiennement avec les capacités de l'application source, en respectant des contraintes minimum permettant aux informations d'entrer dans l'application destinataire. Il y a souvent une raison rationnelle à ce sur-mesure : couvrir rapidement un besoin, à moindre coût, avec une solution temporaire mais efficace. Ainsi chaque banque a ainsi son petit jardin privé de fichiers naviguant de serveurs en serveurs, d'applications en applications, de services en services avec des particularités uniques décrites par une documentation éparse (et pas toujours à jour..). Le petit jardin privé est souvent une vraie jungle.

Autant d'interfaces à concevoir

Il y a ensuite des normes plus ou moins répandues, choisies parfois au hasard de l'achat d'applications ou des contraintes de clients. MDDL, FIX, FinXML, VRXML, RIXML, XBRL, FpML, IFX, TWIST, SWIFT, RosettaNet, EPC, OAGi, ACORD, CIDX, ces acronymes couvrent chacun des standards définissant la manière de transmettre une information financière. Certains ne couvrent pas les même domaines. D'autres ne coïncident pas exactement mais ont des périmètres communs tandis que certaines sont en concurrence frontale sur un même périmètre. Certains enfin sont obsolètes mais survivent en attendant une hypothétique mise à jour. Pour toutes les applications communicant entre elles, c'est autant d'interfaces à concevoir, il faut mettre en place 6 interfaces pour 3 applications en relation, 12 interfaces pour 4 applications, etc. Et comme les petits ruisseaux forment des grandes rivières, toutes ces normes finissent tôt ou tard par irriguer les mêmes bases de données dans les fonctions de support des grandes banques : services de comptabilité, de trésorerie, de risque, portails clients, analyse big data, etc.

Tout cela a naturellement un coût. La mise en place ou les montées de version de chaque application s'accompagnent inévitablement d'un temps considérable pour conceptualiser ou re-tester chaque flux sortant ou entrant de données ayant leurs caractéristiques propres. Il y a aussi le coût plus discret des multiples erreurs qui ne sont identifiées qu'une fois en production. Un client final est identifié à tort comme un intermédiaire, le cours d'une devise est inversée, un montant est refusé à cause d'un séparateur de milliers, une modification d'un ordre est interprétée comme une annulation ; une part non négligeable des sorties de routes informatiques trouve sa source dans la variété des méthodes pour décrire une même information.

Le problème ne va pas en s'arrangeant

Le problème ne va pas en s'arrangeant, depuis trois décennies, la quantité de messages comme l'automatisation de leur traitement a explosé. Et le sujet d'une lingua-franca bancaire est redevenu brûlant au point de sortir en 2004, un nouveau standard ISO, dédié aux messages financiers, ISO 20022, englobant et perfectionnant son ancêtre ISO 15022 au périmètre plus réduit.

Au Moyen Âge, la lingua franca était un jargon rudimentaire, mélange de français, d'espagnol, d'italien, de catalan, utilisé en particulier par les marins de la Méditerranée pour travailler ensemble sur les docks malgré la variété des langues d'origine. Il est clair que les huit cahiers austères d'une norme ISO n'ont pas le charme et la souplesse d'un sabir spontané parlé dans le port de Venise au XVè siècle, mais ils partagent tout de même un usage : une langue commune qui ne remplace pas toutes les langues existences, mais sert de point de rencontre universel.

S'inspirant du cadre Zachman méthode conçue en 1987 par un ingénieur d'IBM pour définir les systèmes d'information, la norme ISO 20022 est d'abord une dictionnaire géant, elle se concentre sur la méthodologie et la sémantique avant de s'intéresser à la technologie utilisée. Elle définit chaque acteur, chaque processus, chaque concept du métier et ses relations avec les autres. Elle résout ainsi l'une des sources majeures de dysfonctionnement : les définitions disparates des champs nécessaires à la description d'un message financier. Le format informatique n'étant pas imposé, IS020022 ne fait pas disparaitre des interfaces multiples, mais cela met la norme à l'abri des évolutions imprévisibles de la technologie ; elle ne deviendra pas obsolète même si le XML, aujourd'hui dominant, passe de mode. Et cela facilite son adoption par des acteurs disparates.

Les débuts ont été laborieux, l'existant est considérable, le sujet complexe pour couvrir tous les besoins et les coûts rendent juste inenvisageable une migration massive et rapide -même dans l'hypothèse farfelue où tous les acteurs auraient été d'accord pour l'adopter. Mais une démarche progressive a petit à petit permis à la norme ISO 20022 d'atteindre un poids qui la rend aujourd'hui crédible et qui va augmenter son attrait pour les participants encore à la traine.

Les technologies resteront disparates

En Europe, elle atteint la taille critique en 15 ans, notamment pour les paiements (SEPA). Appuyé par des acteurs majeurs du secteurs (SWIFT, ISDA, etc.), des éditeurs comme Oracle bâtissent leur solution autour d'elle. N'ayant pas de concurrents majeurs, il est probable qu'elle s'impose dans d'autres domaines bancaires que les paiements et d'autres zones géographiques (un rapport de la Fed de 2015 incite les Etats-Unis à suivre le même chemin), non comme un standard complet, -les technologies resteront disparates-, mais comme un point d'interopérabilité sur la sémantique.

Une victoire probable, mais pas immédiate. Si la progression est nette, des continents entiers de l'activité bancaire n'ont pas, ou peu, commencé son adoption. "Si ce n'est pas cassé, pourquoi le réparer ?" ; les gains en rapidité ou fiabilité sont incontestables mais le retour sur investissement est compliqué à établir et les contraintes sont, elles, bien réelles : coût de la migration, cycle d'évolution de la norme lent par rapport aux innovations bancaires, carcan lourd en particulier pour certains flux internes.

La lingua franca ne s'est pas faite non plus en un jour et elle a été utilisée plusieurs siècles ; ISO 20022 aura du mal à égaler la longévité de cet ancêtre mais 13 ans après sa naissance, elle n'a pas à rougir de sa progression.