Authentification forte, innovation : DSP2 bilan et perspectives

Bertrand Jeannet, Secrétaire Général de Budget Insight intervenait le 15 octobre dernier au Club Banque sur le thème « DSP2 : Quels impacts, quel bilan, quels enjeux ? » Le replay de cet évènement étant réservé aux abonnés du Club Banque, nous vous proposons d’en découvrir quelques morceaux choisis : authentification forte, innovation, parcours client.

 

 

La DSP2 est-elle vraiment un changement de paradigme ?

 

A lire ce qui est écrit dans les textes et dans la presse, on pourrait penser que la DSP2 représente un changement de paradigme technologique, comme si elle sonnait un peu le glas du Webscraping — ce qui n’est pas vraiment le cas — et qu’elle favoriserait l’innovation et l’Open Banking en donnant toute légitimité aux TPP (Third Party Provider), comme Budget Insight — ce qui est davantage le cas. Elle apporte aussi et surtout une sécurité renforcée (avec l’authentification forte), ce qui pèse un peu plus sur le second objectif de la DSP2 qui vise quand même à favoriser l’innovation. Or il n’est pas évident de trouver le juste milieu. Enfin, la DSP2 devait permettre une simplification et une homogénéisation à l’échelle européenne. Oui, dans les faits mais la réalité est toute autre. Nous pensions que nous n’aurions qu’une seule API à connecter, mais nous nous rendons compte que nous avons N API différentes pour N banques. De fait, ce sujet est relativement compliqué à gérer et très chronophage.

Des textes à la pratique

Dans la réalité et la pratique, le changement de paradigme technologique n’en est pas vraiment un. La DSP2 vient même légitimer le Webscraping, et donne la possibilité aux acteurs bancaires de rester dans l’état de l’art actuel. C’est-à-dire qu’aujourd’hui, les banques ont le choix de ne pas bouger. Elles doivent juste vérifier qui se connecte aux espaces de banques en ligne (certificats eIDAS). Si vous allez interroger certaines banques de la place, beaucoup seraient prêtes à rétropédaler sur la mise en place d’API et à continuer sur le webscraping authentifié.

Une simplification est toujours en attente

Aujourd’hui, cela fait un peu plus d’un an et demi que nous connectons les API des établissements bancaires français et autres (belges, luxembourgeois, italiens, etc.) Nous nous rendons bien compte que la simplification n’est pas encore là. Nos développeurs chez Budget Insight ont parfois l’impression de se trouver, dans une SSII et de passer leur temps à débugger les API des banques.

 

Favoriser la sécurité plus que l’innovation 

L’innovation n’est pas née avec la DSP2. En 2013, nous avions déjà des clients Grands Comptes et de grandes banques traditionnelles françaises membres de la FBF qui utilisaient nos services pour des projets innovants. Le constat un peu global, est que la DSP2 est arrivée en réaction à l’émergence d’acteurs comme nous. Les RTS Regulatory Technical Standards) et l’outil de Q&A de l’EBA sont venus ajouter de la confusion à la confusion. C’est en effet un texte compliqué à interpréter, à lire, qui explique aujourd’hui un retard important.

Le constat est sans appel : l’intégration des API accuse beaucoup de retard

Nous sommes très en retard dans l’intégration des API car celles-ci ne sont pas suffisamment fonctionnelles. 65 % de nos flux sont aujourd’hui conformes DSP2. Cela signifie que nous passons soit par la fallback (mécanisme d’urgence des banques) — majorité pour le moment — soit par l’API de la banque, car nous avons estimé qu’elle était suffisamment fonctionnelle et que nous avons pu gérer la transition dans les meilleures conditions possibles. Aujourd’hui, nous misons beaucoup sur ces mécanismes d’urgence, car nous nous rendons bien compte qu’au 31 décembre, la majorité des API des banques ne seront pas totalement fonctionnelles. Nous n’avons pas envie de migrer et d’essuyer un peu plus les plâtres — chose que nous faisons depuis déjà un an et demi.

Parlons du positif …

Des progrès très importants en France depuis un an 

Grâce notamment au travail mené sous l’impulsion de l’AFEPAME et du CNPS, avec des rendez-vous réguliers mensuels entre les banques et les TPP, nous avons pu réduire une longue liste de points bloquants. Ne pas avoir d’instances vraiment dédiées au suivi de l’implémentation des API comme les Allemands ou les Britanniques a été une erreur. Le mandat de STET n’a pas été étendu et c’est dommage.

Une amélioration technologique portée par l’initiation de paiement

Nous avions lancé l’initiation de paiement en scraping, dès 2018 mais c’est très complexe à maintenir. Nous sommes très heureux de l’apparition d’API d’initiation de paiement car il est beaucoup plus facile de vendre de l’initiation de paiement lorsqu’elle repose sur une API plutôt que sur une technologie de scraping. Dès que l’on touche au paiement et qu’il y a un mouvement de fonds, il est important d’être sur des SLA très exigeants. Nous avons beaucoup d’espoir que les API d’initiation de paiement nous aident à répondre à de nombreux besoins clients.

Une acculturation du marché à l’Open Banking

Avant la DSP2, nous entendions beaucoup moins parler de l’Open Banking. Aujourd’hui, beaucoup d’acteurs s’y intéressent et imaginent des relais de croissance et des relais de développement. Il est intéressant, de constater que l’Open Banking ne concerne pas seulement les services financiers. Petit à petit cela touche d’autres services exploitant des flux financiers et de ce fait l’Open Banking devient réalité.

L’authentification forte (SCA) reste le sujet principal d’inquiétude

Aujourd’hui, l’interprétation de l’EBA veut que la SCA soit gérée par les ASPSP teneurs de comptes, donc par les banques. Cela nous pose un vrai problème. Une première authentification forte, pourquoi pas, mais imaginez ce renouvellement de la SCA pour une personne multi-bancarisée et connectée à trois banques : cela signifie que tous les 90 jours, voire plus régulièrement, elle devra renouveler cette authentification forte N fois et selon ses N banques, ce qui engendre beaucoup de friction dans le parcours utilisateur. Il ne faut pas oublier qu’aujourd’hui, les TPP sont des établissements de paiement qui ont des polices d’assurance permettant de gérer des risques et de les supporter. Nous souhaitons gérer cette SCA et en supporter le risque associé (faible). Nous avons des systèmes et nous sommes structurés pour cela. Aujourd’hui, nous avons le sentiment que nous sommes un établissement de paiement, sans vraiment l’être. On ne nous donne pas forcément la latitude nécessaire pour pouvoir gérer ce que nous souhaitons gérer, et c’est assez dommage.

Une SCA (Authentification forte) systématique mettrait en danger de mort certains de nos cas d’usages

Le sujet qui émerge depuis peu et qui nous fait très peur, c’est qu’aujourd’hui, de grandes banques françaises imposent une authentification forte systématique pour des comptes professionnels et entreprises. Elles imposent aussi cette SCA systématique dans l’API. Soyons très clairs, cela signifie qu’aujourd’hui, tous nos cas d’usage liés à la gestion d’entreprise sont en danger de mort. Une SCA systématique via l’API met en danger nos cas d’usage relatifs à l’expertise comptable et à tout ce qui concerne la gestion des finances des sociétés. Ce qui représente un flux énorme — en tout cas chez nous.

Le mur est devant nous

Je termine par une image assez parlante. C’est volontairement un peu provocateur, mais c’est tout de même ce vers quoi nous nous dirigeons. Il est très probable que nous nous prenions un mur dans les prochains mois. Nous constatons que près de 50 % des utilisateurs finaux ne renouvellent pas leur SCA au bout de 90 jours. Nous provisionnons une perte de trafic importante, car cela commence à nous inquiéter fortement.

La solution pour l’éviter

Nous souhaitons que les RTS soient réécrits le plus rapidement possible, que nous puissions gérer la SCA et que nous en supportions la responsabilité. Il faut à tout prix avancer sur des parcours fluides, et même embedded, et pas forcément en redirect. Petit à petit, nous réussirons à lever les barrières. Malheureusement à ce stade le mur nous semble inévitable car nous commençons déjà à ressentir les effets de cette SCA. Certains de nos clients très dépendants de nos technologies ne pourront pas lancer leurs projets et n’auront pas les reins assez solides pour continuer. De nombreux projets sont déjà mis en pause et n’aboutissent pas. J’aurais préféré finir par une conclusion un peu plus joyeuse, mais je préfère que tout le monde soit au courant. Ainsi, on ne pourra pas dire que l’on ne savait pas.