La mise en œuvre complexe de la deuxième Directive sur les services de paiement[1] (fréquemment désignée sous l’acronyme « DSP 2 ») appelait, en raison de la nature éminemment générique des principes qu’elle introduit, des compléments techniques indispensables, matérialisés par une série d’actes d’exécution. Clef de voûte de ce dispositif, le Règlement délégué (UE) n° 2018/389 (ci-après les « RTS » ou Regulatory Technical Standards)[2] traduit, dans la pratique, les concepts d’authentification forte[3] et d’API[4], devenus des instruments incontournables d’une action globale déployée à l’échelle européenne pour endiguer durablement la fraude[5].
L’arsenal réglementaire européen est régulièrement nourri par l’Autorité bancaire européenne (ci-après l’« ABE »), laquelle œuvre efficacement en faveur de la convergence en matière de surveillance des activités bancaires[6]. Sous l’égide de l’ABE, l’élaboration graduelle d’un corpus de règles unifiées a notamment pour corollaire la publication occasionnelle d’avis qui, bien que théoriquement dépourvus de force juridique obligatoire, orientent résolument l’action des autorités étatiques de régulation du secteur bancaire[7]. Ce nouvel avis[8], adopté le 4 juin dernier, s’inscrit globalement dans la lignée de ses prises de position antérieures. Sa singularité réside cependant dans une démarche peu habituelle, empreinte d’originalité : l’avis dénote une prise en considération effective des intérêts des banques. Surtout, l’apport de cet avis consiste, au titre de la définition des obligations applicables à une interface dédiée[9], dans la délimitation du périmètre des entraves éventuelles à l’activité des prestataires de services de paiement tiers (ci-après, les « PSP tiers »)[10]. Les banques, en leur qualité de gestionnaires de comptes, sont en première ligne en tant que garantes de la sécurité du système d’information et verront, par suite, leur responsabilité pleinement engagée en cas de fraude. À ce titre, les indications éclairantes contenues dans cet avis leur sont spécialement adressées, tenant lieu de « grille de lecture » pertinente destinée à orienter utilement leur pratique.
Serait-ce les prémices d’une nouvelle donne favorable aux banques ? Cet infléchissement serait-il le signe d’un changement de paradigme, inscrit dans la durée ? Quoi qu’il en soit, cette inclination nouvelle se manifeste, avec éclat, à trois niveaux. En premier lieu, l’ABE précise que la modalité d’authentification forte[11] fondée sur la redirection – décriée avec virulence par les PSP tiers – ne constitue pas, en soi et en tant que telle, un obstacle à l’activité de ces derniers (I.). L’interprétation que livre l’ABE du principe de non-discrimination est également symptomatique du regard – plutôt bienveillant – porté sur les établissements teneurs de comptes (II.). Finalement, ce pragmatisme se révèle aussi remarquablement dans la démonstration qui est construite autour de la problématique de la délégation de l’authentification forte (III.).
I. La redirection : un obstacle potentiel
Dans son avis, l’ABE recense succinctement les procédures d’authentification à l’usage des banques. On en dénombre essentiellement trois : la redirection ; l’approche dite intégrée ; et le parcours découplé[12]. En vérité, cette modélisation constitue une représentation purement théorique qui, comme telle, comporte certaines limites. La réalité, bigarrée, révèle qu’en pratique, les établissements bancaires montrent une grande propension à combiner plusieurs procédures d’authentification[13] pour en cumuler les avantages avec, en point de mire, un parcours client rendu plus fluide.
Le redirect (ou approche fondée sur la redirection) constitue une méthode d’authentification forte consistant, pour le teneur de compte, à rediriger l’utilisateur vers son interface web aux fins de son authentification. Dans ce cas de figure, la banque maîtrise de bout en bout le processus d’authentification forte. Il appartient, dès lors, au client de prendre l’initiative de s’authentifier en effectuant les démarches en ce sens, ce qui implique nécessairement une intervention de sa part. Du reste, la plupart des banques françaises de la place ont fait le choix de la redirection pour des motifs tenant essentiellement à la simplicité du dispositif. En particulier, la mise en œuvre de cette solution technique dispense le gestionnaire de compte de communiquer au PSP tiers les données personnelles du client. La SCA échappant totalement à l’emprise des prestataires de services de paiement tiers, ces derniers ont fait valoir à l’ABE que cette méthode d’authentification forte constituait un obstacle indu à leur activité.
Sur ce terrain, l’Autorité bancaire européenne défend une position plus nuancée : elle réfute catégoriquement l’argument avancé par les PSP tiers en affirmant, au contraire, qu’un établissement de crédit qui opterait pour la redirection ne serait pas, pour ce seul motif, en porte-à-faux avec la législation en vigueur ; si bien que le dispositif fondé sur le redirect n’est pas, en soi, susceptible de tomber sous le coup d’une sanction[14]. Il peut l’être cependant en fonction des circonstances, surtout de l’application qui en est faite. À l’évidence, un modus operandi qui se répercuterait défavorablement sur l’expérience client en générant complexité et lourdeur en cas de recours aux services d’un PSP tiers appellerait une condamnation exemplaire. Eu égard à une procédure d’authentification rendue plus contraignante sur le parcours API[15] que sur celui de la Banque à distance du client, le constat est sans appel : arme de dissuasion massive, cette pratique tend inévitablement à détourner l’utilisateur de tout penchant éventuel qu’il pourrait nourrir pour les services numériques proposés par un prestataire extérieur à son teneur de comptes habituel. Dans cette configuration, la redirection ne saurait être admise. Cette analyse, construite sur la légalité de principe du redirect, est itérativement reprise par l’ABE pour souligner la force probante de son raisonnement[16].
Il convient de porter au crédit de l’ABE cette consécration de la redirection au titre des modalités licites d’authentification du client. Nonobstant cette reconnaissance indubitable, elle exhorte les autorités nationales compétentes – dont l’ACPR – à faire preuve d’une vigilance extrême à l’égard du parcours client, spécialement dans le cas où la redirection constitue la seule méthode d’authentification sur laquelle s’appuie l’ASPSP[17].
Sur la problématique tenant à la redirection obligatoire au point de vente[18], la logique sous-jacente demeure identique : prenant, une fois n’est pas coutume, le parti des banques, elle prétend que la redirection imposée ne fait obstacle à l’action des prestataires tiers que pour autant qu’elle constitue la seule modalité d’authentification offerte sur le parcours du PSIC/PSIP, alors que, dans le même temps, d’autres solutions techniques – plus ergonomiques – sont mises à la disposition de l’utilisateur via son parcours de banque à distance. Dans ces conditions, la DSP2 ne contraint nullement les teneurs de comptes à devoir privilégier l’approche intégrée[19]. Du reste, cette symétrie recherchée – tel un idéal – entre les parcours client/PSP tiers vient corroborer la lecture proposée par l’ABE dans le cadre de la mise en œuvre du principe de non-discrimination.
II. La non-discrimination interprétée à l’aune du parallélisme entre les parcours client/PSP tiers
Thématique récurrente, traditionnellement développée par l’ABE au fil de ses avis, ce second volet a trait à l’impératif de non-discrimination des PSP tiers. Il convient de préciser, à titre liminaire, que les établissements de crédit gestionnaires de comptes ont toute latitude pour « décider s’ils proposent une interface dédiée à la communication avec les prestataires de services d’information sur les comptes, les prestataires de services d’initiation de paiement et les prestataires de services de paiement qui émettent des instruments de paiement liés à une carte ou s’ils autorisent, pour cette communication, le recours à l’interface servant à l’identification des utilisateurs de services de paiement des prestataires de services de paiement gestionnaires de comptes et à la communication avec ces utilisateurs »[20]. Aussi, en vertu des RTS, la communication avec les prestataires de services de paiement tiers, appréhendés dans toute leur diversité, repose alternativement sur deux canaux distincts : elle s’établit soit via une interface dédiée ad hoc, spécialement créée pour répondre aux spécifications fonctionnelles induites par la DSP 2 et par les actes d’exécution y afférents ; soit cette communication peut avoir lieu en ayant recours à une interface déjà existante, conçue, à l’origine, pour permettre les échanges entre l’établissement teneur de comptes et ses clients. Le premier cas correspond à ce qu’il est convenu d’appeler le « parcours API » tandis que les praticiens se réfèrent volontiers, relativement au second cas, au « parcours utilisateur », comparable au parcours « banque à distance ». Cette simplification extrême, connotée par un tel vocable, ne doit cependant pas occulter la complexité technique du dispositif décrit.
Procédant par analogie, l’ABE rappelle, en substance, que toute rupture d’égalité entre les deux parcours est constitutive d’une discrimination. En somme, la deuxième Directive sur les services de paiement proscrit aux établissements bancaires d’instaurer une différence de traitement entre les PSP tiers et leurs clients. Ce postulat se décline en différentes propositions, examinées tour à tour par l’ABE au gré d’une démonstration circonstanciée.
Par exemple[21], en ce qui concerne l’ouverture aux PSIC/PSIP des interfaces bancaires, les prestataires de services de paiement gestionnaires de comptes (ci-après « PSPGC ») sont tenus de leur concéder l’accès aux procédures d’authentification habituellement accordées aux clients[22]. Bien plus, les méthodes d’authentification forte[23] auxquelles la banque choisit de recourir, en pleine connaissance de cause, pour ses clients devront nécessairement être mises à égale disposition des PSP tiers[24]. En conséquence, dans l’hypothèse où les établissements bancaires ne concéderaient pas aux PSP tiers, au moyen de leurs interfaces, le droit de recourir aux mêmes procédures d’authentification forte que celles qui sont généralement proposées aux clients utilisateurs, la violation de l’article 30, paragraphe 2, des RTS serait valablement constituée[25].
La pratique nous enseigne que les PSPGC sont occasionnellement enclins à procéder à des vérifications portant sur la régularité du consentement donné par les utilisateurs de services de paiement aux prestataires tiers. De tels contrôles – non prescrits par les textes donc superflus – exercés spécifiquement sur le consentement donné par les utilisateurs aux PSIC/PSIP figurent, expressis verbis, au titre des entraves énumérées, de façon purement indicative, par l’article 32, paragraphe 3, des RTS. Par principe prohibés[26], ils ne ressortissent nullement de la compétence de l’établissement teneur de compte, et pour cause : suivant les préconisations de l’ABE[27], seule l’éventualité d’une demande exprimée sans équivoque par l’utilisateur, lequel enjoindrait à son PSPGC de bloquer l’accès à ses comptes de paiement à un ou plusieurs prestataires tiers, paraît légitime. Au surplus, l’ABE fait écho à la DSP 2 en alléguant que les conditions et autres obligations imposées par les banques à leurs clients « ne devraient contenir aucune disposition qui compliquerait d’une quelconque façon l’utilisation des services de paiement d’autres prestataires de services de paiement agréés ou enregistrés […] »[28]. Pour autant, s’agissant du cas particulier des comptes d’entreprises, les clauses contractuelles peuvent valablement stipuler que demeurent seuls habilités à opérer des transactions sur les comptes de paiement visés les utilisateurs bénéficiaires d’une procuration qui, comme tels, seront dûment autorisés et désignés par la société mandante[29]. Faisant sien le principe bien connu de la Directive – quoique présent de manière latente – selon lequel la lutte contre la fraude peut, dans certaines occurrences, justifier le refus d’accès à un compte de paiement, l’ABE met en exergue, de manière éclatante, le bien-fondé de la position des banques. Moyennant le respect scrupuleux de la procédure édictée, le PSPGC est en mesure de dénier, en toute licéité, l’accès à un PSIC/PSIP « pour des raisons objectivement motivées et documentées liées à un accès non autorisé ou frauduleux au compte de paiement de la part dudit prestataire de services d’information sur les comptes ou dudit prestataire de services d’initiation de paiement […] »[30].
III. Déléguer l’authentification forte ? Un choix (stratégique) à la discrétion des banques
Dans le sillage de la DSP 2, les RTS sont venues opportunément compléter le cadre juridique initial – nécessairement lacunaire – par des normes techniques visant à sécuriser les services de paiement fournis par voie électronique. L’authentification forte a cristallisé nombre de revendications – certaines fantaisistes, voire fallacieuses – formulées par les PSP tiers à l’encontre des établissements de crédit.
L’ABE se réfère spécifiquement à l’argument, toujours encore déployé à satiété par certains agrégateurs, selon lequel une authentification forte imposée par les prestataires de services gestionnaires de comptes à leurs clients tous les 90 jours – voire plus fréquemment – compromettrait durablement leur activité[31]. L’hypothèse est la suivante : un utilisateur entend bénéficier d’une vision consolidée de l’ensemble de ses comptes sur une interface unique et recourt, dans cette optique, aux services d’un PSIC. Ce service, qui cible une clientèle multibancarisée, exige souvent du prestataire qu’il agrège les données attachées à plusieurs comptes de paiement détenus par un utilisateur auprès d’établissements bancaires différents. En l’espèce, le client sera tenu de s’authentifier auprès de chacun des teneurs de comptes toutes les fois que son prestataire accédera à ses comptes. Mettant en lumière l’acuité de cette problématique articulée autour de l’authentification forte, cette procédure, pour contraignante qu’elle soit, s’inscrit dans la stratégie globale insufflée par l’Union européenne en vue de sécuriser les opérations de paiement électroniques. Adossée à la protection du consommateur, la confiance qu’inspire un écosystème bancaire fiable conditionne grandement le développement d’un marché intérieur intégré des services de paiement.
La requête pressante de certains agrégateurs, consistant à exiger des établissements de crédit gestionnaires de comptes qu’ils leur délèguent l’authentification forte, n’a pas trouvé écho auprès de l’ABE. Rappelant à bon escient que l’authentification forte demeure obligatoire dès l’instant où l’utilisateur accède à son compte de paiement en ligne, soit directement, soit par l’intermédiaire d’un prestataire de services de paiement tiers, elle ajoute qu’un tempérament à la SCA systématique peut être légitimement envisagé dans l’hypothèse où un volume restreint de données personnelles est rendu accessible au cours de la transaction[32]. Pour autant, quand bien même on se situerait dans le champ de cette espèce, atypique, les utilisateurs ne sont nullement déliés de l’obligation de s’authentifier au moins tous les 90 jours. L’ABE fait manifestement allusion au mandat délivré au PSP tiers par l’utilisateur et à l’importance cardinale que revêt une telle formalité[33], indispensable au contrôle – tacite – de ce mandat et au-delà, à l’existence renouvelée du consentement du client[34].
En définitive, la SCA constitue le principe, de sorte qu’une authentification forte du client appliquée tous les 90 jours – par nature dérogatoire – doit rester reléguée au rang des exceptions et, comme telle, enserrée dans des conditions de mise en œuvre strictes. Une authentification forte prescrite tous les 90 jours ne s’apparente pas, en soi, à une entrave au sens de l’art. 32, par. 3, des RTS en raison, précisément, de son caractère proportionnel[35]. Compte tenu des atouts majeurs que comporte l’exemption des 90 jours, l’ABE invite les autorités nationales compétentes à la généraliser sur le parcours des agrégateurs.
Relativement à la problématique ayant trait à la responsabilité des acteurs de la SCA, l’ABE se prévaut, au soutien de son argumentaire, de son avis émis en 2018 sur la même thématique[36]. En particulier, il incombe aux prestataires de services gestionnaires de comptes – en l’occurrence, les banques – de superviser la procédure d’authentification forte et d’en mener à bien le déroulement[37]. En revanche, l’éventualité d’une délégation/externalisation de la SCA peut valablement être admise mais cette faculté relève alors de la compétence exclusive des entités bancaires, lesquelles peuvent exercer ce choix sans contrainte, au gré des circonstances et en toute opportunité.
Du point de vue de la méthode, en dépit d’une posture inédite, clairement favorable aux banques, l’ABE ne bouleverse pas la donne : s’adossant ponctuellement à ses prises de position antérieures, elle émaille son argumentaire de références appuyées à ses avis, témoignant ainsi d’une continuité avérée dans la démarche adoptée. Bien que la plupart de ses avis fassent la part belle à la technique en lui réservant une place de choix et semblent requérir du lecteur qu’il soit particulièrement versé dans les nouvelles technologies et qu’il maîtrise les arcanes de la banque digitale, l’avis sous commentaire démontre que l’ABE peut faire véritablement œuvre de pédagogie.
Dans le sillage de la DSP 2, les RTS ont concrétisé, tant bien que mal, le volet technique de la directive, consacré à l’authentification forte ainsi qu’aux API. À dire vrai, l’API – thématique ô combien clivante – constitue la pomme de discorde entre les banques et les FinTechs, et la pierre d’achoppement de débats âpres, toujours très controversés. Du reste, la création des API impliquait, par la force des choses, une collaboration étroite et une entente consensuelle entre les parties prenantes. Les établissements bancaires devaient, pour leur part, s’engager à fournir aux PSP tiers les spécifications techniques de leur interface, dûment consignées par écrit et publiées[38]. Subsidiairement, il leur incombait de proposer « un dispositif d’essai, comprenant une assistance et permettant des tests de connexion et de fonctionnement, afin que les prestataires agréés de services d’initiation de paiement, de services d’information sur les comptes et de services de paiement qui émettent des instruments de paiement liés à une carte ou les prestataires de services de paiement qui ont demandé l’agrément nécessaire puissent tester les logiciels et applications qu’ils utilisent pour proposer un service de paiement aux utilisateurs »[39] (nous soulignons) ; si bien qu’en retour, les agrégateurs devaient se consacrer pleinement à cette phase de tests, apportant à cette occasion leur précieux concours au perfectionnement des API. En définitive, l’espoir d’une coopération stimulante et constructive est resté lettre morte du fait de l’inertie délibérée dont les PSP tiers ont fait montre jusque-là. C’est sans doute à dessein que l’ABE a souhaité signifier, à travers cet avis, que de telles pratiques, résolument abusives, n’avaient pas leur place, marquant ainsi son désaccord.
[1] . Directive (UE) 2015/2366 du Parlement européen et du Conseil du 25 novembre 2015 concernant les services de paiement dans le marché intérieur, JOUE L 337 du 23 décembre 2015, p. 35.
[2] [2] . Règlement délégué (UE) n° 2018/389 de la Commission du 27 novembre 2017 complétant la Directive (UE) 2015/2366 du Parlement européen et du Conseil par des normes techniques de réglementation relatives à l’authentification forte du client et à des normes ouvertes communes et sécurisées de communication, JOUE L 69 du 13 mars 2018, p. 23.
[3] . Les praticiens évoquent souvent la « SCA » (pour Strong Customer Authentication) en lieu et place de l’authentification forte. Les deux notions sont strictement équivalentes.
[4] . Intimement liée au modèle de l’Open banking, l’API (Application Programming Interface ou « Interface de programmation ») contribue à accroître la sécurité des canaux de communication établis entre les banques et les prestataires de services de paiement tiers. Qu’il s’agisse d’une interface dédiée ou d’une interface utilisateur, cette solution technique innovante a vocation à permettre au prestataire tiers de s’identifier auprès de l’établissement teneur de comptes. Ce faisant, la diffusion des API, rendues obligatoires par la DSP2, a participé à l’éradication – à tout le moins partielle, non encore définitive – d’une pratique délétère, néanmoins très répandue : le web scraping.
[5] . Par essence protéiforme, la fraude est un phénomène en pleine recrudescence. Elle se reflète notamment dans une pratique en pleine expansion : le phishing (ou « hameçonnage »). L’essor des nouvelles technologies, et la généralisation subséquente de nouveaux usages autour d’internet et du smartphone, a favorisé l’éclosion de procédés frauduleux toujours plus sophistiqués, qui se renouvellent sans cesse avec davantage de subtilité.
[6] . Le Règlement (UE) n° 1093/2010 (JOUE L 331 du 15 décembre 2010, p. 12), instituant une Autorité européenne de surveillance (Autorité bancaire européenne), précise utilement, au titre des missions qui lui sont dévolues, que « l’Autorité contribue activement à créer une culture commune de l’Union et des pratiques cohérentes en matière de surveillance et à garantir l’uniformité des procédures et la cohérence des approches dans l’ensemble de l’Union » (art. 29, § 1).
[7] . Ces autorités de tutelle sont communément désignées par l’ABE sous le vocable de National Competent Authorities (abrégé « NCA »).
[8] . À l’instar d’un avis précédent en date du 13 juin 2018 (EBA-Op-2018-04), l’avis sous commentaire (EBA/OP/2020-2010) s’intéresse spécifiquement à la mise en œuvre concrète des RTS sous l’angle de l’authentification forte et des API.
[9] . Dans cette perspective, il s’agit d’interpréter les termes de l’art. 32, § 3, des RTS, lequel dispose que « les prestataires de services de paiement gestionnaires de comptes qui ont mis en place une interface dédiée veillent à ce que cette interface n’entrave pas la prestation de services d’initiation de paiement et d’information sur les comptes. Les entraves peuvent consister à empêcher l’utilisation par les prestataires de services de paiement visés à l’article 30, paragraphe 1, des données de sécurité émises par les prestataires de services de paiement gestionnaires de comptes à l’intention de leurs clients, à imposer la redirection vers l’authentification ou d’autres fonctions du prestataire de services de paiement gestionnaire du compte, à exiger des agréments et enregistrements en plus de ceux prévus aux articles 11, 14 et 15 de la Directive (UE) 2015/2366 ou à demander des contrôles supplémentaires du consentement donné par les utilisateurs de services de paiement aux prestataires de services d’initiation de paiement et d’information sur les comptes » (nous soulignons). On notera que les exemples énoncés ci-avant ne sont fournis qu’à titre indicatif, ce qui laisse déjà présager, en filigrane, l’appui décisif de l’ABE pour déterminer les contours de ces entraves.
[10] . Au sens de la DSP2, ces PSP tiers (notoirement connus comme étant des Third Party Providers, souvent abrégés « TPP ») peuvent s’entendre des Prestataires de services d’information sur les comptes (PSIC) – appelés, par abus de langage, « agrégateurs » – ou des Prestataires de services d’initiation de paiement (PSIP).
[11] . Née de la DSP2, l’authentification forte (du client) se définit comme « une authentification reposant sur l’utilisation de deux éléments ou plus appartenant aux catégories “connaissance” (quelque chose que seul l’utilisateur connaît), “possession” (quelque chose que seul l’utilisateur possède) et “inhérence” (quelque chose que l’utilisateur est) et indépendants en ce sens que la compromission de l’un ne remet pas en question la fiabilité des autres, et qui est conçue de manière à protéger la confidentialité des données d’authentification » (art. 4, 30), de la DSP2).
[12] . Qualifiées par l’ABE, respectivement, de « redirection », « embedded approach » et « decoupled approach ».
[13] . La pratique fait émerger des combinaisons originales : celle, par exemple, de l’approche découplée et du redirect, ou encore du parcours découplé et de l’approche intégrée.
[14] . Voir le pt. 6 de l’avis.
[15] . Soit celui réservé au prestataire tiers, PSIC ou PSIP.
[16] . Pour s’en convaincre, on se reportera à son avis du 13 juin 2018 (EBA-Op-2018-04) ainsi qu’à ses orientations portant sur l’exemption au mécanisme d’urgence inscrit à l’art. 33, § 6, des RTS (EBA/GL/2018/07).
[17] . Le pt. 9 est particulièrement éloquent.
[18] . Pour un complément utile, voir les pts. 18 et s. de l’avis sous commentaire.
[19] . Ce modèle a clairement la préférence des prestataires tiers, et pour cause : ces derniers disposent des clés pour mener à bien l’authentification du client de manière autonome et pour gérer, dans sa globalité, la procédure comme ils l’entendent (identifiant et mot de passe sont saisis par le client directement sur l’interface du PSP tiers).
[20] . Règlement délégué (UE) n° 2018/389 précité, consid. 20.
[21] . Cette logique se duplique à nouveau relativement aux agréments/enregistrements que le PSPGC réclamerait aux prestataires tiers en sus de ceux qui sont classiquement prescrits par la DSP 2.
[22] . Cette obligation est le fruit d’une interprétation de l’art. 30, § 2, des RTS.
[23] . Sur ces différentes méthodes, cf. supra.
[24] . Cf. pt. 11 de l’avis sous commentaire. Voir, à titre subsidiaire, l’avis précité adopté par l’ABE le 13 juin 2018 (EBA-Op-2018-04) ainsi que ses orientations portant sur l’exemption au mécanisme d’urgence inscrit à l’art. 33, § 6, des RTS (EBA/GL/2018/07).
[25] . Et consécutivement, l’existence d’une entrave au sens de l’art. 32, § 3, des RTS. Voir, pour une confirmation, le pt. 14 de l’avis commenté.
[26] . Voir notamment le pt. 43 de l’avis.
[27] . Spécialement, le pt. 45 de son avis.
[28] . Cf. Directive (UE) 2015/2366 précitée, consid. 69.
[29] . Cette solution est clairement plébiscitée par l’ABE au pt. 46 de son avis.
[30] . Y inclus, le cas échéant, l’initiation non autorisée ou frauduleuse d’une opération de paiement. Cf. Directive (UE) 2015/2366 précitée, art. 68, § 5. Voir également le pt. 45 de l’avis.
[31] . Pour une illustration en ce sens, voir Clément Cœurdeuil et Bertrand Jeannet, « Parcours client : l’authentification forte, un obstacle majeur pour les services d’agrégation de comptes », Banque & Stratégie n° 379, avril 2019, p. 32 et s.
[32] . Expressément circonscrit par les termes de l’art. 10, par. 1er, du Règlement délégué (UE) n° 2018/389, ce cas de figure spécifique est formulé comme suit : « les prestataires de services de paiement sont autorisés à ne pas appliquer l’authentification forte du client […] lorsqu’un utilisateur de services de paiement est limité dans son accès à un ou à deux des éléments suivants en ligne sans que des données de paiement sensibles soient divulguées : a) le solde d’un ou de plusieurs comptes de paiement désignés ; b) les opérations de paiement exécutées durant les 90 derniers jours par l’intermédiaire d’un ou de plusieurs comptes de paiement désignés ».
[33] . Celle de l’authentification forte imposée tous les 90 jours.
[34] . Dans ces conditions, l’exigence d’authentification forte qui pèse sur l’utilisateur assure, en contrepartie, au PSIC qu’il sera autorisé à accéder aux données des comptes de paiement qu’il traite sans devoir se heurter à une nouvelle SCA. Voir, pour davantage de précisions, le pt. 30 de l’avis sous commentaire.
[35] . En vérité, la dérogation des 90 jours, qualifiée par l’ABE de solution équilibrée, se justifie par la conciliation – a priori improbable – de considérations objectives contradictoires tenant, d’une part, à la fluidité du parcours client (convivialité des dispositifs techniques) et, d’autre part, au besoin impérieux de renforcer la sécurité de la chaîne des paiements.
[36] . Opinion of the European Banking Authority on the implementation of the RTS on SCA and CSC, 13 June 2018, EBA-Op-2018-04, spéc. p. 8.
[37] . La formulation choisie par l’ABE n’est pas anodine et ne laisse place à aucune équivoque : elle fait valoir, tout à la fois, que l’obligation et la responsabilité d’accomplir la SCA, dérivées de la DSP2, reposent sur l’établissement teneur de comptes (pt. 32).
[38] . Règlement délégué (UE) n° 2018/389 précité, consid. 21.
[39] . Ibid., art. 30, § 5.
