Data privacy et open finance : RGPD, CCPA et consentement au partage de données

Un utilisateur connecte son compte bancaire à une application de gestion de budget. Derrière ce simple clic, l'application vient de déclencher des obligations relevant d'au moins deux grands régimes de protection des données, d'une règle d'accès aux données bancaires et, éventuellement, d'un standard de consentement sectoriel, selon le lieu de résidence de l'utilisateur. Si cet utilisateur demande ensuite « supprimez mes données », l'agrégateur a 45 jours (ou moins) pour prouver qu'il l'a réellement fait. C'est la réalité opérationnelle de l'open finance en 2026 : le consentement n'est pas une case à cocher, c'est un système de conformité.

Pourquoi les agrégateurs sont au cœur de cette leçon

Les agrégateurs de comptes (Plaid, MX, Yodlee, Tink en Europe) récupèrent les données de transaction auprès des banques via des APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → (application programming interfaces, les canaux techniques que les banques exposent pour l'accès aux données) et les transmettent à des applications fintech : outils de budget, prêteurs, robo-advisors.

Ils sont « responsables du traitement » ou « sous-traitants » au sens du RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète → selon leur rôle, c'est-à-dire qu'ils décident de l'usage des données (responsable) ou agissent sur instruction d'un tiers (sous-traitant). Cette distinction détermine qui est juridiquement en première ligne quand quelque chose dérape.

RGPD : la référence européenne

Le RGPD (Règlement général sur la protection des données), appliqué depuis 2018 par les autorités nationales de protection des données (DPA, comme la DPC irlandaise ou la CNIL française) sous la coordination du Comité européen de la protection des données, fixe le standard de référence mondial en matière de consentement.

Exigences centrales pour les agrégateurs fintech :

• Base légale du traitement. Le consentement n'est qu'une des six bases légales. Pour l'agrégation de comptes, la plupart des fintechs européennes s'appuient sur le « consentement explicite » ou la « nécessité contractuelle », et les régulateurs attendent qu'elles documentent laquelle s'applique à chaque flux de données.
• Le consentement doit être libre, spécifique, éclairé et univoque. Une case précochée ne convient pas. Regrouper « j'accepte de partager mes données de transaction » et « j'accepte de recevoir des emails marketing » dans une seule case est une violation courante.
• Droit à l'effacement (« droit à l'oubli »). Les utilisateurs peuvent exiger la suppression, même si les banques peuvent conserver certaines pièces à des fins de lutte contre le blanchiment en vertu d'une autre législation, ce qui crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →ée une tension réelle que les agrégateurs doivent gérer techniquement.
• Minimisation des données. Ne collecter que le nécessaire. Un agrégateur qui récupère cinq ans d'historique de transactions pour accorder un prêt alors que le modèle du prêteur n'utilise que 12 mois est en défaut de minimisation.
• Portabilité des données (article 20) : les utilisateurs peuvent demander leurs données dans un « format structuré, couramment utilisé et lisible par machine » et les transférer à un concurrent.

Les amendes peuvent atteindre 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. Meta et Amazon ont tous deux reçu des amendes de plusieurs centaines de millions pour violation du RGPD ; une fintech de taille moyenne encourrait des sanctions proportionnellement plus faibles mais tout de même significatives.

CCPA et CPRA : la voie parallèle californienne

Le CCPA (California Consumer Privacy Act, 2018) et son amendement de 2023, le CPRA (California Privacy Rights Act), accordent aux résidents californiens des droits dont l'application est assurée par la California Privacy Protection Agency (CPPA).

Différences clés avec le RGPD sur le plan opérationnel :

• Le CCPA fonctionne par défaut en opt-out pour la vente et le partage de données, et non en consentement opt-in comme le RGPD. Une fintech américaine n'a pas besoin d'un consentement affirmatif pour traiter des données, mais doit permettre aux utilisateurs de dire « ne vendez pas mes données ».
• Le droit à la suppression existe, mais avec davantage d'exceptions pour les documents financiers et de conformité légale que dans l'UE.
• Le CCPA s'applique en fonction de seuils de chiffre d'affaires et de volume de données (en gros, les entreprises de plus de 25 millions de dollars de chiffre d'affaires annuel, ou qui traitent les données de plus de 100 000 consommateurs/foyers). Une petite startup fintech peut en être exemptée ; une entreprise passée à l'échelle non.
• Il n'existe pas de loi fédérale américaine unique équivalente au RGPD. D'autres États (le VCDPA en Virginie, le CPACPACost Per Acquisition : le coût total pour générer un client ou une conversion, calculé en divisant la dépense totale par le nombre d'acquisitions.Voir la définition complète → au Colorado) ajoutent des règles qui se recoupent sans être identiques : une fintech uniquement américaine fait donc face à une mosaïque de textes.

Conséquence pratique : un agrégateur qui sert à la fois des utilisateurs européens et californiens construit généralement au standard RGPD, plus strict, à l'échelle mondiale, puis ajoute par-dessus les mécaniques propres au CCPA (un lien « Do Not Sell or Share My Personal Information »), plutôt que d'exploiter deux systèmes distincts.

Open finance et règles de portabilité des données

Au-delà du droit général de la protection des données, des règles dédiées d'open banking / open finance encadrent spécifiquement la connexion des comptes.

• Europe : la DSP2 (deuxième directive sur les services de paiement) oblige les banques à fournir aux prestataires tiers régulés un accès sécurisé par API aux données de compte, lorsque le client y consent. L'EBA (Autorité bancaire européenne) fixe les standards techniques (authentification forte du client, communication sécurisée). La DSP3, en négociation en 2025-2026, vise à remplacer entièrement le screen-scraping par des API standardisées.
• États-Unis : le CFPB (Consumer Financial Protection Bureau) a finalisé sa règle Section 1033 sur les droits relatifs aux données financières personnelles (publiée en 2024) en vertu du Dodd-Frank Act. Elle oblige les banques à donner aux consommateurs, et aux tiers qu'ils autorisent comme les agrégateurs, l'accès à leurs propres données financières dans un format standardisé et lisible par machine, largement à titre gratuit. En 2026, cette règle est en cours de déploiement progressif et fait face à des contestations juridiques et politiques de la part des organisations professionnelles bancaires ; les calendriers restent donc mouvants. Consultez la page officielle de la règle du CFPB pour l'état actuel.
• Royaume-Uni : le cadre de l'Open Banking Implementation Entity, en cours de transition vers le dispositif plus large Smart Data, joue un rôle similaire après le Brexit.

Le point commun : le consentement au partage de données doit être spécifique (et non global), révocable (l'utilisateur peut couper l'accès à tout moment) et limité dans le temps (de nombreux régimes plafonnent le consentement permanent à 90 jours avant réautorisation).

Ce que cela implique concrètement en engineering produit

Un parcours de consentement conforme pour la connexion de compte suppose généralement :

1. Un écran de consentement nommant les catégories exactes de données demandées (soldes, historique de transactions, nom du titulaire du compte), et non un bouton générique « autoriser l'accès ».
2. Un registre de consentement : un enregistrement interne auditable de ce à quoi l'utilisateur a consenti, quand, et jusqu'à quelle échéance, afin de pouvoir prouver la conformité si un régulateur le demande.
3. Un pipeline de suppression qui propage les demandes d'effacement à tous les systèmes en aval, y compris les entrepôts analytiques et les jeux d'entraînement ML, et pas seulement la base de données principale.
4. Des déclencheurs de réauthentification qui font expirer automatiquement les consentements périmés.

Une structure simplifiée d'enregistrement de consentement :

{
  "user_id": "u_48213",
  "data_scope": ["transactions", "account_balance"],
  "purpose": "credit_underwriting",
  "consent_given_at": "2026-01-14T10:32:00Z",
  "expires_at": "2026-04-14T10:32:00Z",
  "revocable_via": "app_settings",
  "legal_basis": "GDPR Art.6(1)(a) explicit consent"
}

Ce ne sont pas des métadonnées jetables : c'est l'artefact qu'une DPA ou le CFPB demandera à voir lors d'un contrôle.

Là où ça se complique : transfrontalier et risque tiers

Les agrégateurs opèrent rarement dans une seule juridiction. Une néobanque dont le siège est aux États-Unis, qui utilise un partenaire européen de core banking et sert des clients qui circulent entre le Royaume-Uni et l'UE, doit concilier simultanément le RGPD, le UK GDPR (un régime quasi identique mais appliqué séparément depuis le Brexit), les lois d'État de type CCPA et la DSP2/DSP3.

Le risque tiers ajoute une couche : si le prestataire externalisé de KYC (Know Your Customer) d'une fintech gère mal les données, la fintech elle-même, en tant que responsable du traitement, reste généralement responsable au titre du RGPD. C'est pourquoi les régulateurs attendent de plus en plus une due diligence fournisseurs documentée et des accords de traitement de données (DPA, à ne pas confondre avec les autorités de protection des données) avec chaque sous-traitant en contact avec des données personnelles.

🎬 [VIDEO: "GDPR Explained in Simple Terms" - https://www.youtube.com/results?search_query=gdpr+explained+simple+terms - une explication en langage clair du consentement, des bases légales et des mécanismes de sanction, utile aux apprenants non techniques]

Pour aller au fond avec une source primaire, le portail officiel du texte et des lignes directrices RGPD de l'UE est gratuit et fait autorité.

Points clés

• Le RGPD exige un consentement opt-in, spécifique et révocable, et confère aux utilisateurs des droits d'effacement et de portabilité ; le CCPA/CPRA fonctionnent par défaut en opt-out et se concentrent sur les informations relatives à la vente et au partage. Les fintechs mondiales construisent donc généralement au standard RGPD, plus strict, et ajoutent par-dessus les mécaniques propres à chaque État.
• Les règles d'accès de l'open finance (DSP2/DSP3 en Europe, Section 1033 aux États-Unis via le CFPB, Smart Data au Royaume-Uni) sont distinctes du droit général de la protection des données : elles imposent spécifiquement aux banques d'exposer les données de compte à des tiers autorisés via des API sécurisées et standardisées.
• Une connexion de compte conforme relève de l'engineering, pas seulement de la politique juridique : registres de consentement, autorisations à expiration et pipelines de suppression atteignant chaque stockage de données en aval, y compris l'analytics et les données d'entraînement ML.
• La responsabilité suit la donnée, pas l'organigramme : agrégateurs et responsables du traitement restent généralement comptables des manquements de leurs prestataires en matière de protection des données.
• Aux États-Unis, les règles fédérales de protection des données et d'open bankingopen bankingCadre réglementaire (PSD2 en Europe) obligeant les banques à partager les données clients via des API standardisées, avec consentement, transformant les données bancaires en actif compétitif. sont encore en consolidation en 2026 ; vérifiez directement auprès du CFPB et de l'EBA l'état d'avancement de la mise en œuvre avant de supposer qu'une règle est pleinement en vigueur.