DSP2, une période de transition nécessaire

Alors que l'échéance du 14 septembre se rapproche et que l'urgence du calendrier réglementaire se fait de plus en plus ressentir, une période de transition supplémentaire apparaît primordiale pour accompagner sereinement cette transition vers l'ère de l'open banking.

La mise en application de la deuxième directive européenne sur les services de paiement (dite DSP2), en vigueur dans l'Union Européenne depuis le 13 janvier 2018 doit respecter un timing très serré sur la mise à disposition des API par les prestataires de services de paiement gestionnaire de compte (ASPSP).

Surtout pour les ASPSP français qui souhaitent mettre en place une API sans mécanisme de secours. Ils devront respecter le calendrier suivant :

· 14/01: date recommandée par l’ACPR pour la mise à disposition par les ASPSP de la documentation liée aux API, et d’un dispositif d’essai, laissant un délai de trois mois pour atteindre les conditions d’une utilisation étendue

· 14/03 : date limite fixée par les RTS pour la mise à disposition de la documentation et de l’environnement de test de l’API. Néanmoins, l’ASPSP devra démontrer que la mise à disposition de cet environnement à cette date a bien permis aux PSP tiers de se connecter à l’API et l’utiliser dans des conditions étendues à compter du 14/04

· 14/04: date limite de mise à disposition d’une API répondant aux conditions d’utilisation étendue (le dossier déposé à l’ACPR ne peut sinon pas être considéré comme complet).

· 14/07: date limite de dépôt d’un dossier complet pour assurer un retour de l’ACPR d’ici au 14/09. La procédure peut prendre jusqu’à deux mois.

· 14/09: date limite d’obtention d’une exemption pour les ASPSP ayant décidé la mise en œuvre d’une API.  

Près de 50 % des banques n'ont pas respecté l’exigence qui leur laissait jusqu'au 14 mars pour mettre leur portail de sandbox à disposition et beaucoup plus encore n’ont pas réussi à tenir l'échéance du 14 avril pour mettre à disposition des API de production !

Un chantier complexe pour les ASPSP mais aussi pour les TPP !

En plus de ce timing très serré, la difficulté d’implémentation est importante pour les différentes parties prenantes. Si exposer des API est un chantier considérable pour les ASPSP et demande un investissement très important, c’est également la cas pour les TPP.

Connecter une API n’est pas si simple et implique des sujets transverses complexes relatifs notamment à l’authentification par certificat eIDAS (QWAC et QSealC). D’une manière générale, les TPP doivent revoir en profondeur leur façon de récupérer les données et gérer des "connecteurs à 2 têtes" avec l’accès via API d’un côté pour les comptes de paiement et l’accès direct (screen scraping) d’un autre côté pour les autres comptes.

Alors que nous devions gérer, jusqu’à présent, une seule méthode d’accès (screen scraping), nous devrons gérer à partir de septembre 3 méthodes différentes : accès direct (pour les "autres comptes"), API et mécanisme d’urgence (accès banque en ligne avec authentification).

Bref, la DSP2 pour les TPP ne se résume pas à connecter des APIs mais c’est une refonte importante de leur infrastructure interne et des problématiques techniques supplémentaires. La barrière technique, que certains pensaient levée avec les APIs, restera et se verra même renforcée.

L’exemple OBUK

Le retour d'expérience du Royaume-Uni est riche d’enseignements et montre que le passage vers les API est un chantier à mener d’une façon incrémentale. Prétendre qu’à partir du 14 septembre, les TPP seront connectés à tous les ASPSP via API pour les comptes de paiement et auront cessé l’accès direct parce que tout fonctionnera parfaitement est totalement illusoire. Spoiler : nous ne couperons pas l’accès en screen scraping le 15 septembre 2019.

Les représentants de FData (Financial Data and Technology Association) et d’Open Banking UK ont, lors de leurs différents passages à Paris, insisté sur le fait que la transition vers les API est compliqué, long et doit s’appuyer sur une importante phase d’apprentissage.

Alors que le chantier de l’open banking est beaucoup plus mature au Royaume-Uni, les taux de disponibilité des API constatés à fin 2018 restaient décevants et oscillaient entre 96,3 % et 97,7 % (au mieux). Insuffisant si on les compare aux taux de disponibilité des espaces BEL (banque en ligne) souvent supérieurs à 99%. De plus, le nombre d’appels API en échec restaient relativement élevés. 

Nous pouvons toujours espérer que les API de nos banques françaises seront de meilleure qualité alors même que le chantier est lancé depuis moins de temps que celui d’OBUK et que les moyens investis en termes de suivi, de remontée d’informations et de coordination TPP-ASPSP semblent bien inférieurs (pas de portail commun d’exposition des API, pas de portail de remontée d’informations (bugs, corrections…), pas de protocole de tests commun, un groupe de travail sur l’implémentation des API  lancé par les TPP mais déserté par nombreuses banques …).

Période de transition et bienveillance des régulateurs

Dans ce contexte, il nous semble indispensable de prolonger la période de transition qui doit s’achever en septembre 2019 et nous alertons régulièrement les instances nationales à ce sujet. Soyons réalistes et ne laissons pas l’urgence du calendrier réglementaire perturber la mise en place de ces interfaces devant révolutionner à long terme l’écosystème bancaire et financier.

L’argument trop répandu consistant à dire qu’il faut mettre en place ces APIs le plus rapidement possible pour mettre un terme au screen scraping ne tient pas puisque cette méthode sera de toute façon maintenue pour les autres comptes mais aussi pour récupérer les données des nombreuses banques n’ayant pas mis en œuvre d’interface dédiée. 

La transition vers les API se fera mais restons prudents et reconnaissons le fait qu’une période de transition supplémentaire sera nécessaire et que la bienveillance des régulateurs à la fois pour les ASPSP et les TPP sera une des conditions de la réussite de cette transition.