Au-delà du renforcement des aspects liés à la sécurité, la principale novation apportée par la DSP2 consiste à ouvrir l’accès aux comptes bancaires. Les banques doivent  développer et mettre en œuvre des interfaces qui sécurisent et facilitent l’échange des données avec les nouveaux acteurs (prestataires de services d’initiation de paiement et prestataires de services d’information sur les comptes), telles que les interfaces de programmation spécifiques (API), afin de se conformer aux standards techniques réglementaires (RTS) qui entreront en vigueur en septembre 2019. Les enjeux sont importants pour les banques qui souhaitent déployer leur API sans mettre en outre à disposition une solution de secours (fallback option).

La démarche proposée par la France en vue de demander l’exemption de fallback option exigée par l’article 33 du Règlement Délégué UE 2018/389 de la Commission Européenne, a fait l’objet d’un décret d’application publié le 24/12/2018 complété par un formulaire établi par l’ACPR.

Cette démarche a été explicitée, au cours d’une réunion de place lundi 18 mars.

Au-delà du formalisme propre au « commentaire d’arrêt », force est de constater que la principale raison du recours à la Fallback option tient à son calendrier extrêmement contraignant avec l’échéance du 14 septembre 2019. En effet, si les établissements teneurs de compte ne font pas la demande d’exemption avant le 14 juillet 2019 et ne l’obtiennent pas au 14 septembre, alors ils sont dans l’obligation de développer le mécanisme d’urgence décrit dans le règlement, de sorte à ce qu’il soit opérationnel à l’entrée en vigueur du texte.

Cette date couperet interpelle d’autant plus que l’ACPR bénéficie d’une procédure de « silence vaut acceptation » pour son délai de notification de 2 mois après réception du dossier complet.

De plus, il est à craindre que tous les grands établissements de la place faisant cette demande créent un effet d’engorgement pour le service en charge de l’instruction des dossiers, en dépit du fait que l’ACPR ait demandé à des organismes certifiés de valider les performances et la sécurité des APIs et que l’absence de réponse de l’ACPR vaille acceptation.

L’obtention d’une exemption sera d’autant plus difficile, que selon les termes de la seconde directive, (articles 66 et 67), les établissements teneurs de compte de paiement fournissant un moyen d’accès en ligne à leurs clients doivent mettre en œuvre une interface dédiée dont les performances sont équivalentes à celle du web-banking.

Or, la mise en place des indicateurs clés de performance de l’interface client requis pour la demande d’exemption, s’ils n’ont pas été déjà implémentés par les établissements pour répondre à leur propre besoin de pilotage, nécessite en soi un projet qui viendra s’ajouter aux exigences du dossier de la demande d’exemption. Ajoutons à cela que la liste exhaustive de ces « KPIs » n’est pas explicitement décrite dans les RTS.

A ce propos, soulignons l’exemple anglais concernant la mise en œuvre de ces indicateurs de performance : les TPP se sont regroupés en OBIE (Open Banking Implementation Entity) afin de contrôler la performance des APIs des banques au regard des indicateurs définis et les rendre publiques afin d’inciter les banques à améliorer leurs interfaces.

Ce projet d’enrichissement de données de pilotage de la performance de l’interface client, qui s’impose donc désormais à tous les établissements teneurs de compte, peut être utilement mis à profit pour ajouter tout simplement un mode d’accès dédié aux acteurs tiers sur la plateforme de banque en ligne et permettre l’économie de la demande d’exemption, étant de toute façon contraint à la fallback option.

C’est sans doute cette option qu’un certain nombre d’établissements de petite et moyenne taille choisiront dans une approche de sécurité pragmatique et dans un souci d’économie.

Si cette conclusion se fait jour à quelques mois du 14 septembre, le choix de web-scraping avec TPP authentifié reste en accord avec les termes du RÈGLEMENT DÉLÉGUÉ (UE) 2018/389.

Il nous parait donc important de partager ce qui reste à éclairer pour ce mécanisme d’urgence, c’est à dire les modalités d’authentification pour le TPP sur le web-banking utilisé par les clients.

Les ASPSP qui seraient contraints au 14 septembre 2019 d’opter pour ce mécanisme d’urgence, avant de mettre en œuvre (ou non) une interface dédié API, sont fondés à restreindre les droits des TPP selon leur rôle et agrément.

Avant d’autoriser l’accès d’un TPP aux comptes d’un client, l’ASPSP doit vérifier l’agrément sur la liste publique européenne de l’EBA, identifier le client concerné et vérifier son consentement par une SCA (les règles d’exemption de SCA peuvent s’appliquer les fois suivantes), puis générer un token unique pour la session au TPP.

Cela implique notamment de suivre en local les connexions des TPP et d’archiver les consentements clients autorisés. Selon les technologies de web-banking utilisées, il y a potentiellement la contrainte de mettre en place une URL ou des modalités d’accès spécifiques aux TPP.

En Conclusion, le recours au mode « fallback » apparaît plus une modalité de bon sens qu’une simple option. Sa mise en œuvre nécessite une distinction des modes d’accès et des contrôles indispensables (identification du TPP, vérification de son agrément), et représente une quantité non négligeable de développements, concomitamment à l’obligation de l’authentification forte de l’utilisateur à compter du 14 septembre 2019.

Si la cible d’une généralisation des APIs reste pertinente et la nécessité d’une échéance partagée évidente, il n’en reste pas moins 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.