Banken · 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 ManagementMaster Data ManagementMaster Data Management (MDM) ist die Disziplin, eine einzige, konsistente und verlässliche Version der zentralen Geschäftsobjekte eines Unternehmens zu erstellen und zu pflegen: Kunden, Produkte, Lieferanten.Vollständige Definition ansehen →.
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 CRMCRMCustomer Relationship Management: Software und Strategie, um Kundeninteraktionen über den gesamten Lifecycle zu steuern und zu analysieren.Vollständige Definition ansehen →-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. ErErDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → 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 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 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 GovernanceData GovernanceData Governance umfasst die Regeln, Rollen und Prozesse, die sicherstellen, dass Daten in einer Organisation korrekt, sicher, klar definiert und verantwortungsvoll genutzt werden.Vollständige Definition ansehen → ins Spiel.
Ein Data StewardData StewardEin Verantwortlicher auf Fachseite, der für Qualität, Konsistenz und sachgerechte Nutzung der Daten in seiner Domäne zuständig ist.Vollständige Definition ansehen → 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 DSGVODSGVOEU-Verordnung zur Erhebung, Speicherung und Nutzung personenbezogener Daten, mit Bußgeldern, die am weltweiten Umsatz bemessen werden.Vollständige Definition ansehen → (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?
4. Wählen Sie ALLE korrekten Antworten zum Golden Record.
Wählen Sie alle richtigen Antworten aus.
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:
- Die Risikoaggregation untertreibt das Exposure. Zwei IDs für einen Kunden bedeuten, dass Limits unverletzt aussehen, obwohl sie verletzt sind.
- Regulatorische Meldungen sind falsch. Die Großkreditmeldung an Regulatoren summiert pro Counterparty. Duplikate zersplittern die Gesamtsumme.
- 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.
- Die Customer Experience leidet. Der Kunde wird zweimal nach KYC-Dokumenten gefragt, erhält doppelte Postsendungen und sieht inkonsistente Salden.
- 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.
Häufige Fragen
Was ist der Unterschied zwischen Referenzdaten und Stammdaten in einer Bank?
Referenzdaten sind das gemeinsame Vokabular aus sich langsam ändernden Nachschlagelisten, auf die sich alle einigen: Währungscodes, ISO-Ländercodes, Filialcodes, Produkttypcodes. Stammdaten sind die zentralen Geschäftsobjekte, mit denen die Bank arbeitet: Kunden, Kontrahenten, Produkte, Konten, juristische Personen. Transaktionsdaten (eine Überweisung, ein Trade, eine Kreditziehung) bilden eine dritte Kategorie, die auf die Stammdaten verweist. Jeder Fehler in den Stammdaten zieht sich deshalb durch jede Transaktion, die auf sie verweist.
Was ist ein Golden Record und warum tun sich Banken so schwer damit, einen aufzubauen?
Ein Golden Record ist die einzige abgeglichene, maßgebliche Version eines Stammdatenobjekts, also ein Kunde, der aus vielen Quellsystemen zusammengeführt wird. Banken tun sich schwer, weil sie durch Übernahmen und in Produktsilos gewachsen sind: Derselbe Privatkunde kann im Kernbankensystem, in der Plattform für die Baufinanzierung, im Kartensystem, im Wealth-Bestand und im CRM der Filiale existieren, jeweils mit eigener Kunden-ID. Der Golden Record verknüpft diese IDs wieder mit einer realen Person oder einem realen Unternehmen.
Was ist ein LEI und wo kann ich ihn kostenlos nachschlagen?
Der LEI (Legal Entity Identifier) ist ein 20-stelliger Code, der eine juristische Person weltweit eindeutig identifiziert. Er wurde nach der Krise von 2008 eingeführt, weil die Aufsichtsbehörden nicht schnell genug beantworten konnten, wer gegenüber Lehman Brothers exponiert war. Die Abfrage ist kostenlos in der GLEIF-Datenbank (Global LEI Foundation) unter gleif.org.
Wie funktionieren Matching- und Survivorship-Regeln beim Zusammenführen doppelter Kundendatensätze?
Das Matching (Entity Resolution) entscheidet, welche Datensätze sich auf dasselbe reale Objekt beziehen. Dafür werden deterministische Regeln genutzt, etwa eine exakte Übereinstimmung bei einer nationalen Identifikationsnummer oder einem LEI, dazu ein probabilistisches Scoring auf unscharfe Übereinstimmungen bei Name, Adresse und Geburtsdatum. Survivorship legt danach fest, welcher Wert gewinnt, wenn zusammengehörige Datensätze verschmolzen werden: in der Regel das vertrauenswürdige Quellsystem oder der zuletzt verifizierte Wert. Datensätze oberhalb einer Schwelle für das automatische Zusammenführen (oft bei etwa 0,85 angesetzt) werden automatisch verschmolzen, schwächere Scores gehen zur Prüfung an einen Data Steward.
Welche Kennzahlen sollte ich verfolgen, um die Qualität von Stammdaten zu messen?
Fünf Dimensionen: Eindeutigkeit (die Dublettenquote), Vollständigkeit (Anteil der Datensätze mit allen Pflichtfeldern, zum Beispiel ein LEI bei jedem Firmenkontrahenten), Richtigkeit (Abgleich mit einer vertrauenswürdigen Quelle), Aktualität (zum Beispiel Tage seit der letzten KYC-Aktualisierung) und Konsistenz über die Systeme hinweg. Die Vollständigkeit lässt sich am einfachsten berechnen: 47.300 gültige LEIs bei 50.000 Kontrahenten, die einen benötigen, ergeben 94,6 Prozent. Verlangt eine Aufsichtsbehörde eine vollständige LEI-Abdeckung für meldepflichtige Derivate, ist die verbleibende Lücke ein Compliance-Befund.
Was geht tatsächlich kaputt, wenn derselbe Bankkunde unter zwei IDs existiert?
Fünf Dinge, und keines davon erzeugt eine Fehlermeldung. Die Risikoaggregation unterschätzt das Exposure, weil Limits als eingehalten erscheinen, obwohl sie überschritten sind. Aufsichtsrechtliche Meldungen zu Großkrediten zersplittern die Gesamtsumme pro Kontrahent. Die AML-Überwachung verteilt das Verhalten auf zwei Profile, sodass verdächtige Muster unter den Alarmschwellen bleiben. Der Kunde wird zweimal nach KYC-Unterlagen gefragt und sieht widersprüchliche Salden. Und jede Analytics-Zahl, die auf Kundenzahlen, Cross-Selling oder churn aufbaut, ist überhöht. Die Systeme laufen ganz normal weiter, deshalb merkt es niemand, bis eine Aufsichtsbehörde oder eine Krise die Frage erzwingt.