In vielen Banken ist der Begriff des Kunden in jedem System separat definiert. Das Core-Banking-System hat eine Kundennummer, das Kartensystem eine andere, das Kreditsystem eine dritte und die digitalen Kanäle eine vierte. Eine einzelne Person kann in drei Systemen mit drei Schreibweisen ihres Namens, zwei veralteten Adressen und einer Telefonnummer erfasst sein, unter der niemand mehr erreichbar ist. Solange jedes System isoliert arbeitet, bleibt diese Fragmentierung verborgen. Sobald die Bank eine einheitliche Sicht, eine Risikoanalyse oder einen personalisierten Service anbieten will, tritt das Problem zutage.
Die Bedeutung reicht weit über Datenhygiene hinaus. Den Kunden richtig zu kennen, ist die Grundlage für Pflichten zur Kundenidentifizierung, das Kreditrisikomanagement, die Betrugsprävention und sogar eine ehrliche Berechnung der Rentabilität. Kann die Bank nicht sagen, dass drei Konten, zwei Karten und ein Kredit derselben Person gehören, kann sie weder deren Gesamtengagement messen noch ein stimmiges Erlebnis über Filiale und App hinweg bieten. Juristische Personen und die Beziehungen zwischen ihnen, etwa Beteiligungen, Vertretungen und Bürgschaften, fügen eine weitere Ebene hinzu, die eine flache Kundentabelle schlicht nicht abbilden kann.
Die architektonische Antwort ist eine einzige verlässliche Quelle für den Partner, in der Fachliteratur als Party Master Data bezeichnet. In diesem Modell fallen natürliche Personen, juristische Personen und sogar Zwischenrollen wie Bevollmächtigte oder Begünstigte unter den allgemeinen Begriff des Partners, und die Beziehungen zwischen ihnen werden explizit gespeichert. Das Stammdatensystem hält die goldene Identität jedes Partners, bildet die lokalen Kennungen aller anderen Systeme darauf ab und veröffentlicht Änderungen über APIs und Events an alle Konsumenten. Operative Systeme behalten ihre eigenen Daten, sind aber nicht mehr die maßgebliche Quelle.
Die erste praktische Überlegung betrifft die Regeln für Abgleich und Zusammenführung. Die Entscheidung, dass zwei Datensätze zur selben Person gehören, verbindet deterministische Regeln wie eine nationale Identifikationsnummer oder Registernummer mit probabilistischen wie der Ähnlichkeit von Name und Geburtsdatum. Diese Regeln müssen transparent, justierbar und überprüfbar sein, denn jede falsche Zusammenführung kann die Konten zweier Personen miteinander verknüpfen. Haben beispielsweise zwei Datensätze einen ähnlichen Namen und dasselbe Geburtsdatum, aber unterschiedliche Adressen, sollte das System sie zur menschlichen Prüfung markieren, statt sie automatisch zusammenzuführen.
Die zweite Überlegung betrifft die Modellierung von Beziehungen. Im Firmenkundengeschäft entsteht der eigentliche Wert aus dem Verständnis des Netzwerks: Welche Unternehmen gehören zu einer Holding, wer hat Zeichnungsbefugnis, welche Person bürgt für welchen Kredit? Diese Beziehungen brauchen einen Typ, ein Anfangs- und Enddatum und eine erfasste Quelle, damit sie sowohl abgefragt als auch geprüft werden können. Ein gutes Modell erlaubt der Bank die Frage, wie hoch das Gesamtengagement gegenüber einer bestimmten Unternehmensgruppe ist, und liefert eine einzige stimmige Antwort statt einer von Hand zusammengestückelten Tabelle.
Die üblichen Fallstricke in Projekten für Partner-Stammdaten sind erkennbar. Erstens: alle Systeme auf einmal migrieren zu wollen, was das Projekt zu einem mehrjährigen Programm ohne Zwischenergebnisse macht. Zweitens: die Datenverantwortung zu vernachlässigen; ist keine Geschäftseinheit für die Qualität jedes Attributs verantwortlich, sind die Stammdaten binnen Monaten wieder verunreinigt. Drittens: das Stammdatensystem ohne APIs und Events aufzubauen, sodass andere Systeme ihre Daten am Ende über nächtliche Dateien erhalten. Viertens: die Historie zu ignorieren; eine Bank muss rekonstruieren können, was sie zu einem bestimmten Datum in der Vergangenheit über einen Partner wusste.
Die Plattform Ashna von Niadad ist genau für diese Rolle konzipiert: einheitliche Verwaltung natürlicher und juristischer Personen, ihrer Beziehungen untereinander, konfigurierbare Abgleichsregeln und Veröffentlichung von Änderungen über APIs und Events. Im Banking-Programm von Niadad fungiert Ashna als Partner-Stammdatensystem neben der Identitätsschicht und dem API-Gateway, sodass operative Systeme, digitale Kanäle und Analytik alle mit einer gemeinsamen Definition dessen arbeiten, wer der Kunde ist.
Partner-Stammdaten sind nicht das glanzvollste Projekt, das eine Bank angehen kann, aber die Voraussetzung für fast jedes glanzvolle. Ohne sie lernt KI mit falschen Daten, die 360-Grad-Kundensicht bleibt unvollständig, und das Risikomanagement stützt sich auf Vermutungen. Mit ihnen startet jedes weitere Projekt auf festem Grund. Je früher eine Bank Partnerdaten als gemeinsame Infrastruktur statt als Angelegenheit einer Abteilung begreift, desto früher wird der Rest ihrer Roadmap erreichbar.