+150 XP

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

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

Eine Überweisung kommt mit leerem IBAN-Feld herein. Diese einzige 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 Vorstand präsentiert. Datenqualität im Banking ist nichts Abstraktes. Sie ist der Unterschied zwischen einer Zahlung, die durchläuft, und einer, die auf einem Zwischenkonto liegen bleibt.

Diese Lektion zeigt Ihnen, wie Sie Datenqualität anhand von sechs Standarddimensionen messen, sie auf echte Zahlungsdatensätze anwenden und die Ergebnisse zu den Pass-Rate-Scorecards zusammenführen, die Aufsicht und Vorstand erwarten.

Warum Datenqualität ein Thema für den Vorstand ist

Banken arbeiten mit Daten, die nicht immer sauber erhoben wurden. Ein Kunde, der 2009 onboarded wurde, kann einen Datensatz haben, in dem Felder fehlen, 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). Sie verlangen von großen Banken, Accuracy, Completeness und Timeliness der Daten hinter ihren Risikoberichten nachzuweisen. Die Aufsichtsbehörden in der EU (Europäische Zentralbank) und in den USA (Federal Reserve, OCC) prüfen die Einhaltung aktiv. Die Originalprinzipien können Sie kostenlos bei der Bank for International Settlements lesen.

Die praktische Konsequenz: Banken müssen Qualität *messen*, nicht behaupten. Das heißt: 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. Completeness (Vollständigkeit)

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 Completeness durch.

2. Accuracy (Richtigkeit)

Entsprechen die Daten der Realität?

Beispiel: Ein Kontrahentenname lautet "Acme Trading Ltd", die eingetragene Rechtseinheit ist aber "Acme Trading GmbH". Das Feld ist vollständig, aber unrichtig. Accuracy ist am schwersten zu messen, weil sie eine vertrauenswürdige Referenz braucht (eine "Golden Source"), etwa ein validiertes LEI-Register (Legal Entity Identifier).

3. Validity (Konformität)

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. Schlägt die Prüfsumme fehl, ist der Wert ungültig, auch wenn das Feld gefüllt ist.

4. Consistency (Konsistenz)

Stimmt derselbe Sachverhalt systemübergreifend überein?

Beispiel: Das Wohnsitzland des Kunden ist im Kernbankensystem "FR", im AML-Screening-Tool (Anti-Money Laundering) ausgeschrieben "France" und im CRM "DE". Derselbe Kunde, drei Antworten.

5. Uniqueness (Eindeutigkeit)

Ist jede real existierende Entität genau einmal abgebildet?

Beispiel: Derselbe Firmenkunde erscheint als drei separate Datensätze, wegen einer Fusion und zweier Schreibvarianten. Doppelte Kontrahenten verzerren die Exposure-Berechnung.

6. Timeliness (Aktualität)

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 "Completeness" nicht messen; Sie messen "Prozentsatz der Zahlungsdatensätze, bei denen IBAN nicht null ist".

Wenden wir das auf ein Payments-Dataset an. Angenommen ein Batch von 100.000 ausgehenden SEPA-Zahlungen (illustrative Zahlen für ein Rechenbeispiel, keine echten Bankdaten).

| Dimension | Regel | Fehlerhafte Datensätze | Pass Rate |

|---|---|---|---|

| Completeness | IBAN gefüllt | 1.200 | 98,8 % |

| Validity | IBAN besteht Prüfsumme | 450 | 99,55 % |

| Accuracy | Kontrahentenname stimmt mit LEI-Register überein | 3.100 | 96,9 % |

| Consistency | Ländercode stimmt zwischen Kernsystem und AML überein | 800 | 99,2 % |

| Uniqueness | Keine doppelte Kontrahenten-ID | 600 | 99,4 % |

| Timeliness | Datensatz innerhalb des SLA-Fensters eingelesen | 250 | 99,75 % |

Durchgerechnetes Beispiel

Completeness Pass Rate für 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 Vorstand sieht, geht auf einen solchen Bruch zurück.

Die IBAN-Prüfsumme: eine Validity-Regel in Code

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

python
def is_valid_iban(iban):
    iban = iban.replace(" ", "").upper()
    # Die ersten 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 Validity direkt. Keine manuelle Prüfung nötig. Deshalb sind Validity-Regeln meist die günstigsten Qualitätsgewinne.

Schwellenwerte setzen: was als Pass gilt

Eine Pass Rate bedeutet ohne Schwellenwert nichts. Banken setzen DQ-Thresholds pro Regel, oft auf Basis von Rot / Gelb / Grün (RAG). Ein verbreitetes (illustratives) Muster:

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

Kritische Felder bekommen strengere Schwellenwerte. Ein sanktionsrelevantes Feld wie der Kontrahentenname verlangt Grün möglicherweise erst bei 99,9 %, weil ein einziger verpasster Treffer einen Regulierungsverstoß bedeuten kann. Ein Feld zur Marketing-Präferenz kann Gelb verkraften.

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

Wissenscheck

1. Warum argumentiert die Lektion, dass Datenqualität im Banking gemessen und nicht einfach behauptet werden muss?

2. Eine Überweisung kommt mit leerem IBAN-Feld herein. Welche Datenqualitätsdimension wird dadurch am direktesten verletzt?

3. Warum ist ein 2009 onboardeter Kundendatensatz ein nützliches Beispiel für eine Datenqualitätsherausforderung?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE korrekten Antworten zur Rolle von DQ-Scorecards und Dimensionen im Banking.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE korrekten Antworten, warum Datenqualität im Banking als Vorstandsthema behandelt wird.

Wählen Sie alle richtigen Antworten aus.

Die DQ-Scorecard aufbauen

Eine Scorecard aggregiert Ergebnisse auf Regelebene zu etwas, das ein Vorstand in 30 Sekunden erfassen kann. Üblicherweise wird in drei Schichten verdichtet.

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

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

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

Ein einfacher Domänen-Rollup

Nehmen Sie die sechs Pass Rates von oben und gewichten Sie sie der Einfachheit halber 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 %, was nach unseren Schwellenwerten Gelb ist. Beachten Sie, wie die schwache Accuracy-Dimension (96,9 %) die gesamte Domäne unter Grün zieht. Echte Banken gewichten kritische Regeln stärker, sodass eine fehlgeschlagene 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 der sechs Dimensionen mit Rechenbeispielen]

Was der CDO tatsächlich berichtet

Vorstände wollen keine 300 Regeln. Sie wollen:

1. Domänen-Scores mit RAG-Status und Trend gegenüber dem Vorquartal.

2. Die wichtigsten fehlgeschlagenen Regeln, die den roten Status treiben.

3. Remediation-Status: was wird behoben und bis wann.

4. Regulatorische Exposure: 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 Führungskraft aus dem Business, nicht aus der IT. Wenn Payments rot wird, muss eine namentlich benannte Führungskraft dafür einstehen.

Typische Messfallen

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

Falscher Nenner. Wenn Sie IBAN-Completeness nur an 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 fehlgeschlagene Regel, für die niemand verantwortlich ist, bleibt für immer rot. Jede Regel braucht einen Business Owner und einen Remediation-Pfad.

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

Die wichtigsten Punkte

  • Die sechs DQ-Dimensionen (Completeness, Accuracy, Validity, Consistency, Uniqueness, Timeliness) werden erst messbar, wenn sie in testbare Regeln mit klarem Nenner übersetzt werden.
  • Pass Rate = (Gesamtzahl Datensätze minus fehlerhafte Datensätze) / Gesamtzahl Datensätze. Jede Scorecard-Zelle lässt sich auf diesen Bruch reduzieren.
  • Validity-Prüfungen wie die IBAN-Mod-97-Prüfsumme lassen sich günstig automatisieren; Accuracy 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 regulierungsrelevante Felder, und lassen Sie niemals einen hohen Domänendurchschnitt einen Fehler in einem kritischen Feld verdecken.
  • BCBS 239 macht messbare Datenqualität zu einer aufsichtlichen Erwartung, weshalb Scorecards mit benannten Data Ownern Governance-Werkzeuge sind und nicht bloß Dashboards.