Dans le cadre de la version révisée de la directive sur les services de paiement (DSP 2) et des textes qui l’accompagnent, notamment les normes techniques de réglementation (Regulatory Technical Standards – RTS) sur l’authentification forte des clients et la sécurisation des communications, plusieurs initiatives d’API (Application Programming Interface) ont vu le jour afin de faciliter les échanges de données entre les banques et les tiers de paiement (TPP).
Historiquement, Open Banking UK a été la première initiative d’API à voir le jour, car elle procédait d’une démarche distincte de la DSP 2, issue du régulateur britannique. Sa mise en œuvre opérationnelle est intervenue au Royaume-Uni dès 2018. Toutefois, cette initiative a évolué depuis, notamment dans sa version 3, de façon à s’ouvrir aux besoins d’autres marchés.
Le Berlin Group a, quant à lui, lancé en 2016 une initiative destinée à répondre aux besoins de l’ensemble des pays concernés par la DSP 2. Ce groupe de travail rassemble de très nombreux acteurs : banques, associations bancaires nationales et fournisseurs de solutions. Il a produit une version 1.3 constituée d’un socle commun, auquel s’ajoutent certaines spécificités destinées à telle ou telle communauté nationale. Des initiatives purement nationales sont également apparues en Pologne, en Slovaquie et en République tchèque.
STET a été mandatée en 2016 pour travailler sur une API destinée aux établissements français, tout en gardant à l’esprit une ouverture européenne possible, laquelle s’est concrétisée par l’inclusion d’établissements de Belgique ou du Luxembourg dans les différents groupes de travail. La version 1.4 est la dernière publiée à ce jour.
Enfin, certains établissements mettent au point leurs propres jeux d’API.
Une volonté de convergence
En l’absence d’API, les tiers de paiement utilisent essentiellement les technologies de screen scrapping, pour accéder aux informations des comptes bancaires. Ces technologies consistent à se connecter aux services de banque en ligne en utilisant les identifiants du client. Outre les préoccupations de sécurité liées à l'utilisation des identifiants du client, ces technologies obligent les tiers de paiement à développer des interfaces spécifiques à chaque établissement et à suivre en permanence les évolutions des services de banque en ligne.
L’utilisation des standards d’API permet de réduire drastiquement cette multiplicité d’interfaces, de plusieurs milliers à une dizaine. Toutefois, lors des travaux de l’ERPB (Euro Retail Payments Board), les autorités ainsi que les représentants du commerce et des consommateurs ont appelé de leurs vœux l’émergence d’un standard unique d’API. Ce sujet s’est récemment matérialisé par la constitution d’un groupe de travail pour l’émergence d’un scheme d’API européen. STET et le Berlin Group avaient en fait initié dès 2017 des travaux de convergence afin de réduire leurs différences.
En quoi les initiatives d’API diffèrent-elles ?
Une analyse rapide des différentes initiatives permet de comprendre que ces différences peuvent être regroupées en quatre catégories (voir Schéma 1).
Le modèle réglementaire
Il serait imprudent d’imaginer que le modèle réglementaire est d’emblée le même pour tous.
De fait, la directive sur les services de paiement nécessite une transposition dans le droit national de chaque pays concerné. Cette transposition induit donc des distorsions dans l’application des textes, afin de prendre en compte certaines spécificités nationales pouvant concerner par exemple des produits ou des méthodes de paiement, ou encore des méthodes d’identification ou d’authentification.
Par ailleurs, la DSP 2 spécifie un périmètre d’attendus et de contraintes. Certains domaines ne sont toutefois pas spécifiés par la directive et le rôle des normes techniques de réglementation (RTS) est bien de préciser les aspects réglementaires. Toutefois l’interprétation de ces textes peut encore différer d’un pays à l’autre si l’on n’y prend pas garde.
Enfin, certains sujets restent en cours de clarification par les autorités européennes.
Le modèle fonctionnel
En l’absence d’un modèle réglementaire stable ou unifié, les initiatives d’API ont donc spécifié un certain nombre de fonctionnalités destinées à répondre aux attendus tels qu’ils sont compris ici ou là.
Ainsi, telle fonctionnalité existe dans certaines initiatives d’API, mais n’est pas présente dans d’autres. Telle autre existe bien dans les différentes initiatives d’API mais avec des modalités de mise en œuvre assez différentes. C’est notamment le cas de la gestion du consentement de l’utilisateur final.
Le modèle technique
Par définition, une API s’appuie sur des standards techniques, définis à un niveau international, pour la réalisation d’un certain nombre de fonctionnalités de base : sécurisation des communications, authentification des différents acteurs, autorisation des accès, format des données…
Il existe parfois plusieurs standards techniques concurrents et certaines initiatives vont se baser sur un standard alors qu’un autre choix sera fait sur la base d'un autre.
Ce domaine reste aujourd’hui très actif et les standards peuvent évoluer rapidement. De nouveaux standards peuvent émerger et s’imposer, d’autres devenir progressivement obsolètes.
Le modèle de données
Sur des fonctionnalités équivalentes, c’est le domaine sur lequel une convergence des différentes initiatives d’API est certainement la plus facile à obtenir. Les travaux de convergence de STET et du Berlin Group ont avancé rapidement sur cette voie. Cette convergence sur les données est par ailleurs facilitée par l’existence du référentiel de données ISO20022.
STET avait initié dès 2017 des travaux avec SWIFT sur ce sujet afin d’imaginer une modélisation de son API au sein du référentiel ISO20022. Le Berlin Group et Open Banking UK ont rejoint ces travaux respectivement au printemps 2018 et en janvier 2019. Ceux-ci trouvent également un prolongement au sein de l’ISO (Organisation internationale de normalisation) et du World Wide Web Consortium (W3C).
Vers un standard unique ?
En l’absence d’un marché véritablement unifié, il est difficile d’imaginer l’émergence à court terme d’un standard unique d’API.
L’API du Berlin Group est déjà, de fait, un socle commun sur lequel chaque acteur va développer une version nationale prenant en compte les spécificités locales et les différences d’interprétation. Les API de STET et de Open Banking UK sont en ce sens beaucoup plus monolithiques.
Seul un véritable retour d’expérience avec la mise en œuvre opérationnelle des différentes API permettra d’identifier à terme les fonctionnalités phares ou les technologies de base sur lesquelles un standard unique pourrait émerger .
