Open Banking : l’accès aux données des banques par les APIs de DSP2 trop limité

Bertrand Jeannet, DG de Budget Insight

L’accès aux données des comptes bancaires via des APIs dans le cadre de la réglementation européenne DSP2 n’est pas un progrès si évident selon certains acteurs de l’Open Banking. C’est même une contrainte, voire une souffrance et surtout un frein à l’innovation, exprime Bertrand Jeannet, DG de Budget Insight.

Utiliser les données des comptes bancaires pour des services à valeur ajoutée

Budget Insight est ce que l’on appelle un acteur tiers, un Third Party Providers (TPP) et plus précisément un agrégateur de données qui est autorisé à accéder aux données des comptes bancaires et de les diffuser auprès de fintech qui développent des services à valeurs ajoutée, par exemple dans la gestion des finances personnelles. A ce stade, Budget Insight annonce 230 entreprises clientes qui délivrent de tels services.

« La DSP2 a été une aventure, une aventure un peu douloureuse, on ne va se mentir et ça l’est encore »

Dans cette démarche d’accès aux données, Bertrand Jeannet préfère pour l’heure préserver les outils traditionnels de « scrapping » et de « reverse engineering » aux côtés de l’usage des interfaces applicatives des banques, les APIs qui ont été mises en place dans le cadre de la régulation européenne DSP2, la directive sur les services de paiement entrée en vigueur en 2018.  « La DSP2 a été une aventure, une aventure un peu douloureuse, on ne va se mentir et ça l’est encore, ça l’est un peu moins » résume-t-il.

« Nous n’avons pas attendu la DSP2 pour innover » insiste-t-il toutefois. Pour lui, la DSP2 a été plus une contrainte réglementaire et un frein. « Technologiquement parlant, la DSP2 c’est une souffrance, ça l’est encore. Aujourd’hui, sur les APIs DSP2, il y a des banques qui sont en avance, d’autres qui sont vraiment en retard » poursuit-il. Il a pris la parole à l’occasion de l’événement Big organisé par la Banque Publique d’Investissement (BPI), le 7 octobre à l’Accor Arena, à Paris.

Le ‘scrapping’ convenait parfaitement à l’accès aux données

Il tient à souligner que la DSP2 n’implique pas forcément des APIs et que les banques peuvent ne pas en proposer aux TPP. Rétrospectivement parlant, il pense que certaines banques ont vraiment souffert de la mise en place de la DSP2 et ne mettraient pas en place d’APIs aujourd’hui.  « Elles se laisseraient ‘scrapper’ en nous authentifiant et en voyant que nous sommes autorisés à le faire. Elles n’auraient pas engagé de frais. Elles n’auraient pas eu nos complaintes importantes à leur support DSP2 » dit-il.

Certains se sont dit qu’ils allaient pouvoir se passer des prestataires tiers grâce aux APIs des banques, mais c’est encore plus compliqué que le ‘scrapping’

La route vers la DSP2 apparaît comme étant toujours une démarche en cours. « La DSP2 est une aventure qui n’est pas terminée. Au Royaume Uni, cela a pris 5 ans avant que cela ne soit vraiment pérenne et que ce soit ‘sec’. Aujourd’hui, cela commence à être un peu plus ‘sec’ au niveau des APIs DSP2 mais ce n’est pas terminé » prévient-il. Paradoxalement, les APIs compliquent l’accès aux comptes bancaires alors qu’elles devaient le simplifier. « Ce qui est bien pour nous c’est que cela a apporté une contrainte technologique supplémentaire. Il y a des acteurs qui se sont dit qu’il allait y avoir des APIS des banques et qu’ils allaient pouvoir se passer des TPP. Au contraire, c’est encore plus compliqué que le ‘scrapping’ aujourd’hui. Cela nous légitime encore un peu plus » pense-t-il.


A ce stade, le dirigeant déclare être capable de faire passer 80% de son flux de données en DSP2 sur les comptes de paiement. « Les connecteurs sont prêts, on pourrait faire passer 80% de notre flux de données en DSP2. Mais lorsque l’on appuie sur le bouton et que l’on bascule depuis le ‘scrapping‘ vers le DSP2, croyez moi on a des sueurs froides » indique-t-il. Budget Insight souligne qu’il est donc obligé d’effectuer de nombreux tests, ce qui est très long. L’entreprise réalise également beaucoup de « canary testing », c’est-à-dire qu’elle teste la solution sur un petit nombre de clients. « Aujourd’hui, je pense que nous avons plus de 50% [NDLR : de notre flux de données] qui est en DSP2 » précise-t-il.

Couper les connecteurs de ‘scrapping’ signifierait la mort de Budget Insight

Pour autant, il est totalement hors de question de couper les connecteurs historiques vers les banques réalisés en ‘scrapping’. Ce serait la fin de Budget Insight. « Les TPP qui se contentent de connecter les APIs DSP2 des banques, et ne font que cela, ne seront plus autonomes vis-à-vis de la récupération de données, ont perdu. Je vous le dis tout de suite, c’est terminé pour eux » affirme-t-il. Dès lors le ‘scrapping’ demeure indispensable chez Budget Insight. « Les connecteurs en ‘scrapping’ ont encore de très beaux jours devant eux. Petit à petit, cela va devenir des fonctionnalités additionnelles, que l’on va réaliser autour de l’API DSP2 qui est un peu la brique principale et nous avec le ‘scrapping’. Nous allons enrichir ces APIs DSP2 » décrit-il.

La flexibilité qu’apporte le ‘scrapping’ s’illustre lors de la mise en service de nouveaux cas d’usage

Cette flexibilité qu’apporte le ‘scrapping’ s’illustre lors de la mise en service de nouveaux cas d’usage réalisés à partir des données bancaires. Il faut alors moduler la récupération d’information. A ce jour, Budget Insight dénombre une vingtaine de cas d’usage tels que l’agrégation de comptes, la gestion des finances personnelles ou du cash back. Il émerge 3 à 4 cas nouveaux d’usage par an. Cela nourrit la croissance organique de Budget Insight. A cette heure, les nouveaux cas d’usage par exemple concernent l’immobilier et les syndics.

« C’est sur les nouveaux cas d’usage qu’il faut moduler un peu la récupération d’informations parce que peut être qu’il leur faut un petit détail en plus, qu’il leur faut aller chercher un degré supplémentaire d’information » explique Bertrand Jeannet. C’est là qu’il est judicieux d’être indépendants des APIs des banques. « Si on se place en situation de dépendance vis-à-vis des APIs des banques, on n’a pas ce degré de granularité » prévient-il. « On est obligé de maintenir d’autres moteurs de récupération de données, le ‘scrapping’ en est un, le ‘reverse engineering’ en est un autre pour aller chercher cette information, ce rafraîchissement supplémentaire de la donnée pour nourrir ces cas d’usage là et on est obligé de s’adapter en permanence en fait » précise le dirigeant. 

Le protocole bancaire EBICS devient une opportunité de supprimer l’authentification forte

Dans cet accès aux données bancaires, existe-t-il une autre voie telle que le protocole bancaire EBICS (Electronic Banking Internet Communication Standard) ? Pour Bertrand Jeannet, ce protocole EBICS pose des questions, car il concurrence la DSP2 mais de manière déloyale car il n’impose pas l’authentification forte du client utilisateur du service. Le dirigeant y voit même l’opportunité de s’affranchir de cette authentification forte si EBICS devait être maintenu.

Le protocole EBICS est un peu une concurrence déloyale de DSP2 car il ne demande pas d’authentification forte

« On se pose la question de savoir si EBICS n’est pas de la concurrence déloyale par rapport à la DSP2 pour la bonne raison que EBICS n’a pas d’authentification forte. C’est quand même une belle barrière en moins. Ce sont des sujets que nous sommes en train de mouliner entre TPP » indique-t-il. De toute façon, il considère qu’EBICS ne constitue pas le sens de l’histoire en matière de récupération de données. « Il y a une notion de mandat qui est assez compliquée. On observe ce sujet de très près mais pour nous c’est de la concurrence un peu déloyale. Mais on ne pointe personne. C’est un système qui existait. Mais cela pose problème, oui » estime-t-il.


Cette difficulté de l’authentification forte le marque toutefois. « Si EBICS n’a pas d’authentification forte, on ne voit pas pourquoi nous en aurions. On demande juste d’aligner et que l’on ne se retrouve pas tous avec une authentification forte. Mais que plutôt cela nous permette de lever cette barrière et d’avoir une fluidité dans la récupération des données qui soit digne de ce nom » conclut-il.


Le logiciel de gestion de trésorerie Agicap s’appuie sur DSP2 mais prend ses précautions

Face à Budget Insight plutôt critique sur le chemin de croix que représente les APIs de la réglementation DSP2, Clément Mauguet, directeur des ventes et cofondateur de Agicap, une fintech lyonnaise qui propose un logiciel de gestion de trésorerie, se félicite de la DSP2, tout en reconnaissant qu’il lui faut prendre ses précautions face au risque que les APIs bancaires ne fonctionnent pas. « Nous sommes une pure émanation de la DSP2. Nous sommes le succès de la DSP2 dans le sens où 5000 sociétés développent leur activité avec Agicap comme outil de pilotage principal » débute-t-il. « Sans la DSP2, nous ne pourrions pas » dit-il. L’outil Agicap récupère les transactions bancaires. La société est internationale et possède des bureaux à Berlin, Amsterdam, Milan et Barcelone. « Nous récupérons les flux bancaires de chacun de ces pays. On utilise plus de 15 agrégateurs bancaires. En France on travaille avec Budget Insight de manière extrêmement proche » présente le directeur des ventes. Il reconnaît les problèmes rencontrés avec les APIs et explique comment il les contourne. « L’instabilité de la connectique pose de vrais problèmes. Lorsque la connexion ne marche pas, il n’y a non visibilité sur les finances de sa société pour un gérant » rappelle-t-il. « Nous utilisons le meilleur agrégateur [NDLR : de données bancaires] pour chaque pays, mais on crée de la redondance pour chaque pays. Nous avons de 1 à 4 agrégateurs par pays pour que cette stabilité de la connexion bancaire puisse se faire à tout prix pour le bénéfice de nos utilisateurs » explique-t-il. Pour le responsable, il n’existe pas de meilleur agrégateur. « Etant donné que l’on est encore dans des travaux importants avec les banques, il est normal que ce soit les acteurs locaux qui soient meilleurs travaillant avec leur banque locale. Aujourd’hui on travaille de manière locale avec tous les agrégateurs de chacun des pays » termine-t-il.

Chez BNP Paribas, l’un des tout premiers motifs d’appel des clients concerne l’authentification forte

Dans la transformation afin de se conformer à la directive DSP2, Marguerite Bérard, directrice des réseaux France et membre du comité exécutif du groupe BNP Paribas, place en tête des désagréments le temps qu’il faut consacrer à informer les clients sur la mécanique de l’authentification forte liée à la DSP2.
« Ce qui nous a pris le plus de temps et on le voit encore aujourd’hui c’est l’authentification forte des clients » dit-elle. « Quand je vois les motifs d’appel de notre service client, l’authentification forte est un vrai sujet pour les clients aujourd’hui. On leur explique que c’est une protection. Dans les motifs d’appels du service client, c’est l’un des tout tout premiers » poursuit-elle. La dirigeante considère que le sujet est moins technique et informatique que de continuer à expliquer les usages. « Quand on fait du retail, c’est un marché de masse, ce sont des millions de clients qu’il faut pouvoir toucher y compris avec des situations comme le client qui vit à l’étranger mais qui a un compte chez vous, et qui n’a pas un numéro de portable français, et pour qui l’authentification forte c’est la plaie » illustre-t-elle. « Ce sont tous ces cas là qu’il faut pouvoir descendre les uns après les autres et qui a nécessité un peu de manœuvre à pied pour la mise en place de la DSP2 » pointe-t-elle. « Pour la plupart des grandes banques cela [NDLR, la mise en place des APIs de la DSP2] a nécessité de gros investissements avec par exemple la mise en place de l’authentification forte pour l’ensemble de nos clients. Et c’est énormément de travail et d’éducation de nos clients pour pouvoir recourir à celle-ci » constate-t-elle.
Marguerite Bérard reconnaît que la mise en place de la DSP2 chez BNP Paribas à partir de 2019 a quand même été une grande aventure. « Ce sont des investissements importants dans nos infrastructures qu’il a fallu roder. Ce sont aussi nos APIs, nos interfaces de programmation, qu’il a fallu construire, déployer, faire progresser là encore » décrit-elle. Désormais, elle estime que la banque a atteint un bon niveau de maturité. « J’en veux pour preuve qu’aujourd’hui nous n’utilisons plus la technologie du ‘scrapping’ » déclare-t-elle. Elle informe que tous les tiers utilisateurs utilisent les interfaces APIs de la banque et que celles-ci sont sous surveillance. « Nous mesurons à la fois les temps de réponse de nos APIs, qui sont en millisecondes, la disponibilité de celles-ci qui est excellente. Nous avons aussi des équipes support qui aident les Fintech et des experts pour mieux utiliser nos APIs » commente-t-elle. Pour la dirigeante, on peut aujourd’hui avoir avoir accès sans difficulté via l’interface d’un agrégateur par exemple, à la consultation de ses comptes BNP Paribas ou Hello Banque ainsi que payer sur le site d’un e-commerçant en initiant un paiement depuis le site à travers une API en venant débiter son compte BNP Paribas ou Hello Bank. 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *




L'événement digital

IA éthique : Axa dans les pas de LMVH, rejoint le Corporate Affiliate Program de Stanford HAI 

IA éthique : Axa dans les pas de LMVH, rejoint le Corporate Affiliate Program de Stanford HAI 

L’assureur Axa devient membre du Stanford HAI Corporate Affiliate Program du Stanford Institute for Human-Centered AI. Il se place dans …