1. La question est évidemment cruciale pour les uns comme pour les autres. Une Opinion of the European Banking Authority on the implementation of the RTS on SCA and CSC a donné la réponse suivante : « It is the EBA’s view, after discussing it with the Commission, that, where AIS or PIS are provided to a payment service user (PSU) following a contract that has been signed by both parties, ASPSPs do not have to check consent. It suffices that AISPs and PISPs can rely on the authentication procedures provided by the ASPSPs to the PSU, when it comes to the expression of explicit
Où les « RST on SCA and CSC » sont les Regulatory Technical Standards on Strong Customer Authentification and Common and Secure Communication, désormais contenus dans le règlement délégué (UE) 2018/389 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 ; AIS est l’Account Information Service (soit le nouveau service 8 d’information sur les comptes) et AISP leurs providers ; PIS est le Payment Initiation Service (soit le nouveau service 7 d’initiation de paiement) et PISP leurs providers et, enfin, où les ASPSP sont les Account Servicing Payment Service Providers, ces prestataires de services de paiement indifférenciés qui, dans la DSP 2 et au contact des prestataires sans compte qui sollicitent un accès au compte qu’ils ne tiennent pas, se muent en prestataires de services de paiement gestionnaires de compte.
Une fois ce jargon de l’EBA devenu intelligible (ou à peu près), on comprend que l’Autorité bancaire européenne est d’avis que les prestataires de services de paiement gestionnaires de comptes n’ont pas à vérifier le consentement (explicite) donné par un titulaire de compte à l’accès à celui-ci, dès lors toutefois qu’un contrat a été signé entre ce dernier et les prestataires de services d’initiation de paiement (PSIP) ou d’information sur les comptes (PSIC). Il suffit, est-il ajouté, que ceux-ci puissent se fier aux procédures d’authentification fournies par les teneurs de compte, sur la foi d’un consentement explicite.
2. Ces précisions sont bienvenues, dans la mesure où, dans la DSP 2, l’expression (et la destination) du consentement (explicite) du client utilisateur de services de paiement est diverse :
– double consentement donné à la fois au gestionnaire de compte et à l’émetteur d’instruments de paiement liés à une carte pour qu’il demande confirmation de la disponibilité des fonds (art. 65 et CMF, art. L. 133-39) ;
– consentement, non pas à un prestataire déterminé, mais à l’exécution d’un paiement initié par un PSIP selon le droit commun de l’autorisation d’une opération de paiement (art. 66 et CMF, art. 133-40) ;
– enfin, consentement donné par l’utilisateur de services de paiement au PSIC afin qu’il fournisse ses services (art. 66 et CMF, art.
Si l’on se tourne du côté du fameux règlement délégué Autentification forte et communication
3. De fait, il ressort d’un autre document de l’EBA (Consultation Paper – Draft Guidelines on the conditions to be met to benefit from an exemption from contingency measures under Article 33(6) of Regulation (EU) 2018/389 (RTS on SCA &
Si bien que l’on peut lire dans le projet de 5e orientation contenu dans ce Consultation Paper ceci, qui confirme l’opinion de l’EBA par laquelle nous avons débuté cette brève incursion dans le monde nouveau – et semé d’embûches – de l’accès aux comptes par ceux qui ne les tiennent pas : « The ASPSP should provide to the competent authority a confirmation that there are no additional checks on the consent given by the PSU to the PISP, AISP or CBPII to access the information of the payment account held in the ASPSP or initiate payments » (5.2, c.).
Les prestataires d’accès aux comptes (de paiement) ne devraient donc pas être entravés dans la fourniture de leurs services par un « additional check » mené par les gestionnaires desdits comptes. Voilà un outil de moins que ces derniers auront à développer dans leurs interfaces. Il n’est pas sûr, toutefois, qu’ils en soient heureux.
Achevé de rédiger le 3 septembre 2018.