I) Le contexte

La deuxième Directive sur les services de paiement (DSP2) a initialement été proposée par la Commission européenne et votée en 2015 par le Parlement européen. En France c’est l’ordonnance n° 2017-1252 du 9 août 2017 qui est venue la transposer. Le 31 août 2017, des décrets d’application ont complété l’ordonnance ainsi qu’un arrêté.

Pour rappel, la DSP2 ouvre une large place à l’innovation en intégrant de nouveaux services de paiement et donc de nouveaux acteurs. Ces nouveaux services sont d’une part, le service d’initiation de paiement consistant à initier un ordre de paiement à la demande d’un utilisateur à partir d’un compte de paiement détenu auprès d’un autre prestataire de services de paiement et, d’autre part, le service d’information sur les comptes qui consiste à fournir des informations consolidées concernant un ou plusieurs comptes de paiement détenus par l’utilisateur auprès d’un ou plusieurs autres prestataires de services de paiement.

Ces nouveautés ont accéléré l’émergence de l’ère de « l’Open-banking », permettant à de nombreux acteurs, autres que les banques traditionnelles, d’œuvrer en matière de services de paiement. Ainsi, depuis quelques temps déjà les Fintech connaissent une croissance exponentielle et font trembler les banques de la place. L’expression combine en réalité deux termes à savoir « finance » et « technologie ». Ces nouveaux acteurs dans le paysage de la finance sont essentiellement des start-up utilisant la technologie de pointe afin d’insuffler du renouveau en matière de services financiers mais aussi bancaires. C’est en 2008, avec la crise financière mondiale que bon nombre de hauts cadres de la finance se sont retirés du milieu et ont envisagé une finance plus simple et plus intuitive afin de répondre au mieux à une clientèle « ultra-connectée ».

II) Le principe

Avec la DSP2, il est apparu un principe de base consistant en une obligation, à savoir que les banques doivent laisser ces nouveaux prestataires accéder aux espaces en ligne des clients si ces derniers ont donné leur accord. Si jusqu’alors la DSP2 imposait une obligation aux banques, elle n’imposait pas de manière explicite à ces nouveaux prestataires d’avoir recours aux applications mises en place par les banques afin d’accéder aux informations des clients. Ce dernier point étant problématique car ne réglant pas le point très important de la pratique du « web-scraping » dans un monde connecté ou la cybercriminalité connait un essor sans précédent.

Le « web-scraping » est un anglicisme désignant une manipulation informatique consistant en la réalisation d’extractions de contenus de sites internet à l’aide de programmes informatiques dédiés, avec pour objectif d’obtenir des données de manière non autorisée et dans le but de les utiliser à des fins autres que le contexte dans lequel elles ont été extraites. Dans le cadre des services de paiement, les Fintech utilisaient et utilisent encore beaucoup cette technique fortement dénoncée, afin d’obtenir l’ensemble des informations clients grâce à leurs identifiants ; ceci pour les référencer mais aussi afin de développer leur activité d’initiateur de paiement et d’agrégateur de comptes.

Le problème majeur étant la sécurité et l’absence d’encadrement d’accès à des données sensibles. C’est dans ce contexte, que la Commission européenne s’est prononcée le 17 novembre 2017.

III) La nouveauté

Le 17 novembre dernier, la Commission européenne s’est penchée sur la question, et cela était très attendu par les banques de la place européenne. Ainsi à compter du mois de mai 2019, les Fintech devront obligatoirement recourir à des interfaces de programmation, autrement appelées « API » (Accès par protocole Informatique), afin d’avoir accès aux données clients. Étant précisé que ces interfaces seront développées exclusivement par les banques qui devront donc les mettre à disposition des nouveaux acteurs de la finance.

Ainsi, cette décision, fortement influencée par les recommandations de l’Autorité Bancaire Européenne (ABE), a pour objectif de mettre fin à la technique du « web-scraping » qui comme nous l’avons vu supra représente un véritable danger en matière de cybercriminalité.

Toutefois, la décision de l’exécutif européen doit être nuancée de trois manières.

Premièrement, le délai est long ! Actuellement les Fintech ont recours à la technique du « web-scraping » et pourront y avoir recours jusqu’à la mise à dispositions des API par les banques, qui devra avoir lieu en mai 2019 au plus tard. Ainsi, malgré l’entrée en vigueur des RTS (normes techniques réglementaires de la directive) en janvier 2018, les Fintech pourront toujours continuer à avoir recours au « web-scraping » même si elles devront en informer les banques.

Deuxièmement, le « web-scraping » restera autorisé en cas de défaillance des API développées par chacune des banques. Ainsi, le procédé sera toujours plus ou moins d’actualité alors même qu’il est fortement critiqué et dénoncé aujourd’hui.

Troisièmement, ce choix reste à valider par le Parlement européen dont l’étude du sujet est attendue dans les prochaines semaines. Toutefois, si le Parlement mettait plus de temps que prévu à se prononcer, la date retenue pour la fin du « web-scraping » serait repoussée. Et si le Parlement décidait même d’invalider le projet, rien ne semble être prévu, et un travail de négociation long et fastidieux débuterait alors, laissant la liberté aux Fintech d’avoir recours à la technique pointée du doigt.

Enfin, si les banques seront seules à pouvoir développer leurs propres API, auront-elles le libre choix de l’API à mettre en place, et si oui comment faire ce choix ?

IV) La mise en place d’une API adaptée par les banques

Si les API semblent être la solution la plus adaptée afin de prendre en considération l’ensemble des exigences que nous avons vu précédemment, il ne va pas être simple pour les banques de savoir quelle API devra être développée.

Tout d’abord, il faut rappeler qu’une API est une technique informatique permettant de mettre à disposition de tiers des services et des données, et cela de manière sécurisée. En d’autres termes, les tiers pourront via ces interfaces interroger les banques afin d’obtenir des informations précises sur les clients, et les banques devront y répondre via l’interface.

Ainsi, dans le paysage actuel, il existe trois types d’API :

1) Les API dites « privées » : dans cette hypothèse, l’API est mise en place pour un partenaire unique, et n’est utilisable que par ce dernier. Ceci représente un intérêt certain notamment en matière d’échanges de données sensibles. Toutefois, cela nécessite le développement d’une interface unique pour chaque tiers interrogeant la banque.

2) Les API dites « publiques » : elles sont déjà largement utilisées et permettent d’échanger librement des données, sans sensibilité particulière. Il n’est pas certain que ce type d’API soit recommandé pour le domaine bancaire.

3) Les API dites « ouvertes » : mieux connues sous l’anglicisme « Open API ». Si elles sont plus souples que les API privées, elles présentent un degré supérieur de sécurité dans la mesure où le tiers doit accepter des conditions générales d’utilisation, et doit s’authentifier à chacune de ses connexions. L’inscription étant obligatoire, cela permettra aux banques de contrôler les tiers qui se connectent afin de collecter des données clients. Il semblerait donc que ce type d’API soit le plus adapté. Toutefois ces API présenteront-elles un degré de sécurité suffisant notamment dans le cadre d’échange de données sensibles comme les données bancaires ou personnelles par exemple ?

Il faut noter que le développement de ces API va représenter un coût pour les banques, et il est fort probable que ces dernières se tournent vers des API qui sont génératrices de revenus. Les API ouvertes permettent notamment d’offrir des services connexes à la collecte de données, et ces services pourraient s’avérer payants et donc être une manne financière importante pour les banques.
Dès lors, si le modèle envisagé semble être le développement d’une API par chacune des banques, il est tout à fait possible d’envisager le développement d’API universelles ou d’API croisées, ceci permettant de mutualiser les coûts en créant une « open source d’API » et donc de favoriser le développement de « l’Open banking ».

Si des doutes subsistent, ceux-ci sont renforcés par la position de l’Autorité Bancaire Européenne (ABE) qui s’est prononcée le 27 novembre 2017, soit 10 jours après la décision de la Commission européenne. Même si elle reconnait le bien-fondé de ce positionnement, elle estime que la solution retenue ne correspond pas à la réalité opérationnelle et que celle-ci, portée comme une sécurisation du processus d’échange des informations, ne permet pas de savoir si les Fintech auront un accès restreint à ce qu’elles ont strictement besoin ou au contraire si elles auront l’accès à d’autres données au-delà de leur requête.

Il faut donc attendre la décision du Parlement européen, mais nul doute que le sujet risque de poser encore des questions cruciales, auxquelles il conviendrait de répondre avant janvier 2018.