Un règlement attendu. Le moins qu’on puisse dire est qu’il était attendu. Le règlement délégué posant les normes en matière d’authentification et de communication de données, destiné à finaliser la
DSP 2
[1]
, est enfin paru au JOUE du 13 mars
2018
[2]
. L’Autorité bancaire européenne (EBA) avait arrêté le projet des normes techniques (projet de
« RTS »
[3]
) qu’elle avait la charge d’élaborer depuis le 23 février
2017
[4]
. Mais l’on sait que c’est à la Commission d’adopter le règlement qui établit ces normes et que le Parlement peut s’y opposer. La préparation du texte a donné lieu à maints rebondissements, alors que les acteurs concernés étaient en forte attente pour pouvoir commencer à travailler sur les solutions techniques qu’ils allaient devoir mettre en
place
[5]
. Les enjeux étaient tels qu’une navette informelle avec le Parlement, alimentée en sousmain par la très forte opposition d’intérêts entre les banques et les FinTechs, a fortement retardé le processus. Finalement, un accord a été trouvé, permettant de déverrouiller ce qui constitue le coeur de la DSP 2, à savoir l’ouverture de l’accès aux comptes de paiement. Son entrée en application, reportée comme il est usuel à 18 mois après son entrée en vigueur, va donc permettre aux banques et aux autres acteurs du paiement de disposer d’un certain laps de temps pour adopter les dispositifs adéquats. Le 14 septembre 2019 tout devra être en place.
Un règlement finalisant la DSP 2. Signe de la forte technicisation du droit des
paiements
[6]
, ces normes techniques de réglementation conditionnent en effet l’entrée en application d’une partie des dispositions novatrices de la
DSP 2
[7]
. Si la DSP 1 a décloisonné le marché des paiements en ouvrant les services de paiements à de nouveaux prestataires, la DSP 2 agit à un autre niveau, plus profond, en obligeant les gestionnaires de comptes (c’est-à-dire principalement les banques) à permettre à prestataires « de seconde génération » d’accéder aux données de compte.
Après avoir brisé le monopole des paiements, les autorités européennes ont ainsi mis à mal le monopole de fait sur les données de paiement. C’est le triomphe de l’économie de la donnée dans le domaine bancaire.
Or les normes qui sont précisées dans ce règlement délégué devaient être arrêtées afin que les gestionnaires de
comptes
[8]
(i. e. les banques) ouvrent leurs données aux prestataires offrant les nouveaux services de paiement.
Les nouveaux services de paiement dans la dépendance du règlement. La DSP 2 a en effet créé deux nouveaux services de paiements destinés à être fournis en ligne ou à
distance
[9]
: le service d’initiation de paiement et le service d’information sur les comptes. L’initiation de paiement permet à un prestataire d’« initier un ordre de paiement à la demande de l’utilisateur de services de paiement concernant un compte de paiement détenu auprès d’un autre prestataire de services de
paiement »
[10]
. L’information sur les comptes, plus communément connue sous l’expression erronée « agrégationde comptes », consiste « à fournir des informations consolidées concernant un ou plusieurs comptes de paiement détenus par l’utilisateur de services de paiement soit auprès d’un autre prestataire de services de paiement, soit auprès de plus d’un prestataire de services de
paiement »
[11]
. Les prestataires spécialisés dans ces services d’initiation de paiement (« PSIP ») ou d’information sur les comptes (
« PSIC »
[12]
) doivent pouvoir accéder aux comptes des personnes qui les sollicitent, puisque telle est la condition de l’accomplissement de leurs services. Le compte est en effet le point de départ de l’opération de paiement (en cas d’initiation) ou ce dont vont être extraites les informations (en cas d’information sur les comptes).
Si ces nouveaux prestataires doivent être dotés d’un statut pour exercer leur activité (par le biais d’un agrément pour les
PSIP
[13]
ou d’un simple enregistrement pour les
PSIC
[14]
), celui-ci ne leur suffira pas pour accéder aux comptes de leurs clients.
En réalité, ces prestataires ne sont pas réellement de nouveaux acteurs sur le marché : ils agissaient jusqu’à présent (comprendre jusqu’à l’entrée en application de la DSP 2) sans statut, en accédant aux comptes de leurs clients par une pratique jugée dangereuse pour tous, le web scraping. Concrètement, quand une personne entendait bénéficier des services d’un agrégateur ou pouvoir initier des virements par l’intermédiaire d’un autre prestataire que sa banque, elle devait leur fournir ses codes d’accès en ligne à son ou ses comptes. Le prestataire pouvait ainsi extraire les informations de la page web afin de réutiliser les données ou entrer dans le système de gestion du compte pour lancer le virement. Cette atteinte à la confidentialité constituait à la fois un risque pour le client (en cas de faille de sécurité du prestataire ou de fraude) et un risque pour les banques.
C’est l’une des raisons qui a conduit les autorités européennes à vouloir encadrer ces services en les faisant entrer dans le champ de la réglementation des paiements, au prix d’ailleurs d’une approximation dénaturant le cadre posé par la DSP 1, puisque l’information sur les comptes ne conduit pas à la réalisation d’opérations de paiement mais simplement au traitement de données de paiement.
Mais attraire ces nouveaux services dans le champ de la DSP 2 ne pouvait suffire : il convenait de sécuriser l’accès aux comptes, ou plus exactement les échanges de données entre le gestionnaire de compte (souvent une banque) et le prestataire concerné (PSIC ou
PSIP
[15]
).
La sécurité des opérations à distance, autre objectif de la DSP 2. La DSP 2 vise aussi à moderniser le cadre posé par la DSP 1 pour tenir compte des évolutions technologiques et d’usage en matière de paiement. Le développement du paiement à distance (par Internet) et l’utilisation grandissante du smartphone aux fins de paiement imposaient de renforcer la sécurité, tant d’ailleurs pour le client (éviter les fraudes) que pour les prestataires (éviter les contestations qui ouvrent droit à remboursement). C’est pourquoi la DSP 2 a mis en place une nouvelle exigence d’authentification.
Deux objets du règlement délégué. Le règlement
délégué
[16]
a donc deux objets comme son intitulé le fait apparaître. Si les normes relatives à l’authentification vont impacter la fourniture de l’ensemble des services de paiements et des acteurs (prestataires comme utilisateurs de ces services) (I.), celles relatives à la communication sécurisée relève plus de la tuyauterie des paiements puisqu’elles modèlent les relations techniques entre les gestionnaires de comptes et les prestataires qui entendent y avoir accès (II.).
I. FOURNITURE DES SERVICES DE PAIEMENT À DISTANCE : L’EXIGENCE GÉNÉRALE D’AUTHENTIFICATION FORTE
Protection des utilisateurs et des prestataires de services de paiement. La fourniture des services de paiement à distance, qui se développe exponentiellement, ne doit pas porter atteinte à la sécurité des paiements. La lutte contre les fraudes, et plus largement la cybercriminalité, impose donc d’apporter des mesures protégeant les clients afin d’assurer l’applicabilité du principe cardinal en matière de paiement : celui du consentement du payeur à l’
opération
[17]
. En outre, la qualification d’opération de paiement suppose que l’opération ait été initiée par l’utilisateur de
services
[18]
, c’est-à-dire par le payeur ou le bénéficiaire en relation contractuelle avec le prestataire concerné. Ainsi, toute opération qui n’a pas été autorisée par le payeur (à laquelle il n’a pas consenti) ou qui n’a pas été initiée par l’
utilisateur
[19]
est une opération qui peut être contestée, exposant alors le prestataire à devoir la
rembourser
[20]
(sous réserve de la responsabilité exceptionnelle du
payeur
[21]
).
Tous les acteurs du paiement partagent ainsi un intérêt à ce que l’opération de paiement, ou plus largement l’intrusion sur le
compte
[22]
, ne soit pas frauduleuse ou du moins, non autorisée par le payeur.
Mesures de sécurité imposées pour l’authentification forte. C’est pourquoi la DSP 2 a alourdi les exigences en la matière, allant bien au-delà du cadre posé par la DSP 1.
Elle impose, dans les hypothèses soulevant un risque de fraude, une authentification forte, c’est-à-dire une authentification reposant sur un dispositif plus important que celle requise sous DSP 1. La simple signature (pour ordre papier), la composition d’un code confidentiel ou l’utilisation d’un mot de passe ne sont plus suffisantes.
L’authentification forte était définie par la DSP 2 comme une mesure répondant à deux
critères
[23]
que le règlement délégué vient préciser. Le premier tient à la nature et au nombre des éléments mobilisés : elle repose « sur l’utilisation de deux éléments ou plus » appartenant aux catégories « connaissance » (élément que seul l’utilisateur connaît et qui ne doit pouvoir être mis au jour par des tiers non autorisés ou divulgués à
ceux-ci
[24]
), « possession » (élément que seul l’utilisateur possède et qui ne doit pas être utilisé pardes tiers non autorisés et dont le risque de copie doit être
évité
[25]
) et « inhérence » (élément qui identifie qui est l’utilisateur grâce à des dispositifs et
logiciels
[26]
). Le second critère tient aux liens entre ces éléments d’authentification : ils doivent être indépendants en ce sens que la compromission de l’un ne doit pas remettre en question la fiabilité des
autres
[27]
.
L’enjeu est de taille pour les professionnels. D’une part, parce qu’à défaut d’avoir mis en oeuvre un dispositif d’authentification forte ou d’avoir exigé une telle authentification pour une opération donnée, le prestataire assume pleinement le risque de fraude et donc le remboursement des opérations contestées (sauf fraude du
client)
[28]
. D’autre part, parce que le respect de cette exigence devient un élément de leur politique de conformité, qu’ils doivent gérer dans le cadre de leur contrôle
interne
[29]
, sous peine de sanctions disciplinaires.
Spécifications. Le règlement délégué spécifie donc les mesures que les professionnels vont devoir mettre en oeuvre. Chacune des authentifications suppose la génération d’un code
unique
[30]
. Aussi, lors de chaque accès à son compte de paiement en ligne, de chaque opération de paiement initiée par voie électronique ou encore pour l’exécution de n’importe quelle action réalisée grâce à un moyen de communication à distance, un code devra être généré afin d’attester du respect de l’exigence d’authentification.
En outre, pour les opérations de paiement électronique ordonnées à distance (en pratique, par Internet, via un smartphone…), le prestataire doit établir un lien dynamique entre l’opération, le montant et le
bénéficiaire
[31]
.
Champ des opérations visées. Le champ des opérations visées par l’exigence d’authentification forte a été l’un des éléments du bras de fer qui a retardé l’adoption du règlement délégué.
Le principe ne faisait pas débat puisqu’il était posé par la
DSP 2
[32]
. L’authentification forte est imposée dans trois catégories d’hypothèses qui peuvent conduire à la fourniture de services de paiement à distance susceptible de comporter un risque de fraude : l’accès du compte en ligne, l’initiation d’une opération de paiement à
électronique
[33]
et, plus largement, l’exécution de toute action réalisée grâce à un moyen de communication à distance.
Les dérogations à l’application de ce principe ont en revanche nourri de multiples
discussions
[34]
, celles-ci ayant abouti à assouplir l’exigence par l’insertion de nouveaux cas d’exemption. La DSP 2 prévoyait déjà que ces dérogations reposeraient sur trois critères : le niveau de risque lié au service fourni ; le montant, le caractère récurrent de l’opération ou les deux ; le moyen utilisé pour exécuter l’opération. La fameuse approche par les risques, qui tend à devenir un principe transversal dans la réglementation des services financiers (LCF-FT, MIF II…) et de la protection des données (RGPD) avait donc vocation être consacrée ici aussi pour tempérer la rigueur des mesures techniques impliquées par l’authentification forte. Le règlement délégué liste donc les hypothèses où l’authentification forte n’est pas requise : information sur les comptes après une première
authentification
[35]
, paiement sans contact au point de vente pour des petits
montants
[36]
, opérations de faible valeur (mêmes montants que pour le paiement sans
contact)
[37]
, automates de paiement des frais de transport et de
parking
[38]
, opérations récurrentes réalisées auprès du même bénéficiaire après une première authentification
forte
[39]
, opérations réalisées auprès de bénéficiaires de confiance
prélistés
[40]
, virement à soi-même ou intra-banque (sur un compte tenu par un même
gestionnaire)
[41]
ou paiements réalisés au profit de personnes morales par la voie de procédures et de protocoles de paiement
sécurisés
[42]
.
Les critères réglementaires adoptés pour écarter l’exigence de l’authentification reposent donc, on le voit, soit sur la faiblesse des risques de fraude (existence d’une première authentification, identité du bénéficiaire), soit sur les conséquences qui pourraient en résulter (faibles montants concernés). Sans oublier que le règlement autorise les PSP à se dispenser de l’authentification forte en application d’une analyse « en temps réel » des risques liés à l’
opération
[43]
.
Un reporting est organisé pour les autorités puissent vérifier que les fraudes ne sont pas rendues possibles par ces dérogations : les PSP doivent ainsi contrôler et indiquer à leur autorité de contrôle et à l’ABE la valeur des opérations
frauduleuses
[44]
ou non autorisées, comparée avec les taux de fraude
générale
[45]
auxquels ils ont été exposés.
II. ACCÈS AUX COMPTES DE PAIEMENT : NORMES À LA COMMUNICATION ENTRE PRESTATAIRES
Exigences générales. L’effectivité du droit d’accès comme la protection des données de clients impose des mesures évoquées dans la DSP 2 qui sont détaillées dans le chapitre V règlement
délégué
[46]
.
Pendant des règles de bonne conduite que l’on trouve dans la matière voisine des services d’investissement, la DSP2 pose des exigences générales à la charge de l’ensemble des prestataires qui fournissent de services de paiement, qu’il s’agisse des gestionnaires de comptes ou de ceux qui demandent à y avoir accès. Ces derniers recouvrent en réalité trois catégories d’acteurs : les PSIP, les PSIC, mais aussi les émetteurs d’instruments de paiement liés à une carte qui peuvent demander à se faire confirmer immédiatement si le montant nécessaire à l’exécution d’une opération par carte est disponible sur le compte de paiement du
payeur
[47]
.
Le règlement délégué pose ainsi deux exigences qui n’ont pas de quoi surprendre : lors des communications, les PSP doivent d’abord garantir une identification sécurisée entre le dispositif du payeur et les dispositifs d’acceptation du bénéficiaire, notamment les terminaux de
paiement
[48]
; ils doivent ensuite mettre en place des procédures qui garantissent que l’ensemble des opérations de paiement (et toutes autres interactions entre l’utilisateur et d’autres PSP ou entités, dont les commerçants) sont
traçables
[49]
.
Obligations des gestionnaires relatives aux interfaces d’accès (API). Le règlement délégué fixe surtout, et ce n’est pas le moindre aspect pour lequel il était attendu, les spécifications que vont devoir remplir les interfaces, en pratique qualifiées API pour Application Programming Interface. L’objectif est à la fois que les gestionnaires de compte n’entravent pas la fourniture de services par les autres prestataires et que le niveau de sécurité soit identique à celui offert aux utilisateurs eux-mêmes.
Tout prestataire gestionnaire de compte doit, du moins s’il offre la possibilité à ses clients d’accéder à leurs comptes en ligne (quasiment tous donc, en pratique), proposer au moins une API pour permettre aux prestataires qui demandent à accéder à ces comptes de le pouvoir. Cette interface peut être la même que celle mise à disposition des utilisateurs de services de paiement (« l’interface utilisateurs ») ou, au contraire, être dédiée, auquel cas elle doit présenter le même niveau de disponibilité et de performance que l’interface
utilisateurs
[50]
.
L’interface doit permettre aux PSIC, PSIP et émetteurs de cartes de s’identifier. Ensuite, ils doivent pouvoir communiquer de manière sécurisée, d’une part s’agissant des PSIC, afin de demander et de recevoir des informations concernant le ou les comptes de paiement désignés et les opérations de paiement associées, d’autre part s’agissant des PSIP pour initier un ordre de paiement à partir du compte de paiement du payeur et pour recevoir toutes les informations sur l’initiation et l’exécution de l’opération de
paiement
[51]
. L’API doit aussi permettre d’authentifier l’utilisateur de services de paiement par le biais des procédures d’authentification similaires à celle proposées par le gestionnaire du compte à son
client
[52]
.
En outre, l’API doit répondre à des normes dont les spécifications techniques doivent être disponibles à tout
moment
[53]
. Selon un principe de non-
discrimination
[54]
, le gestionnaire doit fournir à chacun des trois PSP les mêmes informations que celles dues aux utilisateurs de services de
paiement
[55]
.
Obligations des gestionnaires ayant opté pour une API dédiée. Si le gestionnaire décide de mettre en place une API dédiée, celle-ci doit offrir à tout moment le même niveau de disponibilité et de performances que l’interface utilisateurs, de même que les indicateurs de performance clés et les valeurs cibles de niveau de service doivent être aussi exigeants, ce qui doit faire l’objet d’un contrôle
permanent
[56]
. À défaut, un « mécanisme de secours » devra en
principe
[57]
être organisé afin de permettre aux trois prestataires sans compte d’utiliser l’interface
utilisateurs
[58]
.
Le but est que l’API dédiée n’entrave pas l’activité des PSIP et des PSIC. La restriction d’utilisation des données de sécurité des clients, une redirection vers l’authentification, l’exigence d’agréments ou d’enregistrements supplémentaires ou des contrôles renforcés du consentement des utilisateurs sont expressément visées comme constituant des entraves
prohibées
[59]
.
Obligations des PSP qui demandent à avoir aux comptes :
règles de sécurité des données. Les PSP qui demandent à avoir accès aux comptes tenus par des gestionnaires doivent recourir à des certificats qualifiés au sens du règlement
eIDAS
[60]
pour s’identifier auprès des
derniers
[61]
. Puis le règlement énonce des
règles
[62]
de sécurité, tels que le cryptage avancé des sessions de communication mis en place par les « parties communicantes » ou encore la réduction au délai le plus court des sessions d’accès aux comptes.
Les PSIC ne doivent accéder qu’aux seules informations provenant des comptes de paiement désignés et des opérations de paiement associées, conformément au consentement de l’
utilisateur
[63]
.
Puisque la DSP 2 a ouvert l’accès aux comptes de paiement à des prestataires qui ne gèrent pas ces comptes, il était indispensable d’organiser un cadre sécurisé pour l’échange des données. Les normes sont désormais posées.
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.
2
Règl. délégué (UE) 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. Pour un commentaire, voir déjà : P. Storrer, « Derrière la DSP 2 : le règlement Authentification forte et Communication sécurisée », Revue Banque n° 820, p. 86.
3
L’acronyme RTS signifie Regulatory Technical Standards.
4
Dir. (UE) 2015/2366, art. 97 et art. 98.
5
On notera qu’un autre règlement délégué a déjà été adopté pour compléter de la DSP 2, suite aux projets de normes élaborés par l’EBA : règlement délégué (UE) 2017/2055 du 23 juin 2017 portant normes techniques de réglementation relatives à la coopération et à l’échange d’informations entre les autorités compétentes dans le cadre de l’exercice du droit d’établissement et de la libre prestation de services par les établissements de paiement (JOUE n° L 294, 11 nov.).
6
P. Storrer, art. précit.
7
L’entrée en application de la DSP 2 était fixée à la date du 13 janvier 2018. Mais la DSP 2 indiquait expressément que les mesures de sécurité, visées à l’article 98, s’appliqueraient dix-huit mois après l’entrée en vigueur des normes techniques de réglementation les précisant (Dir. (UE) 2015/2366, art. 115,4). Or l’article 98 de la DSP 2 vise (1) les exigences relatives à l’authentification forte du client (2) les dérogations y afférentes (3) les mesures de sécurité, destinées à protéger la confidentialité et l’intégrité des données de sécurité personnalisées de l’utilisateur de services de paiement et (4) exigences applicables aux normes ouvertes communes et sécurisées de communication aux fins de l’identification, de l’authentification, de la notification et de l’information, ainsi que pour la mise en oeuvre des mesures de sécurité, entre les prestataires de services de paiement gestionnaires du compte, les prestataires de services d’initiation de paiement, les prestataires de services d’information sur les comptes, les payeurs, les bénéficiaires et d’autres prestataires de services de paiement.
8
Dit aussi « ASPSP » dans le jargon courant des paiements, comme acronyme de leur appellation en anglais Account Servicing Payment Service Provider.
9
Lors de la transposition de la DSP 2 par l’ordonnance 2017-1252 du 9 août 2017, ces deux services ont été insérés dans la liste des services de paiements énumérés à l’article L. 314-1, II du Code monétaire et financier (services 7 et 8).
10
Dir. préc., art. 4, 15. Cette définition est reprise à l’article D. 314-2, 6° du Code monétaire et financier.
11
Dir. préc., art. 4, 16. Cette définition est reprise à l’article D. 314-2, 7° du Code monétaire et financier.
12
C. monét. fin., art. L. 522-1, II : « Les prestataires de services d’information sur les comptes sont les personnes physiques ou morales, autre que les établissements de crédit, les établissements de monnaie électronique, les établissements de paiement et les personnes mentionnées au II de l’article L. 521-1, qui fournissent à titre de profession habituelle le service d’information sur les comptes mentionnés au 8° du II de l’article L. 314-1 à l’exclusion de tout autre service de paiement ».
13
Dir. préc., art. 11.
14
Dir. préc., art. 5. 3. C. monét. fin., art. L. 522-11-2.
15
Les émetteurs de cartes peuvent aussi accéder aux comptes tenus par un gestionnaire de compte. Voir infra, II.
16
Règl. délégué (UE) 2018/389 précit.
17
Dir. (UE) 2015/2366, art. 64.
18
Dir. (UE) 2015/2366, art. 4, 5).
19
Les bénéficiaires peuvent aussi initier des opérations, tels des prélèvements.
20
Dir. (UE) 2015/2366, art. 73.
21
Dir. (UE) 2015/2366, art. 74.
22
Le service d’information sur les comptes n’implique pas la réalisation d’opération de paiement, mais simplement l’extraction et le traitement de données de compte.
23
Dir. (UE) 2015/2366, art. 4, 30).
24
Règl. délégué (UE) 2018/389, art. 6.
25
Règl. délégué (UE) 2018/389, art. 7.
26
Règl. délégué (UE) 2018/389, art. 8.
27
Règl. délégué (UE) 2018/389, art. 9.
28
Dir. (UE) 2015/2366, art. 74.2.
29
Règl. délégué (UE) 2018/389, art. 3, 1. Par ailleurs, les PSP sont tenus d’une obligation générale de veiller à la confidentialité et à l’intégrité desdites données, notamment des codes d’authentification, durant toutes les phases d’authentification (Règl. délégué (UE) 2018/389, art. 22 à 27).
30
Règl. délégué (UE) 2018/389, art. 4.
31
Règl. délégué (UE) 2018/389, art. 5.
32
Dir. (UE) 2015/2366, art. 97.1.
33
Bien que non défini par la DSP 2, il faut comprendre que cette expression ne vise seulement l’opération d’initiation de paiement, mais bien toute opération de paiement qui est ordonnée par voie électronique, c’est-à-dire à distance (le paiement sans contact utilisé pour de petits montants entrant dans le champ des dérogations – cf : infra).
34
Dont le principe était aussi prévu par la DSP 2 : Dir. (UE) 2015/2366, art. 98.1.b).
35
Règl. délégué (UE) 2018/389, art. 10. Cette dérogation peut être appliquée après le premier accès au service d’information sur les comptes et lorsque celui-ci n’accède qu’au solde d’un ou plusieurs comptes désignés et/ou que plus de 90 jours se sont écoulés depuis sa dernière authentification forte.
36
Règl. délégué (UE) 2018/389, art. 11. La dérogation suppose que le montant de l’opération de paiement ne dépasse pas 30 €, le montant cumulé demeure inférieur ou égal à 100 € et le nombre des précédentes opérations depuis la dernière authentification forte du client n’excède pas cinq.
37
Règl. délégué (UE) 2018/389, art. 16.
38
Règl. délégué (UE) 2018/389, art. 12.
39
Règl. délégué (UE) 2018/389, art. 14.
40
Règl. délégué (UE) 2018/389, art. 13.
41
Règl. délégué (UE) 2018/389, art. 15.
42
Règl. délégué (UE) 2018/389, art. 17. La dérogation suppose que « les autorités compétentes ont acquis la certitude que lesdits procédures et protocoles garantissent des niveaux de sécurité au moins équivalents à ceux prévus par la directive (UE) 2015/2366 ».
43
Règl. délégué (UE) 2018/389, art. 18 et sur les conditions, art. 19.
44
Sur les règles de calcul des taux de fraude : Règl. délégué (UE) 2018/389, art. 19.
45
Règl. délégué (UE) 2018/389, art. 21.
46
Règl. délégué (UE) 2018/389, art. 25 à 36.
47
Dir. (UE) 2015/2366, art. 65.1.
48
Règl. délégué (UE) 2018/389, art. 28, 1
49
Règl. délégué (UE) 2018/389, art. 29, 1. Le but est que « l’ensemble des événements en rapport avec l’opération électronique durant ses différentes phases soient connus a posteriori ».
50
Règl. délégué (UE) 2018/389, art. 31.
51
Règl. délégué (UE) 2018/389, art. 30.1.
52
Règl. délégué (UE) 2018/389, art. 30.2.
53
Règl. délégué (UE) 2018/389, art. 30.3 à 6.
54
Dir. (UE) 2015/2366, art. 65, 66 et 67.
55
Règl. délégué (UE) 2018/389, art. 36.1.
56
Règl. délégué (UE) 2018/389, art. 32.4.
57
Peuvent être exemptés par leur autorité compétente de l’obligation de mettre en place un mécanisme d’urgence, les PSPGC qui proposent une interface dédiée en tous points conforme à l’ensemble des obligations de l’article 32.
58
Le gestionnaire doit organiser un mécanisme de secours destiné à prendre le relais en cas d’indisponibilité imprévue ou de panne de l’interface, pour que les PSP puissent recourir aux interfaces utilisateurs, sous condition de respecter un certain nombre d’exigences, dont celles de justifier à leur autorité nationale compétente, sur demande, un tel recours ainsi que d’informer le PSPGC : Règl. délégué (UE) 2018/389, art. 33.
59
Règl. délégué (UE) 2018/389, art. 32, 1 à 3).
60
Règl. n° 910/2014, 23 juill. 2014, sur l’identification électronique et les services de confiance pour les transactions électroniques au sein du marché intérieur.
61
Règl. délégué (UE) 2018/389, art. 34.
62
Règl. délégué (UE) 2018/389, art. 35 et 36.
63
Règl. délégué (UE) 2018/389, art. 36.6. Maître Pierre Storrer (art. précit.) note à cet égard une règle qu’il estime inédite : le PSIC a un droit d’accès chaque fois que l’utilisateur de services de paiement le demande spontanément, ou à défaut, au maximum quatre fois par période de 24 heures, « sauf si une fréquence plus élevée est convenue entre le prestataire de services d’information sur les comptes et le prestataire de services de paiement gestionnaire du compte, avec le consentement de l’utilisateur de services de paiement » (Règl., art. 36, 5). Ceci pourrait conduire à la mise en place d’une relation contractuelle entre gestionnaire de compte et agrégateur de données.
