DSP2 : les agrégateurs tentent de négocier un accord de marché

La seconde directive européenne sur les moyens de paiement (DSP2) est entrée en vigueur en janvier 2018, il y a un an, et les RTS (standards techniques) édictés par l’Autorité Bancaire Européenne (EBA) ont été publiés au Journal Officiel en mars 2018. Mais ces textes ne décrivent pas précisément les standards et parcours utilisateurs des APIs devant être mises en place par les banques (Account Servicing Payment Service Providers, ASPSPs) pour donner accès aux données de paiement de leurs clients à des acteurs tiers (Third Party Payment Services Providers, TPPs). Dans ce contexte, des discussions se sont tenues dans chaque pays de l’Union Européenne pour les déterminer de manière plus précise.

En France, le Comité national des paiements scripturaux (CNPS) a décidé le 25 mai 2018 de lancer des travaux pour “la mise en œuvre à brève échéance d’une interface d’accès aux comptes de paiement harmonisée au niveau de la place française, répondant aux exigences de la DSP2”, le standard étant géré par la STET. Puis il a publié en novembre un communiqué se félicitant “des avancées récentes des travaux” ayant permis “l’émergence d’un consensus entre les acteurs de la place, qui tient lieu d’exemple au niveau européen”. Un communiqué qui fait grincer des dents chez les agrégateurs, loin d’être satisfaits de la tournure prise par les discussions.

“Redirect” et authentification forte tous les 90 jours

Trois parcours ont été envisagés pour le mode d’authentification de l’utilisateur du TPP : “redirect” (l’utilisateur du TPP est redirigé sur le site ou l’application de sa banque pour s’authentifier), “embedded” ou “embarqué” (l’utilisateur reste sur l’interface de l’acteur tiers pour s’authentifier auprès de sa banque) ou “découplé” (l’authentification passe en partie par un acteur tiers). C’est finalement le mode “redirect”, plébiscité par les banques, qui sera privilégié. “Nous estimons que cela sera une entrave à certain cas d’usage et que cela ne sera pas suffisamment fluide”, regrette Bertrand Jeannet, directeur risques et conformité chez Budget Insight.

Surtout, l’EBA s’est prononcée en faveur d’une réauthentification tous les 90 jours sur l’espace de la banque. Une disposition qui pourrait s’avérer catastrophique pour les agrégateurs : le client devrait systématiquement se reconnecter sur chacun de ses espaces bancaires pour redonner son accord. “Nous voudrions trouver un moyen pour que la réauthentification des 90 jours soit déléguée auprès du TPP puis diffusée aux banques, mais ce n’est pas facile techniquement et c’est hors du cadre géré par la STET, explique Bertrand Jeannet. Nous sommes en train d’étudier des solutions techniques (comme FIDO par exemple) nous permettant de gérer ce renouvellement du consentement.”

Bruno Van Haetsdaele, CEO de Linxo, lui aussi, argumente pour une authentification forte chez le TPP et une diffusion la de preuve auprès des banques. “La Commission européenne reste bienveillante à notre égard sur ce point”, ajoute-t-il, précisant espérer une révision des RTS.

A l’étranger, d’autres modèles se dessinent. Transaction Connect (qui développe des programmes de fidélité basés sur les données de paiement) teste par exemple l’API du groupe danois Nordea avec son partenaire d’agrégation Budget Insight et trouve son processus d’authentification forte intéressant : “l’utilisateur sélectionne sa banque sur notre interface et saisit son identifiant, décrit Pierre-Louis Durel, COO. Cela réveille l’application de la banque où il saisit simplement son code., mettant notre parcours en stand-by seulement pendant ce temps.”

Ajout de bénéficiaire de virement

Autre déconvenue pour les TPPs : dans une réponse publiée en octobre dernier, l’EBA a décrété que les APIs ne devaient pas permettre aux TPPs d’accéder aux listes de bénéficiaires de virement en mode “écriture”. Les utilisateurs devront donc systématiquement aller sur leur espace bancaire pour ajouter un nouveau bénéficiaire. Ironie du sort : la norme STET avait prévu dans un premier temps de permettre l’ajout de bénéficiaires. “Cela met en danger de multiples cas d’usage liés l’initiation de paiement”, déplore Bertrand Jeannet. Les virements de compte à compte ou bien le paiement à un commerçant, par exemple.

Mince victoire des TPPs : alors que certaines banques refusaient de transmettre l’IBAN du client, la Banque de France a confirmé que l’IBAN n’était pas une donnée sensible dans le rapport 2017 de l’Observatoire de la Sécurité des Moyens de Paiement. “Si elle est présente sur l’espace en ligne de la banque, alors elle devra bel et bien être présente dans l’API”, commente Bertrand Jeannet. Par ailleurs, les TPPs pourront bel et bien se connecter, en plus des quatre fois par jour prévues dans le texte de loi, à chaque fois que l’utilisateur le demande.

Groupe de travail initié par les agrégateurs

Face à ces multiples déconvenues, Bankin’, Budget Insight et Linxo tentent une nouvelle stratégie : la création d’un nouveau groupe de travail, décorrélé du standard STET et du réglementaire. Une première rencontre devrait avoir lieu début février, mais plusieurs banques auraient refusé d’y participé. “Nous souhaitons réfléchir non pas sous l’angle réglementaire mais sous l’angle innovant souhaité au départ par la DSP2, indique Bertrand Jeannet, de Budget Insight. Nous pourrons discuter du meilleur moyen de gérer l’authentification forte, par exemple”.

“Nous allons probablement avoir un périmètre réglementaire strict minimaliste puis, en bilatéral, les agrégateurs et banques pourront signer des contrats permettant d’en faire plus”, souligne Bruno van Haetsdaele. “Avec la DSP2, il n’y a pas de contrat entre la banque et l’acteur tiers, c’est l’agrément qui donne le droit d’accès à l’API, et cela met les banques sur la défensive.” Car si les acteurs tiers sont aujourd’hui des start-up, ils pourront être Google, Facebook ou Amazon demain. “Les banques pourraient donc être prêtes à partager plus, mais pas avec tout le monde.” Les trois agrégateurs du marché souhaitent cependant être traités équitablement, pour que les règles ne discriminent pas l’un d’entre eux.

Le web scraping survivra à septembre 2019

La DSP2 offre un délai de transition jusqu’à septembre 2019 pour la mise en conformité. Bankin’, Budget Insight et Linxo ont commencé à tester les APIs de certaines grandes banques de détail mais elles sont souvent encore loin d’être prêtes. Certaines commencent à étudier la mise en place du mécanisme de repli (forme de web scraping authentifié sur l’espace bancaire, obligatoire si l’API n’est pas jugée satisfaisante par les autorités). L’ACPR devrait publier sous peu un document précisant les conditions de performance et de fonctionnalité des APIs nécessaires pour bénéficier d’une exemption du mécanisme de repli.

En l’absence d’une API ou d’un mécanisme de repli fonctionnel, les TPPs pourraient continuer à utiliser des techniques de web scraping. Ces dernières demeureront de toute façon pour les comptes d’épargne, qui ne sont pas compris dans le périmètre de la DSP2.