+150 XP

Referenz- und Stammdaten: der Golden Record für Kunden und Produkte

# Referenz- und Stammdaten: der Golden Record für Kunden und Produkte

Eine große Bank stellte einmal fest, dass ein einzelner Firmenkunde, ein global tätiger Hersteller, 47 Mal in ihren Systemen existierte. Verschiedene Schreibweisen, verschiedene Tochtergesellschaften, verschiedene Trading Desks, alle als separate Kunden behandelt. Als das Risikoteam eine einfache Frage beantworten wollte, „Wie hoch ist unser Gesamtexposure gegenüber dieser Gruppe?“, lag die Zahl um Milliarden daneben. Nicht wegen Betrug oder Rechenfehlern, sondern weil die Bank keine einzige, vertrauenswürdige Version davon hatte, wer der Kunde überhaupt war.

Genau dieses Problem löst Master Data Management.

Was „Referenzdaten“ und „Stammdaten“ tatsächlich bedeuten

Diese beiden Begriffe werden ständig verwechselt, deshalb halten wir sie kurz fest.

Referenzdaten sind das gemeinsame Vokabular. Es sind die sich langsam ändernden Nachschlagelisten, auf die sich alle verständigt haben: Währungscodes (USD, EUR), Ländercodes (ISO 3166), Produktartcodes, Filialcodes. Referenzdaten sind in der Regel extern oder standardisiert.

Stammdaten sind die zentralen Geschäftsobjekte, mit denen die Bank arbeitet: Kunden, Counterparties, Produkte, Konten, Rechtseinheiten. Sie sind die „Substantive“ des Geschäfts.

Transaktionsdaten sind im Gegensatz dazu die „Verben“: eine Überweisung, ein Trade, eine Kreditziehung. Jede Transaktion verweist zurück auf Stammdaten („diese Zahlung, von diesem Kunden, in dieser Währung“).

Sind die Stammdaten falsch, erbt jede Transaktion, die darauf verweist, den Fehler.

Der Golden Record

Der Golden Record ist die einzige, abgeglichene, verbindliche Version eines Stammdatenobjekts. Ein Kunde, ein Datensatz, eine Wahrheit, zusammengesetzt aus vielen Quellsystemen.

Banken sind unordentlich, weil sie durch Akquisitionen und Produktsilos gewachsen sind. Ein Privatkunde kann existieren in:

  • dem Kernbankensystem (Giro- und Sparkonten)
  • der Plattform für Hypothekenvergabe
  • dem Kreditkartensystem
  • dem Wealth-Management-Buch
  • dem CRM-Tool (Customer Relationship Management), das die Filiale nutzt

Jedes System hat seine eigene Kunden-ID vergeben. Der Golden Record verknüpft sie.

Die Identifikatoren, die ihn verankern

Bei Privatkunden kommt der Anker aus dem KYC (Know Your Customer, der regulatorische Prozess der Identitätsprüfung zur Verhinderung von Geldwäsche). KYC erfasst einen verifizierten Namen, Geburtsdatum, Adresse und eine staatliche Kennung (eine Social Security Number in den USA, einen Personalausweis oder Pass in Europa).

Bei Firmenkunden und institutionellen Counterparties ist der Goldstandard der LEI (Legal Entity Identifier). Das ist ein 20-stelliger Code, der eine Rechtseinheit weltweit eindeutig identifiziert. Er wurde nach der Krise 2008 geschaffen, genau weil Regulatoren die Frage „Wer ist gegenüber Lehman Brothers exponiert?“ nicht schnell genug beantworten konnten.

Die Abfrage des LEI ist kostenlos. Sie können jede Einheit in der Datenbank der Global LEI Foundation (GLEIF) suchen.

Hierarchien von Rechtseinheiten

Der LEI leistet mehr, als eine einzelne Einheit zu identifizieren. GLEIF erfasst die Mutter-Tochter-Beziehungen zwischen Einheiten: welche Tochtergesellschaft zu welchem obersten Mutterunternehmen gehört. Das ist die Hierarchie, die es der Bank aus unserer Eingangsgeschichte schließlich erlaubte, das Exposure korrekt zu aggregieren.

Beispielstruktur:

Ultimate Parent (LEI: 5493...)
 ├── Regional Holding EU (LEI: 2138...)
 │     ├── Trading Subsidiary FR (LEI: 9695...)
 │     └── Lending Subsidiary DE (LEI: 8945...)
 └── Regional Holding US (LEI: 5493...)
       └── Broker-Dealer US (LEI: 2540...)

Wenn Sie der Trading Subsidiary FR Kredit gewähren, muss Ihr Exposure gegenüber dem Ultimate Parent über diesen Baum aufsummiert werden. Stimmt die Hierarchie nicht, verletzen Sie Konzentrationslimits, ohne es zu merken.

Produkt- und Counterparty-Master

Die gleiche Disziplin gilt über Kunden hinaus.

Der Produktkatalog (oder Produktmaster) definiert jedes Produkt, das die Bank verkauft: jeden Einlagenkontotyp, jeden Kredit, jedes Derivat. Ein einziger falsch gekennzeichneter Produktcode kann eine Transaktion auf das falsche Hauptbuchkonto leiten und damit regulatorische Meldungen verfälschen.

Der Counterparty-Master ist die institutionelle Variante des Kundenmasters und wird stark im Kapitalmarktgeschäft genutzt. Er versorgt Kreditrisiko, Collateral Management und Settlement. Wenn zwei Desks jeweils ihre eigene Counterparty-ID für dieselbe Bank pflegen, brechen Netting-Berechnungen (die Verrechnung dessen, was Sie schulden, mit dem, was Ihnen geschuldet wird).

Wie Datensätze abgeglichen werden: Matching und Survivorship

Einen Golden Record aufzubauen ist ein zweistufiges Datenproblem.

Schritt 1: Matching (Entity Resolution). Entscheiden, welche Datensätze sich auf dieselbe real existierende Einheit beziehen. Das ist selten ein sauberer Join. „J. Smith, 12 Oak St“ und „John Smith, 12 Oak Street“ sind wahrscheinlich dieselbe Person. Matching-Engines nutzen deterministische Regeln (exakte Übereinstimmung der nationalen Kennung) plus probabilistisches Scoring (fuzzy Name, Adresse, Geburtsdatum).

Schritt 2: Survivorship. Wenn Sie gematchte Datensätze zusammenführen, welcher Wert gewinnt? Wenn das CRM eine Telefonnummer nennt und das Hypothekensystem eine andere, wählen Survivorship-Regeln die vertrauenswürdige Quelle oder den aktuellsten verifizierten Wert.

Ein einfaches Matching-Beispiel:

Record A: name="ACME CORP",     LEI=null,      country=US
Record B: name="Acme Corp Inc", LEI=5493001..., country=US
Record C: name="ACME CORPORATION", LEI=5493001..., country=US

Match score B vs C: LEI exact match  -> score 1.00 -> MERGE
Match score A vs B: name fuzzy 0.82, country match 1.0
                    weighted score 0.71 -> REVIEW (below 0.85 auto-merge threshold)

Die Datensätze B und C werden automatisch über den LEI zusammengeführt. Datensatz A geht zur Prüfung an einen menschlichen Steward, weil ihm der starke Identifikator fehlt.

Die Metriken, die für Ehrlichkeit sorgen

Stammdatenqualität wird gemessen, nicht angenommen. Die zentralen Dimensionen:

  • Eindeutigkeit: die Duplikatsrate. Prozentsatz der Einheiten, die tatsächlich dasselbe real existierende Objekt sind. Als Zielwert für einen ausgereiften Kundenmaster werden häufig unter 1 bis 2 Prozent Duplikate genannt (Branchenschätzung, stark schwankend).
  • Vollständigkeit: Prozentsatz der Datensätze, in denen alle Pflichtfelder gefüllt sind (zum Beispiel muss jede Firmen-Counterparty einen LEI haben).
  • Genauigkeit: Prozentsatz der Datensätze, die mit einer vertrauenswürdigen Source of Truth übereinstimmen.
  • Aktualität: wie frisch die Daten sind, zum Beispiel Tage seit der letzten KYC-Aktualisierung.
  • Konsistenz: ob dieselbe Einheit systemübergreifend dieselben Werte trägt.

Eine einfache Berechnung der Vollständigkeit:

Counterparties requiring an LEI:        50,000
Counterparties with a valid LEI:        47,300
LEI completeness = 47,300 / 50,000 = 94.6%

Wenn ein Regulator 100 Prozent LEI-Abdeckung für meldepflichtige Derivate verlangt, ist diese Lücke von 5,4 Prozent ein Compliance-Befund.

🎬 [VIDEO: „What is Master Data Management (MDM)?“ - youtube.com - ein klarer, 6-minütiger konzeptioneller Überblick über MDM und Golden Records]

Governance: wem gehört die Wahrheit

Metriken brauchen Verantwortliche. Hier kommt Data Governance ins Spiel.

Ein Data Steward ist die Person, die für die Qualität einer Datendomäne verantwortlich ist (etwa des Kundenmasters). Ein Data Owner ist typischerweise eine Führungskraft aus dem Business, die Definitionen und Zugriffe freigibt. Gemeinsam setzen sie die Regeln durch: was einen gültigen Datensatz ausmacht, welches System die verbindliche Quelle für welches Feld ist und wer Datensätze anlegen oder zusammenführen darf.

In Europa überschneidet sich Stammdaten-Governance direkt mit der DSGVO (Datenschutz-Grundverordnung), die Personen Rechte über ihre personenbezogenen Daten einräumt. Sie können ein Löschverlangen („Recht auf Vergessenwerden“) nicht erfüllen, wenn Sie nicht alle 47 Stellen kennen, an denen ein Kunde in Ihren Systemen existiert. Der Golden Record ist das, was DSGVO-Compliance operativ überhaupt möglich macht.

In den USA drängen die Prinzipien von BCBS 239 (herausgegeben vom Basler Ausschuss für Bankenaufsicht, zur Aggregation von Risikodaten) große Banken dazu, nachzuweisen, dass sie Risikodaten genau und schnell aggregieren können. Das ist ohne saubere Stammdaten unmöglich.

Wissenscheck

1. Eine Bank stellt fest, dass ihr Gesamt-Risikoexposure gegenüber einer Unternehmensgruppe um Milliarden falsch ist, obwohl weder Betrug noch Rechenfehler vorliegen. Welches zugrunde liegende Datenproblem hat das am wahrscheinlichsten verursacht?

2. Welche Aussage erfasst den Unterschied zwischen Referenzdaten und Stammdaten am besten?

3. Warum hat ein Fehler in den Stammdaten einer Bank besonders weitreichende Folgen?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE korrekten Antworten zum Golden Record.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Antworten, die Datentypen in einer Bank korrekt einordnen.

Wählen Sie alle richtigen Antworten aus.

Warum eine einzige doppelte ID im Stillen alles verfälscht

Zurück zur Eingangsszene. Hier ist die Schadenskette einer einzigen doppelten Kunden-ID:

1. Die Risikoaggregation untertreibt das Exposure. Zwei IDs für einen Kunden bedeuten, dass Limits unverletzt aussehen, obwohl sie verletzt sind.

2. Regulatorische Meldungen sind falsch. Die Großkreditmeldung an Regulatoren summiert pro Counterparty. Duplikate zersplittern die Gesamtsumme.

3. Das AML-Monitoring übersieht Muster. Die Anti-Money-Laundering-Überwachung betrachtet das Verhalten pro Kunde. Teilen Sie einen Kunden in zwei, fallen verdächtige Muster unter die Alarmschwellen.

4. Die Customer Experience leidet. Der Kunde wird zweimal nach KYC-Dokumenten gefragt, erhält doppelte Postsendungen und sieht inkonsistente Salden.

5. Die Analytics lügen. Jede Metrik „Anzahl Kunden“, jedes Cross-Sell-Modell, jede Churn-Prognose baut auf überhöhten, zersplitterten Zählungen auf.

Das Heimtückische daran: Nichts davon wirft einen Fehler. Die Systeme laufen einwandfrei. Die Zahlen sind einfach still und leise falsch, und niemand merkt es, bis ein Regulator oder eine Krise die Frage erzwingt.

Wichtigste Erkenntnisse

  • Der Golden Record ist eine abgeglichene, verbindliche Version eines Stammdatenobjekts, zusammengesetzt aus vielen Silosystemen. Er ist die Grundlage, von der alles Nachgelagerte abhängt.
  • LEIs (aus der kostenlosen GLEIF-Datenbank) verankern die Identität von Unternehmen und kodieren Hierarchien von Rechtseinheiten, die für eine korrekte Exposure-Aggregation unverzichtbar sind.
  • Golden Records aufzubauen ist ein zweistufiges Datenproblem: Matching (Entity Resolution) und Survivorship (welcher Wert gewinnt).
  • Messen Sie Stammdaten anhand von Eindeutigkeit, Vollständigkeit, Genauigkeit, Aktualität und Konsistenz und benennen Sie für jede Domäne einen verantwortlichen Data Steward.
  • Eine doppelte Kunden-ID erzeugt keine Fehlermeldung, verfälscht aber stillschweigend Risikoaggregation, regulatorisches Reporting, AML-Überwachung und jede darauf aufbauende Analytics-Zahl.