Le « problème DSP 2 » ? Il y aurait donc une question, sinon un problème, d’articulation, ou d’interaction (« interplay » en anglais), entre deux textes majeurs, publiés (et entrés en application) à quelques mois d’intervalle : la deuxième directive concernant les services de paiement (DSP 2 ou PSD2 pour Payment Services Directive 2) et le règlement général sur la protection des données (RGPD ou GDPR pour General Data Protection Regulation). Car voilà que le Comité européen de la protection des données (European Data Protection Board ou EDPB), après une première incursion remarquée[1], soumet à consultation publique (désormais close) des lignes directrices consacrées à cette question, ou ce problème, de coexistence.
Mais pourquoi, diable, y aurait-il, particulièrement, un « problème DSP 2 » vis-à-vis du nouveau droit RGPD des données à caractère personnel ? On ne peut certes nier une certaine « collision » entre, d’une part, le mouvement d’open banking (et, peut-être, demain, d’open finance) amorcé par la deuxième directive sur les services de paiement et, de l’autre, la construction d’un espace européen de protection des données encadré par un grand, et fort[2], règlement « général ». Sauf que l’on ne peut pas moins ignorer que c’est précisément pour faire entrer dans le rang de la réglementation des paiements les services d’accès au compte (initiation de paiement et information sur les comptes), qui s’étaient développés en marge (en Allemagne et en France à l’origine), que la DSP 2 est venue relayer, et abroger, la première directive en la matière. Faut-il compter le nombre de considérants et de dispositions de la nouvelle directive qui encadrent les prestataires anciennement tiers et, désormais, prestataires de services de paiement à part entière, ou presque ? pointer les occurrences où la DSP 2 dit et redit que seul l’utilisateur de services de paiement peut consentir, et encore de manière « explicite », à ce que ses données de compte (de paiement, seulement) soient accessibles à d’autres que leurs gestionnaires traditionnels (les banques) ? revenir sur le bouleversement annoncé (même si on l’attend toujours) par l’authentification forte et la communication sécurisée ? Ce sont bien là autant de mesures propres au droit spécial des paiements qui entendent que la banque ou la finance ouvertes ne le soient pas à tous les vents.
Mais admettons qu’il y ait comme un « entrechoquement » entre DSP 2 et RGPD, puisque nous avons tous, les uns et les autres, beaucoup (trop ?) écrit sur le sujet ; que l’EDPB, fort de sa mission générale de contrôle de la cohérence[3], s’est donc attelé à la rédaction de lignes directrices propres à révéler, ou au contraire à dissiper, les points de frottements entre les deux textes. Et d’abord ceci, à titre préliminaire, posé dès la fameuse PSD2 Letter : « The GDPR lays down a strong and coherent data protection framework, whose consistent and homogenous application should be ensured throughout the Union. […] Hence, the interpretation and the implementation of the articles in PSD2 have to be made in light of the GDPR »[4]. Nous y sommes : l’accès aux comptes par les prestataires de services d’initiation de paiement ou d’agrégation de données perturbe à l’évidence le cadre « fort » et « cohérent » du RGPD[5]. Voyons cela.
Les motifs légitimes de traitement (Lawful grounds for processing). Parmi les six conditions (alternatives) de licéité d’un traitement posées par l’article 6, paragraphe 1, du RGPD, nos lignes directrices remarquent utilement que les services de paiement sont toujours fournis sur une base contractuelle. Car, en effet, la DSP 2 elle-même considère qu’elle « ne devrait concerner que les obligations contractuelles et les responsabilités respectives de l’utilisateur de services de paiement et du prestataire de services de paiement »[6].
Si bien que le traitement des données « nécessaire » à l’exécution du contrat de services de paiement ressortit, d’après l’EDPB, du b) du paragraphe 1 de l’article 6, tel que ce caractère de nécessité est interprété par les lignes directrices 2/2019 sur le traitement des données à caractère personnel au titre de l’article 6, paragraphe 1, point b), du RGPD dans le cadre de la fourniture de services en ligne aux personnes concernées[7]. Ce « Necessary for performance » requiert ainsi à l’évidence « something more than a contractual clause » : « The controller should be able to demonstrate how the main object of the specific contract with the data subject cannot, as a matter of fact, be performed if the specific processing of the personal data in question does not occur »[8]. Consentement et nécessité, nous y avions vu comme une contradiction[9], là où les lignes directrices sous commentaire paraissent y voir plutôt deux exigences complémentaires. Cela mériterait d’être éclairci…
Quant à l’éventuel (et tentant) traitement ultérieur, est relevée la limitation importante portée par les articles 66, paragraphe 3, G) et 67, paragraphe 2, f) de la DSP 2 : le prestataire de services d’initiation de paiement, de même que le prestataire de services d’information sur les comptes, ne peuvent utiliser, consulter ou stocker des données à des fins autres que la fourniture du service considéré, expressément demandé par le payeur ou l’utilisateur[10]. « Consequently, Article 66 (3) (g) and Article 67 (2) (f) of the PSD2 considerably restrict the possibilities for processing for other purposes, meaning that the processing for another purpose is not allowed, unless the data subject has given consent pursuant to Article 6 (1) (a) of the GDPR or the processing is laid down by Union law or Member State law to which the controller is subject, pursuant to Article 6 (4) of the GDPR »[11]. Sans préjuger de l’issue de la consultation publique sur les présentes lignes directrices, gageons que ce passage méritera d’être lu et relu à l’heure de la rédaction, peut-être de la révision, des conditions générales d’utilisation des services d’accès au compte.
Le consentement explicite (Explicit consent). La question est celle-ci : le consentement (explicite) du RGPD est-il le même que le consentement (explicite) de la DSP 2 que l’utilisateur de services de paiement doit donner afin que d’autres qui ne le ou les tiennent pas accèdent à son ou ses comptes (de paiement)[12] ? Mais, au fait, pourquoi serait-il différent ? Oui, pourquoi en irait-il différemment alors que l’article 94, paragraphe 1, de la DSP 2 devrait avoir vidé l’interrogation, dans la mesure où il dispose bien que le traitement des données, dans le cadre de la présente directive, doit être conforme au RGPD[13] ? Ce serait bien notre veine que les mêmes mots de « consentement explicite » prennent un sens différent d’un (grand) texte européen à un autre (grand lui aussi), rédigés à quelques mois d’intervalle.
L’EDPB est pourtant d’avis que le paragraphe 2 de l’article 94 – aux termes duquel « 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 explicite de l’utilisateur de services de paiement » – emporte cette conséquence : « Explicit consent under Article 94(2) PSD2 should therefore be regarded as an additional requirement of a contractual nature in relation to the access to and subsequently processing and storage of personal data for the purpose of providing payment services and is therefore not the same as (explicit) consent under the GDPR »[14].
De la nécessité, si nous comprenons bien, d’un consentement contractuel additionnel de la part des utilisateurs de services de paiement. Or l’on peut douter que la pratique des prestataires sans compte aille, ou ira, dans ce sens, alors déjà qu’ils ont à faire application des deux copieux articles 66 (initiation de paiement) et 67 (information sur les comptes) de la DSP 2. Peu importe, l’EDPB conclut : « Explicit consent under the PSD2 is different from (explicit) consent under the GDPR. Explicit consent under Article 94 (2) of the PSD2 is an additional requirement of a contractual nature. When a payment service provider needs access to personal data for the provision of a payment service, explicit consent in line with Article 94 (2) of the PSD2 of the payment service user is needed »[15].
Les données des parties silencieuses (Silent party data). Voilà une bien belle expression que celle de « silent party data »… dont on ne trouve pas d’équivalent en français, mais pas non plus la source dans le GDPR. Outre les présentes guidelines, nous n’en trouvons trace (sous réserve d’une recherche plus approfondie) que dans la PSD2 Letter précitée, qui y consacre un paragraphe s’ouvrant de la sorte : « Concerning “silent party data”, you raised the question whether the processing of persona ! data of ‘silent parties’ is legitimate when explicit consent for the processing of persona ! data has (only) been given by another data subject. »
De quoi s’agit-il ? De ceci : « In the context of this document, silent party data are personal data concerning a data subject who is not the user of a specific payment service provider, but whose personal data are processed by that specific payment service provider for the performance of a contract between the provider and the payment service user. » En somme, si l’on comprend bien, dans le cadre d’un virement, par exemple, la partie silencieuse serait, vis-à-vis du prestataire de services de paiement du payeur, le bénéficiaire, dont le numéro de compte et le montant des fonds transférés seraient communiqués.
Mais où est la difficulté, dès lors que le principe dit de « limitation des finalités » (« Les données à caractère personnel doivent être […] collectées pour des finalités déterminées, explicites et légitimes, et ne pas être traitées ultérieurement d’une manière incompatible avec ces finalités »[16]) devrait trouver assez naturellement à s’appliquer ? Quant au traitement ultérieur des données des parties silencieuses, en quoi la matière des paiements se distinguerait des mille et une autres où une telle réexploitation est probable ? On ne sait pas bien, mais l’expression, redisons-le, est plaisante.
Autres. Sur la question du traitement de catégories particulières de données à caractère personnel dans le cadre de la DSP 2 (« The processing of special categories of personal data under the PSD2 »), on retiendra – mais était-il bien nécessaire de le préciser ? – l’observation selon laquelle la définition des « données de paiement sensibles » dans la DSP 2[17] diffère considérablement (« differs considerably ») de la manière dont l’expression « données personnelles sensibles » est communément utilisée dans le contexte du RGPD[18]. Très bien, on s’y attendait un peu, sauf que cela ne dissipe pas le doute qu’insinue un tel rapprochement ; doute né de ceci que le traitement des catégories particulières de données à caractère personnel (i. e. qui révèle l’origine raciale ou ethnique, les opinions politiques, les convictions religieuses ou philosophiques ou l’appartenance syndicale, ainsi que les données génétiques, biométriques, de santé ou relatives à la vie ou l’orientation sexuelle) est tout bonnement… interdit par l’article 9, paragraphe 1, du règlement. Or s’il paraît évident que les données sensibles de paiement de la DSP 2 n’ont pas grand-chose à voir, a priori, avec la liste du règlement général, on est un peu étonné que les lignes directrices de l’EDPB prescrivent que le traitement des premières puisse bénéficier d’au moins deux dérogations figurant au paragraphe 2 de l’article 9 (consentement explicite et raisons d’intérêt public)[19] : car si le traitement des données de paiement sensibles n’est possible que sur dérogation, c’est qu’il serait par principe interdit, n’est-ce pas ?
Terminons ce rapide survol de la « soft law » européenne en matière de protection des données en évoquant, pêle-mêle, les sujets de la minimisation des données, de la sécurité, de la transparence, de la responsabilité et du profilage. Où il est rappelé que les fameux « tiers de paiement » (ou TPP pour « third party providers », que les Anglo-Saxons, et tous ceux qui les suivent, c’est-à-dire presque tout le monde, persévèrent à nommer improprement tels) doivent obéir au principe de minimisation[20], qui commande que les données à caractère personnel soient « adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités pour lesquelles elles sont traitées »[21]. Or si la règle paraît incontestable, son respect par les prestataires de services d’information sur les comptes, en particulier, dont le modèle économique d’entrée en relation suppose souvent la gratuité, devra être observé.
On passera vite sur la sécurité[22] : tout demeure (mauvaise) littérature tant que le règlement délégué 2018/389 du 27 novembre 2017 sur l’authentification forte et la communication commune sécurisée ne sera pas entré en application, et il ne l’est toujours pas. Concernant la transparence et la responsabilité (« accountability », terme difficilement traduisible), renvoi est principalement fait aux lignes directrices du groupe de travail « Article 29 » sur la transparence au sens du règlement (UE) 2016/679, approuvées par l’EDPB, avec ces deux préconisations intéressantes en pratique : pour les services de paiement en ligne, d’une part, une « approche par couche » (« layered approach ») est privilégiée, qui favoriserait une sorte de découpage de l’information plutôt que l’affichage de toutes sur une même page, au risque sinon d’une certaine lassitude (« information fatigue ») ; des outils complémentaires d’information sont d’autre part suggérés, comme des « tableaux de bord sur la vie privée » (« privacy dashboards »)[23]. Service d’information sur les comptes et profilage au sens de l’article 4, paragraphe 4, du RGPD, enfin, voilà assurément une vraie question, tant il est vrai que les données de compte qui seront (gratuitement) remontées par le prestataire… n’attendent plus qu’à être réutilisées (par lui ou un autre) pour « évaluer » la personne concernée[24].
Alors, existe-t-il un « problème DSP 2 » au regard du droit (conquérant) de la protection des données à caractère personnel ? Sans doute pas, même si de vraies et intéressantes questions se posent, ne serait-ce que parce que l’économie de la donnée suppose de la traiter.
Achevé de rédiger le 21 septembre 2020.
SERVICES DE PAIEMENT – DONNÉES À CARACTÈRE PERSONNEL – DSP 2 – RGPD.
[1] . PSD2 Letter, EDPB-84-2018, 5 July 2018.
[2] . Fort, en effet, et manifestement de plus en plus, si l’on considère l’important arrêt « Schrems II » rendu en juillet dernier par la Cour de justice de l’Union européenne, qui invalide rien moins que la décision de la Commission relative à l’adéquation de la protection assurée par le bouclier de protection des données UE-États-Unis (CJUE, grande chambre, 16 juill. 2020, aff. C-311/18, Data Protection Commissioner c/ Facebook Ireland Ltd et Maximillian Schrems).
[3] . Cf. RGPD, cons. 136 et art. 70 et s.
[4] . PSD2 Letter, EDPB-84-2018, 5 juillet 2018.
[5] . Dans le cadre du RGPD, mais apparemment pas sous l’empire de la directive de 1995, si l’on en croit l’avis du CEPD 2014/C 38/07 sur la proposition de DSP 2, où rien n’est dit sur les services d’accès au compte.
[6] . DSP 2, cons. 87. Cf. GL, n° 14.
[7] . Version 2.0, 8 oct. 2019, adoptée après consultation publique.
[8] . GL, n° 16.
[9] . Cf. P. Storrer, « Statut et gouvernance de la donnée dans la DSP 2 », in Les données à l’heure de la DSP 2 et du RGPD, Hors-série Banque & Droit, mars 2019, p. 8, n° 18.
[10] . Cf. GL, n° 21.
[11] . GL, n° 22. Comp., au n° 25, cette affirmation du droit des utilisateurs de services de paiement de faire usage des services d’accès au compte : « […] payment service users can exercise their right to make use of payment initiation and account information services ».
[12] . Cf. GL, n° 33 : « The EDPB notes that the legal framework regarding explicit consent is complex, since both the PSD2 and the GDPR include the concept of “explicit consent”. This leads to the question whether “explicit consent” as mentioned in Article 94 (2) of the PSD2 should be interpreted in the same way as explicit consent under the GDPR. »
[13] . Pour être tout à fait exact, compte tenu d’un décalage de temps, c’est la directive de 1995 qui est visée dans la DSP 2, mais l’on sait que l’article 94, paragraphe 2, du RGPD commande expressément que « les références à la directive abrogée s’entendent comme faites au présent règlement ».
[14] . GL, n° 35.
[15] . GL, n° 43.
[16] . RGPD, art. 5, 1, b).
[17] . Cf. DSP 2, art. 4, 32) : « “données de paiement sensible”, des données, y compris les données de sécurité personnalisées, qui sont susceptibles d’être utilisées pour commettre une fraude. En ce qui concerne les activités des prestataires de services d’initiation de paiement et des prestataires de services d’information sur les comptes, le nom du titulaire du compte et le numéro de compte ne constituent pas des données de paiement sensibles ».
[18] . Cf. GL, n° 52. Comp. RGPD, cons. 10 : « Le présent règlement laisse aussi aux États membres une marge de manœuvre pour préciser ses règles, y compris en ce qui concerne le traitement de catégories particulières de données à caractère personnel (ci-après dénommées « données sensibles ») ».
[19] . Cf. GL, n° 53.
[20] . Cf. GL, n° 61.
[21] . RGPD, art. 5, 1, c).
[22] . Cf. GL, n° 67 et s.
[23] . Cf. GL, n° 71 et s.
[24] . Cf. RGPD, art. 4, 4 : « “profilage”, toute forme de traitement automatisé de données à caractère personnel consistant à utiliser ces données à caractère personnel pour évaluer certains aspects personnels relatifs à une personne physique, notamment pour analyser ou prédire des éléments concernant le rendement au travail, la situation économique, la santé, les préférences personnelles, les intérêts, la fiabilité, le comportement, la localisation ou les déplacements de cette personne physique ».
