Les nouvelles normes issues de la deuxième Directive Européenne sur les Services de Paiement (DSP2) – authentification forte et ouverture des données bancaires – sont entrées en vigueur le 14 septembre 2019.

Au lendemain de cette date couperet, un observateur de l’actualité bancaire peut raisonnablement se poser la question suivante : qu’y-a-t-il de nouveau dans mon environnement bancaire quotidien ?

Force est de constater qu’en ce lundi 16 septembre, aucun bouleversement marquant n’est intervenu lorsqu’on accède au site internet de sa banque pour consulter son compte.

Pourquoi un engagement aussi structurant, gravé dans la loi, qui a occupé les banques et les acteurs tiers pendant plus de deux ans, porteur d’une promesse d’ouverture de l’accès aux données en même temps que de sécurité renforcée, connaît-il aujourd’hui un effet aussi limité ?

La réponse à cette question tient certainement à la méthode qui a prévalu ici, pouvant s’apparenter à l’image de la « charrue avant les bœufs » : en clair, le bagage réglementaire et législatif (non répressif), avant la compréhension des changements induits sur les parcours client.

Comment expliquer autrement les valses hésitations stratégiques observées çà et là  : par exemple, le choix d’exposer un jeu complet d’API – normées ou maison – avant un retour brutal vers une interface transitant par le site de banque en ligne (« fallback »), ou bien, la planification au cordeau d’un dossier d’exemption de recours à cette « fallback » (finalement obtenu par 6 groupes bancaires) avant un report de l’ouverture du portail d’exposition des API faute de ne pas couvrir l’ensemble des fonctions réglementaires ou à cause de médiocres performances de disponibilité.

Et si l’itinéraire de cette évolution aux si lourdes implications passait plutôt par une approche pragmatique et progressive, plutôt que par un nième big bang ! C’est un peu le sens de l’article publié le 6 juin sur le site du France Payments Forum, en concluant que « la trajectoire pour mettre fin à la pratique du webscraping au profit de la pratique des APIs prendra sans doute encore des mois comme l’a montré l’exemple britannique » [i].

Le monde du commerce en ligne a finalement admis ne pas être en mesure d’être à l’heure au rendez-vous de l’authentification renforcée nouvelle mouture, avec risque de conséquence immédiate sur le chiffre d’affaires. Ce rappel à la raison  a entraîné l’ouverture d’une phase de pédagogie à l’initiative de l’EBA via son Opinion du 21 juin dernier, repris en écho par le rapport annuel de l’Observatoire de la Sécurité des Moyens de Paiement de la Banque de France[ii] et sa proposition d’un plan de migration en 2 volets concernant les consommateurs, d’une part, et les acteurs professionnels de la chaîne des paiements, d’autre part.

Il n’en reste pas moins que si c’est le début de la trajectoire, il faut désormais amorcer la courbe : une solution hybride entre recours aux API et accès aux données via le site de banque en ligne avec identification des tiers appelants permet à certains établissements d’être prêts dès aujourd’hui, comme c’est le cas pour l’établissement Monte Paschi Banque.

– Les API sont documentées sur un portail développeur[iii] permettant à un TPP (Third Party Provider) de les prendre en main :

  • afin de de se déclarer dans le système d’information de l’établissement teneur de compte,
  • puis de s’identifier chaque fois qu’il a besoin d’accéder aux données d’un client de cet établissement, avec un contrôle en temps réel de son agrément.

– Le jeton délivré par la seconde API permet ensuite au TPP d’accéder au site de banque en ligne pour y atteindre la page de l’utilisateur préalablement authentifié et permettre la collecte des données par des techniques classiques bien éprouvées.

Cette approche hybride laisse entrevoir derrière le virage, une nouvelle courbe bien maîtrisée, celle de l’enrichissement progressif du catalogue d’API fonctionnelles, jusqu’au moment où l’établissement considèrera qu’il permet de répondre intégralement au besoin réglementaire et pourra s’affranchir d’un accès via le site de banque en ligne et aller directement collecter les données « à la source » du core banking system.

Le processus d’authentification forte déclenchée par une API dédiée est totalement indépendant de l’interface de connexion mise à disposition des TPP. Il peut être déclenché par le site web de l’établissement si l’accès des TPP aux données passe par ce canal. Il peut être déclenché par la plateforme d’API management si les données sont échangées par l’appel d’API y transitant.

Donc finalement, on le voit, il s’agit d’un processus d’authentification qui est à la fois totalement autonome, exposé à l’interface principale d’échange des données et totalement mutualisé, qu’il s’agisse d’accéder à son compte soi-même ou via un TPP, ou d’initier un paiement électronique soi-même ou via un TPP.

Cette approche apparaît plus que jamais compatible avec la roadmap portée par le plan de migration de l’OSMP[iv], que les établissements teneurs de comptes ne manqueront pas d’emprunter dans les prochaines semaines.


[i] https://www.francepaymentsforum.eu/ouverture-de-lacces-aux-comptes-bancaires-dans-le-cadre-de-la-dsp2/

[ii] https://www.banque-france.fr/sites/default/files/medias/documents/819172_osmp2018_web_3.pdf

[iii] https://developer-api.montepaschi-banque.fr/

[iv] https://www.banque-france.fr/sites/default/files/medias/documents/2019-09-11_osmp_-_cp_migration_dsp2.pdf