Ein finanzierbarer Customer-Master-Business-Case für kleinere Banken

Kurzfassung: Finanzieren Sie eine Folge begrenzter Entscheidungen statt des Versprechens eines perfekten Kundenstamms. Vier Anwendungen teilen eine gesteuerte Identitätsgrenze, erhalten aber eigene Schwellenwerte und Kontrollen. Erheben Sie Ausgangskosten, testen Sie beschriftete Bankdaten und geben Sie weitere Mittel erst nach belegter Qualität, Betriebsfähigkeit und einem sicheren Stop-Pfad frei.

Demo buchen oder Tilores Studio kostenlos testen.

Auf dieser Seite

1. Was sollte der Finanzierungsausschuss freigeben?
2. Welche vier Anwendungen gehören in den Business Case?
3. Wie sollte die Finanzierung gestuft sein?
4. Welche Kennzahlen machen den Fall glaubwürdig?
5. Wie formt Governance den Business Case?
6. Welche Architektur hält den Umfang unter Kontrolle?
7. Wie sollte die Bank Eigenbau und Zukauf vergleichen?
8. Was gehört in die Vorlage für den Ausschuss?
9. Häufige Fragen

Ein kleineres Institut braucht keinen Antrag auf den perfekten Kundendatensatz für die gesamte Bank. Es braucht eine finanzierbare Folge begrenzter Entscheidungen. Die erste Freigabe sollte klären, ob eine gemeinsame Identitätsschicht bekannte Kosten und Risiken in wenigen Arbeitsabläufen senken kann, ohne Quellsystemen oder bestehenden Kontrollteams ihre Verantwortung zu nehmen.

Das ist mehr als eine Frage der Technik. Ein breit formulierter Customer-Master-Auftrag sammelt schnell jedes Datenqualitätsproblem, jeden Integrationswunsch und jede Reporting-Abhängigkeit. Er wird zu groß für eine belastbare Kostenschätzung und zu ungenau für eine Erfolgsmessung. Ein guter Business Case beginnt mit einer konkreten Identitätsfrage, repräsentativen Datensätzen und einem beobachtbaren Ergebnis in einem bestehenden Arbeitsablauf.

Was sollte der Finanzierungsausschuss freigeben?

Benennen Sie eine verantwortliche Führungskraft, eine fachliche Leitung, eine technische Leitung und eine Kontrollverantwortung. Definieren Sie Kundenpopulation, beteiligte Quellen und die erste Entscheidung, die eine aufgelöste Identität unterstützt. Schreiben Sie ebenso auf, was außerhalb der ersten Stufe bleibt. Kreditentscheidungen, Transaktionsüberwachung, Identitätsprüfung und Fallbearbeitung gehören weiter den dafür verantwortlichen Systemen und Teams.

Der Ausschuss genehmigt zunächst den Aufbau von Belegen. Er bestätigt damit weder eine endgültige Architektur noch eine ungetestete Genauigkeitszahl oder eine unumkehrbare Migration. Legen Sie Budgetspanne, Enddatum und Kriterien für die nächste Freigabe offen. So kann die Bank nach jeder Stufe anhand beobachteter Ergebnisse entscheiden, ob sie fortsetzt, nachbessert oder stoppt.

Welche vier Anwendungen gehören in den Business Case?

Die Anwendungen sollten ein gemeinsames Grundproblem haben: dieselbe Kundin oder denselben Kunden über uneinheitliche Datensätze wiederzuerkennen. Sie erzeugen aber verschiedene betriebliche Werte und verlangen nicht denselben Schwellenwert für eine Aktion.

Vier Anwendungen mit getrennten Entscheidungen und Belegen

Anwendung	Verbesserte Entscheidung	Ausgangswert	Beleg in Stufe eins
Dublettenprüfung bei Kontoeröffnung	Existiert die antragstellende Person bereits im Kundenbestand?	Suchaufwand, später gefundene Dubletten und Überweisungen an die manuelle Prüfung.	Bekannte Doppel- und Nicht-Doppelfälle vor jeder automatischen Aktion testen.
Kundenservice	Welche Akten darf eine berechtigte Person gemeinsam sehen?	Suchzeit, Übergaben und Korrekturen durch fragmentierte Datensätze.	Eine verknüpfte Sicht mit erhaltenen Quellbelegen zeigen.
Vorbereitung des Screenings	Welche Identität und Aliase gehen an bestehende Kontrollen?	Wiederholte Suche, vermeidbare Fehlalarme und manuelle Identitätszusammenstellung.	Ein konsistentes Identitätspaket an Sanktionen-, PEP- und Adverse-Media-Prozesse übergeben.
Management- und Risikoberichte	Wie werden Kundenpopulationen gezählt und abgeglichen?	Manueller Abgleich, strittige Zahlen und ungeklärte Differenzen.	Wiederholbare Zählung mit rückverfolgbaren Quellen und Matching-Belegen.

Das sind vier Nutzungen einer gesteuerten Identitätskonfiguration, nicht vier getrennte Master-Data-Plattformen. Jeder Arbeitsablauf kann dieselbe Kundenabgrenzung nutzen und trotzdem einen eigenen Konfidenzschwellenwert, eine eigene menschliche Prüfung und eigene Berechtigungen haben. Sanktionen, PEP und Adverse Media bleiben unterschiedliche kontrollierte Prozesse. Der Customer Master verbessert ihre Eingangsdaten, übernimmt aber weder Regeln noch Quellen, Entscheidungen oder Verantwortung.

Wie sollte die Finanzierung gestuft sein?

Geben Sie jeweils genug Mittel frei, um die nächste wesentliche Unsicherheit zu beantworten. Vier Stufen trennen Erkundung, technische Belege, betriebliche Belege und Erweiterung.

1. Erkundung freigeben

Bestätigen Sie die vier Anwendungen, Quellen, Eigentümer, aktuellen Prozesskosten und repräsentativen Testdatensätze. Erfassen Sie bekannte Treffer, bekannte Nicht-Treffer und schwierige Grenzfälle. Vereinbaren Sie, wie personenbezogene Daten in der Evaluation minimiert und geschützt werden.

2. Kontrollierte Evaluation freigeben

Testen Sie dieselben beschrifteten Datensätze mit dem gewählten Ansatz. Messen Sie Präzision und Recall je Anwendung getrennt. Untersuchen Sie falsch-positive und falsch-negative Ergebnisse nach Segment, Quelle und Regel. Ergebnis dieser Stufe ist ein Entscheidungspaket, keine Produktionsintegration.

3. Einen begrenzten Produktionsfall freigeben

Wählen Sie den Fall mit klarem Wert und sicherer Aktionsgrenze. Ergänzen Sie Monitoring, Zugriffsrechte, menschliche Prüfung und Rollback. Originaldatensätze und Belege jeder Verbindung bleiben erhalten, damit eine Datenverantwortliche die Entscheidung nachvollziehen und anfechten kann.

4. Erweiterung freigeben

Nehmen Sie weitere Arbeitsabläufe erst auf, wenn der erste seine Qualitäts-, Kontroll- und Betriebskosten-Grenzen erfüllt. Nutzen Sie die Identitätskonfiguration wieder, wo es sinnvoll ist, aber kalibrieren Sie Schwellenwerte neu, wenn sich die Folgen eines falschen Links ändern.

Diese Folge schützt beide Seiten. Die Bank verpflichtet sich nicht vor Kenntnis der Match-Qualität auf ein großes Programm. Das Umsetzungsteam erhält zugleich genug Umfang, um den Wert auf echten, freigegebenen Daten statt nur in einer Demonstration zu belegen.

Welche Kennzahlen machen den Fall glaubwürdig?

Der Ausschuss benötigt Ziele. Universelle, erfundene Schwellenwerte schwächen jedoch den Antrag. Messen Sie zunächst den Ausgangszustand der Bank. Kennzeichnen Sie frühe Zahlen als illustrativ, bis die Evaluation sie bestätigt.

Präzision fragt, wie viele vorgeschlagene Links korrekt sind. Recall fragt, wie viele tatsächliche Links gefunden werden. Hohe Präzision kann echte Verbindungen übersehen. Hoher Recall kann Menschen fälschlich verbinden. Das angemessene Verhältnis hängt von der folgenden Aktion ab.

Messgrößen für Freigabegrenzen

Messgröße	Warum sie zählt	Festlegung der Grenze
Präzision	Risiko der Verbindung verschiedener Personen.	Je Anwendung und Fehlerfolge anhand beschrifteter Bankdaten.
Recall	Risiko, dieselbe Person fragmentiert zu lassen.	Zusammen mit Präzision, nie als Ersatz.
Manuelle Prüfquote	Zeigt, ob Unsicherheit nur in eine Warteschlange verschoben wird.	Mit Kapazität der Datenverantwortlichen und aktuellem Fallvolumen vergleichen.
Entscheidungszeit	Verbindet technische Qualität mit Kunden- und Mitarbeitendenaufwand.	Den bisherigen Arbeitsablauf vor dem Pilot messen.
Ungeklärte Dublettenquote	Prüft eine tatsächliche Verbesserung.	Stabile Stichprobe über die Zeit beobachten.
Kosten pro geprüftem Fall	Macht Entlastung für Finanzen sichtbar.	Eigene Personal- und Plattformkosten der Bank nutzen.
Änderungsstabilität	Zeigt Qualitätsverlust nach neuen Quellen oder Regeln.	Beschrifteten Testsatz nach jeder wesentlichen Änderung erneut ausführen.

Mitteln Sie schwierige Fälle nicht weg. Brechen Sie die Ergebnisse nach Quellsystem, Qualität von Name und Adresse, Kundentyp und wirksamer Regel auf. Ein einziger Durchschnitt kann gerade das Segment verdecken, in dem die Bank die meiste Kontrolle benötigt.

Dieselbe akzeptierte Identität kann vier Arbeitsabläufe stützen. Jeder braucht eine eigene Aktionsgrenze; Unklarheit geht zuerst zur menschlichen Prüfung.

Wie formt Governance den Business Case?

Governance gehört in den Wertnachweis und nicht in einen Anhang nach der Technologiewahl. Der Basler Ausschuss beschreibt genaue, umfassende und zeitnahe Risiko-Datenaggregation als wesentlich für das Erkennen und Steuern materieller Risiken. Der Ausschuss sollte deshalb Datenherkunft, Eigentum und betrieblichen Nutzen in derselben Entscheidung sehen.

Die Europäische Kommission nennt Richtigkeit als Grundprinzip der DSGVO. Für einen Customer Master müssen Match-Qualität, Korrektur und Rückverfolgbarkeit zum Betriebsmodell gehören. Zeigen Sie, wie eine berechtigte Person die Quellen hinter einer Kundensicht findet, einen zweifelhaften Link anficht und eine genehmigte Korrektur über die zuständigen Systeme weitergibt. Die Bank of England betont die Bedeutung verfügbarer, genauer und zeitnaher Daten für einzelne Firmen und Marktinfrastrukturen. Monitoring, Rollback und Quellverantwortung sind finanzierte Arbeit, keine technische Dekoration.

Beantworten Sie fünf Fragen: Wer definiert Kundenidentität? Wer darf Matching-Regeln ändern? Wer prüft unklare Links? Wie werden Entscheidungen protokolliert? Wie reagiert die Bank, wenn eine Kundin eine Verbindung bestreitet? Legen Sie zudem je Anwendung die Aktionsgrenze fest. Ein unsicherer Treffer kann zur Prüfung angezeigt werden, ohne einen Datensatz automatisch zu ändern. Ein Reporting-Fall kann einen anderen Schwellenwert brauchen als eine Kontoeröffnung.

Welche Architektur hält den Umfang unter Kontrolle?

Trennen Sie Quellsysteme, Identitätsauflösung, Customer-Master-Governance und verbrauchende Arbeitsabläufe. Systeme of Record behalten ihre Datenautorität. Die Resolution-Schicht normalisiert und vergleicht Datensätze. Der gesteuerte Customer Master entscheidet über veröffentlichte oder betreute Attribute. Anwendungen erhalten nur die Identität und Belege, die sie benötigen.

Entity Resolution liegt neben MDM, CDP und KYC-/AML-Systemen. Sie ersetzt deren Governance, Datenherkunft oder Abläufe nicht. Diese Grenze hält den Antrag bei Matching, Verbindung und Abruf, statt alle Anforderungen der Bank an ein einziges Projekt zu hängen.

Für Tilores ist die technische Grenze klar: GraphQL, kein REST. Eine GraphQL-Abfrage kann zur Abrufzeit die aufgelöste Entity, verbundene Quelldatensätze und Match-Belege zurückgeben. Tilores verwendet deterministisches, Fuzzy- und probabilistisches Matching als drei getrennte Methoden. Daten werden normalisiert und persistiert, die Originale bleiben erhalten. Die Bank kontrolliert Quellautorität, Attributvorrang, Zugriff, Prüfung und nachgelagerte Aktion; der Resolution-Dienst liefert vorgeschlagene Identitätsgrenzen und Belege.

Wie sollte die Bank Eigenbau und Zukauf vergleichen?

Vergleichen Sie vollständige Betriebsmodelle, nicht einen Algorithmus mit einer Lizenzgebühr. Eigenbau umfasst Parsing, Normalisierung, Regeln, Fuzzy-Vergleiche, probabilistische Bewertung, Kandidatenerzeugung, Entity-Aufbau, Persistenz, Erklärbarkeit, Monitoring, Zugriffssteuerung, Infrastruktur und langfristige Regelpflege. Zukauf erfordert weiterhin Integration, Konfiguration, Tests, Governance und Lieferantenaufsicht.

Geben Sie beiden Optionen dieselben beschrifteten Daten, Durchsatzanforderungen, Betriebsbedingungen und anwendungsspezifischen Grenzen. Vergleichen Sie Link-Qualität, Belege für Prüfende, Aufwand einer neuen Quelle und den später erforderlichen Betrieb. Zeigen Sie über drei Jahre Erstkosten, jährliche Verantwortung, Änderungsaufwand, Spezialpersonal, Infrastruktur, Vorfälle und Ausstieg. Unbekanntes gehört als Spanne oder offene Annahme in die Vorlage, nicht in eine scheinbar präzise Gesamtsumme.

Das Tilores-Rahmenwerk für Build versus Buy kann die Optionen strukturieren. Ersetzen Sie seine allgemeinen Annahmen aber durch Belege Ihrer Bank. Kaufen ist nicht automatisch sicherer, Bauen nicht automatisch günstiger. Finanzierbar ist die Option mit klar benannten Risiken, Kontrollen und Eigentümern.

Was gehört in die Vorlage für den Ausschuss?

Halten Sie das Kernpapier kurz genug für eine Entscheidung. Technische Belege gehören als Anlagen dazu, nicht als Ersatz für den Antrag.

• Entscheidung: exakte Stufe, Budgetspanne, Eigentümer und Enddatum.
• Ausgangslage: heutiger Aufwand für Dubletten, Suche, Prüfung und Abgleich in den vier Anwendungen.
• Umfang: Kundenpopulation, Quellen, Verbraucher und ausdrückliche Ausschlüsse.
• Betriebsmodell: verantwortliche Personen, Prüf- und Korrekturpfad sowie Aktionsschwellen.
• Belegplan: beschriftete Daten, Präzision, Recall, Prüfquote, Betriebsergebnis und Segmentanalyse.
• Architektur: Quellautorität, Resolution-Grenze, Customer-Master-Verantwortung und Verbraucher.
• Optionen: Eigenbau, Zukauf und gegebenenfalls begrenzter Hybrid nach denselben Kriterien.
• Risiko und Kontrolle: Datenschutz, Zugriff, Herkunft, Lieferantenrisiko, Änderungen, Rollback und Ausstieg.
• Stufengrenzen: Belege, die vor der nächsten Finanzierung vorliegen müssen.

Die stärkste letzte Folie verspricht keine perfekten Daten. Sie zeigt den Entscheidungsbaum: Erfüllt die Evaluation die vereinbarten Qualitäts- und Kontrollgrenzen, finanzieren Sie einen begrenzten Produktionsfall. Verfehlt sie diese knapp, kalibrieren und testen Sie erneut. Kann sie die Anforderungen der Bank nicht erfüllen, stoppen Sie ohne ein fortlaufendes Transformationsprogramm.

Häufige Fragen

Was sollte ein kleineres Institut zuerst finanzieren?

Eine begrenzte Erkundungs- und Evaluationsstufe, nicht die bankweite Transformation. Am Ende stehen gemessene Match-Qualität, Betriebsaufwand und eine Empfehlung für genau einen begrenzten Produktionsfall.

Welche Kennzahlen muss der Ausschuss verlangen?

Präzision, Recall, manuelle Prüfquote, ungeklärte Dubletten, Zeit je Prüfung und ein Anwendungsergebnis mit Bezug zu bestehenden Kosten. Ziele stammen aus beschrifteten Bankdaten und der eigenen Risikobereitschaft.

Kann eine Identitätskonfiguration mehrere Anwendungen stützen?

Ja, Kontoeröffnung, Service, Screening-Vorbereitung und Reporting können dieselbe gesteuerte Identitätsgrenze nutzen. Jede Anwendung benötigt aber eigene Aktionsschwellen, Berechtigungen und Kontrollen.

Sollte die Bank Entity Resolution selbst bauen oder zukaufen?

Vergleichen Sie das ganze Betriebsmodell einschließlich Konfiguration, Prüfung, Monitoring, Erklärbarkeit, Infrastruktur, Änderungen und langfristiger Verantwortung. Beide Optionen gehören auf denselben Testsatz.

Ersetzt Entity Resolution KYC- oder AML-Kontrollen?

Nein. Sie liegt neben diesen Systemen. Sanktionen-, PEP- und Adverse-Media-Prozesse behalten ihre eigenen Regeln, Quellen, Entscheidungen und Verantwortlichen.

Quellen

1. Basler Ausschuss: Umsetzung von BCBS 239
2. Europäische Kommission: Datenschutzgrundsätze der DSGVO
3. Bank of England: Operational resilience in a macroprudential framework
4. Tilores: Kundenprofil in Echtzeit über eine API abfragen
5. Tilores: Build versus Buy Entity Resolution
6. Tilores: Master Data Management und Entity Resolution