La DSP 2 institue deux nouveaux statuts de prestataires de paiement (AISP et
L’un des points majeurs du RTS concerne la sécurité de l’accès au compte. Il introduit l’obligation pour les nouveaux acteurs de s’authentifier vis-à-vis des banques lorsqu’ils accèdent aux comptes des clients qui leur en ont donné le mandat. Jusqu’ici, avec la technique du web scraping, ce n’était pas le cas. C’est un certificat eIDAS qui permettra à un acteur tiers d’être officiellement reconnu par le teneur de compte, en transmettant son nom, son numéro d’agrément et le nom de l’autorité compétente que le lui a délivré.
Le RTS met-il fin au web scraping ?
Le RTS reste technologiquement neutre. Il laisse le choix au teneur de compte entre :
- développer une interface dédiée (par exemple une API) par laquelle il contrôle les données mise à disposition,
- ou construire un chemin d’accès à son univers de banque en ligne, sous réserve que celui-ci soit capable de reconnaître le certificat du tiers qui souhaite se connecter.
Les exigences autour de l’API ont soulevé de nombreux débats au moment de la rédaction du RTS. La version finale diffère-t-elle de la proposition faite par l’EBA en février 2017 ?
La philosophie reste la même : une authentification du tiers de paiement et le choix pour l’ASPSP de proposer une interface dédiée ou un accès direct au site de banque en ligne. Mais des éléments ont été ajoutés pour renforcer l’assurance, pour les nouveaux acteurs, de pouvoir accéder à des API de qualité ne créant pas d’obstacles à l’exercice de leurs activités. Ainsi, de nouvelles exigences sont apparues pour obliger la publication par chaque ASPSP d’indicateurs de performance et de disponibilité de son API et de son site de banque en ligne, afin que les autorités compétentes puissent facilement vérifier que les deux interfaces fonctionnent dans des conditions équivalentes.
Les ASPSP et les AISP et PISP sont par ailleurs désormais obligés de déclarer tout incident de fonctionnement de l’API auprès des autorités compétentes.
Des requis ont enfin été ajoutés afin d’obliger les ASPSP ayant déployé une API à mettre en place une solution d’accès de secours via son site de banque en ligne en cas d’indisponibilité de cette dernière. Cette obligation peut néanmoins être levée par les autorités compétentes, sous réserve que ces dernières vérifient que ces API fonctionnent conformément aux critères prévus par les RTS.
Le débat s’est en effet porté sur la question de la solution de secours : quel a été le raisonnement sous-jacent ?
Le débat était effectivement de savoir s’il fallait forcer l’ASPSP à maintenir les deux options disponibles. Le régulateur considère que, puisque c’est lui qui supporte les coûts de développement de ces outils, c’est à lui de choisir. Si on le force à donner l’accès au site de banque en ligne, il aura moins d’incitation à développer une API, qui représente des coûts supplémentaires. Or les API offrent des avantages, notamment en termes de traçabilité des accès. Il s’agit donc de ne pas tuer le modèle de l’interface dédiée. La Commission, de son côté, voulait donner davantage de réassurance aux tiers de paiement que les API développées seraient fonctionnelles et leur permettraient de travailler. Elle a donc ajouté l’obligation pour les ASPSP d’avoir une solution de secours via le site de banque en ligne, sauf si l’autorité compétente les en exempte. Cette exemption est accordée si, à l’issue d’une période de test de 6 mois, l’autorité juge que l’API mise à disposition est suffisamment performante.
Comment cela va-t-il se passer en France ?
C’est l’ACPR qui accordera cette exemption, en s’appuyant sur la Banque de France pour les aspects sécuritaires. La procédure opérationnelle n’est pas encore définie, le RTS n’étant pas explicite sur le sujet. Il est en tout cas important qu’elle soit harmonisée au niveau européen, pour assurer une égalité de traitement entre les différents acteurs. L’EBA va publier une communication en la matière. Par ailleurs, un groupe de travail (l’API Evaluation Group) a été mis en place au niveau européen pour faire en sorte que les différents acteurs s’entendent dès maintenant sur les caractéristiques standards des API. Au niveau français, il y a aussi un groupe de travail sur le sujet au sein du
Comment cela s’articule-t-il avec le projet de standard d’API élaboré par STET pour les banques françaises ?
L’ACPR validera les API de chaque établissement, pas le standard. Il s’agira de regarder comment le standard a été mis en œuvre dans le système d’information de chaque ASPSP et quelle est sa performance. Le groupe de travail du CNPS a pour objectif de mettre les parties prenantes autour de la table, de sorte à identifier en amont les obstacles que les nouveaux tiers de paiement peuvent relever dans la proposition faite par STET et, le cas échéant à demander au régulateur de se positionner. Ce dialogue préalable vise à lever ces blocages en amont, plutôt qu’au moment de la validation des API.
Quel est le calendrier de ces travaux ?
Le RTS entrera en vigueur en septembre 2019. Pour qu’une API soit fonctionnelle à cette date et que le teneur de compte n’ait donc pas à développer de solution de secours, il faut qu’auparavant, nous la validions. Le RTS n’a pas donné de délai pour cette validation mais précise que l’EBA doit être consultée. Le process pourrait prendre environ deux mois. Avant cette étape, le marché doit tester l’API pendant six mois dont trois dans des conditions de production. Le rétroplanning plaide pour que les API soient mises à disposition début 2019 et au plus tard en mars 2019. Un amendement de l’Assemblée nationale dans le cadre des discussions sur la transposition de la DSP
Parmi les sujets en discussion autour de l’API, il y a la question de la redirection de l’internaute qui souhaite utiliser le service d’un agrégateur ou d’un initiateur de paiement vers le site du teneur de compte. Les nouveaux acteurs s’inquiètent d’un alourdissement de l’expérience client. Cette redirection est-elle autorisée ou interdite par le RTS ?
Le RTS identifie la redirection comme un obstacle possible à l’utilisation des nouveaux services. C’est un sujet complexe pour les régulateurs car il relève d’enjeux de concurrence qui ne le concernent généralement pas. Cela fait partie des sujets qui sont en cours de discussion entre les différentes parties prenantes et devraient faire l’objet de clarification de la part de l’EBA.
Que dit le RTS sur le stockage des identifiants du client final ?
Le standard technique est clair sur ce sujet : l’AISP peut stocker les identifiants qui lui permettent de fournir son service d’agrégation, mais pas le PISP pour l’initiation de paiement. Le cas des acteurs qui ont le double agrément – comme c’est le cas en
Pourquoi le standard technique réglementaire n’est-il pas plus précis ?
Le RTS n’a jamais été conçu comme un cahier des charges pour les API. Il définit le cadre dans lequel les différents acteurs devront développer des solutions techniques. Mais c’est bien à ces derniers de trouver ces solutions.
Comment l’établissement teneur de comptes saura-t-il si un acteur tiers est agréé ?
La directive prévoit qu’un registre des AISP et PISP soit tenu à l’échelle européenne et mis à jour en cas de retrait d’agrément. L’EBA le mettra en place début 2019. À ce stade, chaque autorité tient son propre registre. L’ACPR entre ainsi dans le Regafi les établissements qu’elle a agréés mais aussi ceux qui utilisent le passeport européen pour accéder au marché français. À noter toutefois que la notion de passeport appliquée à l’agrégation et à l’initiation de paiement porte sur la possibilité de commercialiser des produits en dehors de son pays d’origine. En revanche, tout acteur agréé dans un État membre, même sans passeport, peut accéder aux comptes que ses clients pourraient avoir dans des banques étrangères.
Les AISP et PISP agréés peuvent-ils proposer leurs services à d’autres acteurs ?
Bien entendu, et c’est d’ailleurs le cas des acteurs agréés en France. À ce titre, les modalités de coopération entre les acteurs peuvent être diverses. Si l’acteur agréé noue un partenariat de type co-branding avec une autre entité pour fournir un service lié à l’utilisation de données bancaires, il reste l’interlocuteur des utilisateurs finaux pour le service d’agrégation et l’acteur partenaire n’a pas besoin d’agrément en tant qu’AISP. En revanche, s’il propose son service en marque blanche – par exemple, l’intégration d’une solution d’agrégation de comptes de manière transparente pour l’utilisateur final –, il se trouvera dans un cas de prestation de service essentiel et son partenaire aura besoin d’un agrément en tant qu’AISP et donc d’une assurance responsabilité professionnelle pour fournir ce service. Si ce client est une banque – cas qui se rencontre en France – son statut d’établissement de crédit est bien entendu suffisant. Certaines banques ont par ailleurs déjà développé leur propre service d’agrégation, sans avoir, là non plus, besoin d’un agrément particulier.
Les dispositions de la DSP 2 concernent les comptes de paiement. Qu’en est-il des autres, comme les comptes d’épargne ?
Aucune réglementation n’interdit aujourd’hui qu’un acteur tiers accède à ces autres comptes via du web scraping. Nous sommes toutefois en faveur d’une sécurisation de cet accès, dans la logique de ce qui est fait pour les comptes de paiement. Nous estimons que ce sujet devra être traité au niveau européen. Pour l’instant, l’heure est à la mise en place de la DSP 2.
