Web scraping : l’EBA fait une contre-offre à la Commission

Les désaccords qui empoisonnent la mise en œuvre de la DSP 2 au niveau des acteurs privés se retrouvent en miroir dans les débats entre les autorités régulatrices européennes. Alors que la directive doit entrer en vigueur en janvier 2018, certains standards techniques centraux sont encore en cours de discussion. Plus précisément, la pomme de discorde se situe au niveau du RTS sur l’authentification et la communication entre les ASPSP [1] (les banques qui tiennent les comptes courants des clients) et les AISP [2] et PISP [3] (les nouveaux tiers de paiement qui ont besoin d’y accéder pour agréger les comptes ou initier des virements). Critiqué depuis ses débuts, ce RTS a déjà fait l’objet d’une consultation à l’automne 2016 qui a recueilli environ 150 réponses, d’une proposition officielle en février 2017 et d’une réponse critique de la Commission en mai. C’est au tour de l’EBA de réagir.

Pour l’EBA, le web scraping n’est pas la solution

La Commission voulait que le web scraping [4] ne soit pas totalement interdit, mais puisse perdurer en cas de défaillance de l’interface dédiée mise à disposition par la banque (API [5] ). Une demande poussée par les tiers de paiements qui redoutent que les banques ne jouent pas le jeu et ne produisent pas des interfaces performantes, afin de se protéger de la concurrence. Dans sa réponse du 29 juin, l’EBA réaffirme sa volonté d’interdire le web scraping – ce que souhaitent les banques – et justifie son opinion. Ainsi, le maintien de l’option du web scraping nécessiterait de mettre à niveau les interfaces dédiées aux clients pour qu’elles répondent aux exigences de sécurité de la DSP 2, ce qui serait coûteux pour les ASPSP mais aussi pour les tiers de paiement qui devraient être en mesure de se connecter à la fois aux API mais aussi aux espaces clients de toutes les banques. Et l’EBA de souligner l’avantage comparatif que cela conférerait aux agrégateurs et initiateurs de paiement existants par rapport à de nouveaux entrants. L’autorité bancaire doute même de sa faisabilité technique, étant donné le délai court d’indisponibilité de l’API retenu par la Commission pour autoriser la bascule sur le web scraping (30 secondes). L’EBA pointe enfin le risque de perte de lisibilité du dispositif pour le client final, lorsqu’il donne son consentement pour l’utilisation de ses données financières. « Le RTS proposé avait dû trouver un équilibre entre des objectifs antagonistes de la DSP 2, parmi lesquels le renforcement de la sécurité, la promotion de la concurrence, la neutralité vis-à-vis des technologies et des business models retenus, la contribution à la mise en place d’un espace intégré des paiements européens, la protection des consommateurs, le soutien de l’innovation et l’amélioration du confort d’utilisation pour les clients », a rappelé l’EBA en préambule, allant jusqu’à souligner que les amendements proposés par la Commission allaient au-delà de son mandat quant à ce RTS.

Des API en test trois mois avant

L’autorité dit toutefois comprendre les inquiétudes des tiers de paiements vis-à-vis des API que mettront en place les banques et propose des mesures supplémentaires :

• la définition d’indicateurs de performance clés par les ASPSP que l’API devrait satisfaire avec le même niveau d’exigence que l’interface client ;
• la publication de rapports de performance trimestriels par les AISP et les PISP ;
• la mise à disposition de l’API par l’ASPSP à des fins de test au moins trois mois avant l’entrée en vigueur du RTS ;
• une revue de ces dispositifs 18 mois après.

L’EBA suggère enfin à la Commission d’être plus explicite sur les données auxquelles les tiers de paiement peuvent accéder pour exercer leur activité, et ce dans un souci de clarifier des relations entre ces deux groupes d’acteurs… et de tenter d’apaiser les tensions.