Księgowanie trafia do hurtowni danych z account_id, którego nie ma w tabeli kont. Autoryzacja kartowa wskazuje na akceptanta, który nigdy nie został załadowany. Płatność zawiera identyfikator kontrahenta, którego system ryzyka nie zna. Nic się nie wywraca. Wiersze po prostu wypadają z każdego złączenia wewnętrznego (inner join), a sumy na dalszych etapach są po cichu błędne. Integralność referencyjna w danych bankowych oznacza, że każde odwołanie (konto księgowania, kontrahent płatności, klient kredytu) wskazuje na rekord, który naprawdę istnieje we wskazanej tabeli głównej.

Systemy core banking zwykle wymuszają własne klucze. Kłopoty zaczynają się, gdy dane je opuszczają: hurtownia, silnik ryzyka, platforma AML i warstwa raportowa dostają każda własną kopię, według własnego harmonogramu, często z innym formatem klucza. Tam pojawiają się rekordy osierocone i tam w praktyce rozstrzyga się jakość danych bankowych.

Poniżej: odwołania, które mają znaczenie w banku, co się psuje, gdy nie są spełnione, dlaczego rekordy osierocone wciąż się pojawiają i jak sprawdzić każde z nich w digna bez kopiowania danych poza Twoje systemy.

Najważniejsze wnioski

• Rekord osierocony w danych bankowych to nie komunikat o błędzie. To księgowanie, płatność lub ekspozycja, która po cichu wypada ze złączenia.

• Sprawdzaj złączenia, od których zależą raporty: księgowania, autoryzacje, płatności, kredyty, kursy walut i alerty AML względem ich danych głównych.

• Większość rekordów osieroconych wynika z czasu i tłumaczenia kluczy: spóźnionych danych głównych, migracji, wprowadzania nowych produktów i różnych formatów kluczy.

• W digna Data Validation każda relacja to jedna reguła Referential Integrity, z progiem zero dla danych regulacyjnych i progami względnymi tylko dla zaszumionych zasileń.

• Od Release 2026.01 reguła może porównać tabelę w systemie centralnym z tabelą w hurtowni, a błędne rekordy można wyeksportować jako dowód.

Spis treści

• Najważniejsze wnioski

• Które odwołania są najważniejsze w danych bankowych?

  • Klucze złożone

  • Odwołania między systemami

• Co się dzieje, gdy odwołanie w danych bankowych się psuje?

• Dlaczego w systemach bankowych pojawiają się rekordy osierocone?

• Jak znaleźć osierocone księgowania w SQL?

• Jak skonfigurować kontrolę integralności referencyjnej w digna?

• Jaki próg stosować dla danych regulacyjnych?

• Jak sprawdzić system core banking względem hurtowni danych?

• Jak błędne rekordy stają się dowodem audytowym?

• Zacznij od kluczy, od których zależą Twoje raporty

Które odwołania są najważniejsze w danych bankowych?

Najważniejsze w danych bankowych są odwołania, przez które przechodzi każdy raport i każda miara ryzyka: księgowania do kont, autoryzacje kartowe do kart i akceptantów, płatności do kontrahentów, kredyty do klientów i zabezpieczeń, kursy walut do kodów walut oraz alerty AML do kont i klientów. Jeśli którekolwiek z tych złączeń zawiedzie, rekord znika z wyniku.

Ogólną definicję znajdziesz w głównym artykule Czy Twoje dane wciąż odnajdują swoich rodziców? Zrozumienie integralności referencyjnej. W banku lista jest dość stała:

• Księgowania → konta. Salda, odsetki i opłaty są liczone przez to złączenie.

• Autoryzacje kartowe → karty i akceptanci. Karta prowadzi do konta i klienta; akceptant niesie kod kategorii (MCC).

• Płatności → kontrahenci. Rekord kontrahenta służy do screeningu, statystyk i wyliczania ekspozycji.

• Kredyty → klienci i zabezpieczenia. Zarówno kredytobiorca, jak i zabezpieczenie zasilają ryzyko i tworzenie rezerw.

• Kursy walut → kody walut. Kursy i kwoty w walutach obcych odwołują się do tabeli walut, zwykle kluczowanej kodami ISO 4217.

• Alerty AML → konta i klienci. Bez nich nikt nie może obsłużyć alertu.

Klucze złożone

Wiele kluczy bankowych to nie pojedyncza kolumna. Konto wielowalutowe jest często identyfikowane przez konto + walutę; kredyt konsorcjalny lub wypłacany w transzach przez umowę + transzę. Sprawdzenie samego account_id przepuściłoby księgowanie w EUR na konto, które istnieje tylko w USD. Kontrola musi dotyczyć kombinacji, z tą samą kolejnością kolumn po obu stronach.

Odwołania między systemami

Najbardziej kruche są odwołania przekraczające granice systemów. Kartoteka klientów jest w systemie core banking, transakcje w bankowej hurtowni danych, ekspozycje w systemie ryzyka z własną tabelą kontrahentów. Każda kopia jest spójna sama ze sobą. Pytanie brzmi, czy są spójne ze sobą nawzajem.

Co się dzieje, gdy odwołanie w danych bankowych się psuje?

Gdy odwołanie w danych bankowych się psuje, rekord podrzędny nie zgłasza głośno błędu. Wypada ze złączeń, więc salda, ekspozycje, populacje raportowe i kolejki alertów są liczone na mniejszej liczbie rekordów, niż istnieje. Skutek zależy od tego, która relacja się zepsuła, a poniższa tabela wprost go opisuje dla najczęstszych przypadków.

Żaden z tych przypadków nie generuje błędu w logu ETL. Zadanie zakończyło się sukcesem; złączenie było po prostu mniejsze.

Dlaczego w systemach bankowych pojawiają się rekordy osierocone?

Rekordy osierocone pojawiają się w systemach bankowych głównie dlatego, że dane główne i transakcje docierają według różnych harmonogramów i przez różne tłumaczenia kluczy. Transakcja może trafić do hurtowni przed swoim kontem, migracja może przepisać jedną stronę klucza, a dwa systemy mogą inaczej formatować ten sam identyfikator. Każda przyczyna jest zwyczajna; razem sprawiają, że rekordy osierocone są codziennością.

• Spóźnione dane główne. Transakcje ładują się w ciągu dnia, kartoteka kont raz na noc. Klient zarejestrowany o 10:00, który wykonuje transakcję o 10:05, jest rekordem osieroconym aż do następnego ładowania kartoteki.

• Fuzje i migracje. Gdy portfel przechodzi z przejętego banku lub starego systemu centralnego, numery klientów i umów są mapowane na nowe. Wiersze, które ominęło mapowanie, zachowują stare klucze.

• Wprowadzanie nowych produktów. Nowy produkt kartowy, typ konta czy waluta startuje w systemie centralnym, zanim tabele referencyjne hurtowni się o nim dowiedzą.

• Różnice w formatach kluczy. Jeden system dopełnia numery kont wiodącymi zerami, inny przechowuje je jako liczby całkowite; jeden używa IBAN, inny wewnętrznego identyfikatora; jeden przechowuje identyfikatory kontrahentów wielkimi literami. Wartości znaczą to samo, a mimo to się nie łączą.

• Ograniczenia, które nie są wymuszane. Baza systemu centralnego może wymuszać swoje klucze obce, ale platformy hurtowni danych często traktują zadeklarowane klucze jako informacyjne. Snowflake na przykład dokumentuje klucze obce na standardowych tabelach jako niewymuszane. Nic nie powstrzymuje rekordu osieroconego przed załadowaniem.

Nadzorcy oczekują, że banki będą agregować dane o ryzyku w sposób kompletny i dokładny, zgodnie z zasadami BCBS 239 Bazylejskiego Komitetu Nadzoru Bankowego, a osierocone ekspozycje działają wprost przeciwko temu. Szerszą, organizacyjną stronę tematu omawiamy w artykule o zarządzaniu danymi w bankach.

Jak znaleźć osierocone księgowania w SQL?

Osierocone księgowania znajdziesz za pomocą anti-joina: wybierz księgowania, których account_id nie jest NULL i nie ma pasującego wiersza w accounts. Porównanie ze zbiorem unikalnych identyfikatorów kont daje poprawny wynik nawet wtedy, gdy tabela kont zawiera duplikaty, a wykluczenie wartości NULL oddziela brakujące odwołania od błędnych.

-- 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

Dla klucza złożonego, takiego jak konto + waluta, złączenie po prostu obejmuje obie kolumny:

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

To działa dla jednej relacji w jednej bazie danych. Bank ma dziesiątki relacji w kilku bazach i potrzebuje wyniku codziennie. Ręczne utrzymywanie tych zapytań to ta część, która zwykle zostaje zaniedbana.

Jak skonfigurować kontrolę integralności referencyjnej w digna?

W digna konfigurujesz kontrolę integralności referencyjnej, dodając regułę typu Referential Integrity do podrzędnego źródła danych, wybierając jego kolumny kluczy i wskazując źródło danych oraz kolumny, w których muszą istnieć. Nie trzeba pisać SQL. digna generuje kontrolę, uruchamia ją wewnątrz Twojej bazy danych przy każdej inspekcji i raportuje liczbę rekordów, które przeszły i nie przeszły kontroli.

Dla postings.account_id → accounts.account_id kroki w digna Data Validation są następujące:

1. Przejdź do Configuration, wybierz źródło danych postings, otwórz zakładkę Data Validation i kliknij Add Rule. Otworzy się okno Add Data Validation Rule (dodaj regułę walidacji danych).

2. Wpisz Name (nazwa) i Description (opis), na przykład posting_account_exists, „Każde księgowanie należy do konta w kartotece kont”.

3. Ustaw Type na Referential Integrity.

4. W sekcji Attributes wybierz account_id (dla klucza konto + waluta dodaj też currency).

5. W sekcji must exist in (musi istnieć w) wybierz Data Source accounts i jego Attributes account_id, w tej samej kolejności co po lewej stronie.

6. Wybierz Threshold Mode (tryb progu) i ustaw Info threshold oraz Warn threshold.

7. Zapisz. Reguła uruchamia się przy każdej zaplanowanej lub wykonywanej na żądanie inspekcji postings.

Poniższy zrzut ekranu pochodzi z demo szpitalnego digna, a nie z banku, ale okno dla tabeli bankowej jest identyczne: zamień product_code i hospital_medications na account_id i accounts.

Okno reguły Referential Integrity w digna. Dane demonstracyjne Danubia Kliniken, fikcyjnej austriackiej grupy szpitali.

digna pobiera unikalne wartości z nadrzędnego źródła danych i oznacza jako błędny każdy wiersz podrzędny, który się nie łączy. Obie listy kolumn muszą mieć tę samą długość; niezgodność jest odrzucana, zamiast po cichu sprawdzać słabszy warunek. Klucze obce o wartości NULL są pomijane, więc płatność bez identyfikatora kontrahenta nie powoduje niepowodzenia tej reguły. Jeśli kontrahent jest obowiązkowy, dodaj osobną regułę typu Rule z warunkiem counterparty_id IS NOT NULL. Pełny opis krok po kroku znajdziesz w artykule o tym, jak skonfigurować kontrolę integralności referencyjnej; dokumentacja digna wyjaśnia, jak oceniana jest walidacja.

Jaki próg stosować dla danych regulacyjnych?

Dane regulacyjne powinny mieć zerową tolerancję: tryb progu Absolute, ustawiony tak, by pojedynczy rekord osierocony powodował niepowodzenie kontroli. Ekspozycja brakująca w raporcie regulacyjnym jest defektem bez względu na to, ile wierszy przeszło kontrolę. Progi względne pasują tylko do zaszumionych zasileń, w których oczekuje się małego, znanego odsetka spóźnionych odwołań.

digna ocenia dwa poziomy. Powyżej Info threshold status to Uncertain; powyżej Warn threshold to Failed; w pozostałych przypadkach Passed. Oba progi domyślnie wynoszą zero, więc nowa reguła kończy się błędem przy pierwszym złym rekordzie, dopóki nie zdecydujesz inaczej. Powyższa reguła demonstracyjna używa Absolute, Info 0, Warn 1, więc już jeden rekord osierocony daje status Uncertain, a dwa lub więcej powodują niepowodzenie kontroli; dla danych regulacyjnych zostaw Warn na 0, aby jeden rekord osierocony powodował niepowodzenie.

Jeśli próg względny pochłania spóźnione dane główne, sprawdź te same dane ponownie później, aby „spóźnione” nie stało się po cichu „trwałe”.

Jak sprawdzić system core banking względem hurtowni danych?

System core banking sprawdzisz względem hurtowni danych regułą integralności referencyjnej, której dwa źródła danych leżą na różnych połączeniach bazodanowych w tym samym projekcie digna. Od Release 2026.01 jest to obsługiwane bezpośrednio, więc kartoteka kont w systemie centralnym i księgowania w hurtowni są walidowane bez replikowania którejkolwiek tabeli.

To wyłapuje opisane wyżej problemy między systemami: różnice w formatach kluczy, przemapowane numery klientów, konta, które nigdy nie dotarły do hurtowni. W digna połączenia bazodanowe są globalne i wielokrotnego użytku w różnych projektach, a źródło danych może być tabelą, widokiem lub własną instrukcją SQL. Widok lub źródło danych SQL to praktyczne miejsce na znormalizowanie formatu klucza (na przykład usunięcie wiodących zer) przed porównaniem. Kontrole działają wewnątrz Twoich baz danych; Twoje dane nigdy nie opuszczają Twojej infrastruktury. Szczegóły, w tym schematy i widoki, znajdziesz w artykule o integralności referencyjnej między bazami danych i połączeniami.

Jak błędne rekordy stają się dowodem audytowym?

Błędne rekordy stają się dowodem audytowym, bo digna zwraca same wiersze, a nie tylko ich liczbę. Widok Invalid Records wymienia każdy rekord, który nie przeszedł kontroli w danej inspekcji, z filtrem Passed, Uncertain lub Failed, a listę można wyeksportować dla audytora, właściciela danych lub do zgłoszenia incydentu.

Technicznie to to samo zapytanie z zanegowanym warunkiem, wykonane wewnątrz bazy źródłowej. Dla reguły na księgowaniach widzisz każde osierocone księgowanie z identyfikatorem konta, kwotą, datą księgowania i innymi kolumnami, co zwykle wystarcza zespołowi będącemu właścicielem danych, by znaleźć przyczynę. digna może też powiadomić zespół, który jest właścicielem danych.

Invalid Records dla kontroli integralności referencyjnej zakończonej niepowodzeniem, z tego samego demo szpitalnego; tabela bankowa pokazuje w tym samym widoku własne kolumny.

Ponieważ wyniki są przechowywane dla każdej daty inspekcji, możesz pokazać, kiedy relacja się zepsuła i kiedy została naprawiona. Taki zapis kontroli, wyników i błędnych wierszy jest przydatnym materiałem, gdy objaśniasz swoje mechanizmy kontrolne, choć sam w sobie nie czyni procesu zgodnym z regulacjami.

Zacznij od kluczy, od których zależą Twoje raporty

Nie potrzebujesz wszystkich relacji od pierwszego dnia. Weź pięć lub sześć złączeń, od których zależą Twoje raporty regulacyjne i raporty ryzyka, dodaj jedną regułę Referential Integrity na relację, ustaw zerową tolerancję tam, gdzie brakujący wiersz to brakująca ekspozycja, i pozwól inspekcjom działać. Szybko zobaczysz, które zasilenia produkują rekordy osierocone i kiedy. Jeśli chcesz zobaczyć to na własnych tabelach systemu centralnego i hurtowni, umów demo z zespołem digna.

Najczęściej zadawane pytania

Czym jest integralność referencyjna w danych bankowych?

Oznacza, że każde odwołanie w danych banku wskazuje na rekord, który istnieje: każde księgowanie na znane konto, każda płatność na znanego kontrahenta, każdy kredyt na znanego klienta. Gdy odwołanie się psuje, rekord po cichu wypada ze złączeń, więc salda, ekspozycje i raporty są liczone na mniejszej liczbie wierszy, niż istnieje.

Dlaczego w bankowej hurtowni danych pojawiają się rekordy osierocone?

Głównie dlatego, że transakcje i dane główne docierają według różnych harmonogramów. Księgowania ładują się w ciągu dnia, a kartoteka kont co noc, migracje przemapowują numery klientów, nowe produkty startują, zanim tabele referencyjne je znają, a systemy różnie formatują ten sam klucz, na przykład z wiodącymi zerami lub bez nich.

Jak znaleźć w SQL księgowania bez pasującego konta?

Użyj anti-joina: połącz przez LEFT JOIN księgowania z unikalnymi identyfikatorami kont z tabeli kont i zostaw wiersze, w których strona konta jest NULL, wykluczając księgowania, których account_id samo jest NULL. Dla klucza konto plus waluta łącz po obu kolumnach w tej samej kolejności.

Czy dane do raportowania regulacyjnego mogą dopuszczać jakiekolwiek rekordy osierocone?

Nie. Dla danych zasilających raporty regulacyjne lub raporty ryzyka używaj progu Absolute, aby pojedynczy rekord osierocony powodował niepowodzenie kontroli, bo każdy brakujący wiersz to brakująca ekspozycja lub księgowanie. Progi względne mają sens tylko dla zaszumionych zasileń, takich jak autoryzacje kartowe w ciągu dnia czekające na dane główne akceptantów.

Czy digna może sprawdzać odwołania między systemem core banking a hurtownią?

Tak. Od Release 2026.01 reguła Referential Integrity w digna może porównywać źródła danych na różnych połączeniach bazodanowych w tym samym projekcie, na przykład kartotekę kont w systemie centralnym i księgowania w hurtowni. Kontrole działają wewnątrz Twoich baz danych i żadna tabela nie jest replikowana.