Agrégateurs et banques : comment vont-ils s’échanger les données des comptes ?

En publiant la version finale des très attendus standards techniques (RTS) de la DSP 2 le 27 novembre, la Commission européenne a-t-elle réussi l’exploit de réconcilier des positions irréconciliables ? Les deux camps qui se sont affrontés pendant des mois sur ce texte ont salué les arbitrages finaux du législateur européen. Tout d’abord, les banques, en tant qu’ASPSP [1] c’est-à-dire gestionnaire des comptes de paiement dont la DSP 2 ouvre l’accès à des tiers : « en privilégiant les interfaces standardisées, ouvertes et sécurisées (API) comme solutions d’accès aux comptes de paiement par les agrégateurs et les initiateurs de paiement au sein de l’Union européenne, la Commission a fait le choix de la sécurité », soulignait ainsi la Fédération bancaire française à la publication du RTS. Mais en face la satisfaction se retrouvait aussi du côté de ces tiers dont l’activité, jusqu’ici dans la zone grise du droit va ainsi être légitimée et encadrée. « Le texte constitue un compromis viable entre les intérêts des acteurs bancaires en place d’un côté et les FinTechs européennes de l’autre », notait ainsi un communiqué de l’alliance « Future of European FinTech », regroupant à la fois des agrégateurs de comptes et des initiateurs de paiement que la DSP 2 consacre à travers les nouveaux statuts d’AISP et de PISP [2] .

L’API, voie privilégiée…

Mais comme souvent dans le processus européen, les compromis se traduisent par des usines à gaz réglementaires. Ce RTS régissant – en particulier [3] – la manière dont ASPSP et AISP/PISP vont communiquer et s’échanger des données n’échappe pas à la règle. Dans un monde parfait où tous les acteurs coopèrent et produisent des outils de qualité, les choses sont claires : les banques créent des interfaces sécurisées et standardisées (les API) et les mettent à disposition des nouveaux tiers de paiement dûment agréés et mandatés par les clients. Ces tiers sont obligés de les utiliser en lieu et place de leur pratique de web scraping. Cette dernière est la solution à laquelle ont aujourd’hui recours en France, des agrégateurs comme Bankin, Linxo ou Budget Insight par exemple. Elle permet de récupérer les données directement sur le site de banque en ligne des clients, grâce à des robots scannant la page. Une solution par défaut qui avait l’avantage de permettre aux nouveaux acteurs de développer leur offre sans qu’il soit indispensable d’interagir avec les banques teneuses de compte, mais qui présentait aussi l’inconvénient de la lourdeur puisqu’il fallait développer un outil adapté à chaque espace de banque en ligne. Mais pour les banques [4] , le vrai problème du web scraping vient des risques qu’il fait courir pour la sécurité des fonds et des données bancaires. Selon les teneurs de comptes, le stockage des identifiants et mots de passe des clients qu’implique le web scraping expose le système à un risque de cyberattaque. À quoi les FinTechs rétorquent que leurs systèmes sont très sécurisés [5] . La solution technologique pour contourner ce débat est donc celle de l’API, passerelle informatique où les rôles de chaque intervenant sont bien définis au préalable. Plus question de passer en douce par le soupirail, l’hôte a ouvert la porte de service et a donné la clé.

…mais pas unique

Derrière cette apparente simplicité, la solution « tout API » a inquiété les agrégateurs et initiateurs : que se passerait-il en cas de défaillance de l’interface, ou tout simplement si celle-ci se révélait moins performante que l’espace de banque en ligne à la disposition client ? Les FinTechs ont réclamé des garde-fous. Après plusieurs mois de négociations houleuses, rythmées par les allers-retours entre la Commission et l’EBA, le RTS a accouché d’un système à plusieurs étages. Tout d’abord, les banques teneuses de compte ne souhaitant pas développer d’API – celles de taille modeste par exemple – pourront avoir recours à une solution d’« accès direct », forme de web scraping où la FinTech a l’obligation de s’authentifier. Quand l’API existe, cet accès direct sert également de solution de repli en cas de dysfonctionnement. Cas qui devraient rester rares puisque l’interface aura au préalable été testée par les acteurs pendant six mois. Sa performance en termes de qualité de données, de fréquence de mise à jour, de conditions d’accès aura donc pu être, au préalable, vérifiée. La solution de repli sur l’accès direct est donc surtout un garde-fou et une incitation à ce que la qualité initiale reste la même dans le temps.

Une exemption aux contours encore flous

Le RTS introduit toutefois un système d’exemption à cette solution de repli. L’autorité nationale compétente – en France vraisemblablement l’ACPR, avec en soutien la Banque de France sur les questions de sécurité – pourra dispenser l’ASPSP proposant une API suffisamment performante du développement d’un accès direct avec authentification. « Nous avons proposé aux instances européennes une solution technique sécurisée et simple à mettre en place pour cette authentification », assure Joan Burkovic, fondateur de Bankin. Mais au-delà des coûts de développement, c’est l’existence même d’une solution proche du web scraping qui crispe les banques : « Même authentifié, le web scraping n’est pas sécurisé puisqu’il nécessite le stockage des identifiants et mots de passe », insiste Jérôme Raguénès, directeur du département numérique, systèmes et moyens de paiement de la FBF. Que se passera-t-il, dès lors, si l’API dysfonctionne longtemps [6] et que l’ASPSP n’a pas de solution de secours ? Comment les AISP et les PISP accèderont-ils aux données ? Via du web scraping traditionnel ? Le RTS reste flou sur ce point, certes théorique mais potentiellement déstabilisateur du nouvel écosystème que l’Europe souhaite mettre en place. « Le texte prévoit que l’autorité compétente doit s’assurer de la continuité de nos services en tout état de cause », souligne Joan Burkovic. Elle doit être tenue au courant en permanence des actions entreprises par les différents protagonistes.

Autre point délicat de cette exemption : le « tampon » que doit mettre l’autorité nationale compétente. La procédure n’est pas décrite par le texte et les critères pour juger de la validité d’une API ne sont pas explicités. « Il sera important de trouver une procédure harmonisée entre les différentes autorités, explique Geoffroy Goffinet, directeur adjoint des agréments à l’ACPR. La DSP 2 prévoit un système de passeport européen pour ces nouveaux services et il faut que les critères de conformité soient au même niveau d’exigence dans tous les pays. » Ce sera vraisemblablement à l’EBA de garantir cette harmonisation.

Des points laissés en suspens

En outre, l’autorité européenne doit combler un autre vide de la DSP 2 et de son RTS : celui du registre des AISP et PISP agréés. « Les banques ont besoin de savoir si les tiers qui appellent leurs API sont autorisés à accéder aux données. Ce registre doit être tenu à l’échelle européenne, du fait du passeport, et être dynamique, pour pouvoir tenir compte en temps réel d’éventuels retraits d’agrément. Sans cela, les risques seraient trop importants », fait valoir Jérôme Raguénès. Des standards ont été proposés par l'EBA le 13 décembre et le registre devrait voir le jour courant 2018.

L’ensemble de ce dispositif complexe pâtit par ailleurs de son calendrier : les AISP et les PISP seront agréés à partir du 13 janvier 2018, mais le RTS n’entrera en vigueur qu’à l’été 2019 [7] . Entre-temps, le statu quo prévaut en théorie. À moins que les acteurs n’avancent plus vite. « Cela fait deux ans que nous avons lancé la réflexion sur des standards pour ces API et une première version de spécifications a été publiée en juillet [8] . Nous avons repris les travaux afin de les adapter à la dernière version du RTS », explique Jérôme Raguénès. Les premières API devraient ainsi être disponibles courant 2018. Les nouveaux tiers pourraient alors choisir de les utiliser sans attendre, moyennant la phase de test de six mois. « Nous appelons à ce que les acteurs anticipent l’entrée en vigueur du RTS et convergent au plus vite vers la situation cible », souligne Geoffroy Goffinet.

La DSP 2 et après ?

Même une fois ces API mises en place et utilisées, rien ne sera réglé pour l’accès aux comptes autres ceux de paiement couverts par la directive. La zone grise pré-DSP 2 prévaudra donc toujours pour les comptes d’épargne notamment. Avec de surcroît des différences entre pays, dues à des transpositions hétérogènes de la directive. « 80 % des comptes concernés par nos services ne sont pas des comptes de paiement, rappelle Joan Burkovic. Mais il faut procéder par étapes. Celle-ci est un bon premier pas qu’il faut stabiliser. On peut supposer que l’on utilisera très prochainement les mêmes règles de sécurité pour tous les systèmes. C’est d’ailleurs ce que nous prônons. » Pour réaliser ce pas supplémentaire, il faudra résoudre la question du business model. En imposant qu’un tiers agréé puisse accéder à l’API sans avoir besoin de contractualiser avec la banque, la DSP 2 a complexifié la donne. Cette disposition empêche la tarification de l’accès et donc l’amortissement du développement de l’API. Mais rien n’empêche à l’avenir les parties prenantes de s’entendre sur des fonctionnalités supplémentaires, pouvant, elles, faire l’objet d’une tarification. Une sorte de modèle « freemium » qui offrirait par exemple une plus grande fréquence de mise à jour des données [9] , voire une notification en temps réel des nouvelles opérations, et pourquoi pas, l’accès à d’autres types de données (livrets, assurances vie, comptes-titres…).

À terme, ces frictions entre ASPSP et tiers pourraient même disparaître si l’API devenait la technologie de référence pour tout accès aux données bancaires. « Il y aurait une logique à ce que l’API soit également utilisée par la banque pour connecter l’interface en ligne du client avec le système d’information », soulignait ainsi Julien Lasalle, adjoint au chef du service de surveillance des moyens de paiements scripturaux à la Banque de France, lors d’une conférence organisée par Canton Consulting début décembre. Une manière de solder les débats de ces derniers mois et de travailler ensemble à un écosystème bancaire à la fois ouvert et sécurisé.

 

Achevé de rédiger le 15 décembre 2017.

 

9 Le RTS autorise le tiers à appeler 4 fois par jour l’API, ainsi qu’à chaque fois que le client le demande.