Wie eine Bank und ihr Entity-Resolution-Anbieter sich vor einem PoC auf Matching-Regeln einigen

Kurzfassung: Der Fachbereich schreibt die Matching-Regeln nicht selbst. Wir schlagen aus den eigenen Beispieldaten der Bank ein erstes Regelwerk vor, der Fachbereich sagt bei konkreten Grenzfällen Ja oder Nein und begründet dies, und wir übersetzen diese Antworten in ein überarbeitetes Regelwerk, über mindestens zwei Runden, bis eine Konfiguration entsteht, die die Bank behält.

Demo buchen · Tilores Studio kostenlos testen

Auf dieser Seite

1. Warum kann der Fachbereich die Matching-Regeln nicht einfach selbst festlegen?
2. Wie läuft die Abstimmung der Regeln in der Praxis ab, Runde für Runde?
3. Was sollte eine Bank am Ende des PoC verlangen?
4. Wo passt Tilores in dieses Bild?
5. Was sollte eine Bank einen Anbieter vor Unterschrift des PoC zur Regelabstimmung fragen?
6. Häufig gestellte Fragen
7. Quellen

Die Erfolgskriterien für den Entity-Resolution-PoC einer Bank werden festgelegt, bevor jemand gesehen hat, wie sich die eigenen Daten tatsächlich verhalten: ein vereinbarter Precision-Zielwert, ein vereinbarter Recall-Zielwert, ein Termin für die Abnahme. Keines davon sagt dem Fachbereich, was eine Matching-Regel tatsächlich aussagt, oder warum ein Datensatzpaar am Rand zusammengeführt werden sollte und ein anderes nicht.

Diese Lücke ist kein Schulungsproblem. Eine Leiterin der Data Governance kann zwei Kontodatensätze ansehen und zu Recht wissen, dass sie zur selben Kundin oder zu zwei verschiedenen Personen gehören. Diese Einschätzung als Logik festzuhalten, die eine Matching-Engine ausführen kann, ist eine andere Fähigkeit, und keine, die der Fachbereich mitten im PoC erst lernen sollte.

Die funktionierende Antwort ist ein kurzer, strukturierter Austausch zwischen Anbieter und Fachbereich, wiederholt über mindestens zwei Runden, bis das Regelwerk trägt.

Warum kann der Fachbereich die Matching-Regeln nicht einfach selbst festlegen?

Eine erfahrene Prüferin im Fachbereich erkennt einen echten Treffer oft auf den ersten Blick, ähnlich wie die meisten Menschen ein Gesicht wiedererkennen, ohne seine genauen Proportionen beschreiben zu können. Ökonomen haben für diese Lücke zwischen Wissen und einer explizit formulierbaren Regel einen Namen: das Polanyi-Paradox, benannt nach der Beobachtung des Philosophen Michael Polanyi, dass wir mehr wissen, als wir sagen können.

Dieselbe Lücke zeigt sich im PoC einer Bank. Eine Prüferin kann zu einem konkreten Paar zu Recht sagen: “Das ist dieselbe Kundin” oder “Das sind zwei verschiedene Personen”. Die Kombination aus Namensähnlichkeit, Adressübereinstimmung und Geburtsdatums-Konsistenz zu benennen, die das für jedes andere Paar im gesamten Kundenbestand zutreffen lässt, ist eine andere Aufgabe, und eine, die der Fachbereich nie übernehmen musste, bevor Entity Resolution als Beschaffungsposten auftauchte.

Ein funktionierender PoC-Prozess verlangt vom Fachbereich nicht, die Regel selbst zu schreiben. Er verlangt, dass der Fachbereich dieselbe Einschätzung, die er bereits gut trifft, an konkreten echten Datensätzen wiederholt, und überlässt es jemand anderem, das Muster über diese Einschätzungen hinweg in eine Regel zu übersetzen, die die Matching-Engine ausführen kann.

Wie läuft die Abstimmung der Regeln in der Praxis ab, Runde für Runde?

Der Prozess, den eine Bank erwarten sollte, läuft als fester Zyklus und nicht als einmalige Übergabe. Jede Runde engt das Regelwerk weiter ein; wie viele Runden es braucht, entscheiden die eigenen Daten der Bank, nicht eine Vorlage.

Fachbereich und Anbieter einigen sich auf eine gemeinsame Regelliste, bevor der Proof of Concept läuft.

1. Wir schlagen aus den eigenen Beispieldaten der Bank ein erstes Regelwerk vor. Zuerst läuft die Normalisierung: Namen, Adressen, Telefonnummern und Datumsangaben werden vereinheitlicht, damit der erste Vergleich Gleiches mit Gleichem vergleicht. Anschließend läuft ein erstes deterministisches und Fuzzy-Regelwerk gegen die repräsentative Stichprobe der Bank selbst, nicht gegen eine generische Regelbibliothek, die an den Daten anderer Kunden abgestimmt wurde.
2. Der Fachbereich prüft konkrete Grenzfälle und sagt Ja, Nein oder Eskalieren, mit einer Begründung. Eine aggregierte Precision- oder Recall-Zahl zeigt der Prüferin nicht, welches konkrete Paar falsch lag oder warum. Die nützliche Prüfung findet auf Ebene einzelner Kandidatenpaare statt, besonders bei jenen, die zwischen der Auto-Merge-Schwelle und der Auto-Reject-Schwelle liegen, wo das System selbst nicht sicher genug ist, um allein zu entscheiden.
3. Wir übersetzen diese Antworten in ein überarbeitetes Regelwerk. Jede Ja-, Nein- oder Eskalieren-Antwort wird zusammen mit der Begründung der Prüferin zu einer Eingabe für die nächste Überarbeitung: eine Feldgewichtung ändert sich, eine Konsistenzregel wird verschärft, eine phonetische Variante wird ergänzt. Das Ergebnis ist ein zweites Regelwerk, getestet an derselben Stichprobe plus den neuen Grenzfällen, die die erste Runde aufgedeckt hat.
4. Der Zyklus wiederholt sich über mindestens zwei Runden. Eine einzelne Runde schließt selten alle Grenzfälle, die ein echter Kundenbestand hervorbringt. Dieselbe Abfolge aus Vorschlagen, Prüfen und Überarbeiten mindestens zweimal zu durchlaufen, unterscheidet ein Regelwerk, das nur auf wenige offensichtliche Beispiele abgestimmt ist, von einem, das auch den unordentlicheren Fällen der eigenen Daten der Bank standhält.
5. Die Bank erhält ein gemessenes Ergebnis gegenüber den vereinbarten Zielwerten. Der PoC endet nicht mit einer Demo. Er endet mit einem gemessenen Precision- und Recall-Ergebnis gegenüber den vor Testbeginn vereinbarten Zielwerten, zusammen mit dem Regelwerk, das dieses Ergebnis erzeugt hat.

Ein Prüffall aus Runde zwei zeigt, warum die Begründung des Fachbereichs und nicht nur der Score entscheidend ist. Ein Kandidatenpaar erreichte einen Score von 0,71, unterhalb der Auto-Merge-Schwelle von 0,85 und oberhalb der Auto-Reject-Schwelle von 0,55, und wartete deshalb in der Steward-Warteschlange, statt sich automatisch aufzulösen. Nachname und Adresse stimmten nach der Normalisierung überein. Bei einem der Datensätze fehlte das Geburtsdatum, sodass die Geburtsdatums-Konsistenzregel den Treffer weder bestätigen noch blockieren konnte, und die bekannten E-Mail-Adressen der beiden Datensätze wurden erstmals mit elf Jahren Abstand erfasst.

Eine Prüferin, die antwortet “zusammenführen, weil das fehlende Geburtsdatum eine Lücke in der Dateneingabe ist, kein Widerspruch”, gibt dem Anbieter eine andere Regel zum Kodieren als eine, die antwortet “eskalieren, die Altersdifferenz, die diese Adresse nahelegt, ist zu groß, um sie einfach anzunehmen”. Beide Antworten sind beim selben Score von 0,71 vertretbar. Keine davon existiert, bevor jemand mit dem fachlichen Kontext sie gibt, und genau dafür gibt es den Prüfschritt. Eine solche Konsistenzregel ist genau das, was die Datenqualitätspraxis eine Business-Regel nennt: die DAMA-Forschung zu Datenqualitätsdimensionen, aufbauend auf dem DAMA-DMBOK, definiert sie als eine Konformitätsbedingung, die ein Datenwert erfüllen muss, und die ausdrücklich von den Menschen vereinbart werden muss, die die Daten kennen, statt sie aus den Daten selbst abzuleiten.

Sanktions-, PEP- und Adverse-Media-Treffer sind eine Kategorie von Grenzfällen, die sich lohnt, vor Testbeginn ausdrücklich zu vereinbaren, denn ein falscher Nicht-Treffer bei einer politisch exponierten Person hat andere Folgen als einer bei einem Marketing-Datensatz. Allein OpenSanctions führt mehr als 700.000 individuelle PEP-Ziele in 264 Ländern, sodass die Menge an knappen Namensvarianten, auf die eine Bank während der Abstimmung trifft, kein Gedankenspiel ist, das man bis zur Produktion aufschieben sollte.

Was sollte eine Bank am Ende des PoC verlangen?

Ein PoC, der mit einer Demo und einer mündlichen Beschreibung “der verwendeten Regeln” endet, übergibt der Bank ein Ergebnis, das sie nicht unabhängig prüfen oder weiterverwenden kann. Was den PoC mit der Bank verlassen sollte, ist die Konfiguration selbst: das genaue Regelwerk, in einer Form, die die Bank lesen, versionieren und außerhalb der Sitzung des Anbieters erneut ausführen kann.

Wir versionieren jede Regeländerung in einem Audit-Trail, speichern jeden Treffer als Graph-Kante, die die konkrete Regel festhält, die ihn erzeugt hat, und lassen die Bank das resultierende Regelwerk exportieren, statt es in einer anbieterinternen Oberfläche zu belassen. Wird ein Datensatz mit derselben Quell-ID erneut übermittelt, aktualisiert sich dieser Datensatz an Ort und Stelle, statt ein Duplikat zu erzeugen, was wichtig wird, sobald die abgestimmten Regeln von der PoC-Stichprobe in den laufenden, kontinuierlichen Import wechseln.

Das entspricht auch dem, was britische und europäische Auslagerungsvorschriften von einer regulierten Bank ohnehin erwarten, unabhängig vom guten Willen eines einzelnen Anbieters. Die SYSC-8.1-Anforderungen der britischen FCA verlangen von einem Unternehmen, Auskunfts- sowie Prüfungs- und Zugangsrechte zu behalten, nicht nur eine Demo einer ausgelagerten Funktion, und die SS2/21 der Bank of England/PRA sowie die Leitlinien der EBA von 2019 erweitern dieselbe Erwartung an fortbestehende Aufsicht auf die Vereinbarungen, von denen eine Bank abhängt. Ein Regelwerk, das eine Bank nicht exportieren kann, ist ein Regelwerk, das sie nach diesem Maßstab nicht prüfen kann. Das Regelwerk selbst ist auch die Art von Modell, für die britische Regulierer bereits einen Rahmen haben: Die Modellrisikoprinzipien der PRA in SS1/23 stufen “regelbasierte oder algorithmische Entscheidungsmethoden” als Modelle im Anwendungsbereich ein und erwarten, dass eine unabhängige Validierungsfunktion deren Entwicklung und Nutzung fortlaufend und unabhängig herausfordert, nicht nur einmal am Ende des PoC abzeichnet.

Dasselbe Regelwerk wird anschließend weitergeführt, statt neu zu beginnen. Wir betreiben eine Engine und ein Regelwerk für PoC-Umfang und Produktionsumfang gleichermaßen, unabhängig vom gewählten Deployment-Modell, sodass die während des PoC geprüfte und abgestimmte Konfiguration dieselbe ist, die am ersten Tag der Produktion läuft, nicht ein separat neu aufgesetzter Build.

Wo passt Tilores in dieses Bild?

Das oben beschriebene Abstimmungsgespräch ist keine generische PoC-Formalität, die wir nachträglich beschreiben. So führen wir jeden bezahlten Proof of Concept durch: Vorschlag aus der eigenen Stichprobe der Bank, Prüfung konkreter Grenzfälle mit Begründung, Überarbeitung, Wiederholung über mindestens zwei Runden, dann Übergabe eines gemessenen Ergebnisses und eines exportierbaren, versionierten Regelwerks.

Eine Bank, die die erste Runde dieses Prozesses sehen möchte, bevor überhaupt ein PoC-Gespräch beginnt, kann das Matching lokal in Tilores Studio an bis zu 100.000 eigenen Datensätzen testen, kostenlos, ohne dass Daten das eigene Gerät verlassen.

Was sollte eine Bank einen Anbieter vor Unterschrift des PoC zur Regelabstimmung fragen?

Eine kurze Liste direkter Fragen, gestellt bevor ein PoC-Vertrag unterschrieben wird, unterscheidet einen Anbieter, der den oben beschriebenen Prozess tatsächlich durchführt, von einem, der am Ende eine Blackbox übergibt.

• Wie viele Abstimmungsrunden sind im PoC-Preis enthalten, und was passiert, wenn unsere Daten mehr brauchen?
• Wer schlägt das erste Regelwerk vor, und aus welcher Stichprobe unserer eigenen Daten, nicht eines generischen Datensatzes?
• Werden konkrete Grenzfälle mit Begründung geprüft, nicht nur eine aggregierte Precision- und Recall-Zahl?
• Ist das endgültige Regelwerk exportierbar, versioniert und unser Eigentum, statt in Ihrer Oberfläche gehalten zu werden?
• Läuft dasselbe Regelwerk und dieselbe Engine in der Produktion weiter, oder beginnt die Abstimmung beim Go-Live neu?
• Wie werden die Antworten unserer Prüferinnen protokolliert, damit eine spätere Prüfung erkennen kann, warum sich eine Regel geändert hat?

Ein Anbieter, der alle sechs Fragen ohne Zögern beantwortet, beschreibt einen Prozess, den er bereits durchführt, keinen, den er für dieses Gespräch erst erfindet. Verwandtes Thema: Wie eine Bank nach einem einmaligen Abgleich historischer Daten das laufende Matching anschließend im eigenen Haus fortführt.

Häufig gestellte Fragen

Muss der Fachbereich Fuzzy Matching verstehen, um an der Regelabstimmung mitzuwirken?

Nein. Der Fachbereich beantwortet Ja, Nein oder Eskalieren zu konkreten Datensatzpaaren und begründet dies; wir übersetzen diese Antworten in die Matching-Logik. Niemand im Fachbereich muss eine Regel schreiben.

Wie viele Abstimmungsrunden umfasst ein PoC bei Tilores?

Mindestens zwei. Die meisten PoCs brauchen die erste Runde für einen funktionsfähigen Entwurf und eine zweite, um die dabei übersehenen Grenzfälle zu schließen; eine Bank kann weitere Runden verlangen, wenn die eigenen Daten weiterhin neue Grenzfälle aufzeigen.

Wer behält das Regelwerk nach Abschluss des PoC?

Die Bank. Wir exportieren das Regelwerk einschließlich des Audit-Trails jeder Regeländerung, statt es in einer anbieterinternen Sitzung zu belassen, die die Bank nicht mitnehmen kann.

Muss ein im PoC abgestimmtes Regelwerk für die Produktion neu aufgebaut werden?

Nein. Wir betreiben eine Engine und ein Regelwerk für PoC-Umfang und Produktionsumfang gleichermaßen, sodass die während des PoC abgestimmte Konfiguration dieselbe ist, die in der Produktion läuft.

Kann eine Bank nachvollziehen, warum zwei konkrete Datensätze bei der Abstimmung zusammengeführt wurden oder nicht?

Ja. Jeder Treffer wird als Graph-Kante gespeichert, die die Regel festhält, die ihn erzeugt hat, sodass eine Prüferin eine konkrete Zusammenführung oder Nicht-Zusammenführung bis zur Regel und den zugrunde liegenden Daten zurückverfolgen kann.

Quellen

1. Tilores: eine aufgelöste Datenebene, Tilores.
2. Tilores Deployment-Optionen, Tilores.
3. Tilores Studio: kostenlose Testversion herunterladen, Tilores.
4. Entity Resolution Proof of Concept: 7 PoC-Inputs für Banken im Jahr 2026, Tilores.
5. Identity-Resolution-Anbieter für Banken und regulierte Branchen bewerten (2026), Tilores.
6. Wie Banken historische Kundendaten deduplizieren und das Matching 2026 im eigenen Haus fortführen, Tilores.
7. Polanyi’s Paradox and the Shape of Employment Growth, David H. Autor, National Bureau of Economic Research Working Paper No. 20485.
8. A Theory for Record Linkage, Ivan P. Fellegi und Alan B. Sunter, Journal of the American Statistical Association, Vol. 64, No. 328 (1969).
9. Overview of Record Linkage and Current Research Directions, William E. Winkler, US Census Bureau Research Report Series.
10. SystemER: A Human-in-the-Loop System for Explainable Entity Resolution, Kun Qian, Lucian Popa und Prithviraj Sen, Proceedings of the VLDB Endowment, Vol. 12, No. 12 (2019).
11. SYSC 8.1: General Outsourcing Requirements, Financial Conduct Authority Handbook.
12. SS2/21: Outsourcing and Third Party Risk Management, Bank of England Prudential Regulation Authority.
13. EBA Publishes Revised Guidelines on Outsourcing Arrangements, European Banking Authority.
14. Politically Exposed Persons Datasets, OpenSanctions.
15. Dimensions of Data Quality (DDQ) Research Paper, DAMA Netherlands, Version 1.2, aufbauend auf dem DAMA-DMBOK (DAMA, 2017) und DAMA UK (2013).
16. SS1/23: Model Risk Management Principles for Banks, Bank of England Prudential Regulation Authority.
17. Entity Resolution, Explained, Schmitdy Gadget, YouTube.