1. La technicisation du droit (nous parlons bien du droit, non des opérations) des services de paiement est en marche ; à moins qu’il s’agisse plutôt de régulation technologique de l’activité de paiement. Quoi qu’il en soit, la DSP 2 est presque éclipsée par l’un de ses textes d’application, certes pas le moins important, le « fameux » (il l’est devenu à force de s’être fait attendre et de nourrir nombre de commentaires) règlement portant normes communément connues par leurs acronymes anglais : SCA (strong customer authentification) et CSC (common and secure open standards of communication).
De fait, deux des innovations majeures portées par la DSP 2 sont suspendues (jusqu’au 14 septembre 2019,
Telles seront, logiquement, les deux parties de ce commentaire, même si elles ne correspondent pas tout à fait au plan
I. L’authentification forte du
A. Exigences d’authentification forte
2. L’exigence générale d’authentification forte du
3. Sans entrer dans un détail qui serait indigeste, les mesures de sécurité propres à assurer l’authentification forte du client sont, d’une part, la génération d’un code d’authentification (Règl., art. 4) et, d’autre part, pour les opérations de paiement électronique à distance, l’établissement d’un lien dynamique entre l’opération, le montant et le bénéficiaire donnés (Règl., art. 5).
Viennent ensuite des exigences propres aux trois éléments constitutifs d’une authentification forte (dès lors que deux, au moins, soient réunis) : connaissance, possession et inhérence, destinées à les protéger contre tout usage par des tiers non autorisés (Règl., art. 6 à 8) ou contre le risque que la compromission de l’un ne rejaillisse sur les autres (Règl., art. 9).
B. Dérogations à l’obligation d’authentification forte
4. Conformément aux prescriptions de l’article 98, 1, b) et 3 de la DSP 2, des dérogations au principe d’authentification forte du client ont été définies sur la base du niveau de risque lié au service fourni, des montant et caractère récurrent de l’opération et du moyen utilisé pour exécuter l’opération de paiement (Règl., cons. 9 et art. 1er, b). Le bénéfice desdites dérogations suppose toutefois que les PSP contrôlent, et reportent à leur autorité de contrôle et à l’ABE, la valeur des opérations frauduleuses ou non autorisées, comparée avec les taux de fraude générale (Règl., cons. 15 et art. 21).
Encore faut-il rappeler que le prix de la dérogation est élevé : « Lorsque le prestataire de services de paiement du payeur n’exige pas une authentification forte du client, le payeur ne supporte aucune perte financière éventuelle à moins qu’il ait agi frauduleusement. Lorsque le bénéficiaire ou son prestataire de services de paiement n’accepte pas une authentification forte du client, il rembourse le préjudice financier causé au prestataire de services de paiement du payeur » (DSP 2, art. 74, 2).
Dérogation par nature
5. On la trouve, non pas dans le « dur » des articles du règlement, mais à son considérant 8, ainsi rédigé : « En raison même de leur nature, les paiements effectués par l'intermédiaire d'instruments de paiement anonymes ne sont pas soumis à l'obligation d'authentification forte du client. Lorsque le caractère anonyme de ces instruments est supprimé pour des motifs contractuels ou législatifs, ces paiements sont soumis aux exigences de sécurité qui découlent de la directive (UE) 2015/2366 et de cette norme technique de réglementation ».
Voilà une considération qui pourrait redonner de l’utilité à quelques moyens de paiements anonymes : monnaie électronique (mais demeure-t-il encore un peu d’anonymat chez celle-ci ?), voire monnaies virtuelles (mais peut-on encore s’autoriser à les nommer
Dérogations particulières
6. Les dérogations particulières sont au nombre de huit.
7. Information sur les comptes : sauf lorsque l’utilisateur de services de paiement accède pour la première fois en ligne à ses informations de compte, les PSP peuvent s’affranchir de toute authentification forte du client dès lors que 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 (Règl., art. 10, à la rédaction plus que confuse).
8. Paiement sans contact au point de vente : il peut être dérogé à l’authentification forte par les PSP si (i) le montant individuel de l’opération de paiement n’excède pas 50 euros, (ii) le montant cumulé depuis la dernière authentification forte ne dépasse pas 150 euros et (iii) et le nombre d’opérations sans contacts depuis une telle authentification ne va pas au-delà de cinq (Règl., art. 11).
9. Opérations à distance de faible valeur : on retrouve la même logique de seuils que l’hypothèse précédente, la dérogation étant ici acquise si (i) le montant de l’opération de paiement ne dépasse pas 30 €, (ii) le montant cumulé demeure inférieur ou égal à 100 € et (iii) le nombre des précédentes opérations depuis la dernière authentification forte du client n’excède pas cinq (Règl., art. 16).
10. Automates de paiement des frais de transport et de parking : la dérogation est inconditionnelle, évidemment liée à une raison pratique (Règl., 12).
11. Opérations récurrentes : après qu’un payeur, sous authentification forte, a créé, modifié ou initié une série d’opérations récurrentes ayant le même montant et le même bénéficiaire, l’initiation des opérations ultérieures est dispensée d’une telle authentification (Règl., art. 14).
12. Bénéficiaire de confiance : dans la même veine, une fois qu’une liste de bénéficiaires de confiance a été créée ou modifiée par l’intermédiaire de son prestataire de services de paiement gestionnaire de compte (PSPGC) appliquant l’authentification forte, celle-ci ne sera plus requise lorsque le payeur initiera une opération de paiement au profit d’un bénéficiaire figurant dans cette liste (Règl., art. 13).
13. Virements internes : où l’on s’aperçoit combien l’authentification forte a été érigée en principe cardinal, puisqu’il ne pourra y être dérogé que pour un virement à soi-même (le payeur et le bénéficiaire sont la même personne physique ou morale) et entre comptes détenus par le même PSPGC (Règl., art. 15).
14. Procédures et protocoles de paiement sécurisés utilisés par les entreprises : voici une dernière dérogation particulière ajoutée par la Commission européenne par rapport à la proposition de l’ABE : l’exigence d’authentification forte cède devant des protocoles ou procédures réservés à des payeurs personnes morales lorsque (la formule est savoureuse) « 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 » (Règl., art. 17).
Dérogation par les risques
15. La chose est inédite : une analyse (« en temps réel » nous dit le considérant 14, confirmé par le c) de l’article 18) des risques liés à une opération de paiement électronique initiée à distance par le payeur permet aux PSP de s’affranchir de l’obligation d’authentification forte du client s’ils jugent l’opération à faible niveau de risque (Règl., art. 18).
On passe sur les multiples conditions, règles de calcul des taux de fraude (Règl., art. 19), étalonnage du montant de l’opération par rapport à la valeur-seuil de dérogation correspondante fixée dans un tableau en annexe du règlement, etc. : tout cela est bien compliqué sur le papier, mais que des outils (RegTechs ?) traiteront à coup sûr.
Notons cependant, à l’heure de l’entrée en application prochaine du règlement général sur la protection des données (RGPD), que ce "risk scoring" va très loin : analyse comportementale du payeur (Règl., art. 18, 2, c), i)), localisation anormale de celui-ci ou présentant des risques élevés concernant le bénéficiaire (art. 18, 2, c), v) et vi)), habitudes de dépenses antérieures (art. 18, 3, a)), etc. Tout, vous saurez tout, non plus seulement sur les utilisateurs de réseaux sociaux, mais aussi sur ceux de services de paiement ! L’ironie (peut-être) veut que le considérant 14 du règlement annonce que l’analyse des risques liés à l’opération de paiement entend garantir la sécurité des fonds « et des données à caractère personnel de l’utilisateur de services de paiement ».
16. Qu’on se le dise, l’analyse fondée sur les risques ne sera bientôt plus réservée à la mesure des seules obligations de lutte contre le blanchiment des capitaux et le financement du terrorisme, mais gagnera donc celle de la fraude aux opérations de paiement. Gageons qu’une cartographie des risques, au sens de la LCB-FT, sera bientôt requise, en amont de cette disposition terminale de l’article 18 du règlement, qui promet un dispositif de contrôle interne d’un raffinement poussé : « L'évaluation du prestataire de services de paiement intègre l'ensemble de ces facteurs liés aux risques dans une note de risque, attribuée à chaque opération individuelle, qui permet de déterminer s'il convient d'autoriser un paiement spécifique sans authentification forte du client ».
C. Encadrement des données de sécurité personnalisées
17. On rappelle qu’aux termes de l’article 4, 31) de la DSP 2, les données de sécurité personnalisées sont des « données personnalisées fournies à un utilisateur de services de paiement par le prestataire de services de paiement à des fins d’authentification » et forment un sous-ensemble des « données de paiement sensibles ». Elles sont ainsi au cœur du volet « authentification » du présent règlement, qui dès son considérant 1er observe : « La procédure d'authentification devrait comprendre, en règle générale, des mécanismes de contrôle des opérations permettant de déceler les tentatives d'utiliser les données de sécurité personnalisées d'un utilisateur de services de paiement qui ont été perdues, volées ou détournées et devrait également garantir que l'utilisateur de services de paiement est l'utilisateur légitime et donne dès lors son consentement au transfert de fonds et à l'accès aux informations sur son compte au travers d'une utilisation normale des données de sécurité personnalisées ».
18. Pèse en conséquence sur les PSP l’exigence 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., art. 22) : création et transmission des données, association avec l’utilisateur de services de paiement, livraison des données, des dispositifs et du logiciel d’authentification, renouvellement des données, enfin destruction, désactivation et révocation des données, des dispositifs et du logiciel (Règl., art. 23 à 27).
Ce sont autant de mesures destinées à lutter contre la fraude : utilisation non autorisée ou frauduleuse d’instruments de paiement, accès non autorisé à des comptes de paiement (Règl., cons. 18). Le présent règlement est bien un texte sur la fraude, qui devrait ainsi concerner toute utilisation détournée des « données de paiement sensibles », au sens où la DSP 2 définit celles-ci (mais la définition est bien large) comme des « données, y compris les données de sécurité personnalisées, qui sont susceptibles d’être utilisées pour commettre une fraude » (art. 4, 32)). De sorte qu’il faudra veiller à coordonner le présent règlement avec les orientations sur le reporting de la fraude en cours d’élaboration par l’ABE.
II. La communication commune, ouverte et sécurisée
19. Communication « sécurisée », mais aussi, et d’abord, « commune » et « ouverte », voilà ce qu’il faut retenir. L’objectif immédiat est que communiquent entre eux « les acteurs concernés dans le contexte des services d'information sur les comptes, des services d'initiation des paiements et de la confirmation de la disponibilité des fonds » (Règl., cons. 19) : où l’on retrouve bien l’ouverture (des comptes à ceux qui ne les tiennent pas), la nécessité de standards communs, doublées par une évidente exigence de sécurité. Mais, néanmoins, pas de « toute ouverture » : le considérant 19 du règlement précise bien qu’il ne modifie pas les règles d’accès aux comptes qui ne sont pas des comptes de paiement. On touche là l’ambiguïté fondamentale de la DSP 2 : ouvrir l’accès aux autres comptes que les seuls comptes de paiement ne peut se prévaloir d’un texte qui ne couvre que le paiement ; mais ne pas le faire conduit à laisser à « l’état sauvage » l’accès en « screen scraping » aux autres comptes que le compte de paiement. Pour l’heure, observons que les sénateurs français ont estimé opportun de créer un nouvel article L. 522-7-2 du Code monétaire et
A. Identification et traçabilité
20. En amont des règles relatives aux interfaces d’accès, sont posées deux exigences générales de communication, l’une relative à l’identification, l’autre à la traçabilité.
21. Identification, d’abord, dans la mesure où les PSP doivent 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 (Règl., art. 28, 1).
22. Traçabilité, ensuite, en ce sens que lesdits PSP sont encore tenus de 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, i. e. que « l’ensemble des événements en rapport avec l’opération électronique durant ses différentes phases soient connus a posteriori » (Règl., art. 29, 1). Rien que cela…
B. Interfaces d’accès
23. Après les cas de dérogations à l’authentification forte du client, voici sans doute que nous entrons dans le vif du règlement, dont les articles 30 à 33 posent les obligations et mesures relatives aux interfaces.
Mécanisme général
24. Des importants considérants 20 à 25 du règlement, on retient ceci :
- les PSPGC ont l’obligation de proposer au moins une interface d’accès permettant une communication sécurisée (identification et authentification) avec les prestataires de services d’initiation de paiement (PSIP), les prestataires de services d’information sur les comptes (PSIC) et les émetteurs d’instruments de paiement liés à une carte ;
- toutefois, les PSPGC demeurent libres de faire le choix entre proposer une interface dédiée à cette communication (« l’interface dédiée ») ou recourir à l’interface servant à l’identification (ainsi qu’à l’authentification et à la communication avec) des utilisateurs de services de paiement (« l’interface utilisateurs ») ;
- sachant que l’interface dédiée doit présenter le même niveau de disponibilité et de performance que l’interface utilisateurs, faute de quoi un « mécanisme de secours » (lequel a fait couler beaucoup d’encre), strictement encadré, sera mis en œuvre afin de permettre aux trois prestataires sans compte d’utiliser l’interface utilisateurs ;
- ce à quoi s’ajoute que si les interfaces ne sont pas au niveau, des mesures doivent être prises afin d’assurer la continuité des activités d’initiation de paiement et d’information sur les comptes au profit des utilisateurs, les prestataires, de leur côté, ne devant pas être bloqués ou entravés dans la prestation de leurs services.
Obligations générales
25. Le PSPGC qui propose à un payeur un compte de paiement accessible en ligne aura bientôt l’obligation de mettre en place au moins une interface répondant à chacune des deux exigences suivantes :
- les trois
PSP sans compte devront en premier lieu être en mesure de s’identifier auprès du PSPGC ;[9] - PSIP et PSIC, en second lieu, devront pouvoir communiquer de manière sécurisée, afin chacun d’offrir leurs services (Règl., art. 30, 1).
26. Quant à l’interface elle-même, les points 3 à 6 de l’article 30 du règlement en détaillent les exigences en termes de normalisation, de documentation des spécifications techniques, de mise à disposition (au moins six mois avant la date d’entrée en application du règlement ou de la date de lancement postérieur d’une interface), de modification (préavis d’au moins trois mois) et de dispositif d’essai (six mois encore).
Un fort principe de continuité est enfin posé : au cas où un PSPGC ne respecterait pas l’ensemble des exigences relatives à la ou aux interfaces, pouvoir est donné aux autorités compétentes pour que la prestation d’initiation de paiement ou d’information sur les comptes ne soit pas empêchée ou perturbée, dans la mesure du mécanisme de secours prévu à l’article 33 (cf. infra).
Interface dédiée
27. Comme nous l’avons évoqué plus haut, les PSPGC disposent de l’« option interface » suivante : soit ils mettent en place une interface dédiée, soit ils permettent aux trois PSP sans compte d’utiliser les interfaces servant à l’authentification et à la communication avec les utilisateurs de services de paiement (Règl., art. 31).
28. Lorsqu’un PSPG a fait le choix de développer une interface dédiée, le principe est celui de son étalonnement sur l’interface utilisateurs : celle-là doit offrir à tout moment le même niveau de disponibilité et de performances que celle-ci, de même que les indicateurs de performance clés et les valeurs cibles de niveau de service sont aussi exigeants. Partant, il est exigé des PSPGC éditeurs d’une interface dédiée de veiller à ce qu’elle n’entrave pas la prestation de services d’initiation de paiement ou d’information sur les comptes, entraves pouvant être caractérisées – ce n’est pas anodin – par une 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 (Règl., art. 32, 1 à 3).
On notera encore que les PSPGC sont tenus de contrôler la disponibilité et les performances de l’interface dédiée, à quoi s’ajoute l’obligation de publier sur leur site internet des statistiques trimestrielles concernant la disponibilité et les performances de l’interface dédiée… et de l’interface utilisateurs (Règl., art. 32, 4).
29. La crainte fut un temps que, à titre de mesure d’urgence, sous la forme d’un mécanisme de secours (fallback mechanism), les PSP sans compte puissent revenir au screen scraping, comme une sorte d’accès direct aux comptes , via login et mot de passe de l’utilisateur. Telle n’est cependant pas la voie empruntée par l’article 33 du règlement (on voit mal comment il aurait pu en être autrement) qui, en cas d’indisponibilité imprévue ou de panne de l’interface (présumée lorsqu’un PSIP ou un PSIC demande l’accès cinq fois consécutives aux informations de compte sans obtenir de réponse dans les trente secondes), autorise lesdits PSP à 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.
Notons enfin que 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 tout point conforme à l’ensemble des obligations de l’article 32 ; qui a été conçue et testée conformément à l’article 30, 5, à la satisfaction des PSP sans compte, lesquels l’ont ensuite utilisée largement pendant trois mois ; enfin, que tout problème a été résolu sans retard injustifié (Règl., art. 33, 6).
C. Certificats et sécurité des données
30. Et puis voici qu’intervient le règlement
Lesdits certificats contiendront, sans nuire à leur interopérabilité ni à leur reconnaissance, des attributs spécifiques supplémentaires concernant d’une part le rôle du PSP (gestion de comptes, initiation de paiement, information sur les comptes ou instruments de paiement liés à une carte), d’autre part le nom des autorités compétentes auprès desquelles le PSP est enregistré (Règl., art. 34, 3).
31. Un certain nombre de règles de sécurité sont enfin posées aux articles 35 et 36 du règlement, desquelles nous retiendrons :
- la nécessité d’un cryptage avancé des sessions de communication mis en place par les « parties communicantes » (Règl., art. 35, 1) ;
- une sorte de principe de « minimisation » qui veut que les sessions d’accès aux comptes soient les plus brèves possibles (Règl., art. 35, 2) ;
- la réaffirmation de la règle de non-discrimination, contenue dans la DSP 2 (art. 65, 66 et 67), qui oblige le PSPGC à fournir à chacun des trois PSP sans compte les mêmes informations que celles dues aux utilisateurs de services de paiement (Règl., art. 36, 1).
Achevé de rédiger le 19 avril 2018.
