Eine Buchung landet im Data Warehouse mit einer account_id, die in der Kontentabelle nicht existiert. Eine Kartenautorisierung verweist auf einen Händler, der nie geladen wurde. Eine Zahlung nennt eine Gegenpartei-ID, die das Risikosystem nicht kennt. Nichts stürzt ab. Die Zeilen fallen einfach aus jedem Inner Join heraus, und die nachgelagerten Summen sind unbemerkt falsch. Referenzielle Integrität in Bankdaten bedeutet, dass jede Referenz (das Konto einer Buchung, die Gegenpartei einer Zahlung, der Kunde eines Kredits) auf einen Datensatz zeigt, der in der genannten Stammdatentabelle tatsächlich existiert.

Core-Banking-Systeme setzen ihre eigenen Schlüssel in der Regel durch. Die Probleme beginnen, sobald die Daten sie verlassen: Data Warehouse, Risk Engine, AML-Plattform und Reporting-Schicht erhalten jeweils ihre eigene Kopie, nach eigenem Zeitplan, oft mit einem anderen Schlüsselformat. Dort entstehen verwaiste Datensätze, und dort entscheidet sich die Datenqualität einer Bank tatsächlich.

Im Folgenden: die Referenzen, die in einer Bank zählen, was bricht, wenn sie nicht halten, warum immer wieder verwaiste Datensätze entstehen und wie Sie jede einzelne mit digna prüfen, ohne Daten aus Ihren Systemen zu kopieren.

Das Wichtigste in Kürze

• Ein verwaister Datensatz in Bankdaten ist keine Fehlermeldung. Er ist eine Buchung, Zahlung oder Risikoposition, die stillschweigend aus einem Join herausfällt.

• Prüfen Sie die Joins, von denen Berichte abhängen: Buchungen, Autorisierungen, Zahlungen, Kredite, Devisenkurse und AML-Alerts gegen ihre Stammdaten.

• Die meisten verwaisten Datensätze entstehen durch Timing und Übersetzung: verspätete Stammdaten, Migrationen, Produkteinführungen und unterschiedliche Schlüsselformate.

• In digna Data Validation ist jede Beziehung eine Referential-Integrity-Regel, mit einem Schwellenwert von null für regulatorische Daten und relativen Schwellenwerten nur für verrauschte Datenfeeds.

• Seit Release 2026.01 kann eine Regel eine Tabelle im Kernsystem mit einer im Data Warehouse vergleichen, und die fehlgeschlagenen Datensätze lassen sich als Nachweis exportieren.

Inhaltsverzeichnis

• Das Wichtigste in Kürze

• Welche Referenzen zählen in Bankdaten am meisten?

  • Zusammengesetzte Schlüssel

  • Systemübergreifende Referenzen

• Was passiert, wenn eine Referenz in Bankdaten bricht?

• Warum entstehen verwaiste Datensätze in Banksystemen?

• Wie finden Sie verwaiste Buchungen mit SQL?

• Wie richten Sie eine Prüfung der referenziellen Integrität in digna ein?

• Welchen Schwellenwert sollten regulatorische Daten verwenden?

• Wie prüfen Sie Core Banking gegen das Data Warehouse?

• Wie werden fehlgeschlagene Datensätze zum Prüfungsnachweis?

• Beginnen Sie mit den Schlüsseln, von denen Ihre Berichte abhängen

Welche Referenzen zählen in Bankdaten am meisten?

Am meisten zählen in Bankdaten die Referenzen, über die jeder Bericht und jede Risikokennzahl joint: Buchungen zu Konten, Kartenautorisierungen zu Karten und Händlern, Zahlungen zu Gegenparteien, Kredite zu Kunden und Sicherheiten, Devisenkurse zu Währungscodes sowie AML-Alerts zu Konten und Kunden. Schlägt einer dieser Joins fehl, verschwindet der Datensatz aus dem Ergebnis.

Die allgemeine Definition finden Sie im Grundlagenartikel Finden Ihre Daten noch ihre Eltern? Referenzielle Integrität verstehen. In einer Bank ist die Liste ziemlich stabil:

• Buchungen → Konten. Salden, Zinsen und Gebühren werden alle über diesen Join berechnet.

• Kartenautorisierungen → Karten und Händler. Die Karte führt zu Konto und Kunde; der Händler trägt den Branchencode (Merchant Category Code).

• Zahlungen → Gegenparteien. Der Gegenpartei-Datensatz dient für Screening, Statistik und Risikopositionen.

• Kredite → Kunden und Sicherheiten. Kreditnehmer und Sicherheiten fließen beide in Risiko und Risikovorsorge ein.

• Devisenkurse → Währungscodes. Kurse und Fremdwährungsbeträge verweisen auf eine Währungstabelle, typischerweise mit ISO-4217-Codes als Schlüssel.

• AML-Alerts → Konten und Kunden. Ohne sie kann niemand den Alert bearbeiten.

Zusammengesetzte Schlüssel

Viele Schlüssel in Banken bestehen nicht aus einer einzigen Spalte. Ein Mehrwährungskonto wird oft über Konto + Währung identifiziert, ein syndizierter oder in Tranchen gezogener Kredit über Vertrag + Tranche. Wer nur account_id prüft, lässt eine EUR-Buchung gegen ein Konto bestehen, das nur in USD existiert. Die Prüfung muss auf der Kombination erfolgen, mit derselben Spaltenreihenfolge auf beiden Seiten.

Systemübergreifende Referenzen

Am anfälligsten sind Referenzen, die Systemgrenzen überschreiten. Der Kundenstamm liegt im Core-Banking-System, die Transaktionen im Data Warehouse, die Risikopositionen in einem Risikosystem mit eigener Gegenparteitabelle. Jede Kopie ist in sich konsistent. Die Frage ist, ob sie übereinstimmen.

Was passiert, wenn eine Referenz in Bankdaten bricht?

Bricht eine Referenz in Bankdaten, schlägt der Kind-Datensatz nicht laut fehl. Er fällt aus den Joins heraus, sodass Salden, Risikopositionen, Meldepopulationen und Alert-Warteschlangen auf weniger Datensätzen berechnet werden, als tatsächlich existieren. Die Folge hängt davon ab, welche Beziehung gebrochen ist; die Tabelle unten benennt sie für die häufigsten Fälle.

Keiner dieser Fälle erzeugt einen Fehler im ETL-Log. Der Job war erfolgreich; der Join war nur kleiner.

Warum entstehen verwaiste Datensätze in Banksystemen?

Verwaiste Datensätze entstehen in Banksystemen vor allem, weil Stammdaten und Transaktionen nach unterschiedlichen Zeitplänen und über unterschiedliche Übersetzungen ankommen. Eine Transaktion kann das Data Warehouse vor ihrem Konto erreichen, eine Migration kann eine Seite eines Schlüssels umschreiben, und zwei Systeme können denselben Identifikator unterschiedlich formatieren. Jede Ursache ist alltäglich; zusammen machen sie verwaiste Datensätze zur Routine.

• Verspätete Stammdaten. Transaktionen werden untertägig geladen, der Kontenstamm einmal pro Nacht. Ein Kunde, der um 10:00 angelegt wird und um 10:05 eine Transaktion ausführt, ist bis zum nächsten Stammdatenladen verwaist.

• Fusionen und Migrationen. Wenn ein Portfolio von einer übernommenen Bank oder einem alten Kernsystem umzieht, werden Kunden- und Vertragsnummern neu zugeordnet. Zeilen, die das Mapping verfehlen, behalten alte Schlüssel.

• Produkteinführungen. Ein neues Kartenprodukt, eine neue Kontoart oder Währung geht im Kernsystem live, bevor die Referenztabellen im Data Warehouse davon wissen.

• Unterschiedliche Schlüsselformate. Ein System füllt Kontonummern mit führenden Nullen auf, ein anderes speichert sie als Integer; eines verwendet die IBAN, ein anderes eine interne ID; eines speichert Gegenpartei-IDs in Großbuchstaben. Die Werte bedeuten dasselbe und lassen sich trotzdem nicht joinen.

• Nicht durchgesetzte Constraints. Die Kerndatenbank setzt ihre Fremdschlüssel vielleicht durch, aber Data-Warehouse-Plattformen behandeln deklarierte Schlüssel oft nur als informativ. Snowflake etwa dokumentiert Fremdschlüssel auf Standardtabellen als nicht durchgesetzt. Nichts hindert einen verwaisten Datensatz daran, geladen zu werden.

Die Aufsicht erwartet von Banken, Risikodaten vollständig und genau zu aggregieren, wie in den BCBS-239-Grundsätzen des Basler Ausschusses festgelegt, und verwaiste Risikopositionen laufen dem direkt zuwider. Zur organisatorischen Seite des Themas lesen Sie mehr über Datenmanagement in Banken.

Wie finden Sie verwaiste Buchungen mit SQL?

Verwaiste Buchungen finden Sie mit einem Anti-Join: Wählen Sie Buchungen, deren account_id nicht NULL ist und keine passende Zeile in accounts hat. Der Vergleich gegen die eindeutige Menge der Konto-IDs hält das Ergebnis auch dann korrekt, wenn die Kontentabelle Duplikate enthält, und das Ausschließen von NULL-Werten trennt fehlende Referenzen von falschen.

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

Bei einem zusammengesetzten Schlüssel wie Konto + Währung trägt der Join einfach beide Spalten:

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

Das funktioniert für eine Beziehung in einer Datenbank. Eine Bank hat Dutzende von Beziehungen über mehrere Datenbanken hinweg und braucht das Ergebnis jeden Tag. Genau das Pflegen dieser Abfragen von Hand ist der Teil, der gern einschläft.

Wie richten Sie eine Prüfung der referenziellen Integrität in digna ein?

In digna richten Sie eine Prüfung der referenziellen Integrität ein, indem Sie der Kind-Datenquelle eine Regel vom Typ Referential Integrity hinzufügen, ihre Schlüsselspalten auswählen und die Datenquelle und Spalten benennen, in denen diese existieren müssen. Kein SQL zu schreiben. digna erzeugt die Prüfung, führt sie bei jeder Inspektion in Ihrer Datenbank aus und meldet die Anzahl bestandener und fehlgeschlagener Datensätze.

Für postings.account_id → accounts.account_id sind die Schritte in digna Data Validation:

1. Gehen Sie zu Configuration, wählen Sie die Datenquelle postings, öffnen Sie den Tab Data Validation und klicken Sie auf Add Rule. Der Dialog Add Data Validation Rule öffnet sich.

2. Geben Sie Name und Description (Beschreibung) ein, zum Beispiel posting_account_exists, „Jede Buchung gehört zu einem Konto im Kontenstamm“.

3. Setzen Sie Type auf Referential Integrity.

4. Wählen Sie unter Attributes die Spalte account_id (bei einem Schlüssel aus Konto + Währung zusätzlich currency).

5. Wählen Sie unter must exist in die Data Source accounts und deren Attributes account_id, in derselben Reihenfolge wie links.

6. Wählen Sie den Threshold Mode (Schwellenwertmodus) und setzen Sie Info threshold und Warn threshold.

7. Speichern. Die Regel läuft bei jeder geplanten oder auf Abruf gestarteten Inspektion von postings mit.

Der Screenshot unten stammt aus der Krankenhaus-Demo von digna statt aus einer Bank, aber der Dialog ist für eine Banktabelle identisch: Ersetzen Sie product_code und hospital_medications durch account_id und accounts.

Der Dialog für die Referential-Integrity-Regel in digna. Demodaten der Danubia Kliniken, einer fiktiven österreichischen Krankenhausgruppe.

digna hält die eindeutigen Werte aus der Eltern-Datenquelle vor und lässt jede Kind-Zeile fehlschlagen, die sich nicht joinen lässt. Die beiden Spaltenlisten müssen gleich lang sein; eine Abweichung wird zurückgewiesen, statt stillschweigend eine schwächere Bedingung zu prüfen. NULL-Fremdschlüssel werden übersprungen, eine Zahlung ohne Gegenpartei-ID schlägt bei dieser Regel also nicht fehl. Ist die Gegenpartei ein Pflichtfeld, ergänzen Sie eine separate Regel vom Typ Rule mit counterparty_id IS NOT NULL. Die vollständige Anleitung finden Sie unter So richten Sie eine Prüfung der referenziellen Integrität ein; die digna-Dokumentation erklärt, wie die Validierung ausgewertet wird.

Welchen Schwellenwert sollten regulatorische Daten verwenden?

Regulatorische Daten sollten Nulltoleranz verwenden: den Threshold Mode Absolute, so eingestellt, dass ein einziger verwaister Datensatz die Prüfung fehlschlagen lässt. Eine Risikoposition, die in einer aufsichtlichen Meldung fehlt, ist ein Mangel, egal wie viele Zeilen bestanden haben. Relative Schwellenwerte gehören nur zu verrauschten Datenfeeds, bei denen ein kleiner, bekannter Anteil verspäteter Referenzen zu erwarten ist.

digna wertet zwei Stufen aus. Oberhalb des Info threshold lautet der Status Uncertain, oberhalb des Warn threshold Failed, andernfalls Passed. Beide Schwellenwerte stehen standardmäßig auf null, eine neue Regel schlägt also beim ersten fehlerhaften Datensatz fehl, bis Sie anders entscheiden. Die Demo-Regel oben verwendet Absolute, Info 0, Warn 1, sodass bereits ein einziger verwaister Datensatz den Status Uncertain auslöst und zwei oder mehr die Prüfung fehlschlagen lassen; für regulatorische Daten belassen Sie Warn bei 0, damit schon ein verwaister Datensatz zum Fehlschlag führt.

Wenn ein relativer Schwellenwert verspätete Stammdaten auffängt, prüfen Sie dieselben Daten später erneut, damit aus „verspätet“ nicht unbemerkt „dauerhaft“ wird.

Wie prüfen Sie Core Banking gegen das Data Warehouse?

Sie prüfen Core Banking gegen das Data Warehouse mit einer Regel für referenzielle Integrität, deren zwei Datenquellen auf verschiedenen Datenbankverbindungen im selben digna-Projekt liegen. Seit Release 2026.01 wird das direkt unterstützt, sodass Kontenstamm im Kernsystem und Buchungen im Data Warehouse validiert werden, ohne eine der beiden Tabellen zu replizieren.

So werden die oben beschriebenen systemübergreifenden Probleme erkannt: unterschiedliche Schlüsselformate, neu zugeordnete Kundennummern, Konten, die nie im Data Warehouse angekommen sind. In digna sind Datenbankverbindungen global und projektübergreifend wiederverwendbar, und eine Datenquelle kann eine Tabelle, eine View oder ein eigenes SQL-Statement sein. Eine View oder eine SQL-Datenquelle ist ein praktischer Ort, um ein Schlüsselformat vor dem Vergleich zu normalisieren (etwa führende Nullen zu entfernen). Die Prüfungen laufen in Ihren Datenbanken; Ihre Daten verlassen nie Ihre Infrastruktur. Die Details, einschließlich Schemas und Views, finden Sie im Beitrag über referenzielle Integrität über Datenbanken und Verbindungen hinweg.

Wie werden fehlgeschlagene Datensätze zum Prüfungsnachweis?

Fehlgeschlagene Datensätze werden zum Prüfungsnachweis, weil digna die Zeilen selbst liefert, nicht nur eine Anzahl. Die Ansicht Invalid Records listet jeden Datensatz auf, der bei einer bestimmten Inspektion eine Prüfung nicht bestanden hat, gefiltert nach Passed, Uncertain oder Failed, und die Liste lässt sich für Prüfer, Datenverantwortliche oder ein Incident-Ticket exportieren.

Technisch ist es dieselbe Abfrage mit negierter Bestehensbedingung, ausgeführt in der Quelldatenbank. Bei einer Regel für Buchungen sehen Sie jede verwaiste Buchung mit Konto-ID, Betrag, Buchungsdatum und weiteren Spalten, was dem zuständigen Team meist reicht, um die Ursache zu finden. digna kann außerdem das Team benachrichtigen, dem die Daten gehören.

Invalid Records für eine fehlgeschlagene Prüfung der referenziellen Integrität, aus derselben Krankenhaus-Demo; eine Banktabelle zeigt in derselben Ansicht ihre eigenen Spalten.

Da die Ergebnisse pro Inspektionsdatum gespeichert werden, können Sie zeigen, wann eine Beziehung gebrochen und wann sie behoben wurde. Diese Aufzeichnung von Prüfungen, Ergebnissen und fehlgeschlagenen Zeilen ist nützliches Material, wenn Sie Ihre Kontrollen erläutern, macht einen Prozess aber für sich genommen noch nicht compliant.

Beginnen Sie mit den Schlüsseln, von denen Ihre Berichte abhängen

Sie brauchen nicht jede Beziehung am ersten Tag. Nehmen Sie die fünf oder sechs Joins, von denen Ihre aufsichtlichen Meldungen und Risikoberichte abhängen, legen Sie pro Beziehung eine Referential-Integrity-Regel an, setzen Sie Nulltoleranz dort, wo eine fehlende Zeile eine fehlende Risikoposition ist, und lassen Sie die Inspektionen laufen. Sie sehen bald, welche Datenfeeds verwaiste Datensätze erzeugen, und wann. Wenn Sie das an Ihren eigenen Core-Banking- und Data-Warehouse-Tabellen sehen möchten, buchen Sie eine Demo mit dem digna-Team.

Häufig gestellte Fragen

Was ist referenzielle Integrität in Bankdaten?

Sie bedeutet, dass jede Referenz in den Daten einer Bank auf einen existierenden Datensatz zeigt: jede Buchung auf ein bekanntes Konto, jede Zahlung auf eine bekannte Gegenpartei, jeder Kredit auf einen bekannten Kunden. Bricht eine Referenz, fällt der Datensatz stillschweigend aus den Joins heraus, sodass Salden, Risikopositionen und Berichte auf weniger Zeilen berechnet werden, als existieren.

Warum entstehen verwaiste Datensätze in einem Core-Banking-Data-Warehouse?

Vor allem, weil Transaktionen und Stammdaten nach unterschiedlichen Zeitplänen ankommen. Buchungen werden untertägig geladen, der Kontenstamm nächtlich, Migrationen ordnen Kundennummern neu zu, neue Produkte gehen live, bevor die Referenztabellen sie kennen, und Systeme formatieren denselben Schlüssel unterschiedlich, zum Beispiel mit oder ohne führende Nullen.

Wie finde ich Buchungen ohne passendes Konto mit SQL?

Verwenden Sie einen Anti-Join: Verknüpfen Sie die Buchungen per LEFT JOIN mit den eindeutigen Konto-IDs aus der Kontentabelle und behalten Sie die Zeilen, bei denen die Kontoseite NULL ist; Buchungen, deren account_id selbst NULL ist, schließen Sie aus. Bei einem Schlüssel aus Konto und Währung joinen Sie über beide Spalten in derselben Reihenfolge.

Dürfen Daten für das Meldewesen verwaiste Datensätze enthalten?

Nein. Für Daten, die in aufsichtliche Meldungen oder Risikoberichte einfließen, verwenden Sie einen Absolute-Schwellenwert, sodass ein einziger verwaister Datensatz die Prüfung fehlschlagen lässt, denn jede fehlende Zeile ist eine fehlende Risikoposition oder Buchung. Relative Schwellenwerte sind nur bei verrauschten Datenfeeds sinnvoll, etwa bei untertägigen Kartenautorisierungen, die auf Händlerstammdaten warten.

Kann digna Referenzen zwischen dem Core-Banking-System und dem Data Warehouse prüfen?

Ja. Seit Release 2026.01 kann eine Referential-Integrity-Regel in digna Datenquellen auf verschiedenen Datenbankverbindungen im selben Projekt vergleichen, etwa den Kontenstamm im Kernsystem und die Buchungen im Data Warehouse. Die Prüfungen laufen in Ihren Datenbanken, und keine Tabelle wird repliziert.