Une écriture arrive dans l'entrepôt de données avec un account_id qui n'existe pas dans la table des comptes. Une autorisation de carte pointe vers un commerçant qui n'a jamais été chargé. Un paiement indique un identifiant de contrepartie que le système de risques n'a jamais vu. Rien ne plante. Les lignes sortent simplement de chaque jointure interne, et les totaux en aval deviennent faux sans bruit. L'intégrité référentielle des données bancaires signifie que chaque référence (le compte d'une écriture, la contrepartie d'un paiement, le client d'un prêt) pointe vers un enregistrement qui existe réellement dans la table de référence qu'elle désigne.

Les systèmes de core banking appliquent généralement leurs propres clés. Les difficultés commencent dès que les données en sortent : l'entrepôt, le moteur de risques, la plateforme LCB-FT (AML) et la couche de reporting reçoivent chacun leur propre copie, selon leur propre calendrier, souvent avec un format de clé différent. C'est là qu'apparaissent les orphelins, et là que se joue réellement la qualité des données bancaires.

Ci-dessous : les références qui comptent dans une banque, ce qui casse lorsqu'elles ne tiennent pas, pourquoi les orphelins réapparaissent sans cesse, et comment vérifier chacune d'elles avec digna sans copier de données hors de vos systèmes.

Points clés

• Un orphelin dans les données bancaires n'est pas un message d'erreur. C'est une écriture, un paiement ou une exposition qui sort silencieusement d'une jointure.

• Vérifiez les jointures dont dépendent les rapports : écritures, autorisations, paiements, prêts, cours de change et alertes AML par rapport à leurs référentiels.

• La plupart des orphelins viennent du calendrier et de la traduction des clés : données de référence en retard, migrations, lancements de produits et formats de clé différents.

• Dans digna Data Validation, chaque relation correspond à une règle Referential Integrity, avec un seuil à zéro pour les données réglementaires et des seuils relatifs uniquement pour les flux bruités.

• Depuis la Release 2026.01, une règle peut comparer une table du système central avec une table de l'entrepôt, et les enregistrements en échec peuvent être exportés comme éléments probants.

Table des matières

• Points clés

• Quelles références comptent le plus dans les données bancaires ?

  • Clés composites

  • Références entre systèmes

• Que se passe-t-il lorsqu'une référence bancaire se rompt ?

• Pourquoi des enregistrements orphelins apparaissent-ils dans les systèmes bancaires ?

• Comment trouver les écritures orphelines en SQL ?

• Comment configurer un contrôle d'intégrité référentielle dans digna ?

• Quel seuil appliquer aux données réglementaires ?

• Comment vérifier le core banking par rapport à l'entrepôt de données ?

• Comment les enregistrements en échec deviennent-ils des éléments probants pour l'audit ?

• Commencez par les clés dont dépendent vos rapports

Quelles références comptent le plus dans les données bancaires ?

Les références qui comptent le plus dans les données bancaires sont celles par lesquelles passent chaque rapport et chaque indicateur de risque : écritures vers comptes, autorisations de carte vers cartes et commerçants, paiements vers contreparties, prêts vers clients et garanties, cours de change vers codes devises, et alertes AML vers comptes et clients. Si l'une d'elles ne se joint pas, l'enregistrement disparaît du résultat.

Pour la définition générale, consultez l'article de référence Vos données retrouvent-elles encore leurs parents ? Comprendre l'intégrité référentielle. Dans une banque, la liste est assez stable :

• Écritures → comptes. Les soldes, les intérêts et les frais sont tous calculés via cette jointure.

• Autorisations de carte → cartes et commerçants. La carte mène au compte et au client ; le commerçant porte le code de catégorie.

• Paiements → contreparties. La fiche de la contrepartie sert au filtrage, aux statistiques et au calcul de l'exposition.

• Prêts → clients et garanties. L'emprunteur et la garantie alimentent tous deux le risque et le provisionnement.

• Cours de change → codes devises. Les cours et les montants en devises référencent une table des devises, généralement indexée par les codes ISO 4217.

• Alertes AML → comptes et clients. Sans eux, personne ne peut traiter l'alerte.

Clés composites

De nombreuses clés bancaires ne tiennent pas en une seule colonne. Un compte multidevise est souvent identifié par compte + devise ; un prêt syndiqué ou décaissé par tranches par contrat + tranche. Vérifier uniquement account_id validerait une écriture en EUR sur un compte qui n'existe qu'en USD. Le contrôle doit porter sur la combinaison, dans le même ordre de colonnes des deux côtés.

Références entre systèmes

Les références les plus fragiles franchissent les frontières entre systèmes. Le référentiel clients réside dans le système de core banking, les transactions dans l'entrepôt de données bancaire, les expositions dans un système de risques doté de sa propre table de contreparties. Chaque copie est cohérente avec elle-même. La question est de savoir si elles concordent.

Que se passe-t-il lorsqu'une référence bancaire se rompt ?

Lorsqu'une référence bancaire se rompt, l'enregistrement enfant n'échoue pas bruyamment. Il sort des jointures, si bien que les soldes, les expositions, les populations des rapports et les files d'alertes sont calculés sur moins d'enregistrements qu'il n'en existe. La conséquence dépend de la relation rompue, et le tableau ci-dessous l'énonce clairement pour les cas courants.

Aucun de ces cas ne produit d'erreur dans le journal ETL. Le job a réussi ; la jointure était simplement plus petite.

Pourquoi des enregistrements orphelins apparaissent-ils dans les systèmes bancaires ?

Des enregistrements orphelins apparaissent dans les systèmes bancaires principalement parce que les données de référence et les transactions arrivent selon des calendriers différents et via des traductions différentes. Une transaction peut atteindre l'entrepôt avant son compte, une migration peut réécrire un côté d'une clé, et deux systèmes peuvent formater le même identifiant différemment. Chaque cause est banale ; ensemble, elles rendent les orphelins routiniers.

• Données de référence arrivant en retard. Les transactions se chargent en intrajournalier, le référentiel des comptes une fois par nuit. Un client entré en relation à 10:00 et qui effectue une transaction à 10:05 est orphelin jusqu'au prochain chargement du référentiel.

• Fusions et migrations. Lorsqu'un portefeuille est transféré depuis une banque rachetée ou un ancien système central, les numéros de clients et de contrats sont réaffectés. Les lignes qui échappent à la table de correspondance conservent les anciennes clés.

• Lancements de produits. Un nouveau produit de carte, un type de compte ou une devise est mis en production dans le système central avant que les tables de référence de l'entrepôt n'en aient connaissance.

• Différences de format de clé. Un système complète les numéros de compte avec des zéros non significatifs, un autre les stocke en entiers ; l'un utilise l'IBAN, l'autre un identifiant interne ; l'un stocke les identifiants de contrepartie en majuscules. Les valeurs signifient la même chose et pourtant ne se joignent pas.

• Des contraintes non appliquées. La base centrale peut appliquer ses clés étrangères, mais les plateformes d'entrepôt traitent souvent les clés déclarées comme purement informatives. Snowflake, par exemple, documente les clés étrangères sur les tables standard comme non appliquées. Rien n'empêche un orphelin de se charger.

Les superviseurs attendent des banques qu'elles agrègent les données de risque de manière complète et exacte, comme le prévoient les principes BCBS 239 du Comité de Bâle, et les expositions orphelines vont directement à l'encontre de cette exigence. Pour le volet organisationnel plus large, consultez la gestion des données dans les banques.

Comment trouver les écritures orphelines en SQL ?

Vous trouvez les écritures orphelines avec une anti-jointure : sélectionnez les écritures dont l'account_id n'est pas nul et n'a aucune ligne correspondante dans accounts. Comparer à l'ensemble distinct des identifiants de compte garantit un résultat correct même si la table des comptes contient des doublons, et exclure les valeurs nulles sépare les références manquantes des références erronées.

-- Postings whose account does not exist in the account master
SELECT p.*
FROM postings p
LEFT JOIN (SELECT DISTINCT account_id FROM accounts) a
  ON p.account_id = a.account_id
WHERE p.account_id IS NOT NULL
  AND a.account_id IS NULL

-- Postings whose account does not exist in the account master
SELECT p.*
FROM postings p
LEFT JOIN (SELECT DISTINCT account_id FROM accounts) a
  ON p.account_id = a.account_id
WHERE p.account_id IS NOT NULL
  AND a.account_id IS NULL

-- Postings whose account does not exist in the account master
SELECT p.*
FROM postings p
LEFT JOIN (SELECT DISTINCT account_id FROM accounts) a
  ON p.account_id = a.account_id
WHERE p.account_id IS NOT NULL
  AND a.account_id IS NULL

Pour une clé composite comme compte + devise, la jointure porte simplement les deux colonnes :

SELECT p.*
FROM postings p
LEFT JOIN (SELECT DISTINCT account_id, currency FROM accounts) a
  ON p.account_id = a.account_id
 AND p.currency   = a.currency
WHERE p.account_id IS NOT NULL
  AND p.currency   IS NOT NULL
  AND a.account_id IS NULL

SELECT p.*
FROM postings p
LEFT JOIN (SELECT DISTINCT account_id, currency FROM accounts) a
  ON p.account_id = a.account_id
 AND p.currency   = a.currency
WHERE p.account_id IS NOT NULL
  AND p.currency   IS NOT NULL
  AND a.account_id IS NULL

SELECT p.*
FROM postings p
LEFT JOIN (SELECT DISTINCT account_id, currency FROM accounts) a
  ON p.account_id = a.account_id
 AND p.currency   = a.currency
WHERE p.account_id IS NOT NULL
  AND p.currency   IS NOT NULL
  AND a.account_id IS NULL

Cela fonctionne pour une relation dans une base de données. Une banque compte des dizaines de relations réparties sur plusieurs bases et a besoin du résultat chaque jour. La maintenance manuelle de ces requêtes est la partie qui a tendance à être abandonnée.

Comment configurer un contrôle d'intégrité référentielle dans digna ?

Dans digna, vous configurez un contrôle d'intégrité référentielle en ajoutant une règle de type Referential Integrity à la source de données enfant, en choisissant ses colonnes de clé et en désignant la source de données et les colonnes dans lesquelles elles doivent exister. Aucun SQL à écrire. digna génère le contrôle, l'exécute dans votre base de données à chaque inspection et indique le nombre de lignes réussies et en échec.

Pour postings.account_id → accounts.account_id, les étapes dans digna Data Validation sont les suivantes :

1. Allez dans Configuration, sélectionnez la source de données postings, ouvrez l'onglet Data Validation et cliquez sur Add Rule. La boîte de dialogue Add Data Validation Rule s'ouvre.

2. Saisissez un Name (nom) et une Description, par exemple posting_account_exists, « Chaque écriture appartient à un compte du référentiel des comptes ».

3. Réglez Type sur Referential Integrity.

4. Sous Attributes (attributs), choisissez account_id (ajoutez aussi currency pour une clé compte + devise).

5. Sous must exist in (doit exister dans), choisissez la Data Source accounts et ses Attributes account_id, dans le même ordre qu'à gauche.

6. Choisissez le Threshold Mode (mode de seuil) et définissez l'Info threshold et le Warn threshold.

7. Enregistrez. La règle s'exécute à chaque inspection planifiée ou à la demande de postings.

La capture d'écran ci-dessous provient de la démo hospitalière de digna et non d'une banque, mais la boîte de dialogue est identique pour une table bancaire : remplacez product_code et hospital_medications par account_id et accounts.

La boîte de dialogue de la règle Referential Integrity dans digna. Données de démonstration de Danubia Kliniken, un groupe hospitalier autrichien fictif.

digna conserve les valeurs distinctes de la source de données parente et fait échouer toute ligne enfant qui ne se joint pas. Les deux listes de colonnes doivent avoir la même longueur ; une différence est rejetée au lieu de vérifier silencieusement une condition plus faible. Les clés étrangères nulles sont ignorées, de sorte qu'un paiement sans identifiant de contrepartie ne fait pas échouer cette règle. Si la contrepartie est obligatoire, ajoutez une règle distincte de type Rule avec counterparty_id IS NOT NULL. Le pas-à-pas complet se trouve dans l'article Comment configurer un contrôle d'intégrité référentielle ; la documentation digna explique comment la validation est évaluée.

Quel seuil appliquer aux données réglementaires ?

Les données réglementaires doivent appliquer la tolérance zéro : le mode de seuil Absolute, réglé de sorte qu'un seul orphelin fasse échouer le contrôle. Une exposition absente d'un rapport réglementaire est un défaut, quel que soit le nombre de lignes réussies. Les seuils relatifs ne conviennent qu'aux flux bruités, où une faible part connue de références en retard est attendue.

digna évalue deux niveaux. Au-dessus de l'Info threshold, le statut est Uncertain ; au-dessus du Warn threshold, il est Failed ; sinon Passed. Les deux seuils valent zéro par défaut, de sorte qu'une nouvelle règle échoue au premier enregistrement erroné jusqu'à ce que vous en décidiez autrement. La règle de démonstration ci-dessus utilise Absolute, Info 0, Warn 1 : un seul orphelin déclenche déjà un statut Uncertain et deux ou plus font échouer le contrôle ; pour les données réglementaires, laissez Warn à 0 afin qu'un seul orphelin suffise à faire échouer le contrôle.

Si un seuil relatif absorbe des données de référence en retard, revérifiez les mêmes données plus tard, afin que le « retard » ne devienne pas discrètement permanent.

Comment vérifier le core banking par rapport à l'entrepôt de données ?

Vous vérifiez le core banking par rapport à l'entrepôt de données avec une règle d'intégrité référentielle dont les deux sources de données se trouvent sur des connexions de base de données différentes d'un même projet digna. Depuis la Release 2026.01, c'est pris en charge directement : le référentiel des comptes du système central et les écritures de l'entrepôt sont validés sans répliquer l'une ou l'autre table.

Cela détecte les problèmes entre systèmes décrits plus haut : différences de format de clé, numéros clients réaffectés, comptes qui ne sont jamais arrivés dans l'entrepôt. Dans digna, les connexions de base de données sont globales et réutilisables d'un projet à l'autre, et une source de données peut être une table, une vue ou une instruction SQL personnalisée. Une vue ou une source de données SQL est un endroit pratique pour normaliser un format de clé (par exemple, supprimer les zéros non significatifs) avant la comparaison. Les contrôles s'exécutent dans vos bases de données ; vos données ne quittent jamais votre infrastructure. Les détails, y compris les schémas et les vues, se trouvent dans l'article sur l'intégrité référentielle entre bases de données et connexions.

Comment les enregistrements en échec deviennent-ils des éléments probants pour l'audit ?

Les enregistrements en échec deviennent des éléments probants pour l'audit parce que digna renvoie les lignes elles-mêmes, et pas seulement un comptage. La vue Invalid Records liste chaque enregistrement ayant échoué à un contrôle lors d'une inspection donnée, filtré par Passed, Uncertain ou Failed, et la liste peut être exportée pour un auditeur, un propriétaire de données ou un ticket d'incident.

Techniquement, c'est la même requête avec la condition de réussite inversée, exécutée dans la base de données source. Pour une règle portant sur les écritures, vous voyez chaque écriture orpheline avec son identifiant de compte, son montant, sa date de comptabilisation et d'autres colonnes, ce qui suffit généralement à l'équipe responsable pour remonter à la cause. digna peut aussi prévenir l'équipe responsable des données.

Invalid Records d'un contrôle d'intégrité référentielle en échec, issu de la même démo hospitalière ; une table bancaire affiche ses propres colonnes dans la même vue.

Comme les résultats sont conservés par date d'inspection, vous pouvez montrer quand une relation s'est rompue et quand elle a été corrigée. Cet historique des contrôles, des résultats et des lignes en échec est un matériau utile pour expliquer vos contrôles, même s'il ne rend pas à lui seul un processus conforme.

Commencez par les clés dont dépendent vos rapports

Vous n'avez pas besoin de toutes les relations dès le premier jour. Prenez les cinq ou six jointures dont dépendent vos rapports réglementaires et de risques, ajoutez une règle Referential Integrity par relation, appliquez la tolérance zéro là où une ligne manquante est une exposition manquante, et laissez les inspections tourner. Vous verrez vite quels flux produisent des orphelins, et à quel moment. Si vous souhaitez voir cela sur vos propres tables du système central et de l'entrepôt, réservez une démo avec l'équipe digna.

Questions fréquentes

Qu'est-ce que l'intégrité référentielle des données bancaires ?

Cela signifie que chaque référence dans les données d'une banque pointe vers un enregistrement qui existe : chaque écriture vers un compte connu, chaque paiement vers une contrepartie connue, chaque prêt vers un client connu. Lorsqu'une référence se rompt, l'enregistrement sort silencieusement des jointures, si bien que les soldes, les expositions et les rapports sont calculés sur moins de lignes qu'il n'en existe.

Pourquoi des enregistrements orphelins apparaissent-ils dans un entrepôt de données bancaire ?

Surtout parce que les transactions et les données de référence arrivent selon des calendriers différents. Les écritures se chargent en intrajournalier tandis que le référentiel des comptes se charge chaque nuit, les migrations réaffectent les numéros clients, les nouveaux produits sont mis en production avant que les tables de référence ne les connaissent, et les systèmes formatent la même clé différemment, par exemple avec ou sans zéros non significatifs.

Comment trouver en SQL les écritures sans compte correspondant ?

Utilisez une anti-jointure : faites un LEFT JOIN des écritures sur les identifiants de compte distincts de la table des comptes et conservez les lignes où le côté compte est NULL, en excluant les écritures dont l'account_id est lui-même NULL. Pour une clé compte plus devise, joignez sur les deux colonnes dans le même ordre.

Les données de reporting réglementaire peuvent-elles tolérer des enregistrements orphelins ?

Non. Pour les données qui alimentent les rapports réglementaires ou de risques, utilisez un seuil Absolute afin qu'un seul orphelin fasse échouer le contrôle, car chaque ligne manquante est une exposition ou une écriture manquante. Les seuils relatifs ne sont raisonnables que pour les flux bruités, comme les autorisations de carte intrajournalières en attente des données de référence des commerçants.

digna peut-il vérifier les références entre le système de core banking et l'entrepôt ?

Oui. Depuis la Release 2026.01, une règle Referential Integrity de digna peut comparer des sources de données situées sur des connexions de base de données différentes d'un même projet, comme le référentiel des comptes du système central et les écritures de l'entrepôt. Les contrôles s'exécutent dans vos bases de données, et aucune table n'est répliquée.