Un petit tour du côté de la DSP 2

Contexte de la DSP 2

Avec l’entrée en vigueur ce 14 septembre 2019, de la 2ème Directive sur les Services de Paiement, plus connue sous le doux nom de DSP 2, les journaux n’auront jamais autant parlé de monétique, avec des raccourcis légèrement erronés mais qui ont certes le mérite d’être plus racoleurs.

Si vous suivez l’actualité monétique, peut-être vous souvenez-vous que la DSP2 est déjà en vigueur depuis le 13 janvier 2018. Pour bien comprendre, cette article retrace l’historique de la mise en place de la DSP2 et ce qui change (ou pas…) depuis le 14 septembre 2019, afin d’y voir plus clair.

La directive 2015/2366 du Parlement européen et du Conseil du 25 novembre 2015 (nom officiel de la DSP 2), est un texte juridique européen qui s’applique à l’ensemble des États membres de l’Union, visant principalement à renforcer la sécurité des paiements en ligne. Ce texte abroge la DSP 1 écrite 8 ans plus tôt.
Pour être applicable dans les États membres, cette Directive, comme toutes les autres, doit être transposée en droit souverain. Toutefois, les dispositions relatives à l’authentification forte (impact B2C) et à la communication sécurisée entre les prestataires de services de paiement (PSP) tiers et gestionnaires de comptes (impact B2B), décrites dans les articles 65, 66, 67, 97 méritaient des règles plus claires et plus précises et ont donc fait l’objet de normes techniques de réglementations (RTS en anglais) par l’ABE (Autorité Bancaire Européenne).

La transposition de la DSP 2 s’est faite par l’ordonnance n°2017-1252 du 9 août 2017 qui a d’ailleurs fortement impacté le Code Monétaire et Financier et est entrée en vigueur le 13 janvier 2018. Parallèlement, l’ABE a publié 3 séries d’orientation pour préciser les exigences de la DSP 2 : sur les mesures de sécurité pour les risques opérationnels et de sécurité, sur la notification des incidents majeurs, sur les exigences de déclarations de données relatives à la fraude.
Quant aux RTS (RTS Strong Customer Authentication and Common and Secure Communication), elles ont été adoptées le 27 novembre 2017 par la Commission européenne, publiées au Journal Officiel de l’UE le 13 mars 2018 et sont entrées en vigueur 18 mois plus tard, soit le 14 septembre 2019 ; à l’exception de 2 paragraphes permettant de donner les moyens aux PSP de s’interconnecter avec les comptes de paiements du gestionnaire de comptes (article 30 paragraphe 3 et 5) qui eux, sont applicables depuis le 14 mars 2019.

Qu’est-ce qui change depuis le 14 septembre 2019 ?

Depuis le 14 septembre 2019, les fameuses RTS sont entrées en vigueur. Ainsi s’applique désormais pleinement la DSP 2.
Toutefois, l’ABE ayant publié un avis le 21 juin 2019 (EBA Opinion on SCA elements under PSD2) qui, devant la complexité de la mise en place de l’authentification forte, autorise les autorités nationales compétentes à octroyer un délai supplémentaire aux acteurs concernés. Ainsi l’ACPR a accordé un délai supplémentaire de 3 ans pour la mise en conformité totale des RTS.

Que contiennent ces RTS ?

Ces normes techniques de réglementation précisent les mesures de sécurité pour l’authentification forte du client et les dérogations, encadre les données de sécurité personnalisées des utilisateurs (ie les codes d’authentification) pour assurer la confidentialité et l’intégrité, ainsi que les normes ouvertes communes et sécurisées de communication.

Authentification forte

L’authentification forte, au sein de la DSP2, consiste en la vérification d’au moins deux éléments parmi les catégories :

  • ce que je connais (connaissance) : un mot de passe, un code PIN, …
  • ce que je possède (possession) : une carte à puce, un smartphone, …
  • ce que je suis (inhérence) : empreinte digitale, empreinte vocale, …

En cas d’authentification forte, un code d’authentification est généré. Ce code n’est bien évidemment valable qu’une fois.

La DSP 2 impose l’authentification forte dès lors que le porteur accède à son compte, initie une opération de paiement, ou qu’une action est susceptible de présenter un risque de fraude (lorsque réalisé à distance comme internet).
Toutefois, les RTS listent également un certain nombre de cas où l’authentification forte n’est pas requise (paiements sur les automates de parking, sans contact (si inférieur à 50 euros et que le nombre de transactions non authentifiées est strictement inférieur à 5 ou que le montant associé est strictement inférieur à 150 euros, paiements vers des bénéficiaires de confiance, opérations récurrentes, virements entre comptes d’un même porteur au sein d’un même prestataire, opérations de faible valeur, opération présentant un faible niveau de risque).
Vous aurez sans doute fait ici le lien avec le projet 3D Secure 2.0.

Confidentialité et intégrité

Les prestataires de services de paiement ont l’obligation de confidentialité et d’intégrité. Les RTS listent précisément les obligations attendues en matière de sécurité des données de sécurité personnalisées (code d’authentification). Pas grand-chose d’autres à ajouter d’un point de vue monétique.

Normes ouvertes communes et sécurisées de communication

Les RTS imposent aux prestataires de services de paiement une traçabilité de toutes les interactions avec le porteur, avec les autres entités (PSP tiers, commerçants, …).
Les RTS indiquent également les exigences de sécurité concernant les interfaces d’accès aux comptes de paiement pour les initiateurs de paiement ou les agrégateurs de comptes bancaires.

Contrairement à ce qui est dit, il ne risque donc pas y avoir beaucoup de changement le 14 septembre 2019. La transition se fera en douceur : mars 2021 pour la majorité des transactions et septembre 2022 pour la totalité. En attendant, le bon vieux 3D Secure avec l’envoi d’un code à usage unique par SMS pour prouver que l’on est détenteur du téléphone (catégorie « ce que l’on possède ») est toléré.

5 commentaires à propos de “Un petit tour du côté de la DSP 2”

  1. A noter que qu’à partir du 1er avril 2020, les e-commerçants doivent initier un processus d’authentification (systématiquement sur le scheme CB) ou bénéficier d’une dérogation (schemes Visa/ MC), si l’opération de paiement est dans le scope des RTS SCA.

    Si le processus d’authentification n’est pas initié par le commerçant, alors la demande d’autorisation risque d’être refusée par l’émetteur.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.