mener un audit de data governance que les régulateurs respectent

Un examinateur de l'OCC (Office of the Comptroller of the Currency, qui supervise les banques nationales américaines) arrive pour une revue de partenariat bancaire chez une fintech et pose d'abord une seule question : « Montrez-moi qui a accédé aux numéros de sécurité sociale des clients mardi dernier, et pourquoi. » Si la réponse prend plus de quelques minutes à produire, l'audit a déjà mal commencé.

C'est la réalité de la data governancedata governanceLa data governance est l'ensemble des politiques, rôles et processus qui garantissent que les données sont exactes, sécurisées, bien définies et utilisées de façon responsable dans toute l'organisation.Voir la définition complète → en fintech en 2026. Les régulateurs ne veulent pas d'un classeur de politiques. Ils veulent la preuve que les contrôles tournent réellement, chaque jour, sur des données réelles. Cette leçon construit le script d'audit lui-même : la séquence exacte qu'une équipe compliance ou data bien tenue déroule avant qu'un régulateur ne se présente.

Pourquoi ce n'est plus optionnel

Les fintechs se situent à l'intersection du droit bancaire et de la vitesse des plateformes tech, ce qui signifie qu'elles héritent d'obligations issues de plusieurs régimes à la fois :

• GLBA (Gramm-Leach-Bliley Act, États-Unis) : impose aux institutions financières de protéger les informations personnelles non publiques (NPI) et d'expliquer le partage de données aux clients.
• GDPRGDPRRè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 → (General Data Protection Regulation, UE/Royaume-Uni) : encadre le traitement des données personnelles, avec des amendes pouvant atteindre 4 % du chiffre d'affaires annuel mondial.
• Règles FCA (Financial Conduct Authority, Royaume-Uni) Consumer Duty et SYSC : exigent des firmes qu'elles démontrent des « systèmes et contrôles appropriés » sur les données utilisées dans les décisions.
• CFPB Section 1033 (États-Unis, règle de partage de données 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., finalisée en 2024, entrée en vigueur progressive jusqu'en 2026-2027) : encadre la façon dont les données financières des consommateurs doivent être partagées avec des tiers sur demande.

Les examinateurs testent de plus en plus les trois mêmes choses dans tous ces régimes : qui peut toucher les données, ce que sont réellement ces données, et où elles vont après avoir quitté la maison. Cela correspond directement à l'audit en trois parties ci-dessous.

Partie 1 : audit du contrôle d'accès

L'objectif : prouver que l'accès aux données sensibles est restreint, journalisé et revu, et pas seulement restreint en théorie par un document de politique.

Étape 1 : sortez la matrice d'accès. Listez chaque système détenant des données clients (registre bancaire central, prestataire KYC, modèle de fraude, CRMCRMCustomer Relationship Management : logiciel et stratégie pour gérer et analyser les interactions clients tout au long de leur cycle de vie.Voir la définition complète → du support client) face à chaque rôle pouvant y lire ou y écrire. Si vous ne pouvez pas produire cela en moins d'une journée, c'est déjà un constat.

Étape 2 : testez le moindre privilège. Sur un échantillon de 20 à 30 collaborateurs, vérifiez si leurs accès réels correspondent à leur fonction. Un constat fréquent : un ancien analyste underwriting passé au marketing conserve un accès en lecture aux dossiers de prêt six mois plus tard.

Étape 3 : vérifiez la robustesse de l'authentification. Les comptes à privilèges (admins, ingénieurs base de données) sont-ils protégés par MFA (multi-factor authentication) ? Selon les orientations du FFIEC (Federal Financial Institutions Examination Council), les examinateurs considèrent par défaut un accès admin à facteur unique comme un signal d'alerte.

Étape 4 : revoyez le log d'accès lui-même. Pas seulement « un log existe-t-il » mais « quelqu'un le lit-il ». Demandez : qui a revu le log des accès à privilèges le mois dernier, et qu'a-t-il signalé ?

Une requête simple qu'une équipe data ou sécurité devrait pouvoir lancer à la demande :

SELECT user_id, resource_accessed, access_timestamp, action_type
FROM access_logs
WHERE resource_sensitivity = 'PII_HIGH'
  AND access_timestamp >= NOW() - INTERVAL '30 days'
ORDER BY user_id;

Si cette requête n'existe pas, ou demande plusieurs jours d'ingénierie à construire, vous n'avez pas de véritable piste d'audit des accès. C'est exactement cette faille qu'un examinateur de l'OCC ou de la FCA est formé à sonder.

Partie 2 : audit de la classification des données

Les régulateurs veulent voir que toutes les données ne sont pas traitées de la même manière, parce qu'elles ne sont pas juridiquement équivalentes.

Exemple de tiering utilisé par la plupart des fintechs :

Le test d'audit : choisissez cinq tables de base de données au hasard et demandez à l'équipe data de nommer le tier de classification et de le justifier. Un échec fréquent : une base « test » ou « staging » qui est une copie complète de la production, non masquée, accessible à vingt ingénieurs. Ce seul constat revient régulièrement dans les actions coercitives, notamment dans les actions de la FTC au titre de la Section 5 contre des fintechs pour pratiques déloyales sur les données (base des actions coercitives de la FTC).

Contrôle de minimisation des données : la fintech détient-elle encore des données dont elle n'a plus besoin ? Le principe de limitation de la conservation du GDPR et de nombreuses lois d'États américains sur la vie privée (par exemple le CCPA/CPRA californien) exigent la suppression dès que la finalité prend fin. Demandez : quelle est la politique de suppression pour un compte clôturé, et pouvez-vous la montrer s'exécuter, pas seulement écrite ?

Partie 3 : audit du log de partage avec les tiers

C'est là que les fintechs se font le plus souvent prendre, parce que le business model repose sur le partage de données avec des partenaires : banques sponsors, prestataires KYC/AML (know-your-customer, anti-money-laundering), processeurs de paiement, bureaux de crédit, plateformes publicitaires.

Étape 1 : inventoriez chaque tiers recevant des données clients. Pas seulement « nous utilisons Plaid pour la vérification de compte bancaire » mais les champs de données précis transmis.

Étape 2 : rattachez chaque transfert à une base légale. Le GLBA exige un avis de confidentialité couvrant les catégories de partage ; le GDPR exige une base légale (consentement, contrat, intérêt légitime) par transfert ; la règle 1033 du CFPB exige l'autorisation affirmative du consommateur pour les données partagées 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 → d'open banking.

Étape 3 : vérifiez la présence d'un Data Processing Agreement (DPA) dans le contrat fournisseur, le document juridique précisant comment un prestataire doit traiter, sécuriser et supprimer les données partagées. Les examinateurs demandent systématiquement le DPA, pas seulement le contrat commercial.

Étape 4 : tracez une transaction réelle de bout en bout. Prenez la demande de prêt d'un client unique et demandez : quels tiers ont touché cet enregistrement, dans quel ordre, et où est l'entrée de log pour chaque passage de main ? Cette méthode du « suivi d'un dossier » est une technique d'examen connue de la FCA parce qu'elle expose les failles que les rapports agrégés masquent.

Construire le script d'audit

Assemblez les trois parties en un cycle trimestriel reproductible :

1. Snapshot des accès : extrayez et revoyez le log des accès à privilèges.
2. Contrôle ponctuel de classification : échantillonnez cinq entrepôts de données, vérifiez le tier et le masquage.
3. Traçage tiers : suivez un enregistrement client à travers chaque prestataire qu'il traverse.
4. Log de remédiation : documentez chaque constat et le correctif, avec une date. Les examinateurs valorisent bien davantage le « avez-vous trouvé et corrigé vous-mêmes » qu'un rapport propre à zéro constat, puisque zéro constat issu d'un audit réel est statistiquement invraisemblable.

Pour un modèle public utile de ce que les examinateurs recherchent structurellement, l'OCC publie ses propres sections de manuel sur la gestion du risque tiers, qui valent une lecture rapide pour le vocabulaire réel des checklists : OCC Comptroller's Handbook: Third-Party Relationships.

🎬 [VIDEO: « How Bank Examiners Actually Review Your Data Controls » - youtube.com - cherchez des présentations de formation d'examinateurs FFIEC ou OCC sur les examens IT et data governance, utiles pour voir de première main l'état d'esprit checklist de l'examinateur]

Points clés

• Les régulateurs testent l'exécution, pas la politique : ils veulent voir des logs, des enregistrements échantillonnés et une transaction tracée, pas un PDF de gouvernance.
• Structurez les audits autour de trois piliers : contrôle d'accès (qui peut toucher les données), classification (les données sensibles sont-elles traitées différemment) et partage avec les tiers (où vont les données et sur quelle base légale).
• Une fintech qui fonctionne doit pouvoir produire à bref délai une requête de log d'accès à privilèges sur 30 jours et la trace complète des données d'un client ; si elle ne peut pas, cette faille est le constat.
• Les problèmes identifiés en interne avec une remédiation documentée sont bien mieux perçus par les examinateurs (OCC, FCA, CFPB) que des rapports affichant zéro constat.
• Sachez quelles lois s'appliquent à votre périmètre : GLBA et CFPB 1033 pour le partage de données financières aux États-Unis, GDPR pour les données personnelles UE/Royaume-Uni, plus les lois d'États comme CCPA/CPRA, chacune définissant « données sensibles » et « partage » un peu différemment.