La DSP2 et le RGPD sont-ils alignés ou orthogonaux ?

L’ouverture des données de paiement, qui est au centre de l’open banking, permet à de nouveaux acteurs d’accéder à ces données, et place donc l’interaction entre la directive sur les services de paiement (DSP 2) et le Règlement général sur la protection des données (RGPD) au cœur du débat.

La  DSP 2 a été adoptée le 25 novembre 2015 ; le Règlement général sur la protection des données, le 14 avril 2016, pour une entrée en application au 25 mai 2018. Ces deux textes ont donc été adoptés dans un cadre temporel très proche. Dès lors, même si la DSP 2 a été adoptée alors que la Directive 95/46/CE sur la protection des données personnelles était encore en vigueur, on aurait pu légitimement supposer que le législateur veillerait à la cohérence de ce texte avec la future législation relative à la protection des données.

Ce sentiment est renforcé par le fait que la DSP 2 fasse référence, dès son considérant 89, aux principes de protection des données dans les systèmes de traitement « dès la conception » et « par défaut », concepts qui n’étaient pas présents dans la directive de 1995. Les philosophies de ces textes sont souvent opposées, l’ouverture des données de paiement étant pour certains difficilement conciliable avec la protection des données personnelles.

La nature même des deux textes en présence diverge : d’un côté un règlement d’application directe, et de l’autre, une directive qui nécessite d’être transposée en droit national, ce qui laisse toujours une marge d’appréciation aux États membres. Qu’en est-il réellement, alors que le règlement délégué [1] sur les API (Application Programming Interface – interface de programmation applicative) et l’authentification forte sera applicable à compter du 14 septembre prochain ?

Une discordance des concepts ?

La DSP 2 telle que transposée en droit français introduit deux nouvelles notions dans le code monétaire et financier (CMF) : celle de « données de sécurité personnalisées » et celle de « données de paiement sensibles ». La première est définie à l’article L. 133-4 du CMF comme « les données personnalisées fournies à un utilisateur de services de paiement par le prestataire de services de paiement (PSP) à des fins d’authentification » et la seconde comme les données « susceptibles d’être utilisées pour commettre une fraude ». Cette dernière inclut les « données de sécurité personnalisées ».

Ces deux catégories de données sont à n’en pas douter des données à caractère personnel, c’est-à-dire des données permettant directement ou indirectement d’identifier une personne concernée dont le traitement est soumis aux dispositions du RGPD. Toutefois, le RGPD ne fait pas des données de paiement des données particulières. Seules relèvent de cette catégorie des données comportant un risque pour la vie privée des personnes concernées et relatives à l’origine raciale ou ethnique, les opinions politiques, les convictions religieuses, les données de santé, etc [2] .

Faut-il y voir une discordance ? En pratique, l’introduction de ces deux nouveaux concepts n’a que peu d’impacts, on pourrait d’ailleurs considérer que sur ce point la DSP 2 spécifie le RGPD.

Caractère libre du consentement : bonjour l'orthogonalité !

L’article 94 de la DSP 2 transposé à l’article L. 521-5 du CMF dispose que « 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 ». Dans la mesure où ces dispositions doivent être lues à la lumière du RGPD [3] , ce consentement doit être libre, spécifique, informé et univoque et résulter d’un acte positif clair de la personne concernée et non d’une simple information préalable. Or c’est bien sur le caractère libre du consentement qu’apparaît un problème d’articulation. En effet, si les données sont nécessaires à l’exécution du service de paiement, c’est que le prestataire de services de paiement (PSP) n’est pas en mesure de fournir le service sans ces informations. En outre, tout retrait de ce consentement entraînerait de facto l’arrêt du service, le PSP ne disposant plus des données nécessaires à son exécution. Un client souhaitant bénéficier du service n’apparaît donc pas libre de retirer son consentement, ce qui est une atteinte au principe posé par le RGPD. À cela s’ajoute le fait que le consentement ne peut pas être tacite et résulter du remplissage d’un formulaire de demande de service de paiement.

Face à cette situation le Comité européen de la protection des données (CEPD/EDPB) est venu préciser sa lecture de ces dispositions dans un courrier en date du 5 juillet 2018 [4] . Dans ce document, le Comité estime que les services de paiement reposent sur une base contractuelle entre l’utilisateur et le fournisseur et que les traitements mis en œuvre à cette occasion relèvent de l’exécution d’un contrat ou de mesures précontractuelles. Il considère par ailleurs que la notion de consentement de l’article 94 de la DSP 2 est de nature contractuelle et n’est pas équivalente à celle figurant dans le RGPD. Si l’on peut saluer cette lecture programmatique, elle soulève tout de même quelque interrogation notamment quant à son articulation avec le consentement à l’opération de paiement mentionné à l’article 64 de la DSP 2. Il apparaît en effet que la volonté du législateur était bien de prévoir un consentement spécifique au traitement des données distinct de celui relatif à l’opération de paiement.

Notification des incidents et des violations de données : l’orthogonalité demeure

La DSP 2 stipule qu'« en cas d'incident opérationnel ou de sécurité majeur, les prestataires de services de paiement informent sans retard injustifié l'autorité compétente ». En outre, lorsque cet incident a eu ou est « susceptible d'avoir des répercussions sur les intérêts financiers de ses utilisateurs, le PSP informe sans retard injustifié ses utilisateurs […] de l'incident et de toutes les mesures disponibles qu'ils peuvent prendre pour atténuer les effets dommageables de l'incident ». L'article L. 521-10 du CMF précise les autorités à notifier, en l’occurrence l'Autorité de contrôle prudentiel et de résolution (ACPR) pour tout incident opérationnel majeur et la Banque de France pour tout incident de sécurité majeur. C'est donc deux autorités distinctes qui ont été choisies en France en raison de leur compétence respective.

L'incident opérationnel correspond à un incident découlant d'une insuffisance ou d'une défaillance d'un process, d'une personne ou d'un système ou d'un événement de force majeur affectant l'intégrité, la disponibilité, la confidentialité, l'authenticité et/ou la continuité des services de paiement associés. L'incident de sécurité correspond quant à lui à un accès non autorisé, une utilisation, une diffusion, une modification ou une destruction des biens du PSP affectant l'intégrité, la disponibilité, la confidentialité, l'authenticité et/ou la continuité des services de paiement associés [5] .

Le RGPD exige quant à lui que les responsables du traitement notifient à l’autorité de contrôle en France, la Cnil, les violations de données, à savoir les violations « entraînant de manière accidentelle ou illicite, la destruction, la perte, l'altération, la divulgation non autorisée de données à caractère personnel transmises, conservées ou traitées d'une autre manière, ou l'accès non autorisé à de telles données » à moins que cette violation ne soit pas susceptible d’engendrer un risque pour les droits et libertés des personnes concernées.

La seule lecture de ces définitions suffit à identifier une convergence d’obligations entre ces dispositions. Les incidents de sécurité ou opérationnels peuvent en effet porter sur des données personnelles, ce qui nécessite de notifier la Cnil, en plus de l’ACPR et/ou la Banque de France. La situation se complexifie encore à l’examen des informations à communiquer qui divergent en fonction des législations.

Mécanismes antifraude et mutualisation de données : quelle articulation ?

Les RTS relatifs à l’authentification forte imposent aux PSP de mettre en place « des mécanismes de contrôle des opérations qui leur permettent de déceler les opérations de paiement non autorisées ou frauduleuses ». Ces mécanismes sont fondés sur l’analyse d’opérations de paiement « tenant compte d’éléments qui sont propres à l’utilisateur de services de paiement ».

Ils vont donc nécessiter de traiter des données à caractère personnel sur ces utilisateurs. Or le RGPD précise que les traitements mis en œuvre à des fins de lutte contre la fraude peuvent relever de l’intérêt légitime du responsable du traitement [6] . À la lecture des RTS, il semble préférable de privilégier l’exécution de mesures contractuelles notamment en raison des impacts en termes de droit des personnes concernées. En effet, dans ce cas, les personnes concernées n’ont pas la possibilité de s’opposer au traitement de leurs données.

De la même manière, d’éventuels partages de données de fraude entre PSP et commerçants pourraient aller à l’encontre de la doctrine de la Cnil relative à la sectorisation des traitements de lutte contre la fraude [7] .

Une concurrence d’autorités ?

Les modalités de protection des données personnelles font désormais partie des conditions d’obtention de l’agrément en qualité d’établissement de paiement. Doivent en effet être fournies à l’ACPR une description du processus pour enregistrer, surveiller et restreindre l’accès aux données de paiement sensibles, ainsi qu'une description des mesures de maîtrise et d’atténuation des risques décelés en matière de sécurité (article 5, 1), g). L’article L. 522-6-II du CMF soumet également la délivrance de l’agrément à la vérification de l’existence de « dispositifs à même d’assurer la sécurité des services de paiement fournis, ainsi que la protection des données de paiement sensibles ». Faut-il y voir une volonté de l’ACPR de rentrer dans le champ de compétence de la Cnil et ce alors même que la compétence de cette dernière est explicitement rappelée à l’article L. 521-7 du CMF ?

L’analyse tend plutôt, il faut bien l’avouer, à l’orthogonalité. L’articulation de la DSP 2 et du RGPD est d’ailleurs au programme du Comité européen de la protection des données (CEPD) pour cette année [8] . Ce nouvel avis permettra peut-être de réduire ces divergences.