En une phrase. La directive DSP2 (UE) 2015/2366, transposée en France par l’ordonnance n° 2017-1252, organise l’accès des agrégateurs (AISP) et prestataires d’initiation de paiement (PISP) aux comptes bancaires ; l’EDPB a précisé dans ses lignes directrices 06/2020 que la base légale de ces traitements est en principe l’exécution du contrat (art. 6(1)(b) RGPD) et non le consentement RGPD, le « consentement explicite » de l’article 94(2) DSP2 étant une notion contractuelle distincte.
L’open banking est l’un des terrains où la confusion entre notions juridiques voisines mais distinctes coûte le plus cher en conformité : le « consentement » exigé par la DSP2 pour accéder à un compte bancaire n’est pas le consentement au sens des articles 6 et 7 du RGPD, et les deux textes doivent être appliqués cumulativement, sans que l’un ne dispense de l’autre. La directive elle-même est consultable sur EUR-Lex ; l’articulation avec le RGPD fait l’objet de lignes directrices dédiées du Comité européen de la protection des données (EDPB).
Cet article détaille le cadre DSP2, les acteurs de l’open banking et leurs bases légales respectives, ainsi que les points de vigilance RGPD spécifiques identifiés par l’EDPB pour les agrégateurs financiers.
Points clés
- La DSP2 (directive (UE) 2015/2366) organise l’open banking et l’accès aux comptes de paiement (XS2A), transposée en France par l’ordonnance n° 2017-1252.
- Deux nouveaux acteurs agréés par l’ACPR : les agrégateurs (AISP) et les prestataires d’initiation de paiement (PISP).
- L’authentification forte (SCA) est imposée par la DSP2 et précisée par le règlement délégué (UE) 2018/389 (RTS).
- La base légale du traitement des données de paiement par les AISP/PISP est en principe l’exécution du contrat (art. 6(1)(b) RGPD), pas le consentement RGPD.
- Le « consentement explicite » de l’article 94(2) DSP2 est une notion contractuelle, distincte du consentement RGPD des art. 6 et 7.
- Les données de tiers non parties au contrat (« silent party data ») reposent sur l’intérêt légitime, avec minimisation stricte.
1. Le cadre DSP2 : open banking et nouveaux acteurs
Un cadre transposé en droit français
La directive (UE) 2015/2366 sur les services de paiement, dite DSP2, a été transposée en France par l’ordonnance n° 2017-1252. Elle poursuit un objectif structurant pour le secteur bancaire : ouvrir l’accès aux comptes de paiement à des tiers agréés, au-delà des seuls établissements bancaires teneurs de compte — ce que le texte désigne sous l’acronyme XS2A (access to account).
Deux catégories de prestataires nouveaux émergent de ce cadre, tous deux agréés ou enregistrés auprès de l’ACPR :
- les AISP (Account Information Service Providers), communément appelés « agrégateurs », qui consolident les informations de plusieurs comptes bancaires d’un même utilisateur dans une interface unique ;
- les PISP (Payment Initiation Service Providers), qui initient un ordre de paiement directement depuis le compte de l’utilisateur, sans passer par les moyens de paiement traditionnels.
| Acteur | Rôle | Base légale RGPD principale | Données traitées |
|---|---|---|---|
| Banque teneuse de compte | Détient le compte, met à disposition une API DSP2 | Exécution du contrat bancaire | Données du client titulaire du compte |
| AISP (agrégateur) | Consolide les informations de comptes multiples | Exécution du contrat conclu avec l’utilisateur | Soldes, historiques de transactions |
| PISP (initiation de paiement) | Initie un ordre de paiement pour le compte de l’utilisateur | Exécution du contrat conclu avec l’utilisateur | Données nécessaires à l’ordre de paiement |
| Traitement de données de tiers (silent party) | Bénéficiaires de virements apparaissant dans l’historique | Intérêt légitime, minimisation stricte | Nom, IBAN du tiers apparaissant dans la transaction |
L’authentification forte, pierre angulaire de la sécurité DSP2
La DSP2 impose une authentification forte du client (SCA — Strong Customer Authentication), précisée par le règlement délégué (UE) 2018/389 (RTS). Elle exige la combinaison d’au moins deux facteurs indépendants parmi trois catégories : la connaissance (mot de passe, code), la possession (téléphone, carte) et l’inhérence (biométrie). Cette exigence de sécurité technique rejoint, sur le fond, l’obligation générale de sécurité du traitement posée par l’article 32 du RGPD : les API dédiées à l’open banking doivent être conçues nativement pour limiter la surface d’exposition des données bancaires.
2. L’articulation DSP2/RGPD selon l’EDPB : la clarification essentielle
Deux notions de « consentement » à ne pas confondre
Le point le plus structurant pour la conformité des agrégateurs a été clarifié par l’EDPB dans ses lignes directrices 06/2020 sur l’interaction entre la DSP2 et le RGPD : le « consentement explicite » exigé par l’article 94(2) de la DSP2 pour le traitement des données à des fins de services de paiement est une notion contractuelle propre au droit des paiements, distincte du consentement au sens des articles 6 et 7 du RGPD.
Concrètement, cela signifie que :
- l’accord donné par l’utilisateur pour que l’agrégateur accède à ses comptes relève d’une logique contractuelle DSP2, et ne constitue pas en lui-même la base légale RGPD du traitement ;
- la base légale RGPD appropriée pour le traitement des données de paiement par les AISP et PISP est, en principe, l’exécution du contrat conclu entre le prestataire et l’utilisateur (article 6(1)(b) du RGPD), et non le consentement de l’article 6(1)(a).
Cette distinction a des conséquences pratiques directes : un agrégateur ne peut pas se contenter de faire cocher une case de consentement DSP2 pour s’estimer couvert au regard du RGPD ; il doit identifier, documenter et justifier séparément sa base légale RGPD — le plus souvent l’exécution du contrat de service d’agrégation. Voir notre guide sur les bases juridiques du RGPD et sur les conditions de validité du consentement RGPD pour approfondir cette distinction, souvent source d’erreur dans les CGU des fintechs.
Le cas des « silent party data » : les tiers non contractants
Un historique de compte bancaire ne contient pas que des données de son titulaire : il révèle systématiquement l’identité de tiers non parties au contrat d’agrégation — bénéficiaires de virements, émetteurs de prélèvements. L’EDPB qualifie ces informations de « silent party data » et recommande de fonder leur traitement sur l’intérêt légitime (article 6(1)(f) du RGPD), sous réserve d’une minimisation stricte et de l’absence de tout traitement ultérieur incompatible avec la finalité initiale.
Cela implique concrètement de mener un test de mise en balance en trois temps — conformément à notre guide sur le triple test de l’intérêt légitime — et d’éviter toute exploitation secondaire de ces données de tiers (profilage commercial, revente, enrichissement de bases marketing), qui romprait le lien de proportionnalité avec la finalité de service de paiement initialement poursuivie.
L’interdiction de principe sur les données sensibles
Un historique de transactions bancaires peut, par déduction, révéler des données sensibles au sens de l’article 9 du RGPD — dons à une organisation religieuse, achats liés à un état de santé, cotisation à un syndicat. L’EDPB pose un principe d’interdiction de traitement de ces données sensibles éventuellement révélées par l’analyse des transactions, sauf exception strictement encadrée par l’article 9. Les agrégateurs doivent donc concevoir leurs algorithmes de catégorisation des dépenses en excluant toute inférence portant sur ces catégories protégées.
3. Les principes RGPD structurants pour les acteurs de l’open banking
Au-delà de la question de la base légale, quatre principes RGPD structurent la conformité des AISP et PISP :
- Minimisation : ne collecter que les données de compte strictement nécessaires au service d’agrégation ou d’initiation de paiement souscrit, et non l’intégralité de l’historique disponible via l’API bancaire.
- Limitation des finalités : les données collectées pour un service d’agrégation ne peuvent être réutilisées à des fins de scoring crédit ou de prospection commerciale sans base légale et information distinctes.
- Sécurité (art. 32) : recours obligatoire à des API dédiées et sécurisées (et non au « web scraping » d’interfaces bancaires classiques, pratique que la DSP2 a précisément entendu faire disparaître).
- Transparence : information claire de l’utilisateur sur l’étendue des données de compte consultées, la durée de conservation et les destinataires éventuels.
Ce cadre s’inscrit dans une exigence de résilience opérationnelle plus large pour le secteur financier, également structurée par le règlement DORA — voir notre guide DORA France pour l’articulation entre sécurité des API de paiement et gestion du risque TIC.
Legiscope accompagne les fintechs et agrégateurs dans la qualification de leur base légale RGPD pour les services DSP2 et dans la rédaction de leurs analyses d’intérêt légitime pour les données de tiers.
FAQ
Le consentement DSP2 suffit-il pour être conforme au RGPD ?
Non. Selon les lignes directrices 06/2020 de l’EDPB, le consentement explicite de l’article 94(2) de la DSP2 est une notion contractuelle distincte du consentement RGPD. La base légale RGPD appropriée pour un AISP ou un PISP est en principe l’exécution du contrat (art. 6(1)(b)), à documenter séparément.
Comment un agrégateur doit-il traiter les données des bénéficiaires de virements ?
Ces données de tiers non contractants (« silent party data ») doivent reposer sur l’intérêt légitime, avec une minimisation stricte et sans réutilisation à des fins incompatibles avec le service de paiement initial.
Un agrégateur doit-il être agréé pour accéder aux comptes bancaires ?
Oui, les AISP et PISP doivent être agréés ou enregistrés auprès de l’ACPR pour exercer légalement leur activité d’accès aux comptes de paiement dans le cadre de la DSP2.
L’authentification forte (SCA) s’applique-t-elle à tous les accès aux comptes ?
Le règlement délégué (UE) 2018/389 impose la SCA pour l’accès aux comptes de paiement en ligne et l’initiation de paiement, sous réserve des exemptions prévues par ce même règlement pour certaines opérations à faible risque.
Conclusion
La DSP2 et le RGPD ne s’excluent pas, ils se cumulent — mais selon une logique que l’EDPB a dû clarifier tant la confusion entre les deux régimes de « consentement » était source d’erreurs de conformité. Pour les agrégateurs et prestataires d’initiation de paiement, l’enjeu 2026 consiste à documenter une base légale RGPD autonome de l’accord contractuel DSP2 — le plus souvent l’exécution du contrat —, à traiter les données de tiers via un intérêt légitime rigoureusement testé, et à s’appuyer sur des API sécurisées conformes aux exigences de la SCA. Une conformité DSP2 formelle ne vaut pas conformité RGPD : les deux dossiers doivent être construits en parallèle.
Legiscope automates this for you
Stop doing compliance manually. Legiscope's AI handles ROPA creation, DPA audits, and gap analysis — in minutes, not weeks.
Start free trial