1. Conjonction… et disjonction.
Soit, d’une part, entré en application le 13 janvier 2018, un texte majeur (du moins dans son domaine) : la DSP 2[1], majeur en ceci qu’il fait entrer de plain-pied sur la scène juridique les données de compte, les données de paiement, toutes massivement à caractère personnel, sans quoi elles n’intéresseraient pas ceux qui les convoitent. Cela a un nom : l’open banking, la DSP 2 pouvant être considérée comme le premier grand texte de réglementation, en même temps que de consécration, de ce phénomène proprement remarquable d’ouverture des comptes de paiement, et de leurs données, à d’autres qui ne les tiennent pas, le tout à la main (faut-il l’espérer tremblante, comme elle devrait l’être avant de s’engager dans un acte grave ?) du payeur, titulaire du ou des comptes.
Soit, d’autre part, applicable à compter du 25 mai 2018, le règlement que l’on attendait depuis vingt ans : le RGPD[2], qui est de toutes les conversations – y compris Outre-Atlantique –, comme si la protection (mais n’oublions pas leur libre circulation) des données à caractère personnel était devenue le symbole de l’esprit juridique européen, sa réglementation son chef-d’œuvre[3]. À telle enseigne que l’on avait presque oublié qu’existaient aussi et encore, et même en nombre, des données non personnelles, qu’un tout petit règlement traite désormais : le règlement (UE) 2018/1807 du 14 novembre 2018 établissant un cadre applicable au libre flux des données à caractère non personnel dans l’Union européenne[4].
La conjonction entre DSP 2 et RGPD est ainsi un événement considérable, l’événement de l’année 2018, dont les conséquences iront bien au-delà de celle-ci, ne serait-ce que pour trouver les clés d’articulation entre la directive et le règlement. Mais, assez curieusement somme toute, disjonction aussi, dans la mesure où la DSP 2 n’est pas, faute d’un petit décalage (aurait-on pu le combler ?), « GDPR by design ». Presque contemporaine du RGPD, la DSP 2 se réfère en effet encore à l’antique directive de 1995, en particulier lorsque son article 94 dispose que « la communication aux personnes d’informations sur le traitement des données à caractère personnel et le traitement de ces données à caractère personnel ainsi que tout autre traitement de données à caractère personnel aux fins de la présente directive sont effectués conformément à la directive 95/46/CE et aux règles nationales transposant ladite directive, ainsi qu’au règlement (CE) n° 45/2001 ». Et ce n’est pas l’artifice de cet autre article 94 (du RGPD cette fois : « Les références faites à la directive abrogée s’entendent comme faites au présent règlement ») qui permettra de réduire l’anachronisme.
2. Des difficultés d’articulation ? La question de l’articulation entre les deux textes s’est vite posée. On se souvient que, en mars 2018, dans sa FinTech Roadmap, l’Autorité bancaire européenne (ABE ou EBA) se préoccupait de l’interaction entre la DSP 2 (PSD2) et le RGPD (GDPR) : « the EBA will monitor potential clarifications that may be provided by the European Parliament, the Council of the EU, the Commission or other EU authorities on the interaction between PSD2 and the GDPR, in order to assess what, if any, implications such clarifications may have on the EBA, national authorities, consumers and/or payment service providers »[5].
Difficultés d’articulation[6] ? En tout cas complexité, a répondu le nouveau European Data Protection Board (EDBP), aux termes d’une lettre (PSD2 Letter) qui n’est pas passée inaperçue parmi les professionnels et annonce d’emblée : « The legal framework regarding the protection of personal data in the context of PSD2 is complex and developments in this regard are therefore being monitored by the EDPB[7]. » On y reviendra.
3. Plan. Il ne fait guère de doute que la donnée acquiert un véritable « statut » dans la DSP 2, au sens étymologique qu’elle s’y « tient debout » et, ce faisant, fait l’objet de diverses règles et régimes de protection. Partant, la donnée est l’objet de règles de « gouvernance », terme ayant acquis droit de cité, notamment en matière bancaire et financière.
Statut (I.) et gouvernance (II.) de la donnée dans la DSP 2 – plutôt dans la DSP 2 telle que transposée dans notre Code monétaire et financier (CMF) – à l’heure du RGPD seront sans surprise les deux thèmes de cette contribution, qui sera loin de les épuiser.
I. Statut de la donnée
4. Catégorisation. La donnée ou, plutôt, les données, doit-on dire, car à lire la DSP 2, il nous est apparu que la donnée se présente sous divers aspects. Les données sont en effet diversement nommées (1.) ; il est ensuite des cas où les données apparaissent comme nécessaires ou obligées (2.) et, enfin et surtout, d’autres cas où elles sont convoitées, convoitise de l’open banking à l’origine de la deuxième génération de DSP (3.).
1. Données nommées
5. Données de sécurité personnalisées.
On ne parle dorénavant plus de « dispositif » mais de « données de sécurité personnalisées », qui s’entendent « des données personnalisées fournies à un utilisateur de services de paiement par le prestataire de services de paiement à des fins d’authentification » (CMF, art. L. 133-4, a), issu de DSP 2, art. 4, 31)).
Données d’authentification, les données de sécurité personnalisées sont naturellement au cœur du dispositif de la DSP 2, non seulement pour protéger les fonds des utilisateurs de services de paiement et pour limiter les risques de fraude, mais aussi et avant tout afin d’empêcher l’accès non autorisé au compte de paiement[8]. Si bien que les nouveaux acteurs d’accès aux comptes, eux-mêmes nommés de manière inédite – prestataires de services d’initiation de paiement (PSIP) et prestataires de services d’information sur les comptes (PSIC), faisant ressortir la catégorie nouvelle des prestataires de services de paiement gestionnaires de comptes (PSPGC) – doivent spécialement veiller à ce que lesdites données ne soient pas accessibles à d’autres que leur titulaire et leur émetteur, le plus souvent PSPGC (CMF, art. L. 133-40 et L. 133-41, issus de DSP 2, art. 66 et 67).
On n’oublie pas, enfin, que la confidentialité et l’intégrité des données de sécurité personnalisées font l’objet de normes techniques de réglementation (dites « RTS ») particulières, prévues aux articles 22 et suivants du fameux règlement délégué 2018/389 du 27 novembre 2017 complétant la DSP 2 par des normes techniques de réglementation relatives à l’authentification forte du client et à des normes ouvertes communes et sécurisées de communication, concernant tant leur création et transmission, association avec l’utilisateur, livraison, renouvellement, et destruction, désactivation et révocation.
6. Données de paiement sensibles. Nous avons déjà eu l’occasion de le dire, leur définition est décevante, dans la mesure où ce sont toutes données (y compris de sécurité personnalisées) « qui sont susceptibles d’être utilisées pour commettre une fraude » (CMF, art. L. 133-4, g) issu de DSP 2, art. 4, 32)).
Quoi qu’il en soit, et alors même que leur occurrence, dans la DSP 2, est limitée, il faut remarquer que la protection des données de paiement sensibles fait désormais partie des exigences premières d’un dossier d’agrément de prestataire de services de paiement (PSP) : « Pour délivrer l’agrément à un établissement de paiement, l’Autorité de contrôle prudentiel et de résolution vérifie que, compte tenu de la nécessité de garantir une gestion saine et prudente de l’établissement de paiement, celui-ci dispose pour son activité de prestation de services de paiement d’une gouvernance et d’un contrôle interne adéquat, des dispositifs à même d’assurer la sécurité des services de paiement fournis, ainsi que la protection des données de paiement sensibles » (CMF, art. L. 522-6, II, al. 1er, issu de DSP 2, art. 5,1, g))[9]. Prescription relative à la protection des données de paiement sensibles que l’on trouve détaillée dans les importantes orientations de l’ABE sur les informations à fournir pour l’agrément d’établissement de paiement (EP) et d’établissement de monnaie électronique (EME) et pour l’enregistrement de PSIC au titre de l’article 5, paragraphe 5, de la DSP 2.[10].
Les données de paiement sensibles, faut-il encore observer, sont soustraites aux PSIP et PSIC : les premiers ne peuvent les stocker (CMF, art. L. 133-40, II, 5°, issu de DSP 2, art. 66, 3, e)), les seconds les demander (CMF, art. L. 133-41, II, 5°, issu DSP 2, art. 67, 2, e)), étant précisé que, vis-à-vis des uns et des autres, dans le cadre de leur activité, le nom du titulaire du compte et le numéro du compte (IBAN) n’en constituent exceptionnellement pas.
7. Données à caractère personnel. Leur irruption, dans la DSP 2 et, par voie de conséquence, dans le CMF, est sans nul doute une affaire importante.
Jugeons sur pièces :
– un principe général, d’abord, exigeant nécessité et consentement exprès : « Les prestataires de services de paiement n’ont accès à des données à caractère personnel nécessaires à l’exécution de leurs services de paiement, ne les traitent et ne les conservent qu’avec le consentement exprès de l’utilisateur de services de paiement » (CMF, art. L. 521-5, issu de DSP 2, art. 94, 2) ;
– une permission légale, ensuite : « Les systèmes de paiement et les prestataires de services de paiement sont autorisés à traiter des données à caractère personnel lorsque cela est nécessaire pour garantir la prévention, la recherche et la détection des fraudes en matière de paiements. […] » (CMF, art. L. 521-6, issu de DSP 2, art. 94, 1) ;
– la compétence exceptionnelle (car dérogatoire à celle de l’ACPR) de la CNIL, enfin : « Par dérogation aux dispositions de l’article L. 612-1, la Commission nationale de l’informatique et des libertés veille au respect des dispositions des articles L. 521-5 et L. 521-6 en utilisant les compétences qui lui sont reconnues par le règlement (UE) 2016/679 du Parlement européen et du Conseil. À cette fin, elle peut notamment recevoir, par tous moyens, les plaintes relatives aux infractions aux dispositions des articles L. 521-5 et L. 521-6 » (CMF, art. L. 561-7).
L’observatoire de la sécurité des moyens de paiement a ainsi pu observer, dans son rapport annuel 2017, que « le RGPD s’applique dans son intégralité aux traitements de données à caractère personnel effectués par les prestataires de services de paiement (PSP), que ces traitements relèvent ou non de la DSP 2. Par exemple, les PSP doivent se conformer aux obligations de documentation (registre et étude d’impact relative à la protection des données, le cas échéant), de pertinence des données par rapport à l’objectif poursuivi, ou encore d’information préalable quant aux caractéristiques des traitements, et enfin de respect des droits d’accès, d’opposition, etc. » (p. 18, encadré 3).
2. Entre données nécessaires et données obligées
8. Données nécessaires à l’exécution des services de paiement et à la lutte contre la fraude. Nous revenons par là aux données à caractère personnel, dont le traitement, dorénavant, suppose qu’elles soient, de manière générale, nécessaires à l’exécution des services de paiement ou, particulièrement, nécessaires à la lutte contre la fraude. En observant à cet égard que l’article 96, 6 de la DSP 2 fait obligation aux PSP de fournir, au moins annuellement, à leurs autorités compétentes, des données statistiques relatives à la fraude liée aux différents moyens de paiement ; obligations que des orientations adoptées par l’ABE le 17 septembre 2018 sont venues éclairées[11].
Où l’on retrouve, non sans contradiction on le verra, l’exigence de nécessité – souvent associée à celle de proportionnalité – si chère au RGPD, lorsque par exemple le texte pose les principes relatifs au traitement des données (art. 5) ou les conditions de sa licéité (art. 6).
9. Données d’authentification (forte). On retombe ici sur les données de sécurité personnalisées, dans leur fonction d’authentification « forte », qui est l’une des grandes innovations de la DSP 2. L’exigence d’authentification forte figure au point 1 de l’emblématique article 97 de la DSP 2 : « Les États membres veillent à ce qu’un prestataire de services de paiement applique l’authentification forte du client lorsque le payeur : / a) accède à son compte de paiement en ligne ; / b) initie une opération de paiement électronique ; / c) 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 »[12].
Mis à part les pouvoirs publics, voire certains utilisateurs précautionneux, personne ou presque n’aime l’authentification forte – ni n’a aimé, du moins au départ, 3Dsecure – qui perturbera nécessairement le « parcours client ». D’où l’intérêt porté par marchands ou prestataires sans comptes, entre autres, aux dérogations permises par le règlement 2018/389 (art. 10 et s.). Or parmi celles-ci, il en est une générale, tirée de l’« analyse des risques liés à l’opération » (risk scoring), qui veut qu’un PSP soit autorisé à ne pas appliquer l’authentification forte du client après qu’il s’est assuré que l’opération de paiement considérée présente un faible niveau de risque (art. 18). Pourquoi la distingue-t-on des autres? Et bien parce que, à défaut d’authentification forte, c’est une masse considérable de données (à caractère personnel) que le PSP doit recueillir. Ainsi ne doit-il avoir décelé, à l’issue d’une « analyse en temps réel des risques », ni « des dépenses anormales ou un type de comportement anormal du payeur », ni « une localisation anormale du payeur » ou ni « une localisation du bénéficiaire présentant des risques élevés » ; et encore faut-il qu’il tienne compte des « habitudes de dépenses antérieures de l’utilisateur individuel de services de paiement », de l’« historique des opérations de paiement de chacun des utilisateurs de services de paiement du prestataire de services de paiement » ou de l’« identification de comportements de paiement anormaux de l’utilisateur de services de paiement par rapport à l’historique de ses opérations de paiement » (art. 18, 2, c), i), v) et vi), et 3, a), b) et d)).
On conviendra que de la dispense d’authentification forte est au prix d’une intrusion plus que forte dans la vie numérique des utilisateurs de services de paiement.
10. Données de LCB-FT. Nous sortons sans doute un peu de notre sujet en abordant celui de la lutte contre le blanchiment des capitaux et le financement du terrorisme (LCB-FT), qui relève évidemment d’un autre corps de règles que celui de la DSP 2.
Mais on ne peut parler de « données » dans le cadre du paiement, évoquer leur « statut », en passant sous silence cette réalité qu’elles sont, qu’il est emporté(es) par la vague irrépressible de l’identification obligée des clients, désormais formellement doublée par la vérification de celle-ci (KYC)[13]. En y ajoutant que, bientôt, l’identification électronique, au sens du règlement eIDAS[14], prévaudra certainement sur les mesures archaïques mises en œuvre aujourd’hui ; qu’il en sera bien fini des quelques parcelles d’anonymat qui demeuraient encore, qui ne peuvent résister longtemps au « traitement invasif » des données, pour reprendre une expression de l’ancien contrôleur européen de la protection des données (CEPD)[15].
Quoi qu’il en soit, remarquons cette originalité qu’est le « droit d’accès indirect aux données » de l’article L. 561-45 du CMF : « Lorsque des données à caractère personnel font l’objet d’un traitement aux seules fins de l’application des articles L. 561-5 à L. 561-23 par une personne mentionnée à l’article L. 561-2, le droit d’accès s’exerce auprès de la Commission nationale de l’informatique et des libertés. […] ».
3. Données convoitées
11. Renvoi. Nous passerons rapidement sur la principale « innovation DSP 2 » qu’est l’accès aux comptes par d’autres qui ne le tiennent pas, spécialement traitée par M. Guillaume Richard dans son exposé sur les nouveaux droits d’accès aux comptes et aux données de compte, pour nous contenter de quelques observations.
12. L’accès aux comptes : un droit des utilisateurs de services de paiement. Il n’a jamais été question, à notre connaissance, de donner un droit d’accès à tel ou tel prestataire nouveau, mais bien de (re)donner pouvoir aux utilisateurs – aux payeurs en particulier – de consentir à ce que d’autres que les PSPGC puissent avoir accès aux comptes dont ils (les utilisateurs) sont titulaires. En somme, la titularité l’emporte sur la gestion, sans même évoquer la question de la propriété, hors de propos (comme pour les données à caractère personnel au demeurant).
13. L’accès aux comptes : des différentes manières d’y accéder. On le sait, les prestataires sans comptes ne sont pas deux, mais trois :
– les premiers, émetteurs d’instruments de paiement lié à une carte, peuvent bénéficier, sur consentement exprès de leurs clients payeurs donné au PSPGC et à eux-mêmes, d’un « droit d’interrogation » : interrogation du solde du compte et confirmation par ce dernier que le montant nécessaire à l’exécution de l’opération de paiement liée à une carte est disponible (CMF, art. L. 133-39, issu de DSP 2, art. 65) ;
– comme leur nom l’indique, les seconds, PSIP, se voient accorder un « droit d’initiation » de paiement à partir de comptes qu’ils ne tiennent pas, sur la foi du consentement explicite (le législateur français, même par voie d’ordonnance, aurait pu choisir entre « exprès » ou « explicite ») du payeur (CMF, art. L. 133-40, issu de DSP 2, art. 66)
– les troisièmes, les PSIC, diffèrent des deux premiers en ce que leur matière première n’est pas le paiement, mais bien les données de paiement (ou de compte) (CMF, art. L. 133-41, issu de DSP 2, art. 67) et, en cela, participent bien de cette économie de la donnée que la Commission européenne nous vend (ou nous vante) depuis quelques années déjà.
14. L’accès aux comptes : l’enjeu des données. La sécurisation des données ainsi « ouvertes à tous les vents », ou presque, est naturellement au cœur du règlement délégué 2018/389 qui, outre le sujet de l’authentification forte, traite également de la protection de la confidentialité et de l’intégrité des données de sécurité personnalisées ainsi que de la mise en place de normes ouvertes communes et sécurisées de communication entre PSPGC et PSIP et PSIC ; normes qui, à n’en pas douter, donneront naissance à une réglementation, voire un droit (et une gouvernance) des interfaces d’accès ou API.
II. Gouvernance de la donnée
15. Gouvernance ? Nous employons le terme de « gouvernance » au sens désormais admis par les textes de droit bancaire, CRD 4 bien sûr, mais désormais aussi la DSP 2 qui, au titre des conditions d’octroi de l’agrément, impose aux PSP de disposer « d’un solide dispositif de gouvernance d’entreprise, comprenant notamment une structure organisationnelle claire avec un partage des responsabilités qui soit bien défini, transparent et cohérent, des procédures efficaces de détection, de gestion, de contrôle et de déclaration des risques auxquels il est ou pourrait être exposé et des mécanismes adéquats de contrôle interne, y compris des procédures administratives et comptables saines »[16].
16. Modes. En nous concentrant de manière privilégiée, cette fois, sur les données à caractère personnel – sujet de ce colloque –, contrat (1.), responsabilité du traitement (2.) et, enfin, contrôle interne (3.) sont les trois modes de gouvernance que nous aborderons.
1. Contrat
17. L’hypertrophie de la clause RGPD. Il y a eu comme un phénomène de « passage à l’an 2000 du RGPD », un avant et un après 25 mai 2018, une sorte d’« hystérisation » qui a soufflé sur la mise à jour RGPD des contrats bancaires (conventions de compte, contrats-cadres de services de paiement, etc.).
Si bien que nous avons vu passer nombre de contrats de paiement où l’incorporation des règles nouvelles de la DSP 2, par nature prioritaire, avait marqué le pas face à l’hypertrophie de la clause RGPD (souvent doublée par une « politique de confidentialité » tout aussi ampoulée), tellement verbeuse qu’elle disait tout hormis les quelques mesures élémentaires de gouvernance des données à caractère personnel.
Sauf à ce que les contrats bancaires ou para-bancaires ne soient plus que des contrats de traitement de données à caractère personnel – ce qui nous étonnerait –, voilà une inversion des choses qui ne laisse pas de nous étonner.
18. Consentement et nécessité ? Faut-il que l’utilisateur de services de paiement consente expressément, ou explicitement, au traitement de ses données à caractère personnel ? Si oui, comme semble l’exiger l’article L. 521-5 du CMF, n’y-a-t-il pas une contradiction in adjecto à imposer, de surcroît, que l’accès auxdites données par le PSP soit nécessaire à l’exécution de leurs services de paiement ?
Car, si nous avons bien lu le RGPD et ses différents commentaires, la nécessité du traitement emporte la négation du consentement, nie toute manifestation de volonté libre dès lors que la personne concernée n’est plus en mesure de refuser de consentir. Tel est l’objet du curieux point 4 de l’article 7 du règlement : « Au moment de déterminer si le consentement est donné librement, il y a lieu de tenir le plus grand compte de la question de savoir, entre autres, si l’exécution d’un contrat, y compris la fourniture d’un service, est subordonnée au consentement au traitement de données à caractère personnel qui n’est pas nécessaire à l’exécution dudit contrat ». De sorte que le Groupe de travail « Article 29 » sur la protection des données a pu écrire : « Si un responsable du traitement cherche à traiter des données qui sont effectivement nécessaires à l’exécution d’un contrat, le consentement n’est alors pas la base juridique appropriée[17]. »
Nécessité et consentement ne vont pas ensemble, y compris en matière de protection des données à caractère personnel : « Soit le traitement est nécessaire à l’exécution d’un contrat, soit un consentement (libre) doit être obtenu »[18]. La DSP 2 aurait ainsi fait preuve d’un excès de « zèle protecteur » en doublant l’exigence de nécessité par celle d’un consentement, qui plus est explicite. Or la condition de nécessité se suffisait parfaitement à elle-même, puisque la licéité du traitement peut très bien reposer sur ceci : « le traitement est nécessaire à l’exécution d’un contrat auquel la personne concernée est partie ou à l’exécution de mesures précontractuelles prises à la demande de celle-ci » (RGPD, art. 6, 1, b). Partant, si l’on considère que la DSP 2 n’est pas une lex specialis du RGPD, ou que l’article 94, 2 de la DSP 2 ne crée pas une base légale nouvelle mais doit être interprété à la lumière du RGPD[19], on a un problème… quoiqu’en pense l’EDBP, qui cherche à concilier, d’une main à l’autre, ce qui paraît difficile de l’être : « The EDPB is of the view that the “explicit consent” referred to in Article 94 (2) of PSD2 is a contractual consent. Payment services are always provided on a contractual basis between the payment services user and the payment services provider. As stated in recital 87 of PSD2, “This Directive should concern only contractual obligations and responsibilities between the payment service user and the payment service provider.” In tern1s of the GDPR, the legal basis for the processing of personal data is Article 6 (1) (b) of the GDPR, meaning that the processing is necessary for the performance of a contract to which the data subject is party. We consider that, in view of the foregoing, Article 94(2) of PSD2 should be interpreted, on the one hand, in coherence with the applicable data protection legal framework and, on the other band, in a way that preserves its useful effect. This in1plies that Article 94 (2) of PSD2 should be interpreted in the sense that when entering a contract with a payment service provider under PSD2, data subjects must be n1ade full y aware of the purposes for which their personal data will be processed and have to explicitly agree to these clauses. Such clauses should be clearly distinguishable from the other n1atters dealt with in the contract and would need to be explicitly accepted by the data subject. The concept of explicit consent under Article 94(2) of PSD2 is therefore an additional requirement of a contractual nature and is therefore not the same as (explicit) consent under the GDPR »[20].
2. Responsabilité du traitement
19. Qui fait quoi ? On a vu et lu, à cet égard, tout et son contraire, dès lors que le modèle contractuel faisait apparaître d’autres intervenants que seulement l’utilisateur de services de paiement et son prestataire, notamment agents (de services de paiement) et nouveaux prestataires de services d’initiation de paiement et/ou d’information sur les comptes.
Comme si, là encore, les « mots » du RGPD étaient entourés d’une sorte de vertu auto-qualificatrice, tels ou tels étaient indifféremment tantôt nommés « responsables du traitement », tantôt « sous-traitant », et inversement ; mots auto-qualificateurs qui, au final, ne qualifient plus rien. Faut-il que l’on ne sache pas, ou plus, qui sont, naturellement, les uns et les autres ? Ce n’est pas à exclure.
20. Responsabilité conjointe ? Il serait tout de même embêtant, en droit des paiements comme ailleurs, de buter sur une notion aussi prégnante de la protection des données à caractère personnel. D’autant que, si nous lisons bien les travaux en la matière, « le rôle premier de la notion de responsable du traitement est de déterminer qui est chargé de faire respecter les règles de protection des données, et comment les personnes concernées peuvent exercer leurs droits dans la pratique. En d’autres termes, il s’agit d’attribuer les responsabilités[21]. »
Ou alors faut-il considérer que les traitements mis en œuvre par les uns et les autres, à l’heure de l’économie de la donnée, y compris de la donnée de paiement, sont tellement imbriqués les uns aux autres, que la détermination de leurs responsables serait vaine ? On ne peut dès lors écarter l’hypothèse qu’il faille se satisfaire de la qualification, remise au goût du jour, de « responsables conjoints du traitement », au sens où l’article 26, 1 du RGPD nous dit que « lorsque deux responsables du traitement ou plus déterminent conjointement les finalités et les moyens du traitement, ils sont les responsables conjoints du traitement ». Peut-être, à condition de ne pas oublier que cette économie de qualification, en amont, se répercute, en aval, sur la nécessaire répartition contractuelle et transparente, entre responsables conjoints, de leurs obligations respectives, notamment en ce qui concerne l’exercice des droits de la personne concernée, destinataire des grandes lignes de l’accord que les responsables conjoints du traitement auront passé entre eux (RGPD, art. 26, 1, 2 et 3).
Notons, pour finir sur ce point, que l’avis précité 1/2010 sur les notions de « responsable du traitement » et de « sous-traitant » donnait cet exemple intéressant sur les « transactions financières » : « Prenons maintenant l’exemple d’une banque qui a recours à un service de messagerie financière pour réaliser ses transactions financières. La banque et le service de messagerie conviennent des moyens du traitement des données financières. Le traitement des données à caractère personnel concernant les transactions financières est réalisé en premier lieu par l’établissement financier et, seulement après, par le service de messagerie financière. Cependant, même si au niveau individuel, chacune de ces entités poursuit sa propre finalité, au niveau global, les différentes phases, les finalités et les moyens du traitement sont étroitement liés. Dans cet exemple, la banque et le service de messagerie peuvent être considérés comme coresponsables[22]. »
3. Contrôle interne
21. Accountablity et conformité. Ce n’est pas une révélation mais, associé à la matière bancaire et financière, le principe « cardinal » d’accountability (mal traduit par le terme de « responsabilité »), posé au point 2 de l’article 5 du RGPD, est potentiellement explosif : « Le responsable du traitement est responsable du respect du paragraphe 1 et est en mesure de démontrer que celui- ci est respecté (responsabilité) »[23].
Explosif ? Nécessairement, dans la mesure où cette disposition, en apparence anodine (et curieusement non exposée dans les considérants du RGPD), fait basculer la protection des données à caractère personnel dans une logique de « conformité » (on aime à dire compliance aujourd’hui), clairement mise en œuvre aux articles 24 et suivants, à commencer par ceci : « Compte tenu de la nature, de la portée, du contexte et des finalités du traitement ainsi que des risques, dont le degré de probabilité et de gravité varie, pour les droits et libertés des personnes physiques, le responsable du traitement met en œuvre des mesures techniques et organisationnelles appropriées pour s’assurer et être en mesure de démontrer que le traitement est effectué conformément au présent règlement. Ces mesures sont réexaminées et actualisées si nécessaire » (RGPD, art. 24, 1). Fichtre, ne serait-ce qu’en regard de ce seul bout de texte qui introduit les obligations générales du responsable du traitement – et sans même parler de privacy by design, etc. –, la tâche est immense !
22. Faut-il réécrire l’arrêté du 3 novembre 2014 ? La question se pose, nous semble-t-il, à l’égard des établissements relevant de l’arrêté du 3 novembre 2014 relatif au contrôle interne, c’est-à-dire aux entreprises du secteur de la banque, des services de paiement et des services d’investissement soumises au contrôle de l’ACPR. Car le thème de la gouvernance (dispositifs, procédures) des données, quelles qu’elles soient (donc pas seulement celles à caractère personnel), y est évidemment absent, cependant que les impératifs de conformité (et les risques de non-conformité[24]) ne cessent de croître.
Réécrire l’arrêté de 2014, non pas en ce qui concerne, directement, les données à caractère personnel : on a vu que compétence exceptionnelle, en matière de services de paiement, a été donnée à la CNIL (cf. CMF, art. L. 521-7) ; il faudra toutefois que celle-ci se coordonne avec celle-là (ACPR), voire avec la Banque de France, elle-même nouvellement investie de s’assurer de la sécurité de « l’accès aux comptes de paiement et à leurs informations » dans le cadre des nouveaux services d’initiation de paiement et d’information sur les comptes (CMF, art. L. 521-8). Mais il s’agirait peut-être de réécrire l’arrêté relatif au contrôle interne à l’égard des données de sécurité personnalisées et autres données de paiement sensibles, ne serait-ce que pour y intégrer davantage le « risque informatique » et les mesures de cybersécurité propres à l’endiguer[25]. Avec cette difficulté qu’elles devraient majoritairement présenter un caractère personnel, sans quoi elles ne seraient pas convoitées. Et cette autre qu’il faudrait aussi aller voir du côté de l’Agence nationale de la sécurité des systèmes d’information (ANSSI) ; du côté, encore, de la directive NIS (Network and Information Security)…
23. La question de l’anonymat, pour finir. Nous avions remarqué, lors de la lecture du règlement délégué 2018/389, la première phrase de son considérant 8 : « 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 ». « Anonyme », le mot devient rare dans la réglementation bancaire et financière.
DSP 2, RGPD : 2018 fut aussi marquée par les transpositions nationales chaotiques – la France ne fit pas exception – de la 4e directive Antiblanchiment[26] et par la publication de la 4e directive bis[27]. Or quel objectif immédiat poursuivent-elles ? La fin de l’anonymat des paiements et, pour cela, la chasse aux paiements en espèces, bien sûr, mais aussi en monnaie électronique ou en monnaies virtuelles ; le « requiem » même, pour reprendre les mots d’un auteur[28], de cet « anonyme », qui caractérise les sociétés du même nom (voire toutes les sociétés par actions), avec la recherche du bénéficiaire effectif ultime. Et si, en paiement comme ailleurs, nous n’avions pas besoin de préserver une petite, voire infime, part d’anonymat ? Un peu d’anonymat n’est-il pas le meilleur garant de nos données à caractère personnel[29] ? Du respect de (l’intimité de) notre vie privée ? Or autant nous pouvons faire l’économie de nous exhiber sur les réseaux sociaux, autant il devient impossible de ne pas payer à l’aide d’instruments électroniques. Nécessité et consentement, toujours et encore… l
[1] Dir. (UE) 2015/2366, 25 nov. 2015, concernant les services de paiement dans le marché intérieur, abrogeant Dir. 2007/64/CE, 13 nov. 2007 (DSP 1).
[2] Règl. (UE) 2016/679, 27 avr. 2016, relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/46/CE (règlement général sur la protection des données).
[3] Voir encore Ord. n° 2018-1125, 12 déc. 2018, prise en application de l’article 32 de la loi n° 2018-493 du 20 juin 2018 relative à la protection des données personnelles et portant modification de la loi n° 78-17 du 6 janvier relative à l’informatique, aux fichiers et aux libertés et diverses dispositions concernant la protection des données à caractère personnel.
[4] Cf. P. Storrer, « À l’heure du règlement européen relatif au libre flux des données à caractère non personnel », RTDF n° 4-2018, déc. 2018, p. 76
[5] The EBA’s Fintech Roadmap, Conclusion from the consultation on the EBA’s approach to financial technology (Fintech), 15 mars 2018, n° 87.
[6] Cf. A. Banck, « Données personnelles : la difficile articulation des dispositions de la Directive sur les Services de Paiement 2 et du Règlement général sur la protection des données », RD bancaire et fin. 2018, étude 1 ; et « Données personnelles : articulation de la Directive sur les Services de Paiement 2 et du Règlement général sur la protection des données – Acte II : suite et fin ? », RD bancaire et fin. 2018, étude 20.
[7] EDPB-84-2018, 5 juillet 2018.
[8] Cf. DSP 2, cons. 69.
[9] Pour les établissements de monnaie électronique, cf. CMF, art. L. 526-8, I, al. 1er.
[10] EBA/GL/2017/09, 8 nov. 2017. Comp. Orientations de l’ABE relatives aux mesures de sécurité pour les risques opérationnels et de sécurité liées aux services de paiement dans le cadre de la DSP 2, EBA/GL/2017/17, 12 janv. 2018, point 4.3 : « Les PSP devraient veiller à la confidentialité, l’intégrité et la disponibilité de leurs actifs logiques et physiques critiques, ressources et données de paiement sensibles de leurs USP qu’elles soient stockées, en transit ou en cours d’utilisation ».
[11] EBA/GL/2018/05. Cf. Avis de l’ACPR de mise en œuvre des orientations du 18 décembre 2018.
[12] Voir encore CMF, art. L. 133-44, I.
[13] Voir, en dernier lieu, ACPR, Lignes directrices relatives à l’identification, la vérification de l’identité et la connaissance de la clientèle, 14 déc. 2018.
[14] Règl. (UE)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, dont les mesures d’identification électronique intègrent désormais llle CMF au titre de l’exécution des obligation de vigilance.
[15] Cf. Avis 1/2017 du CEPD sur la proposition de la Commission modifiant la directive (UE) 2015/849 et la directive 2009/101/CE – Accès aux informations sur les bénéficiaires effectifs et conséquences sur la protection des données, 2 févr. 2017.
[16] DSP 2, art. 11, 4, reprenant quasi exactement les termes de l’art. 74, 1 de CRD 4. Voir encore ABE, Orientations sur la gouvernance interne, EBA/GL/2017/11, 21 mars 2018.
[17] Lignes directrices sur le consentement au sens du règlement 2016/679, adoptées le 28 novembre 2017, version révisée et adoptée le 10 avril 2019, WP259 rév. 01, p. 10.
[18] Groupe de travail « Article 29 » sur la protection des données, Avis 15/2011 sur la définition du consentement, adopté le 13 juillet 2011, WP 187, p. 8.
[19] En ce sens, P. Silva (European Commission, DG FISMA), Interaction between PSD2 and GDPR. Adde, Observatoire de la sécurité des moyens de paiement, Rapport annuel 2017 précit., p. 18, encadré 3.
[20] PS2 Letter, précit.
[21] Groupe de travail « Article 29 » sur la protection des données, Avis 1/2010 sur les notions de « responsable du traitement » et de « sous-traitant », adopté le 16 février 2010, WP 169, p. 4.
[22] WP 169, p. 22.
[23] En anglais : « The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (‘accountability’) ».
[24] Cf. Arr. 3 nov. 2014 relatif au contrôle interne, art. art. 10, p) : « Risque de non-conformité : le risque de sanction judiciaire, administrative ou disciplinaire, de perte financière significative ou d’atteinte à la réputation, qui naît du non-respect de dispositions propres aux activités bancaires et financières, qu’elles soient de nature législative ou réglementaire, nationales ou européennes directement applicables, ou qu’il s’agisse de normes professionnelles et déontologiques, ou d’instructions des dirigeants effectifs prises notamment en application des orientations de l’organe de surveillance ».
[25] Cf. ACPR, Le risque informatique, Document de réflexion, mars 2018, dont l’annexe relative à la catégorisation du risque informatique.
[26] Dir. (UE) 2015/849, 20 mai 2015, relative à la prévention de l’utilisation du système financier aux fins de blanchiment de capitaux ou du financement du terrorisme.
[27] Dir. (UE) 2018/843, 30 mai 2018, modifiant la directive (UE) 2015/849 relative à la prévention de l’utilisation du système financier aux fins du blanchiment de capitaux ou du financement du terrorisme.
[28] R. Mortier, Requiem pour l’anonymat, Recueil Dalloz n° 36, 18 oct. 2018, 1977.
[29] Comp. RGPD, cons. 26.
