la carte réglementaire que tout responsable data en fintech doit avoir en tête

Un seul enregistrement client, disons Maria à Berlin, qui utilise une néobanque dont le siège est aux États-Unis avec un partenaire de paiement britannique, peut déclencher simultanément des obligations relevant de quatre ou cinq lois sur les données qui se chevauchent, dès qu'elle appuie sur « confirmer » pour une transaction. Son nom, son IBAN, son historique de dépenses et l'empreinte de son appareil relèvent chacun de juridictions différentes, de règles de consentement différentes et de délais de suppression différents. Ce n'est pas un cas limite. C'est l'architecture par défaut de la fintech moderne.

Cette leçon vous donne la carte : les réglementations centrales, les points de friction entre elles, et les vérifications concrètes à mener pour survivre à un audit sans geler votre roadmap produit.

Les cinq régimes que vous devez mamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète →îtriser parfaitement

Le RGPD (Règlement général sur la protection des données), droit européen en vigueur depuis 2018, encadre toute donnée personnelle de résidents de l'UE, quel que soit le pays où est basée votre entreprise. Mécanique centrale : base légale du traitement, droit à l'effacement (« droit à l'oubli »), portabilité des données, et notification obligatoire des violations aux régulateurs sous 72 heures. Appliqué par les autorités nationales de protection des données (DPA), coordonnées de manière souple par le Comité européen de la protection des données.

La DSP2 (Directive sur les services de paiement révisée), directive européenne de 2018, impose l'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. : les banques doivent exposer les données de comptes clients à des tiers agréés 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 →, si le client y consent. Elle a 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 →éé la base légale des agrégateurs de comptes comme Tink (racheté par Visa) et les activités européennes de Plaid. La DSP2 impose également l'authentification forte du client (SCA), une vérification à deux facteurs sur la plupart des paiements en ligne.

Le GLBA (Gramm-Leach-Bliley Act), loi fédérale américaine de 1999, oblige les institutions financières à expliquer leurs pratiques de partage d'informations et à protéger les informations personnelles non publiques (NPI). Appliqué par la FTC et les régulateurs bancaires prudentiels (OCC, Réserve fédérale, FDIC). Le GLBA repose sur la notification, pas sur le consentement : les institutions peuvent partager les données avec leurs affiliés par défaut, sauf opt-out du client.

Le CCPA / CPRA (California Consumer Privacy Act, amendé par le California Privacy Rights Act), en vigueur respectivement depuis 2020 et 2023, donne aux résidents californiens le droit de savoir, de supprimer et de refuser la « vente ou le partage » de leurs données personnelles. Appliqué par la California Privacy Protection Agency (CPPA). À noter : les données régies par le GLBA sont largement exemptées du CCPA, une exclusion qui piège les équipes conformité persuadées que le droit américain de la vie privée est uniforme.

Les règles d'open banking hors UE : le Royaume-Uni applique son propre régime post-Brexit via l'Open Banking Implementation Entity, et les États-Unis sont passés de frameworks volontaires à un régime contraignant fondé sur la Section 1033 du Dodd-Frank Act, le Consumer Financial Protection Bureau (CFPB) finalisant les règles d'accès aux données des consommateurs à partir de 2024. Le périmètre et les calendriers d'application diffèrent encore sensiblement de la trajectoire européenne DSP2/DSP3.

Là où les régimes s'entrechoquent sur un même enregistrement

Revenons à Maria. Voici la carte des collisions pour son unique enregistrement de transaction :

• Modèles de consentement incompatibles : le 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 → exige un consentement explicite (opt-in) pour la plupart des traitements. Le GLBA fonctionne par défaut en opt-out. Si votre plateforme sert des clients américains et européens depuis un même pipeline de donnéespipeline de donnéesSéquence automatisée d'étapes qui déplace les données de la source vers la destination : ingestion, transformation, validation et chargement, pour qu'elles arrivent propres et prêtes à l'emploi.Voir la définition complète →, vous ne pouvez pas utiliser un seul flag de consentement. Il vous faut un état de consentement sensible à la juridiction, enregistrement par enregistrement.

• Conflits de suppression : le droit à l'effacement du RGPD impose de supprimer sur demande. Mais les règles de conservation des documents financiers (dans l'UE, les directives anti-blanchiment ; aux États-Unis, les exigences du Bank Secrecy Act appliquées par le FinCEN) imposent de conserver les enregistrements de transactions pendant cinq à sept ans. Votre architecture de données doit permettre le « soft delete avec legal hold », pas une suppression réelle, et vous devez être capable d'expliquer cette distinction à un régulateur ou à un client mécontent.

• Accès de tiers dans le cadre de l'open banking : la DSP2 vous oblige à exposer les données de compte de Maria à tout prestataire tiers agréé (TPP) qu'elle autorise. Le RGPD fait toujours de vous le responsable de traitement, comptable de ce qu'il advient de ces données ensuite. Si le TPP les gère mal, les régulateurs peuvent quand même se tourner vers vous pour l'exposition initiale et la conception du consentement.

• Transferts transfrontaliers : si les données de Maria transitent par une région cloud américaine (courant avec les architectures globales AWS, GCP, Azure), les règles du RGPD sur les transferts internationaux s'appliquent. Depuis l'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êt *Schrems II* (2020, Cour de justice de l'UE), les clauses contractuelles types et, depuis 2023, le Data Privacy Framework UE-États-Unis sont les principaux mécanismes juridiques. Une erreur ici et toute votre stack analytique hébergée aux États-Unis devient un passif. Référence : la présentation du Data Privacy Framework par la Commission européenne.

Les arbitrages d'architecture que cela impose

Comme ces règles ne s'harmonisent pas, les responsables data font des choix d'architecture délibérés :

1. Partitionnement par résidence des données : de nombreuses fintechs font tourner les données de leurs clients européens sur des infrastructures cloud en région UE (localisation des donnéeslocalisation des donnéesL'exigence de stocker et traiter les données physiquement dans un pays ou une région précise, souvent pour des raisons légales ou contractuelles.Voir la définition complète →) même quand ce n'est pas toujours techniquement obligatoire, simplement pour réduire le risque lié aux mécanismes de transfert et la complexité d'audit.

1. Le consentement comme objet de données de premier rang : l'état du consentement (qui, pour quelle finalité, dans quelle juridiction, à quel horodatage, quelle version de politique acceptée) est modélisé dans sa propre table auditable, pas comme un booléen enfoui dans un profil utilisateur.

1. Une gouvernance au niveau du champ, pas de la table : les NPI au sens du GLBA, les données de catégorie particulière au sens du RGPD (qui incluent par exemple les identifiants biométriques) et la catégorie « sensitive personal information » du CCPA ne correspondent pas à des listes de champs identiques. Le tagging doit se faire au niveau de la colonne ou du champ, avec des métadonnées de juridiction associées.

Un schéma simplifié de ce que cela donne en pratique :

-- consent_ledger : une ligne par événement de consentement, pas par utilisateur
CREATE TABLE consent_ledger (
    consent_id UUID PRIMARY KEY,
    customer_id UUID NOT NULL,
    jurisdiction VARCHAR(10) NOT NULL,   -- 'EU', 'US-CA', 'US-FED', 'UK'
    legal_basis VARCHAR(50) NOT NULL,    -- 'GDPR_ART6_1A', 'GLBA_OPT_OUT', 'CCPA_OPT_OUT'
    purpose VARCHAR(100) NOT NULL,       -- 'MARKETING', 'OPEN_BANKING_SHARE'
    granted_at TIMESTAMP,
    revoked_at TIMESTAMP,
    policy_version VARCHAR(20)
);

Ce n'est pas de la décoration. Les auditeurs et les régulateurs demanderont « montrez-moi le consentement pour cette finalité de traitement précise, à cette date, pour ce client ». Si cette requête exige trois jours d'archéologie de logs à un data engineer, vous avez un problème de gouvernance.

Les vérifications concrètes à mener

La maîtrise du secteur, c'est savoir à quoi ressemble un vrai audit ou un cycle de contrôle interne, pas seulement citer les lois.

Audit trimestriel de cartographie des données : maintenez un registre des activités de traitement (ROPA) vivant, inventaire imposé par le RGPD de ce que vous détenez comme données personnelles, pourquoi, où elles sont stockées et qui peut y accéder. La plupart des fintechs matures automatisent cela avec des outils de data catalog (Collibra, Alation par exemple) plutôt qu'avec des tableurs.

Revue des contrôles d'accès : vérifiez le principe du moindre privilège sur les NPI et les données de catégorie particulière. Constat fréquent en audit : des agents du support client disposant d'un accès SQL étendu à des tables de production dont leur rôle n'a pas besoin.

Simulation de violation / exercice de réponse à incident : le compte à rebours de 72 heures du RGPD démarre à la prise de connaissance, pas à la confirmation. Menez des exercices sur table pour vérifier si votre équipe sait réellement détecter, cadrer et rédiger une notification dans ce délai.

Revue du risque lié aux API tierces : sous la DSP2 et les règles d'open banking du CFPB, auditez quels TPP disposent de jetons d'accès actifs, quand le consentement expire, et si la révocation se propage réellement dans vos systèmes, pas seulement dans votre base de données.

Inventaire des transferts transfrontaliers : listez chaque système où des données personnelles européennes quittent une infrastructure européenne, et confirmez que le mécanisme de transfert juridique est à jour (le framework UE-États-Unis a déjà résisté à des recours mais reste contestable).

Pour une vue côté régulateur des tendances de sanction, la bibliothèque des actions coercitives de l'ICO (Information Commissioner's Office britannique) est une source gratuite réellement utile de cas réels, pratique pour repérer les schémas de ce qui est effectivement sanctionné.

Points clés à retenir

• Aucun framework global unique ne régit les données en fintech. RGPD, DSP2, GLBA et CCPA/CPRA fonctionnent selon des logiques différentes (consentement vs notification, suppression vs conservation) et un seul enregistrement client peut relever des quatre à la fois.
• Les demandes de suppression au titre du RGPD doivent être conciliées avec les obligations de conservation financière (AML, Bank Secrecy Act) ; la réponse pratique est le soft delete avec legal hold, pas l'effacement réel.
• Le consentement doit être modélisé comme un objet de données auditable et taggé par juridiction, pas comme un flag unique, parce que les régulateurs demanderont une preuve horodatée et spécifique à la finalité.
• Les transferts transfrontaliers de données (surtout de l'UE vers des infrastructures cloud américaines) exigent un mécanisme juridique actif (CCT ou Data Privacy Framework UE-États-Unis) qui doit être suivi et revérifié périodiquement.
• Menez des vérifications récurrentes et concrètes : cartographie ROPA, revues des contrôles d'accès, exercices de violation et audits d'accès des TPP, car c'est ce que les examinateurs et les DPA testent en premier.