PSD2 / Authentification forte du client :
La cryptographie au service de l'Open Banking et des paiements
| Région | UE/EEE, transposée dans le droit national par chaque État membre |
| Champ d'application | Prestataires de services de gestion de comptes (ASPSP) : banques et établissements détenant des comptes de paiement, tenus de mettre à disposition des API sécurisées et d’appliquer l’authentification forte (SCA) ; Prestataires de services d’initiation de paiement et d’information sur les comptes (PISP/AISP) : prestataires tiers accédant aux comptes dans le cadre de l’open banking ; Émetteurs et acquéreurs de cartes : appliquent l’authentification forte (SCA) aux transactions à distance, sans présentation de la carte, généralement via le protocole EMV 3-D Secure |
| Sections concernées | Directive (UE) 2015/2366, article 97 : Exigence d’authentification forte du client Règlement délégué (UE) 2018/389 : Normes techniques de réglementation (RTS) relatives à l’authentification forte du client (SCA) et aux communications communes et sécurisées Articles 5 à 9 des RTS : Liaison dynamique , indépendance des éléments d’authentification et exemptions |
Vue d'ensemble
L'exigence d'authentification forte du client prévue par la directive PSD2 s'applique depuis le 14 septembre 2019, conformément aux normes techniques réglementaires de l'Autorité bancaire européenne. Elle impose une authentification utilisant au moins deux éléments indépendants issus de trois catégories (connaissance, possession et caractéristique intrinsèque) pour la plupart des paiements électroniques à distance et des accès aux comptes, le code d'authentification ainsi généré étant lié de manière dynamique au montant spécifique du paiement et au bénéficiaire.
La directive PSD3 et le règlement sur les services de paiement qui l’accompagne suivent leur cours dans le cadre du processus législatif de l’UE, leur entrée en vigueur étant prévue, de manière réaliste, entre 2026 et 2028. Ces textes devraient affiner le cadre des exemptions et renforcer les exigences en matière d’authentification dans le cadre de l’open banking, mais l’obligation sous-jacente relative à l’authentification forte (SCA) reste en vigueur.
Pourquoi c'est important
Les infractions à la directive SCA, notamment les défaillances du lien dynamique et l'utilisation abusive de l'exemption relative à l'analyse des risques liés à la transaction, figurent toujours parmi les constatations les plus courantes dans le cadre de la surveillance exercée par l'autorité compétente nationale. Des processus d'authentification non conformes peuvent faire porter la responsabilité des transactions non autorisées sur le prestataire de services de paiement et l'exposer à des mesures coercitives directes.
L'open banking a élargi le champ d'application des éléments nécessitant une protection cryptographique : les API que les ASPSP mettent à la disposition des AISP et des PISP doivent, à part entière, répondre aux mêmes exigences de sécurité en matière de communication que les canaux destinés aux clients, généralement au moyen de certificats qualifiés conformes au règlement eIDAS.
En quoi cela s'applique-t-il à la cryptographie ?
La directive PSD2 / l’authentification forte des clients aborde la cryptographie à travers plusieurs domaines de contrôle étroitement liés. Les principaux domaines ayant des implications cryptographiques directes sont les suivants :
| Section | Fonction | Ce qu'il dit | Produits complémentaires |
| RTS, article 5 | Liaison dynamique des codes d'authentification | Un code d'authentification crypté, lié au montant précis du paiement et au bénéficiaire, empêchant toute relecture ou altération des détails de la transaction. | EJBCA |
| RTS, article 9 | Indépendance des éléments d'authentification | Un facteur de possession basé sur un certificat ou une clé, maintenu cryptographiquement isolé des facteurs de connaissance et d'inherentie utilisés conjointement avec lui. | EJBCA |
| RTS, articles 30 et 35 | Communication sécurisée pour les API de l'Open Banking | Certificats qualifiés pour l'authentification de sites web et les cachets électroniques (QWAC/QSealC), ainsi que l'TLS mutuelle permettant d'authentifier les sessions API entre les ASPSP et les TPP. | EJBCA |
| RTS, articles 22 à 23 | Confidentialité et intégrité des identifiants personnalisés | Gestion du cycle de vie des certificats et des clés protégeant les identifiants de sécurité personnalisés contre toute divulgation ou compromission. | Keyfactor Command |
| RTS, article 18 | Éléments probants relatifs à l'analyse des risques liés aux transactions | Justificatifs cryptographiques et d'authentification étayant les calculs documentés du taux de fraude nécessaires pour demander une exonération au titre de la TRA. | AgileSec |
| Recommandations relatives aux éléments sécurisés et à l'intégrité des applications | Intégrité des demandes de paiement | Des applications bancaires et de paiement mobiles signées, garantissant l’intégrité du facteur de possession qu’elles mettent en œuvre. | SignServer |
Préparation à l'audit
Les évaluations et les contrôles, qu'ils soient menés en interne, réalisés par une autorité de régulation ou examinés par un évaluateur indépendant, se concentrent sur les preuves concrètes plutôt que sur les simples déclarations de principe. Voici les principaux domaines sur lesquels les contrôleurs et les évaluateurs s'attardent généralement :
- Mise en œuvre de la liaison dynamique : le code d'authentification est-il lié de manière cryptographique au montant spécifique de la transaction et au bénéficiaire pour chaque paiement concerné ?
- Indépendance des facteurs d'authentification : les éléments de « possession », de « connaissance » et d'« inhérence » utilisés pour l'authentification forte (SCA) sont-ils véritablement indépendants les uns des autres ?
- Utilisation de certificats qualifiés pour les API d’Open Banking : les certificats QWAC et QSealC sont-ils utilisés et tenus à jour pour la communication via API entre les ASPSP et les TPP ?
- Documents relatifs aux dérogations au titre de l'analyse des risques transactionnels (TRA) : le calcul du taux de fraude et les pièces justificatives relatives à toute dérogation au titre de l'analyse des risques transactionnels sont-ils consignés par écrit et à jour ?
- Gestion du cycle de vie des identifiants personnalisés : les certificats et clés protégeant les identifiants de sécurité personnalisés font-ils l'objet d'une gestion formelle tout au long de leur cycle de vie (émission, renouvellement et révocation) ?
- Préparation aux normes PSD3 / PSR1 : L’organisation suit-elle de près le processus législatif relatif aux normes PSD3 et PSR1 concernant les modifications apportées à la loi sur la protection des données (SCA) et au cadre des exemptions ?
TRANSMETTEZ CELA À LA DIRECTION
Les défaillances liées à la liaison dynamique et l’utilisation abusive de l’exemption relative à l’analyse des risques liés aux transactions restent les principales constatations des contrôles prudentiels nationaux, sept ans après l’entrée en vigueur obligatoire de la directive SCA. Une mauvaise gestion de ces aspects ne constitue pas un risque théorique : elle fait peser sur nous la responsabilité des transactions non autorisées.
La directive PSD3 va entrer en vigueur, mais elle maintient l'obligation fondamentale prévue par la directive SCA au lieu de la remplacer ; il n'y a donc aucune raison d'attendre son entrée en vigueur pour combler les lacunes dont nous avons déjà connaissance, notamment en ce qui concerne la manière dont nos codes d'authentification sont associés aux détails des transactions et la manière dont nos justificatifs d'exemption au titre de la directive TRA sont documentés.
Conformités associées
Règlement général sur la protection des données (RGPD)
Loi sur la résilience opérationnelle numérique (DORA)
