Un movimento contabile arriva nel data warehouse con un account_id che non esiste nella tabella dei conti. Un'autorizzazione di carta fa riferimento a un esercente che non è mai stato caricato. Un pagamento indica un ID di controparte che il sistema di rischio non ha mai visto. Non si blocca nulla. Le righe semplicemente scompaiono da ogni inner join e i totali a valle risultano silenziosamente errati. L'integrità referenziale nei dati bancari significa che ogni riferimento (il conto di un movimento, la controparte di un pagamento, il cliente di un prestito) punta a un record che esiste davvero nella tabella anagrafica a cui si riferisce.

I sistemi di core banking di solito applicano le proprie chiavi. I problemi iniziano quando i dati ne escono: il data warehouse, il motore di rischio, la piattaforma AML e il livello di reporting ricevono ciascuno la propria copia, con la propria tempistica e spesso con un formato di chiave diverso. È lì che compaiono i record orfani, ed è lì che si decide davvero la qualità dei dati bancari.

Di seguito: i riferimenti che contano in una banca, cosa si rompe quando non reggono, perché i record orfani continuano a comparire e come verificare ciascuno di essi con digna senza copiare i dati fuori dai vostri sistemi.

Punti chiave

• Un record orfano nei dati bancari non è un messaggio di errore. È un movimento, un pagamento o un'esposizione che scompare silenziosamente da un join.

• Verificate i join da cui dipendono i report: movimenti, autorizzazioni, pagamenti, prestiti, tassi di cambio e alert AML rispetto alle rispettive anagrafiche.

• La maggior parte dei record orfani nasce da tempistiche e conversioni: anagrafiche in ritardo, migrazioni, lanci di prodotti e formati di chiave differenti.

• In digna Data Validation ogni relazione corrisponde a una regola Referential Integrity, con soglia zero per i dati regolamentari e soglie relative solo per i feed rumorosi.

• Dalla Release 2026.01 una regola può confrontare una tabella nel sistema core con una nel data warehouse e i record non conformi possono essere esportati come evidenza.

Indice

• Punti chiave

• Quali riferimenti contano di più nei dati bancari?

  • Chiavi composite

  • Riferimenti tra sistemi diversi

• Cosa succede quando un riferimento bancario si rompe?

• Perché compaiono record orfani nei sistemi bancari?

• Come si trovano i movimenti orfani con SQL?

• Come si configura un controllo di integrità referenziale in digna?

• Quale soglia usare per i dati regolamentari?

• Come si confronta il core banking con il data warehouse?

• Come diventano evidenze di audit i record non conformi?

• Iniziate dalle chiavi da cui dipendono i vostri report

Quali riferimenti contano di più nei dati bancari?

I riferimenti che contano di più nei dati bancari sono quelli attraverso cui passano tutti i report e tutti gli indicatori di rischio: movimenti verso conti, autorizzazioni di carte verso carte ed esercenti, pagamenti verso controparti, prestiti verso clienti e garanzie, tassi di cambio verso codici valuta e alert AML verso conti e clienti. Se uno di questi join non riesce, il record scompare dal risultato.

Per la definizione generale, consultate l'articolo di riferimento I vostri dati riescono ancora a trovare i loro genitori? Capire l'integrità referenziale. In una banca, l'elenco è piuttosto stabile:

• Movimenti → conti. Saldi, interessi e commissioni sono tutti calcolati attraverso questo join.

• Autorizzazioni di carte → carte ed esercenti. La carta porta al conto e al cliente; l'esercente porta con sé il codice di categoria.

• Pagamenti → controparti. Il record della controparte viene usato per screening, statistiche ed esposizione.

• Prestiti → clienti e garanzie. Mutuatario e garanzie alimentano entrambi il rischio e gli accantonamenti.

• Tassi di cambio → codici valuta. I tassi e gli importi in valuta estera fanno riferimento a una tabella delle valute, tipicamente con chiave basata sui codici ISO 4217.

• Alert AML → conti e clienti. Senza di essi, nessuno può lavorare l'alert.

Chiavi composite

Molte chiavi bancarie non sono costituite da una sola colonna. Un conto multivaluta è spesso identificato da conto + valuta; un prestito sindacato o erogato in più tranche da contratto + tranche. Verificare solo account_id farebbe passare un movimento in EUR su un conto che esiste solo in USD. Il controllo deve riguardare la combinazione, con lo stesso ordine delle colonne su entrambi i lati.

Riferimenti tra sistemi diversi

I riferimenti più fragili sono quelli che attraversano i confini tra sistemi. L'anagrafica clienti risiede nel sistema di core banking, le transazioni nel data warehouse del core banking, le esposizioni in un sistema di rischio con la propria tabella delle controparti. Ogni copia è coerente con se stessa. La domanda è se siano coerenti tra loro.

Cosa succede quando un riferimento bancario si rompe?

Quando un riferimento bancario si rompe, il record figlio non genera un errore evidente. Scompare dai join, quindi saldi, esposizioni, popolazioni dei report e code di alert vengono calcolati su meno record di quelli esistenti. La conseguenza dipende da quale relazione si è rotta, e la tabella seguente la descrive chiaramente per i casi più comuni.

Nessuno di questi casi produce un errore nel log dell'ETL. Il job è andato a buon fine; il join era solo più piccolo.

Perché compaiono record orfani nei sistemi bancari?

I record orfani compaiono nei sistemi bancari soprattutto perché anagrafiche e transazioni arrivano con tempistiche diverse e attraverso conversioni diverse. Una transazione può raggiungere il data warehouse prima del suo conto, una migrazione può riscrivere un lato di una chiave e due sistemi possono formattare in modo diverso lo stesso identificativo. Ogni causa è ordinaria; insieme rendono i record orfani una routine.

• Anagrafiche che arrivano in ritardo. Le transazioni vengono caricate in giornata, l'anagrafica conti una volta per notte. Un cliente acquisito alle 10:00 che effettua una transazione alle 10:05 resta orfano fino al successivo caricamento dell'anagrafica.

• Fusioni e migrazioni. Quando un portafoglio viene trasferito da una banca acquisita o da un vecchio sistema core, i numeri di cliente e di contratto vengono rimappati. Le righe che sfuggono alla mappatura mantengono le vecchie chiavi.

• Lanci di prodotti. Un nuovo prodotto di carte, tipo di conto o valuta entra in produzione nel sistema core prima che le tabelle di riferimento del data warehouse lo conoscano.

• Differenze nel formato delle chiavi. Un sistema completa i numeri di conto con zeri iniziali, un altro li memorizza come interi; uno usa l'IBAN, un altro un ID interno; uno memorizza gli ID di controparte in maiuscolo. I valori hanno lo stesso significato ma non fanno comunque join.

• Vincoli non applicati. Il database core può applicare le proprie foreign key, ma le piattaforme di data warehouse spesso trattano le chiavi dichiarate come puramente informative. Snowflake, ad esempio, documenta le foreign key sulle tabelle standard come non applicate. Nulla impedisce il caricamento di un record orfano.

Le autorità di vigilanza si aspettano che le banche aggreghino i dati di rischio in modo completo e accurato, come stabilito dai principi BCBS 239 del Comitato di Basilea, e le esposizioni orfane vanno direttamente contro questo obiettivo. Per il lato organizzativo più ampio, consultate la gestione dei dati nelle banche.

Come si trovano i movimenti orfani con SQL?

I movimenti orfani si trovano con un anti-join: selezionate i movimenti il cui account_id non è null e non ha una riga corrispondente in accounts. Il confronto con l'insieme distinto degli ID conto mantiene il risultato corretto anche se la tabella dei conti contiene duplicati, mentre l'esclusione dei null separa i riferimenti mancanti da quelli errati.

Per una chiave composita come conto + valuta, il join include semplicemente entrambe le colonne:

Questo funziona per una relazione in un database. Una banca ha decine di relazioni distribuite su più database e ha bisogno del risultato ogni giorno. Mantenere queste query a mano è la parte che tende a essere trascurata.

Come si configura un controllo di integrità referenziale in digna?

In digna un controllo di integrità referenziale si configura aggiungendo una regola di tipo Referential Integrity alla data source figlia, scegliendone le colonne chiave e indicando la data source e le colonne in cui devono esistere. Non c'è SQL da scrivere. digna genera il controllo, lo esegue all'interno del vostro database a ogni ispezione e riporta il numero di record conformi e non conformi.

Per postings.account_id → accounts.account_id, i passaggi in digna Data Validation sono:

1. Andate su Configuration, selezionate la data source postings, aprite la scheda Data Validation e fate clic su Add Rule. Si apre la finestra di dialogo Add Data Validation Rule.

2. Inserite un Name e una Description, ad esempio posting_account_exists, "Ogni movimento appartiene a un conto presente nell'anagrafica conti".

3. Impostate Type su Referential Integrity.

4. In Attributes, scegliete account_id (aggiungete anche currency per una chiave conto + valuta).

5. In must exist in, scegliete la Data Source accounts e i relativi Attributes account_id, nello stesso ordine del lato sinistro.

6. Scegliete il Threshold Mode e impostate l'Info threshold e il Warn threshold.

7. Salvate. La regola viene eseguita a ogni ispezione pianificata o su richiesta di postings.

Lo screenshot seguente proviene dalla demo ospedaliera di digna e non da una banca, ma la finestra di dialogo è identica per una tabella bancaria: sostituite product_code e hospital_medications con account_id e accounts.

La finestra di dialogo della regola Referential Integrity in digna. Dati demo di Danubia Kliniken, un gruppo ospedaliero austriaco fittizio.

digna conserva i valori distinti della data source padre e segnala come non conforme ogni riga figlia che non fa join. I due elenchi di colonne devono avere la stessa lunghezza; una discrepanza viene rifiutata anziché verificare silenziosamente una condizione più debole. Le foreign key null vengono ignorate, quindi un pagamento senza ID di controparte non fa fallire questa regola. Se la controparte è obbligatoria, aggiungete una regola separata con counterparty_id IS NOT NULL. La procedura completa è descritta in come configurare un controllo di integrità referenziale; la documentazione di digna spiega come viene valutata la validazione.

Quale soglia usare per i dati regolamentari?

I dati regolamentari dovrebbero usare la tolleranza zero: modalità di soglia Absolute, impostata in modo che un solo record orfano faccia fallire il controllo. Un'esposizione mancante da un report regolamentare è un difetto, indipendentemente da quante righe abbiano superato il controllo. Le soglie relative vanno usate solo per i feed rumorosi, in cui è prevista una piccola quota nota di riferimenti in ritardo.

digna valuta due livelli. Sopra l'Info threshold lo stato è Uncertain; sopra il Warn threshold è Failed; altrimenti è Passed. Entrambe le soglie sono impostate a zero per impostazione predefinita, quindi una nuova regola fallisce al primo record errato finché non decidete diversamente. La regola demo sopra usa Absolute, Info 0, Warn 1, quindi un solo record orfano genera già uno stato Uncertain e due o più fanno fallire il controllo; per i dati regolamentari, lasciate Warn a 0 in modo che un solo record orfano provochi il fallimento.

Se una soglia relativa assorbe anagrafiche in ritardo, ricontrollate gli stessi dati in un secondo momento, in modo che il “ritardo” non diventi silenziosamente permanente.

Come si confronta il core banking con il data warehouse?

Il core banking si confronta con il data warehouse tramite una regola di integrità referenziale le cui due data source si trovano su connessioni di database diverse all'interno dello stesso progetto digna. Dalla Release 2026.01 questo è supportato direttamente, quindi l'anagrafica conti nel sistema core e i movimenti nel data warehouse vengono convalidati senza replicare nessuna delle due tabelle.

In questo modo si intercettano i problemi tra sistemi descritti sopra: differenze nel formato delle chiavi, numeri cliente rimappati, conti che non hanno mai raggiunto il data warehouse. In digna le connessioni ai database sono globali e riutilizzabili tra progetti, e una data source può essere una tabella, una vista o un'istruzione SQL personalizzata. Una vista o una data source SQL è un punto pratico in cui normalizzare il formato di una chiave (ad esempio rimuovendo gli zeri iniziali) prima del confronto. I controlli vengono eseguiti all'interno dei vostri database; i vostri dati non lasciano mai la vostra infrastruttura. I dettagli, inclusi schemi e viste, sono descritti in integrità referenziale tra database e connessioni.

Come diventano evidenze di audit i record non conformi?

I record non conformi diventano evidenze di audit perché digna restituisce le righe stesse, non solo un conteggio. La vista Invalid Records elenca ogni record che non ha superato un controllo in una determinata ispezione, filtrabile per Passed, Uncertain o Failed, e l'elenco può essere esportato per un auditor, un data owner o un ticket di incidente.

Tecnicamente si tratta della stessa query con la condizione di superamento negata, eseguita all'interno del database sorgente. Per una regola sui movimenti vedete ogni movimento orfano con il suo ID conto, importo, data di registrazione e altre colonne, in genere sufficienti perché il team responsabile possa risalire alla causa. digna può anche inviare una notifica al team che gestisce i dati.

Invalid Records per un controllo di integrità referenziale fallito, dalla stessa demo ospedaliera; una tabella bancaria mostra le proprie colonne nella stessa vista.

Poiché i risultati vengono conservati per data di ispezione, potete mostrare quando una relazione si è rotta e quando è stata corretta. Questo registro di controlli, risultati e righe non conformi è materiale utile quando spiegate i vostri controlli, anche se da solo non rende conforme un processo.

Iniziate dalle chiavi da cui dipendono i vostri report

Non vi servono tutte le relazioni fin dal primo giorno. Prendete i cinque o sei join da cui dipendono i vostri report regolamentari e di rischio, aggiungete una regola Referential Integrity per ciascuna relazione, impostate la tolleranza zero dove una riga mancante è un'esposizione mancante e lasciate che le ispezioni facciano il loro lavoro. Vedrete presto quali feed producono record orfani, e quando. Se volete vederlo sulle vostre tabelle del sistema core e del data warehouse, prenotate una demo con il team di digna.

Domande frequenti

Che cos'è l'integrità referenziale nei dati bancari?

Significa che ogni riferimento nei dati di una banca punta a un record esistente: ogni movimento a un conto noto, ogni pagamento a una controparte nota, ogni prestito a un cliente noto. Quando un riferimento si rompe, il record scompare silenziosamente dai join, quindi saldi, esposizioni e report vengono calcolati su meno righe di quelle esistenti.

Perché compaiono record orfani in un data warehouse di core banking?

Soprattutto perché transazioni e anagrafiche arrivano con tempistiche diverse. I movimenti vengono caricati in giornata mentre l'anagrafica conti viene caricata di notte, le migrazioni rimappano i numeri cliente, i nuovi prodotti entrano in produzione prima che le tabelle di riferimento li conoscano e i sistemi formattano la stessa chiave in modo diverso, ad esempio con o senza zeri iniziali.

Come trovo in SQL i movimenti senza un conto corrispondente?

Usate un anti-join: eseguite un LEFT JOIN dei movimenti sugli ID conto distinti della tabella dei conti e mantenete le righe in cui il lato del conto è NULL, escludendo i movimenti il cui account_id è esso stesso NULL. Per una chiave conto più valuta, eseguite il join su entrambe le colonne nello stesso ordine.

I dati per il reporting regolamentare possono ammettere record orfani?

No. Per i dati che alimentano report regolamentari o di rischio, usate una soglia Absolute in modo che un solo record orfano faccia fallire il controllo, perché ogni riga mancante è un'esposizione o una registrazione mancante. Le soglie relative sono ragionevoli solo per i feed rumorosi, come le autorizzazioni di carte infragiornaliere in attesa dell'anagrafica esercenti.

digna può verificare i riferimenti tra il sistema di core banking e il data warehouse?

Sì. Dalla Release 2026.01, una regola Referential Integrity di digna può confrontare data source su connessioni di database diverse all'interno dello stesso progetto, come l'anagrafica conti nel sistema core e i movimenti nel data warehouse. I controlli vengono eseguiti all'interno dei vostri database e nessuna tabella viene replicata.