Bien qu'en France, les gestionnaires de comptes de paiement soient habitués à communiquer chaque année à l'Autorité de contrôle prudentiel et de résolution (ACPR) leurs rapports au titre de « l’annexe sur la sécurité des moyens de paiement scripturaux », ils doivent aujourd'hui anticiper les nouvelles obligations de reporting liées à la deuxième Directive sur les Services de Paiement (DSP 2). Celles-ci exigent de mettre à disposition beaucoup plus d’informations qu’ils n’en communiquent actuellement, notamment le calcul des taux de fraude, à décomposer en fonction des dérogations, ainsi que leur justification du respect des mesures de sécurité, qui nécessite des informations détaillées, de même nature que celles exigées dans un dossier de demande d’agrément en tant qu'établissement de paiement ou établissement de monnaie électronique, et auxquelles les établissements de crédit « établis » ne sont pas habitués dans les rapports transmis jusqu'alors à l'ACPR. Par ailleurs, cette conformité doit être attestée par des auditeurs indépendants, « possédant une expertise dans le domaine de la sécurité informatique et des paiements électroniques ».
La DSP 2 ambitionne à la fois de renforcer la sécurité des paiements et d’ouvrir à des tiers l’accès aux données de paiement pour permettre davantage de concurrence. En contrepartie, les Autorités de tutelle souhaitent s’assurer que la fraude sur les paiements est maîtrisée, que l'ensemble des acteurs impliqués respecte bien les règles de l’ouverture, et que l’ouverture ne crée pas de brèches de sécurité dans les systèmes d’information. Tous les prestataires de services de paiement (PSP) européens, de la banque teneur de comptes (Account Servicing Payment Service Provider – ASPSP) à l’initiateur de paiement (Payment Initiation Service Provider – PISP), en passant par l’agrégateur de comptes (Account Information Service Provider – AISP), doivent mettre à la disposition des Autorités de tutelle plusieurs rapports afin d'attester de leur conformité à la DSP 2 et aux normes techniques de réglementation (Regulatory Technical Standards – RTS) sur l'authentification forte du client et la communication sécurisée (RTS SCA &
Trois obligations de reporting issues de la DSP 2
De la DSP 2 découlent trois obligations de rapports. La première est définie dans le paragraphe 2 de l’article 95, qui exige que « les États membres veillent à ce que les prestataires de services de paiement fournissent à l’Autorité compétente, chaque année ou à des intervalles plus rapprochés fixés par l’Autorité compétente, une évaluation à jour et exhaustive des risques opérationnels et de sécurité liés aux services de paiement qu’ils fournissent et des informations sur le caractère adéquat des mesures d’atténuation et des mécanismes de contrôle mis en œuvre pour faire face à ces risques ». La deuxième, au paragraphe 1 de l'article 96, impose qu’« en cas d’incident opérationnel ou de sécurité majeur, les PSP informent sans retard injustifié l’Autorité compétente dans l’État membre d’origine du prestataire de services de paiement ». Enfin, le paragraphe 6 de l’article 96 précise que « les États membres veillent à ce que les PSP fournissent à leurs Autorités compétentes, au moins chaque année, des données statistiques relatives à la fraude liée aux différents moyens de paiement ».
Afin de préciser l’intention de la DSP 2 et de fournir aux acteurs des instructions plus opérationnelles, en particulier sur la nature des informations à faire figurer dans ces rapports, l’Autorité bancaire européenne (ABE) a publié trois séries d’orientations :
la première série concerne les mesures de sécurité pour les risques opérationnels et de sécurité liés aux services de paiement dans le cadre de la DSP
la deuxième la notification des incidents majeurs en vertu de la DSP
la troisième les exigences pour la déclaration de données relatives à la fraude au titre de l’article 96, paragraphe 6, de la DSP
Dans ces documents, une partie des orientations est destinée aux prestataires de services de paiement auxquels il incombe de concevoir les différents rapports, une autre, aux Autorités compétentes chargées d’évaluer, sur la base du rapport, la conformité de ces PSP. Après l’avoir éventuellement consolidé, l’Autorité compétente de l’État membre transmet le rapport à l’ABE.
Les Autorités compétentes ont eu deux mois pour se prononcer sur leur propre conformité aux orientations émises par l’ABE, et permettre ainsi à l’ABE d’évaluer le risque de différences d’interprétation ou de traitement d’un pays à l’autre.
Obligations de reporting et dérogations issues des RTS
Trois autres obligations de rapports découlent des normes techniques de réglementation sur l'authentification forte du client et la communication sécurisée (RTS SCA & CSC).
L’obligation d’authentification forte, exposée dans l'article 97 de la DSP 2, est précisée dans les RTS SCA & CSC. Les prestataires de services de paiement doivent appliquer l’authentification forte du client quand un payeur initie une opération de paiement électronique, accède aux informations sur ses comptes ou exécute une action grâce à un moyen de communication à distance, susceptible de comporter un risque de fraude en matière de paiement ou de toute autre utilisation frauduleuse. Les PSP doivent également protéger la confidentialité et l’intégrité des données de sécurité personnalisées de « l’utilisateur de services de paiement » (Payment Service User – PSU) et établir des normes ouvertes communes et sécurisées de communication, afin de sécuriser l’échange de données entre PSP. Dans cette optique, ils doivent prouver qu’ils mettent en œuvre ces mesures dans un rapport d’examen des mesures de
D’autre part, les RTS permettent aux teneurs de comptes (ASPSP) de ne pas appliquer l’authentification forte du client pour certaines opérations, dans un certain nombre de cas : lorsque les informations auxquelles on accède sont
Les ASPSP qui mettent en œuvre des interfaces d'échanges de données (Application Programming Interfaces – API) conformes à la DSP 2 peuvent quant à eux bénéficier d’une dérogation de screen-scraping, et ainsi imposer aux autres PSP d’accéder aux comptes de paiement de leurs clients via leurs propres API. Ils doivent respecter une série de critères pour bénéficier de la dérogation de fallback vers l’interface de l’utilisateur, avant de demander à leur Autorité compétente cette dérogation. Pour assister les PSP et Autorités compétentes, l’ABE a publié également un avis sur la mise en œuvre des RTS SCA &
Les textes fixent à quelle fréquence doit être produit chaque rapport, la première échéance à laquelle il doit être disponible, le mode de communication à l’Autorité responsable – l’information doit obligatoirement être disponible, mais elle peut être transmise de façon systématique ou sur demande de l’Autorité –, et enfin l’Autorité destinatrice, en règle générale l’Autorité compétente de l’État membre (AC), charge à elle de consolider l’information et de la communiquer à l’ABE (voir Repère 1). L’information sur le taux de fraude lié à la dérogation relative au faible risque d’une transaction, précisée dans l’article 18 des RTS, doit être communiquée à la fois à l’Autorité compétente et à l’ABE, ce qui dénote une vigilance particulière de l’ABE sur ce point.
Toutefois, la date de mise en ligne des API réglementaires pour les prestataires de services de paiement gestionnaires de comptes (ASPSP) souhaitant bénéficier dès le 14 septembre 2019 de la dérogation de fallback vers l’interface de l’utilisateur, et donc ne pas mettre en œuvre de solution de fallback, mécanisme de secours reposant sur le screen-scraping dans le cas où les API seraient indisponibles ou insuffisamment performantes, n’a pas été renseignée en raison de la diversité d’interprétation des régulateurs nationaux sur deux points. Le premier concerne leur délai de réponse à la demande de dérogation : la Financial Conduct Authority(FCA), régulateur en Grande-Bretagne, a fait savoir qu'il lui fallait un mois pour répondre aux demandes de dérogation de fallback, alors que l’ACPR, régulateur en France, a indiqué un délai de deux mois.
L'autre point sujet à interprétations concerne le délai de diffusion des API instaurées par la DSP 2 avant de pouvoir déposer la demande de dérogation de fallback. L’un des critères pour bénéficier de la dérogation de fallback est une large utilisation des API pendant trois mois. Certains régulateurs proposent que les ASPSP déposent leur demande de dérogation de fallback dès la mise en ligne de leurs API, et d’évaluer tous les autres critères en avance de phase, tandis que d’autres exigent que l’interface dédiée soit en ligne trois mois avant que l’ASPSP ne dépose sa demande de dérogation de fallback vers l’interface de l’utilisateur.
Quels rapports par quels acteurs ?
La DSP 2 concerne différents acteurs : prestataires de services de paiement gestionnaires de comptes (ASPSP), prestataires de services de paiement du bénéficiaire (ou acquéreur), agrégateurs de comptes (AISP), initiateurs de paiement (PISP), et prestataires de services de paiement émetteurs d’instruments de paiement liés à une carte (Card Based Payment Instrument Issuer – CBPII). Chacun de ces acteurs a l'obligation de fournir plusieurs rapports de conformité à la DSP 2 et aux RTS (voir Repère 2). La banque teneur de compte du client (ASPSP) est même concernée par l’ensemble de ces rapports. Cela traduit assez bien l’esprit de la DSP 2 selon lequel la responsabilité en matière de fraude incombe à l’ASPSP.
Enfin, certains acquéreurs souhaitant utiliser leur « faible » taux de fraude pour solliciter une dérogation d’authentification forte, il est sans doute dans leur intérêt d'être aussi en mesure de produire cette information.
Quel est le périmètre de chaque rapport ?
Les RTS SCA & CSC imposent plusieurs exigences fonctionnelles aux prestataires de services de paiement :
l'authentification forte du client (Strong Customer Authentication – SCA) : il s'agit de la combinaison de deux facteurs qui ne doivent pas appartenir à la même catégorie : possession, connaissance ou inhérence. Elle permet de sécuriser l’accès aux informations sur les comptes, les validations d’opérations de paiement et la manipulation de données de paiement sensibles ;
la dérogation de SCA : dans certains cas, tels qu'une opération de faible montant ou un paiement récurrent, le gestionnaire de compte peut ne pas exiger de son client une SCA ;
la confidentialité et l'intégrité des données de sécurité personnalisées (Personalised Security Credentials – PSC) de l'utilisateur de services de paiement : les facteurs d’authentification (couple identifiant-mot de passe de banque en ligne, code reçu par SMS, etc.) doivent être manipulés de manière sécurisée pendant tout leur cycle de vie, afin de garantir un niveau de sécurité suffisant ;
les normes ouvertes communes et sécurisées de communication (Common and Secure open standard of Communication – CSC) : le gestionnaire de comptes doit mettre en œuvre des API conformes, afin de pouvoir communiquer et échanger des données avec les nouveaux acteurs, agrégateurs de comptes et initiateurs de paiement ;
le taux de fraude : pour utiliser certaines dérogations et réaliser leur reporting de fraude, les prestataires de services de paiement doivent calculer leur taux de fraude, c’est-à-dire la valeur des opérations frauduleuses sur 90 jours par rapport à la valeur totale des opérations sur 90 jours. Ils doivent s’assurer qu’il est inférieur au taux de fraude de référence selon le type d’opération ;
les méthodes de calcul du taux de fraude : elles doivent être conformes aux exigences de l’ABE ;
l'analyse des risques en temps réel : un PSP qui souhaite utiliser la dérogation d’analyse des risques liés à la transaction doit, en plus du calcul de son taux de fraude, réaliser une analyse des risques en temps réel : contexte de la transaction, localisation du payeur, appareil utilisé, etc.
Chaque acteur peut ensuite déterminer dans quelle mesure ces exigences fonctionnelles s’intègrent aux différents rapports de conformité (voir Repère 3).
Un PSP qui souhaite utiliser la dérogation d’analyse des risques liés à la transaction
Enfin, chaque opération, paiement, accès aux informations sur les comptes ou opération à distance pouvant entraîner un risque de fraude, trouve place dans le périmètre des différents rapports (voir Repère 4).
L'ensemble des acteurs devront enfin veiller à la cohérence des processus mis en place pour effectuer les deux reportings sur les incidents de sécurité, l’un au titre de l'article 3 du Règlement général sur la protection des données (RGPD), l’autre au titre de l’article 96.1 de la DSP 2. Cette dernière impose un premier reporting quatre heures après la détection de l’incident, le RGPD au bout de 72 heures.
La collecte de ces données s'annonce assurément plus aisée pour les nouveaux entrants disposant d'un système d’information construit en tenant compte de la DSP 2, que pour les acteurs historiques, qui doivent extraire ces informations de nombreuses sources avant de les consolider.
Pour tous, préparer l'élaboration de ces nouveaux reportings, imposés par la DSP 2, nécessite une réelle anticipation et une vision transverse. Elle offre aussi l’occasion d’enrichir ses propres indicateurs de performance.
