Une demande de stress test du régulateur arrive avant le déjeuner. En milieu d'après-midi, le directeur des risques ne dispose toujours pas d'une vue fiable des expositions par entité juridique, région, produit et classe d'actifs. Une équipe rapproche des tableurs, une autre attend un fichier source en retard, et le tableau de bord sur lequel tout le monde s'appuie repose sur les données de la veille.

Cette situation n'a rien d'exceptionnel, et ce n'est pas faute de données dans les institutions financières. Elles peinent parce que les données ne circulent pas dans l'organisation avec suffisamment de contrôle, de contexte et de rapidité. La gestion des données dans les services financiers est la discipline pratique qui répond à ce problème, depuis la création dans les systèmes cœurs jusqu'à l'agrégation, la validation, le reporting, l'usage par les modèles et les preuves d'audit.

Table des matières

• Quand les données de risque ne circulaient pas assez vite

• Ce que recouvre réellement la gestion des données financières

  • Les quatre piliers du modèle opérationnel

• Transformer BCBS 239 en contrôles techniques

  • Du principe au pipeline

• Les six dimensions de la qualité des données que les banques ne peuvent ignorer

  • Les dimensions en termes opérationnels

  • Contrôles déterministes et détection adaptative

• Lignage, suivi des schémas et ponctualité : un seul système

  • Ce que le plan de contrôle doit capturer

• Moderniser sans tout centraliser

  • Utiliser un plan de contrôle, pas seulement une plateforme cible

• La qualité des données comme contrôle d'exécution pour l'IA et les modèles

• Un modèle opérationnel en 90 jours pour la gestion des données financières

Quand les données de risque ne circulaient pas assez vite

Le problème est devenu impossible à ignorer lors de la crise financière mondiale de 2007-2009. Les superviseurs ont constaté que de nombreuses grandes banques ne parvenaient pas à agréger rapidement leurs expositions par ligne métier, entité juridique, région et produit, en particulier en période de tension. Une banque pouvait détenir les enregistrements pertinents sans que ses systèmes soient capables de produire une vue fiable à l'échelle du groupe au moment où les décideurs en avaient besoin.

Une demande de stress test révèle vite la faiblesse. L'équipe risques demande l'exposition par contrepartie sur l'ensemble des filiales. La première extraction arrive avec des identifiants d'entité manquants. Une deuxième source utilise une autre taxonomie de produits. La trésorerie dispose d'un solde plus récent, mais la finance détient le chiffre de reporting approuvé. Les opérations savent qu'un flux est arrivé en retard, et pourtant le tableau de bord présente le résultat comme complet.

Règle pratique : si un rapport de risque dépend d'un rapprochement manuel en pleine crise, l'institution n'a pas de processus de reporting. Elle a une dépendance opérationnelle non maîtrisée.

Le Comité de Bâle a réagi en publiant en janvier 2013 les « Principes aux fins de l'agrégation des données sur les risques et de la notification des risques ». Le cadre comprend 14 principes, dont 11 s'appliquent directement aux banques et trois portent sur la revue prudentielle, les outils et la coopération. Ses attentes vont au-delà de la technologie de reporting. Les banques ont besoin d'une gouvernance, d'une architecture adaptée, de données fiables et complètes, d'une agrégation dans les délais, d'une capacité d'adaptation aux demandes ponctuelles et d'un reporting clair. Ce dispositif doit fonctionner en conditions normales comme en période de crise, l'agrégation étant en grande partie automatisée afin de limiter les erreurs. Le cadre de Bâle reste une référence fondamentale pour les données bancaires et la gestion des risques.

La leçon est opérationnelle. La qualité des données, le lignage, le rapprochement, la ponctualité et la cohérence structurelle ne sont pas des améliorations distinctes qui peuvent attendre une future migration de plateforme. Elles déterminent si la direction peut identifier les concentrations, expliquer les variations, répondre aux superviseurs et agir avant qu'un risque ne se transforme en perte. Les équipes qui souhaitent une vue concrète des conséquences peuvent aussi consulter comment une mauvaise qualité des données génère des coûts pour les institutions financières.

Le reste de la discipline découle de ce constat. La gouvernance définit les responsabilités, l'architecture fait circuler les données et préserve leur contexte, la qualité vérifie leur adéquation à l'usage, et le reporting prouve que le résultat est digne de confiance.

Ce que recouvre réellement la gestion des données financières

La gestion des données dans les services financiers est la discipline de bout en bout qui consiste à gouverner, déplacer, valider, stocker, rendre accessibles et restituer les données dans toute une institution. Elle commence lorsqu'un client, un paiement, une transaction de marché, un prêt ou un événement de marché entre dans un système source. Elle se poursuit à travers les entrepôts, les lacs de données, les moteurs réglementaires, les calculs de risque, les rapports de gestion, les modèles et les preuves conservées.

L'instrumentation offre une analogie utile. Les produits et processus de la banque sont le moteur, tandis que la gestion des données fournit les jauges, les capteurs, les alertes et le carnet d'entretien. L'instrumentation ne crée pas l'activité, mais sans elle, le conducteur ne peut pas savoir si le moteur tourne normalement ou s'il approche de la panne.

Les quatre piliers du modèle opérationnel

• Gouvernance : attribue aux données critiques des propriétaires responsables, des stewards, des définitions, des seuils, des circuits d'escalade et des usages autorisés.

• Architecture : relie le core banking, les paiements, les activités de marché, la finance, les risques, les entrepôts, les lacs de données et les services de reporting sans perte de sens ni de contrôle.

• Qualité des données : vérifie si les enregistrements sont complets, exacts, ponctuels, valides, uniques et cohérents pour un cas d'usage défini.

• Reporting : fournit des informations claires, exhaustives et rapprochées, à la fréquence requise par le conseil d'administration, la direction, les régulateurs et les équipes opérationnelles.

Ces piliers dépendent les uns des autres. Une règle de qualité sans propriétaire n'a pas de circuit de réponse durable. Un rapport sans lignage ne peut pas expliquer l'origine d'un chiffre. Un référentiel centralisé sans validation ne fait que concentrer des enregistrements peu fiables. Une politique de gouvernance sans contrôles lisibles par les machines reste difficile à tester et facile à interpréter différemment d'un département à l'autre.

Partez du cas d'usage, pas du référentiel. Un rapport de liquidité, un calcul d'exposition de crédit, une décision sur le risque client et une déclaration réglementaire peuvent utiliser des données qui se recoupent, mais chacun a ses propres exigences de fraîcheur, de complétude et de rapprochement. L'architecture doit préserver ces distinctions tout en offrant aux équipes des définitions partagées et des preuves de contrôle visibles.

Transformer BCBS 239 en contrôles techniques

BCBS 239 est souvent cité en comité de pilotage comme une exigence de gouvernance, puis mis en œuvre comme un projet de reporting de plus. Cette approche passe à côté de son intention opérationnelle. Les principes destinés aux banques fixent des attentes sur la manière dont une institution identifie les données significatives, les agrège à l'échelle du groupe, valide le résultat et fournit une information qui reste utile en conditions normales comme en période de tension.

Le Comité de Bâle a organisé les 11 principes destinés aux banques en trois domaines opérationnels : la gouvernance et l'infrastructure globales, les capacités d'agrégation des données de risque et les pratiques de notification des risques. Les équipes d'ingénierie peuvent traduire ces domaines en contrôles qui produisent des preuves plutôt que des déclarations de principe. La publication originale de BCBS 239 constitue la référence de ce cadre.

Du principe au pipeline

La gouvernance devient des métadonnées que les systèmes peuvent faire appliquer. Pour chaque jeu de données critique, consignez qui est responsable de sa signification métier, qui opère le contrôle, ce qui constitue un échec et qui doit agir. La propriété doit suivre les données à travers les couches source, transformation, agrégation et reporting, et non s'arrêter à la frontière de l'application.

La capacité d'agrégation exige plus qu'un traitement terminé avec succès. Comparez les totaux source et cible, rapprochez les soldes entre systèmes, vérifiez les dimensions obligatoires comme l'entité juridique et la ligne métier, et conservez le résultat pour chaque cycle de reporting. Un pipeline qui s'achève sans erreur peut tout de même omettre une partition, dupliquer des enregistrements ou appliquer un mauvais mapping de référence.

Les contrôles de reporting doivent tester le résultat comme un produit d'aide à la décision. Un dirigeant peut-il comprendre l'exposition ? Un analyste peut-il descendre jusqu'à l'entité ou au type d'actif concerné ? La banque peut-elle produire une réponse utile à une demande ponctuelle sans reconstruire le rapport manuellement ?

L'alignement sur BCBS 239 reste un défi technique considérable. L'évaluation 2023 du Comité de Bâle portait sur 31 G-SIB et a montré que les banques se situaient toujours à des stades d'alignement différents, près de dix ans après la publication des principes et sept ans après la date de conformité attendue. La conséquence pratique est directe : une plateforme de risque doit être un pipeline contrôlé et reproductible pour l'agrégation, le rapprochement, le lignage et la livraison, et non un simple référentiel de reporting passif. L'évaluation de Bâle fournit le contexte prudentiel. Les équipes qui comparent les options de mise en œuvre peuvent aussi étudier une approche fondée sur l'IA pour respecter les principes BCBS 239.

Les six dimensions de la qualité des données que les banques ne peuvent ignorer

Un jeu de données n'est pas « de haute qualité » dans l'absolu. Il est adapté, ou non, à une décision, un rapport, un modèle ou un contrôle précis. Un portefeuille de prêts peut être complet mais obsolète. Un flux clients peut être à jour mais inexact. Une extraction réglementaire peut passer les contrôles de format tout en traitant les devises de manière incohérente d'une entité à l'autre.

Les dimensions en termes opérationnels

• La complétude vérifie que les enregistrements et champs requis sont présents. Des attributs d'identification client manquants dans un flux KYC, ou un code d'entité juridique absent dans une extraction de prêts, peuvent rendre inutilisable un jeu de données par ailleurs bien rempli.

• L'exactitude vérifie que la valeur reflète la situation réelle. Un encours de prêt qui ne correspond pas à l'enregistrement de gestion faisant foi doit déclencher une investigation avant d'atteindre un rapport de fonds propres ou de gestion.

• La ponctualité vérifie que l'information arrive à temps pour éclairer la décision. Un fichier de transactions de marché en retard peut être techniquement valide mais opérationnellement faux pour une vue des risques intrajournalière.

• La validité vérifie que les valeurs respectent les règles métier et structurelles définies. Les dates, identifiants de compte, devises, classifications et codes produits doivent suivre des formats acceptés et des valeurs autorisées.

• L'unicité empêche qu'un même client, une même contrepartie, un même compte ou une même transaction apparaisse plusieurs fois là où un seul enregistrement est attendu. Des contreparties en double peuvent fausser l'agrégation des expositions et les vues de relation.

• La cohérence vérifie qu'un même fait concorde d'un système à l'autre. Un solde, une normalisation de devise, une hiérarchie d'entités ou une classification de risque ne doit pas changer sans avertissement entre la plateforme cœur et l'entrepôt de données.

Ces dimensions fonctionnent ensemble, mais elles ne doivent pas être réduites à un score unique. Un score composite peut masquer une défaillance significative. Indiquez plutôt la dimension en échec, l'élément de données concerné, l'impact métier, le propriétaire et l'état de la remédiation. Un comité des risques doit savoir qu'un flux est en retard ou qu'un rapprochement de solde a échoué, et pas seulement qu'un score de qualité a baissé.

Contrôles déterministes et détection adaptative

La validation déterministe est la plus efficace lorsque la règle est explicite. Vérifiez que chaque prêt est rattaché à une entité juridique, que chaque transaction de marché référence un instrument connu, que chaque compte utilise une devise acceptée et que les totaux source-cible concordent. Ces contrôles sont explicables et faciles à rattacher aux preuves d'audit.

La détection d'anomalies apporte une capacité différente. Elle peut repérer une variation de volume inhabituelle, un changement de distribution ou un mouvement de solde par rapport au comportement normal d'un jeu de données donné. Elle ne doit pas remplacer les règles métier. Elle doit aider à déterminer si un mouvement correspond à un véritable événement de portefeuille, à un chargement source partiel ou à une transformation défaillante.

Pour une présentation pratique des dimensions et de leur application, consultez les six dimensions de la qualité des données. Le changement opérationnel essentiel consiste à surveiller la qualité en continu. Profiler une table lors d'un projet de remédiation vous dit ce qui s'est passé à ce moment-là. Les contrôles en continu vous disent si le jeu de données peut encore être utilisé en toute sécurité aujourd'hui.

Lignage, suivi des schémas et ponctualité : un seul système

Le lignage est souvent traité comme un exercice de cartographie. La ponctualité est déléguée aux opérations. Le suivi des schémas est ajouté après qu'un traitement en aval a échoué. Dans les services financiers, ces trois contrôles vont de pair, car un changement structurel ou un retard de livraison peut modifier le sens d'un rapport même lorsque chaque traitement planifié signale un succès.

Prenons un système source qui transforme un champ numérique d'exposition en chaîne de caractères. Le processus d'ingestion accepte le nouveau type, une transformation convertit certaines valeurs, et le traitement de reporting se termine. L'exposition obtenue peut contenir des valeurs nulles, des valeurs tronquées ou des jointures en échec. Sans suivi des schémas, l'organisation ne découvre le défaut que lorsque quelqu'un remet le chiffre en question.

Une partition perdue pose un problème similaire. Le pipeline s'exécute, mais une région ou une entité juridique manque. Un flux de marché ou de transactions en retard peut être tout aussi dommageable lorsqu'un rapport reprend la dernière valeur valide et la présente comme actuelle.

Ce que le plan de contrôle doit capturer

Le lignage de bout en bout doit identifier la table source, le champ, la transformation, les données de référence, le jeu de données de destination, le rapport et le modèle qui dépendent d'un élément critique. Il doit aussi intégrer l'historique des versions, la propriété, la dernière livraison réussie et les résultats de contrôle associés à chaque exécution.

Le suivi des schémas doit détecter :

• Les colonnes ajoutées ou supprimées : un nouveau champ peut être anodin, alors qu'un identifiant supprimé peut casser des jointures ou une classification réglementaire.

• Les modifications de type de données : un montant, une date ou une clé dont le type change peut modifier les calculs sans arrêter le pipeline.

• Les changements de définition : un champ peut conserver son nom alors que sa signification métier ou sa logique d'alimentation change.

• La dérive structurelle en aval : un entrepôt ou une couche de reporting peut s'écarter du contrat approuvé même lorsque la source reste stable.

La surveillance de la ponctualité doit apprendre le comportement de livraison attendu plutôt qu'appliquer un calendrier fixe unique à chaque flux. Les sources de marché, transactionnelles et batch fonctionnent différemment. Un flux qui arrive habituellement tôt peut être anormal s'il manque sa fenêtre attendue, tandis qu'une horloge rigide peut générer du bruit pour une source dont les variations sont légitimes.

L'évaluation 2023 du Comité de Bâle portait sur 31 G-SIB et a constaté que les institutions se trouvaient à des stades différents d'alignement sur BCBS 239, ce qui renforce le besoin de pipelines contrôlés capables d'assurer l'agrégation, le rapprochement, le lignage et la livraison en conditions normales comme en période de tension. Le détail de l'évaluation rend la conséquence technique évidente.

Il est utile de distinguer provenance et lignage. La provenance indique ce qui est arrivé aux données et dans le cadre de quel processus. Le lignage cartographie la manière dont un champ circule à travers les systèmes et les dépendances. Les équipes qui comparent ces notions peuvent consulter ce guide sur la provenance et le lignage des données. Aucune des deux ne suffit seule. Un lignage sans contrôles de structure et de fraîcheur n'est qu'un plan de contrôle partiel.

Moderniser sans tout centraliser

Une banque peut centraliser ses données de reporting et échouer malgré tout à une revue BCBS 239. La copie centrale peut être incomplète, en retard ou déconnectée du système qui porte le processus métier. La centralisation change l'endroit où se trouvent les données. Elle n'établit pas, à elle seule, la propriété, la validation, la ponctualité ou les preuves.

Copier des données de production sensibles dans une nouvelle plateforme a aussi un coût. La banque doit sécuriser, classifier, rapprocher, gouverner et justifier un référentiel supplémentaire. Un stockage central peut simplifier l'accès pour certains utilisateurs tout en augmentant la duplication, l'exposition en matière de confidentialité, la latence et le travail d'intégration.

La réalité opérationnelle est distribuée. Les données clients peuvent rester dans les systèmes cœurs, les transactions dans les entrepôts, les données de marché dans des plateformes spécialisées, et des copies propres à chaque juridiction sous des contrôles distincts. La vraie question est de savoir si la banque peut prouver que ses données critiques sont adaptées à l'usage, où qu'elles se trouvent.

Utiliser un plan de contrôle, pas seulement une plateforme cible

Un plan de contrôle distribué exécute les contrôles au plus près des systèmes sources ou directement dans la base de données du client, puis centralise les métadonnées et les preuves plutôt que les enregistrements sensibles. Ses contrôles opérationnels doivent inclure :

• Validation sur place : appliquer les règles métier aux tables sources sans créer une nouvelle copie de production.

• Propriété : attribuer chaque jeu de données critique, règle, exception et action de remédiation à une équipe responsable.

• Surveillance structurelle : détecter les changements de schéma à la source et identifier les consommateurs concernés grâce au lignage.

• Contrôles de fraîcheur : comparer la livraison effective au comportement attendu de chaque flux.

• Conservation des preuves : conserver les résultats des règles, les exceptions, les approbations, les escalades et l'historique des remédiations.

• Priorisation selon le risque : commencer par les jeux de données qui alimentent le reporting sur les fonds propres, la liquidité, le crédit, la finance et la réglementation.

Cette conception transforme les attentes prudentielles issues de BCBS 239, des revues de la BCE et de SR 11-7 en preuves opérationnelles. Les équipes peuvent montrer qui est propriétaire d'un contrôle, quelle validation a été exécutée, si un flux est arrivé dans sa fenêtre attendue, quel schéma a changé et comment les exceptions ont été résolues.

Le compromis reste réel. Les contrôles sur place exigent des métadonnées, des connecteurs et une discipline de propriété plus solides. Les plateformes centralisées peuvent simplifier l'analyse, mais une copie centrale peut masquer des défauts à la source ou devenir la référence sans preuve qu'elle reste synchronisée. Les banques qui hésitent entre ces approches peuvent consulter cette comparaison entre data mesh et plateformes de données centralisées. Le choix doit dépendre de la couverture des contrôles, de la sensibilité des données, des performances, de la juridiction et des contraintes liées à l'existant, et non d'une préférence pour une architecture.

La qualité des données comme contrôle d'exécution pour l'IA et les modèles

Dans les services financiers, la préparation à l'IA est avant tout un problème de comportement des données, et non de choix du modèle. Un modèle validé peut se comporter de manière risquée lorsque son flux d'entrée arrive en retard, change de schéma, perd une classe, développe une nouvelle distribution ou s'écarte de la référence utilisée lors de la validation.

Une enquête IIF-EY de 2025 a montré que 79 % des établissements de services financiers, et 100 % des G-SIB et des assureurs d'importance systémique mondiale, considèrent la qualité des données comme l'un des principaux défis du développement de l'IA. Parmi ces établissements, 96 % ont cité des données bruitées, tardives, inexactes ou peu adaptables comme principal obstacle à la mise en production. L'enquête IIF-EY fournit les éléments qui étayent cette préoccupation opérationnelle.

SR 11-7 ajoute une perspective de gouvernance du risque de modèle. Les banques ont besoin de contrôles documentés couvrant le développement, la mise en œuvre, la validation, le suivi continu et la gouvernance des modèles. Avec la lettre de supervision SR 11-7 de la Réserve fédérale, une anomalie de données peut devenir un événement de risque de modèle lorsqu'elle modifie une entrée sans explication approuvée.

Conservez des preuves pour la période qui suit la validation, et pas seulement le dossier de validation lui-même :

• Évolution de la référence : ce qui a changé, à quel moment, et si ce mouvement était attendu.

• Comportement du flux : si le jeu de données est arrivé en retard, partiellement ou avec des partitions manquantes.

• État du schéma : quels champs, types ou définitions ont changé.

• Comportement des distributions : si les distributions de classes ou de valeurs ont dépassé le seuil accepté.

• Registre des décisions : qui a évalué l'incident et si la réponse a été de poursuivre, de revenir en arrière ou de revalider.

Les équipes qui étudient des solutions d'IA pour la finance doivent intégrer cette boucle de preuves à la mise en œuvre, et non la considérer comme un ajout ultérieur de gouvernance. Le propriétaire d'un modèle a besoin de seuils propres à chaque jeu de données et de déclencheurs explicites pour l'investigation, le retour arrière ou la revalidation.

L'enquête IIF-EY de 2025 indique aussi que 72 % des établissements disposaient de mécanismes de retour ou de contrôles pour corriger les modèles d'IA, et que 25 % supplémentaires y travaillaient. Cette tendance confirme le constat : la gouvernance des modèles devient corrective et opérationnelle. La data observability doit être directement reliée à cette boucle.

Un modèle opérationnel en 90 jours pour la gestion des données financières

Commencez par les données qui peuvent modifier une décision de risque, une déclaration réglementaire, un calcul de fonds propres ou une entrée de modèle. Définissez les éléments de données critiques par domaine de risque, entité juridique, ligne métier, classe d'actifs, zone géographique et cas d'usage de reporting.

Désignez un propriétaire responsable et un steward sous forme de métadonnées lisibles par les machines. Associez à chaque élément des contrôles de complétude, de ponctualité, de rapprochement, d'intégrité référentielle, de doublons et de schéma. Exécutez les contrôles au plus près de la source lorsque c'est possible, conservez les preuves pour chaque cycle de reporting et acheminez les exceptions vers des personnes nommément désignées.

Utilisez la validation déterministe pour les règles connues et la détection d'anomalies fondée sur une référence pour les comportements inattendus. Testez le modèle opérationnel en conditions de livraison normales et dans un scénario de tension avant d'étendre la couverture. Un petit ensemble de jeux de données contrôlés et documentés est plus défendable qu'un vaste catalogue sans circuit de réponse fiable.

digna apporte la qualité et l'observabilité des données directement dans votre environnement aux équipes des services financiers, avec la validation dans la base de données, la surveillance de la ponctualité, la détection d'anomalies, le suivi des schémas et des preuves pour les pipelines de données distribués. Rendez-vous sur digna pour découvrir comment son approche de plan de contrôle peut vous aider à surveiller vos données critiques sans partir du principe que la centralisation est la solution.

Les contreparties en double et les prêts sans entité juridique valide sont, au fond, des relations rompues entre systèmes. Pour les contrôles qui maintiennent ces clés alignées du core banking jusqu'à l'entrepôt de données de risque, consultez l'intégrité référentielle des données bancaires.

Questions fréquentes

Que recouvre la gestion des données dans les services financiers ?

Elle recouvre la gouvernance, le déplacement, la validation, le stockage et le reporting des données, depuis l'entrée d'un paiement, d'une transaction, d'un prêt ou d'un événement client dans un système source jusqu'aux calculs de risque, aux rapports réglementaires et aux modèles. Gouvernance, architecture, qualité des données et reporting forment quatre piliers qui ne fonctionnent que s'ils s'appuient les uns sur les autres.

Comment transformer BCBS 239 en contrôles techniques ?

Traduisez chaque domaine de principes en contrôles qui produisent des preuves : un registre des éléments de données critiques avec propriétaires et seuils pour la gouvernance, des rapprochements source-cible et une surveillance de la fraîcheur pour l'agrégation, ainsi qu'une validation et une certification au niveau des rapports pour le reporting. Conservez les résultats des règles, les instantanés de lignage et les registres d'incidents pour chaque cycle de reporting.

Quelles dimensions de la qualité des données comptent le plus pour les banques ?

La complétude, l'exactitude, la ponctualité, la validité, l'unicité et la cohérence. Chacune répond à une question différente, par exemple si un prêt porte bien son code d'entité juridique ou si un solde concorde entre la plateforme cœur et l'entrepôt de données. Indiquez séparément la dimension en échec, le propriétaire et l'impact plutôt que de les fondre dans un score composite qui peut masquer une défaillance significative.

Les banques doivent-elles centraliser toutes leurs données pour respecter BCBS 239 ?

Non. Une copie centrale peut tout de même être incomplète, en retard ou déconnectée du système qui porte le processus. Un plan de contrôle distribué exécute les contrôles sur place, au plus près des systèmes sources, et ne centralise que les métadonnées et les preuves. Cela évite des copies supplémentaires de données sensibles tout en prouvant que les données critiques sont adaptées à l'usage.

Pourquoi la qualité des données est-elle un contrôle d'exécution pour les modèles d'IA en finance ?

Un modèle validé peut se comporter de manière risquée lorsque ses données d'entrée arrivent en retard, changent de schéma ou s'écartent de leur référence. Dans une enquête IIF-EY de 2025, 79 % des établissements de services financiers ont cité la qualité des données parmi les principaux défis de l'IA. Selon SR 11-7, une modification inexpliquée des entrées peut devenir un événement de risque de modèle nécessitant une investigation ou une revalidation.