Datenqualität messen mit Banking-Dimensionen und DQ-Scorecards

Eine Überweisung kommt an, das IBAN-Feld ist leer. Diese eine Lücke kann eine Zahlung blockieren, eine Ausnahme im Sanktionsscreening auslösen und im nächsten Quartal als rote Zelle auf einer Scorecard landen, die der Chief Data Officer (CDO) dem Board vorlegt. Datenqualität im Banking ist nichts Abstraktes. Sie ist der Unterschied zwischen einer Zahlung, die durchgeht, und einer, die auf einem Verrechnungskonto liegen bleibt.

Diese Lektion zeigt Ihnen, wie Sie Datenqualität über sechs Standarddimensionen messen, sie auf echte Zahlungsdatensätze anwenden und die Ergebnisse in die Pass-Rate-Scorecards überführen, die Aufsicht und Board erwarten.

Warum Datenqualität ein Thema für das Board ist

Banken arbeiten mit Daten, die sie nicht immer sauber erhoben haben. Ein 2009 onboardeter Kunde hat möglicherweise einen Datensatz ohne Felder, die erst später verpflichtend wurden. Wenn diese Daten in regulatorische Meldungen einfließen, treten die Fehler dort auf, wo es weh tut.

Der Anker ist hier BCBS 239, die "Principles for effective risk data aggregation and risk reporting" des Basler Ausschusses für Bankenaufsicht (2013). Große Banken müssen darin Genauigkeit, Vollständigkeit und Aktualität der Daten hinter ihren Risikoberichten nachweisen. Die Aufsichtsbehörden in der EU (Europäische Zentralbank) und den USA (Federal Reserve, OCC) prüfen die Einhaltung aktiv. Die Originalprinzipien kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen Sie kostenlos bei der Bank for International Settlements lesen.

Die praktische Konsequenz: **Banken müssen Qualität *messen*, nicht behaupten**. Das bedeutet Dimensionen und Scorecards.

Die sechs Datenqualitätsdimensionen

Die Branche hat sich auf sechs Dimensionen verständigt, formalisiert in Frameworks wie dem von DAMA (Data Management Association). Hier sind sie, jeweils mit einem Beispiel aus dem Banking.

1. Vollständigkeit (Completeness)

Sind die Daten dort vorhanden, wo sie sein sollten?

Beispiel: Bei einer SEPA-Überweisung (Single Euro Payments Area) müssen die Felder IBAN (International Bank Account Number) und BIC (Bank Identifier Code) gefüllt sein. Ein Datensatz ohne IBAN fällt bei der Vollständigkeit durch.

2. Genauigkeit (Accuracy)

Stimmen die Daten mit der Realität überein?

Beispiel: Der Name einer Gegenpartei lautet "Acme Trading Ltd", die eingetragene juristische Person ist aber "Acme Trading GmbH". Das Feld ist vollständig, aber nicht korrekt. Genauigkeit ist am schwersten zu messen, weil sie eine vertrauenswürdige Referenz braucht (eine "golden source"), etwa ein validiertes LEI-Register (Legal Entity Identifier).

3. Gültigkeit (Validity, Conformity)

Folgt der Wert dem vorgeschriebenen Format oder der Regel?

Beispiel: Eine IBAN hat eine länderspezifische Länge und eine Prüfsumme. Eine deutsche IBAN hat 22 Zeichen. Wenn die Prüfsumme scheitert, ist der Wert ungültig, auch wenn das Feld gefüllt ist.

4. Konsistenz (Consistency)

Stimmt derselbe Sachverhalt über die Systeme hinweg überein?

Beispiel: Das Wohnsitzland des Kunden ist im Kernbankensystem "FR", im AML-Screening-Tool (Anti-Money Laundering) ausgeschrieben "France" und im CRMCRMCustomer Relationship Management: Software und Strategie, um Kundeninteraktionen über den gesamten Lifecycle zu steuern und zu analysieren.Vollständige Definition ansehen → "DE". Derselbe Kunde, drei Antworten.

5. Eindeutigkeit (Uniqueness)

Ist jede real existierende Entität genau einmal abgebildet?

Beispiel: Derselbe Firmenkunde erscheint wegen einer Fusion und zwei Schreibvarianten als drei separate Datensätze. Doppelte Gegenparteien verzerren Exposure-Berechnungen.

6. Aktualität (Timeliness)

Sind die Daten aktuell und verfügbar, wenn sie gebraucht werden?

Beispiel: Ein Update der Sanktionsliste kommt um 09:00 an, die Payments-Engine aktualisiert aber erst um 18:00. Neun Stunden lang läuft das Screening auf veralteten Daten.

Aus Dimensionen werden Regeln

Eine Dimension ist ein Konzept. Eine DQ-Regel ist die testbare Variante. Sie können "Vollständigkeit" nicht messen; Sie messen "Anteil der Zahlungsdatensätze, in denen IBAN nicht null ist".

Wenden wir das auf einen Zahlungsdatensatz an. Angenommen, ein Batch von 100.000 ausgehenden SEPA-Zahlungen (Beispielzahlen für eine Rechenübung, keine echten Bankdaten).

Durchgerechnetes Beispiel

Pass Rate für Vollständigkeit der IBAN:

Pass rate = (Total records - Failing records) / Total records
          = (100,000 - 1,200) / 100,000
          = 98,800 / 100,000
          = 0.988 = 98.8%

Das ist die atomare Einheit einer Scorecard. Jede grüne, gelbe oder rote Zelle, die ein Board sieht, geht auf so einen Bruch zurück.

Die IBAN-Prüfsumme: eine Gültigkeitsregel in Code

Gültigkeit ist eine der wenigen Dimensionen, die Sie mit reiner Logik prüfen können, ohne externe Quelle. Die IBAN nutzt den Standard ISO 13616 mit einer Mod-97-Prüfsumme. Hier die Kernprüfung in Python.

def is_valid_iban(iban):
    iban = iban.replace(" ", "").upper()
    # Erste 4 Zeichen ans Ende verschieben
    rearranged = iban[4:] + iban[:4]
    # Buchstaben in Zahlen umwandeln: A=10, B=11, ... Z=35
    digits = ""
    for ch in rearranged:
        if ch.isdigit():
            digits += ch
        else:
            digits += str(ord(ch) - 55)
    # Gültig, wenn die große Zahl mod 97 gleich 1 ist
    return int(digits) % 97 == 1

print(is_valid_iban("DE89370400440532013000"))  # True

Lassen Sie das über eine Zahlungstabelle laufen und Sie haben die Anzahl der fehlerhaften Datensätze für Gültigkeit direkt. Keine manuelle Prüfung nötig. Deshalb sind Gültigkeitsregeln meist die günstigsten Qualitätsgewinne.

Schwellenwerte setzen: was gilt als bestanden

Eine Pass Rate bedeutet ohne Schwellenwert nichts. Banken setzen DQ-Schwellenwerte pro Regel, oft auf Basis von Rot / Gelb / Grün (RAGRAGVerfahren, mit dem ein KI-Modell aus Ihren eigenen Dokumenten antwortet, indem es relevante Passagen abruft, bevor es eine Antwort erzeugt.Vollständige Definition ansehen →). Ein verbreitetes (illustratives) Muster:

• Grün: Pass Rate bei oder über 99 %
• Gelb: 95 % bis 98,99 %
• Rot: unter 95 %

Kritische Felder erhalten strengere Schwellenwerte. Ein sanktionsrelevantes Feld wie der Name der Gegenpartei verlangt grün vielleicht erst bei 99,9 %, weil ein einziger übersehener Treffer einen Regelverstoß bedeuten kann. Ein Feld für Marketingpräferenzen kann gelb verkraften.

Angewendet auf unsere Tabelle: Genauigkeit mit 96,9 % landet auf gelb. Das ist die Geschichte, die der CDO erklären muss, und das LEI-Abgleichsprojekt, das ins Budget des nächsten Jahres geht.

Die DQDQDer Grad, in dem Daten für ihren Zweck geeignet sind: korrekt, vollständig, konsistent, aktuell, valide und eindeutig. Schlechte Datenqualität untergräbt Analytics, Reporting und KI.Vollständige Definition ansehen →-Scorecard aufbauen

Eine Scorecard verdichtet Ergebnisse auf Regelebene zu etwas, das ein Board in 30 Sekunden aufnehmen kann. Üblich ist eine Aggregation in drei Schichten.

Schicht 1: Regelebene. Einzelne Pass Rates, wie in der Tabelle oben.

Schicht 2: Dimensionsebene. Gewichteter Durchschnitt der Regeln innerhalb einer Dimension. Hat Vollständigkeit fünf Regeln, bilden Sie den Durchschnitt ihrer Pass Rates (oft gewichtet nach Kritikalität des Feldes).

Schicht 3: Domänenebene. Ein einzelner Score für eine Datendomäne wie "Payments" oder "Customer". Das ist, was auf dem Executive-Dashboard erscheint.

Eine einfache Domänen-Aggregation

Nehmen Sie die sechs Pass Rates oben und gewichten Sie sie zur Vereinfachung gleich:

Domain score = (98.8 + 99.55 + 96.9 + 99.2 + 99.4 + 99.75) / 6
             = 593.6 / 6
             = 98.93%

Die Domäne Payments erreicht 98,93 %, nach unseren Schwellenwerten gelb. Beachten Sie, wie die schwache Dimension Genauigkeit (96,9 %) die ganze Domäne unter grün zieht. Echte Banken gewichten kritische Regeln stärker, sodass eine gerissene sanktionsrelevante Regel den Score härter nach unten zieht als ein gleichgewichteter Durchschnitt.

🎬 [VIDEO: "Data Quality Dimensions Explained" - youtube.com - ein klarer 10-minütiger Durchgang durch die sechs Dimensionen mit Rechenbeispielen]

Was der CDO tatsächlich berichtet

Boards wollen keine 300 Regeln. Sie wollen:

1. Domänen-Scores mit RAG-Status und Trend gegenüber dem letzten Quartal.
2. Die wichtigsten gerissenen Regeln, die den roten Status treiben.
3. Status der Behebung: was wird bis wann repariert.
4. Regulatorische Exponierung: welche Fehler BCBS-239-Meldungen betreffen.

Die Scorecard ist ein Governance-Instrument. Sie schafft Verantwortlichkeit, indem sie für jede Domäne einen Data Owner benennt, üblicherweise eine leitende Person aus dem Business, nicht aus der IT. Wenn Payments auf rot geht, antwortet eine namentlich benannte Führungskraft dafür.

Typische Messfallen

Risiko wegmitteln. Ein Domänen-Score von 98,9 % kann ein Sanktionsfeld bei 92 % verdecken. Zeigen Sie Fehler in kritischen Feldern immer separat.

Falscher Nenner. Wenn Sie IBAN-Vollständigkeit nur auf Datensätzen messen, in denen das Feld übermittelt wurde, verpassen Sie die, die vorgelagert verloren gingen. Messen Sie gegen die vollständige erwartete Population.

Regeln ohne Owner. Eine gerissene Regel, für die niemand verantwortlich ist, bleibt für immer rot. Jede Regel braucht einen Business Owner und einen Behebungsweg.

Statische Schwellenwerte. Wenn regulatorische Erwartungen steigen, wird das Grün von gestern zum Gelb von heute. Prüfen Sie Schwellenwerte mindestens jährlich.

Wichtigste Erkenntnisse

• Die sechs DQ-Dimensionen (Vollständigkeit, Genauigkeit, Gültigkeit, Konsistenz, Eindeutigkeit, Aktualität) werden erst messbar, wenn sie in testbare Regeln mit klarem Nenner übersetzt werden.
• Pass Rate = (Gesamtzahl der Datensätze minus fehlerhafte Datensätze) / Gesamtzahl der Datensätze. Jede Zelle einer Scorecard lässt sich auf diesen Bruch zurückführen.
• Gültigkeitsprüfungen wie die IBAN-Mod-97-Prüfsumme lassen sich günstig automatisieren; Genauigkeit braucht eine vertrauenswürdige golden source und ist am schwersten und teuersten zu beheben.
• Setzen Sie RAG-Schwellenwerte pro Regel, strenger für sanktions- und regulatorisch relevante Felder, und lassen Sie nie zu, dass ein hoher Domänendurchschnitt einen Fehler in einem kritischen Feld verdeckt.
• BCBS 239 macht messbare Datenqualität zu einer aufsichtlichen Erwartung, weshalb Scorecards mit namentlich benannten Data Ownern Governance-Werkzeuge sind, nicht bloß Dashboards.