DSP2 : quels points restent à définir pour le futur standard ?

Les RTS (standards techniques) de la directive européenne des moyens de paiement édictés par l’Autorité Bancaire Européenne (EBA) ont été publiés au Journal Officiel en mars 2018. Ils indiquent qu’à partir de septembre 2019, les banques devront proposer a minima une interface sécurisée d’accès aux comptes bancaires. Pourtant, les détails de déploiement et de fonctionnement des APIs par les ASPSP (Account Servicing Payment Service Providers, principalement les banques) restent encore bien floues.

En France, le Comité national des paiements scripturaux (CNPS) a décidé le 25 mai dernier 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”. Autrement dit, l’élaboration d’une interface de place standardisée afin que les TPPs (Third Party Payment Services Providers) puissent accéder aux données bancaires et à l’initiation de virements.

Les travaux s’inscrivent dans la lignée de la publication par la STET l’an dernier d’un premier document décrivant les APIs à mettre en place, mais qui restait encore incomplet sur de nombreux sujets et qui avait été élaboré sous l’impulsion de la Fédération bancaire française (FBF). Le CNPS réunit un groupe de travail composé des banques et des TPPs (agrégateurs, initiateurs de paiements). “Nous avons listé une dizaine de points sur lesquels il est nécessaire de se mettre d’accord pour que les banques puissent travailler sur le déploiement, et nous en avons déjà résolu une grande partie”, indique Alexandre Stervinou, chef de service de surveillance des moyens de paiement à la Banque de France (qui préside le CNPS).

Les banques veulent décrocher l’exemption

Un avancement remis en cause par Joan Burkovic, CEO du PFM (agrégateur et application de gestion des finances personnelles) Bankin’ : “la France souhaite trancher certains points et cela coupe toute discussion alors même que ces décisions auront des conséquences majeures sur le marché si elles sont appliquées et que les débats sont encore en cours au niveau européen.” Joan Burkovic participe en effet au API Evaluation Group, groupe de discussions animé par la Commission européenne pour déterminer un standard d’API en accord avec tous les acteurs du marché.

Les banques souhaitent être prêtes pour la date réglementaire de déploiement, en septembre 2019. Pour rappel, les ASPSPs (banques) n’ont pas d’obligation de proposer une API, mais si elles proposent une API de bonne qualité (reconnue comme telle par le régulateur), alors les TPPs auront l’obligation de passer par ce biais plutôt que par l’accès direct. Dans le cas contraire, les banques devront proposer une solution de repli (“fallback mechanism”) et permettre aux TPPs de s’identifier directement sur l’interface client classique en renseignant leur clé d’authentification (“accès direct”, une forme de “web scraping” authentifié).

“Certaines banques veulent que les détails des APIs soient rapidement tranchés pour être exemptées dès septembre et ne pas développer l’accès direct”, déplore Joan Burkovic. “Mais développer de bonnes APIs va prendre du temps ! Il faut éviter que des APIs soient poussées prématurément alors qu’elles pourraient porter un risque sur le marché si elles discriminent les TPPs. Il vaut mieux commencer avec l’accès direct puis exempter les APIs petit à petit en fonction de leur qualité et des taux d’adoption.” Car pour définir ce que sera considéré comme une API de qualité, plusieurs questions subsistent.

Quel parcours d’authentification ?

L’une des principales est celle du mode d’authentification de l’utilisateur du TPP, indique Alexandre Stervinou.  Se pose donc la question de quel PSP (le TPP ou la banque) gère l’authentification forte et dans quel cas. Trois parcours sont envisagés, notamment décrits dans les documents de la STET. Pour le premier, baptisé “redirect”, l’utilisateur du TPP (un agrégateur, par exemple) est redirigé sur le site ou l’application de sa banque pour s’authentifier. Avec la seconde option, baptisée “embedded” ou “embarquée”, l’utilisateur reste sur l’interface de l’acteur tiers pour s’authentifier auprès de sa banque. Enfin, dans le mode “découplé”, l’authentification passe en partie par un acteur tiers (ce mode est notamment envisagé dans les pays disposant d’un outil de KYC national). L’application de la banque ou bien une application tierce est “réveillée” en arrière-plan pour l’authentification et le parcours du TPP est mis en stand-by tant que l’utilisateur n’est pas allé valider l’authentification.

Le choix du parcours est primordial. “Cet élément technique peut avoir une conséquence sur la manière dont le client perçoit l’expérience, analyse Alexandre Stervinou. Le “redirect” rend plus dépendant à la banque, alors qu’avec “l’embedded”, on perçoit davantage le tiers.”

Pour la start-up Transaction Connect, qui agrège les données bancaires pour créer des programmes de fidélité et qui a demandé le statut d’AISP et non de PISP (initiateur de paiement), peu importe si le parcours est réalisé sur l’écran de la banque ou celui de la start-up. “Notre critère est celui de la simplicité pour le client”, assène ainsi Pierre-Louis Durel, directeur des opérations.

Mais d’autres TPPs défendent plutôt le processus embarqué, à l’image de Bankin. “Il ne faut pas oublier l’objectif énoncé par la Commission Européenne, c’est à dire qu’il n’y ait pas de régression de service pour les acteurs tiers, argue Joan Burkovic. Il est par définition quasiment impossible qu’une API ne proposant que la redirection soit exemptée [de la solution de repli d’accès direct] puisque cela crée des étapes supplémentaires par rapport à un service “embedded”. Une redirection exproprie une partie de l’expérience utilisateur du TPP chez la banque, alors que toute la proposition de valeur des TPP réside justement dans l’UX.”

Stockage des identifiants et mots de passe

Se pose aussi la question technique du stockage des “credentials”, identifiants et mots de passe. Les TPPs ne veulent pas devoir redemander au client son identifiant complet à chaque authentification. Mais dans ce cas, la question du stockage de ces données entre en jeu. “Dans le cadre de la DSP2, même si une opération est initiée par l’intermédiaire d’un TPP, le client se retournera vers sa banque en cas de fraude puisqu’il n’y a pas de transfert de responsabilité, rappelle Marc Giordanengo, manager au sein du cabinet Ailancy. Les banques sont donc plutôt favorables à l’idée de conserver la gestion des “credentials”. Dans ce cas, il faut trouver des méthodes d’authentification pour permettre la gestion de consentement partagée sans que les identifiants ne soient stockés par les TPPs.”

Cette option est celle privilégiée par Transaction Connect, qui devra mettre en place un parcours d’authentification forte lors de la souscription du client puis réitérer l’opération tous les 90 jours, comme le réclame la DSP2. “Nous aimerions qu’à la première authentification un token soit échangé entre la banque et le TPP, comme cela a été prévu pour l’initiation de paiement, décrit Pierre-Louis Durel. Nous pourrions le retransmettre à la banque à chaque réauthentification pour éviter le stockage ou la ressaisie par le client de son identifiant, et un token est plus sécurisé.”

Mais cette solution nécessiterait davantage de développements techniques de la part des banques… et elle n’est pas forcément privilégiée par les acteurs qui agrègent aussi les comptes d’épargne, qui ne sont pas concernés par la DSP2. Conserver les identifiants leur permettrait de les utiliser à d’autres fins, comme accéder à ces comptes. “Tant que les APIs ne couvriront pas tous les comptes, les AIS stockeront les identifiants puisque cela restera le seul moyen de connecter les comptes d’épargne et de crédits, résume Joan Burkovic. D’ailleurs, toutes les banques qui proposent un agrégateur le feront aussi si elles proposent ce service…” Et la question de l’étendue des données personnelles contenues dans l’API (nom, prénom, date de naissance…) se pose également dans le cadre de la lutte contre la fraude.

Étendue des données transmises

De la même façon, pour les parcours d’exemption, c’est à dire ceux pour lesquels les clients n’auront pas besoin de s’authentifier de façon forte en raison du risque faible (en deçà d’un certain montant, lors d’une succession de paiements…), les acteurs vont devoir trouver un moyen pour que lors de l’appel d’API, la banque reconnaisse le client et réalise qu’il n’y a pas besoin d’authentification forte puisqu’elle a déjà été réalisée. Pour cela, une tokenisation sera probablement nécessaire lors de la première authentification.

Fréquence de connexion

Les acteurs de la place doivent par ailleurs se mettre d’accord sur la fréquence de connexion aux APIs. La réglementation prévoit que le TPP peut synchroniser les données quatre fois par jour, mais les agrégateurs souhaitent pouvoir appeler l’API dès que le client se connecte sur l’application – un besoin d’autant plus fort que l’instantanéité des opérations fait son entrée sur le marché. Encore faudra-t-il pouvoir différencier un appel automatique d’API d’un appel lié à l’ouverture de l’application par l’utilisateur… Les TPPs poussent donc pour un accès illimité à l’API, dans une optique de non-discrimination, tandis que les banques résistent en invoquant des questions d’infrastructure.

Accès à la liste des bénéficiaires et virements programmés

Le périmètre qui sera couvert par les APIs et les cas d’usage associés font également débat. Les PISPs, qui auront la possibilité d’initier des virements, réclament par exemple l’accès à la liste des bénéficiaires de virements. La DSP2 étant basée sur un prérequis d’équité entre l’interface de la banque et des TPPs, les clients doivent pouvoir réaliser les mêmes opérations sur leurs comptes de paiement quelle que soit l’interface. Dans le cadre des virements, le client réalise une authentification forte sur le site de la banque pour ajouter un nouveau bénéficiaire, mais il n’en a plus besoin pour les virements suivants. Se pose donc la question pour les agrégateurs : pour atteindre l’équité, les TPPs devraient avoir accès aux bénéficiaires enregistrés afin d’exempter le client de renseigner de nouveau l’IBAN et de réaliser une authentification forte si le bénéficiaire est déjà connu. Mais “le texte indique simplement que les PSPs peuvent modifier la liste des bénéficiaires, donc tout dépend de l’interprétation…”, résume Joan Burkovic, de Bankin.

Autre sujet de discussion crucial pour les agrégateurs : la possibilité de programmer des virements et de réaliser des virements groupés sera-t-elle intégrée dans les APIs ? “Les questions portent plus sur les logiques métiers que sur l’API qui n’est que le point d’accès, confirme Bruno Cambounet, digital product marketing director chez Sopra Banking. On ne s’intéresse souvent qu’aux fonctions élémentaires, comme “initier un paiement”, sans les positionner dans les cas d’usage des clients finaux.”

Stratégie européenne

 “Des annonces seront faites d’ici la fin de l’année, conjointement avec les acteurs du marché, assure Alexandre Stervinou, de la Banque de France. Une stratégie nationale verra alors le jour.” Le CNPS s’est par ailleurs rapproché du Berlin Group pour faire converger les standards en cours d’élaboration. “Nous avons activement soutenu la STET dans son rapprochement auprès du Berlin Group car nous ne voulons pas d’une solution franco-française et d’une fragmentation en Europe sur ce sujet structurant, confirme Alexandre Stervinou. Depuis quelques mois, une convergence est dans les faits engagée.” Mais, souligne Joan Burkovic, “prendre des décisions sur le standard d’API avant les conclusion de l’API Evaluation Group est risqué”.

Outre le standard élaboré en France et celui du Berlin Group, qui se veut paneuropéen, il faut aussi compter sur le standard Open Banking, élaboré au Royaume-Uni, sur celui de la Polish Bank Association en Pologne et sur une initiative de place en Slovaquie. Certaines banques, positionnées comme précurseuses sur l’open banking, sont même en train de créer leur propre standard et veulent en faire un critère de différenciation, comme ING et BBVA.