Erklärbare Entity Resolution: Konfidenzwerte, Match-Schwellen und Audit-Trails (2026)

Was macht Entity Resolution in Finanzdienstleistungen erklärbar?

Erklärbare Entity Resolution bedeutet, dass ein Team belegen kann, warum zwei Datensätze verknüpft, getrennt gehalten oder zur Prüfung gegeben wurden. Die Erklärung sollte auf die verglichenen Felder, die angewandte Normalisierung, die genutzten Regeln oder Modellsignale, den erzeugten Score, das gewählte Schwellenband und die endgültige Entscheidung verweisen.

Es geht nicht darum, jeden Algorithmus einfach zu machen. Es geht darum, die Geschäftsentscheidung reproduzierbar zu machen. Das AI Risk Management Framework des NIST beschreibt Vertrauenswürdigkeit als etwas, das in Design, Nutzung und Evaluierung eingebaut wird. Für Entity Resolution heißt das: klare Belege für jede Match-Entscheidung, die einen regulierten Prozess berührt.

Das ist deshalb wichtig, weil Matching nicht nur eine Aufgabe der Datenbereinigung ist. Eine Übereinstimmung kann darüber entscheiden, ob zwei Konten zu einem Kunden gehören, ob eine Gegenpartei mit einem anderen Kreditnehmer gruppiert werden muss, ob ein Sanktionsalarm relevant ist oder ob eine KYC-Aktualisierung genug Kontext hat. Eine Blackbox-Zusammenführung lässt sich im Nachhinein nur schwer verteidigen.

Eine gute Erklärung hat zwei Ebenen. Die technische Ebene zeigt Datensatz-IDs, Quellsysteme, Transformationen, Regel-IDs, Kantenbezeichnungen, Match-Scores und Entitätsversionen. Die operative Ebene zeigt, wer die Policy freigegeben hat, welcher Schwellenwert aktiv war, welche Ausnahmen bestanden und ob die Aktion automatisch oder geprüft erfolgte.

Wie sollte ein Konfidenzwert verwendet werden?

Ein Konfidenzwert sollte einordnen, wie viel Evidenz für eine vorgeschlagene Übereinstimmung spricht. Er darf nicht zur gesamten Entscheidung werden. Scores eignen sich hervorragend dafür, Kandidaten zu sortieren, offensichtliche Übereinstimmungen von unwahrscheinlichen Paaren zu trennen und unsichere Fälle weiterzuleiten – Policy-Kontext brauchen sie trotzdem.

Die Record-Linkage-Konzepte der AHRQ beschreiben probabilistisches Matching als einen Prozess, der Paar-Scores berechnet, Grenzwerte für automatische Annahme- und Ablehnungsentscheidungen nutzt und einen Graubereich für die manuelle Prüfung offenlässt. Diese Struktur ist nützlich, weil sie Unsicherheit als etwas behandelt, das gesteuert und nicht versteckt werden muss.

In Tilores können Entitäts- und Suchantworten die aufgelöste Entität, die Datensätze, die Kanten, Duplikate, einen Entitäts-Score und einen Hit-Score ausweisen. Die Tilores-API-Referenz beschreibt score als Ausdruck der Gesamtqualität der Übereinstimmungen innerhalb einer Entität, während hitScore angibt, wie genau ein Suchergebnis zu den übergebenen Suchparametern passt.

Halten Sie diese Bedeutungen auseinander. Match-Konfidenz ist nicht dasselbe wie Kundenrisiko. Suchnähe ist nicht dasselbe wie ausreichende Evidenz. Datenvollständigkeit ist nicht dasselbe wie Identitätsgewissheit. Wenn die Bezeichnungen eindeutig sind, können Prüfer das Richtige hinterfragen.

Wie sollten Match-Schwellen gesetzt und begründet werden?

Schwellenwerte sollten an den eigenen Daten des Instituts kalibriert werden, nicht von einer Anbieterfolie oder einem öffentlichen Benchmark übernommen. Namen, Adressen, Identifikatoren, Daten zu wirtschaftlich Berechtigten und Unternehmensregisterdaten verhalten sich je nach Land, Produkt und Quellsystem unterschiedlich.

Definieren Sie zuerst die Entscheidungsbänder, bevor Sie über Zahlen streiten. Ein Band hoher Konfidenz kann automatische Verknüpfungen zulassen, wenn die Evidenz stark und der Konflikt gering ist. Ein Band niedriger Konfidenz kann Kandidaten ablehnen oder getrennt halten. Das mittlere Band sollte eine manuelle Prüfung, zusätzliche Belege oder eine Korrektur im Quellsystem auslösen.

Das Schwellenwertregister sollte den Schwellenwert, die Feldmenge, das Matching-Verfahren, die beabsichtigte Aktion, die bekannten Fehlerbilder, die zur Kalibrierung genutzte Stichprobe, die Prüfergruppe und das Datum der Aktivierung dokumentieren. Es sollte außerdem festhalten, was sich geändert hat, wenn Quelldaten, Regeln oder Produkte sich änderten.

Mit Tilores-Regeln legen Teams fest, wie Datensätze zu Entitäten verbunden und wie Suchwerte verglichen werden. Die Dokumentation zu den Regeln beschreibt regelbasierte Kanten, Regelsätze und Matcher, einschließlich der Fälle, in denen ein Schwellenwert innerhalb der Matching-Logik definiert werden kann. Damit wird der Schwellenwert zu einem konfigurierten Policy-Objekt statt zu einem undokumentierten Nebeneffekt.

Setzen Sie deterministische Regeln dort ein, wo die Evidenz tatsächlich deterministisch ist, etwa bei einer kontrollierten internen ID. Setzen Sie probabilistisches oder unscharfes Matching dort ein, wo reale Varianz existiert. Die Fuzzy-Matching-Werkzeuge von Tilores zeigen, warum Namen, Adressen und Zeichenketten mehr brauchen als exakte Gleichheit.

Was sollte der Audit-Trail zu jeder Match-Entscheidung erfassen?

Ein Audit-Trail sollte es einem späteren Prüfer ermöglichen, die Übereinstimmung ohne Raten zu rekonstruieren. Mindestens sollte er Quell-Datensatz-IDs, Quellsysteme, übermittelte Werte, normalisierte Werte, verglichene Felder, Regel- oder Modellversion, Score, Schwellenband, Entscheidung, Entscheidungszeitpunkt, ergriffene Maßnahme und den Prüfer- beziehungsweise Automatisierungspfad erfassen.

Er sollte auch die Gegenbelege erfassen. Wenn Datensätze getrennt blieben, weil ein Geburtsdatum widersprüchlich war, weil eine Handelsregistereintragung abwich oder weil eine Policy den Score überstimmt hat, ist dieser Grund genauso wichtig wie eine erfolgreiche Übereinstimmung. Aufsicht und Model-Risk-Teams interessieren sich oft gerade für den Ausnahmepfad.

Tilores-Entitätsantworten weisen Datensätze, Kanten, Duplikate und den Score aus, während recordInsights Datensätze innerhalb einer Entität filtern, gruppieren und aggregieren kann. Die API unterstützt außerdem Operationen wie disassemble, um Datensätze oder Kanten zu entfernen. In einer gesteuerten Implementierung sollten diese Ereignisse zusammen mit der Schwellenwert-Policy und den Prüfernotizen aufbewahrt werden.

Der Audit-Trail sollte nicht nur in Screenshots oder im Erfahrungswissen Einzelner existieren. Er sollte dauerhaft genug sein, um eine Compliance-Prüfung, eine Kundenbeschwerde, eine Modelländerung, eine Migration eines Quellsystems oder eine Rekonstruktion nach einem Vorfall zu tragen.

Wie unterstützt das die Arbeit an KYC, AML und verbundenen Kunden?

KYC- und AML-Teams brauchen aktuellen Kontext zu Kunden, Gegenparteien und wirtschaftlich Berechtigten. Entity Resolution hilft dabei, die Datensätze zusammenzuführen, die dieselbe reale Partei beschreiben, bevor das nachgelagerte System eine Screening-, Prüf- oder Aktualisierungsentscheidung trifft.

Die FATF-Empfehlungen bleiben der globale Referenzpunkt für Standards zur Geldwäschebekämpfung und Terrorismusfinanzierung. Sie schreiben keiner Bank vor, welchen Matching-Schwellenwert sie verwenden soll, machen aber deutlich, dass Kunden- und Risikokontrollen verlässliche Informationen brauchen. Schwache Entity Resolution untergräbt dieses Fundament.

Bei der Analyse verbundener Kunden steigt der Einsatz. Die finalen technischen Standards der EBA zu Gruppen verbundener Kunden beschreiben einen Rahmen zur Identifikation von Personen, die durch Kontrolle, wirtschaftliche Abhängigkeit oder kombinierte Risikofaktoren verbunden sind. Eine solche Gruppierung hängt davon ab, erklären zu können, wie Entitäten und Beziehungen gebildet wurden.

Tilores hat bereits über verbundene Kunden, Perpetual KYC und Entity Resolution in Echtzeit für AML und KYC geschrieben. Dieser Artikel verengt die operative Frage: Wie belegen Sie Konfidenzwert, Schwellenwert und Audit-Nachweis hinter jeder einzelnen Übereinstimmung?

Das saubere Muster besteht darin, Datensätze bei der Ingestion aufzulösen und zusammenzuführen und den aktuellen aufgelösten Kontext dann zur Abfragezeit abzurufen. Damit erhalten AML-, KYC- und Exposure-Workflows eine aktuelle Entitätssicht, ohne dass jedes nachgelagerte System die Matching-Logik neu bauen muss.

Wo gehört Tilores neben MDM, CDP und Governance-Plattformen hin?

Tilores gehört neben MDM-, CDP-, KYC-, AML-, Warehouse- und Governance-Systeme. Es sollte sie nicht ersetzen. MDM verantwortet weiterhin die kuratierten Stammdatenprozesse. Eine CDP verantwortet weiterhin Aktivierung und Segmentierung. KYC- und AML-Werkzeuge verantworten weiterhin Screening, Fallbearbeitung und regulatorische Aufzeichnungen. Governance-Plattformen verantworten weiterhin Katalog-, Policy- und Lineage-Kontrollen.

Die Entity-Resolution-Schicht hat eine andere Aufgabe. Sie nimmt Datensätze auf, wendet Schema- und Matching-Regeln an, setzt Entitäten zusammen und stellt den aktuellen aufgelösten Kontext über API-Abfragen und Events bereit. Die Tilores-Schema-Dokumentation beschreibt, wie sich Eingabe-, Ausgabe- und Suchstrukturen an die Anwendung anpassen lassen. Genau das erlaubt es der aufgelösten Entitätsschicht, sich der Fachdomäne anzupassen, statt alle Datensätze in eine generische Form zu zwingen.

Eine praxistaugliche Architektur ist einfach. Quellsysteme übermitteln Datensätze an Tilores. Tilores löst sie während der Ingestion zu Entitäten auf. Fachsysteme fragen die Entität ab, suchen nach Kandidaten oder konsumieren Events. MDM-, KYC-, AML-, CDP- und Analytics-Systeme nutzen diesen aufgelösten Kontext und behalten dabei ihre eigene Freigabe- und Maßnahmenhistorie.

Diese Trennung verbessert auch die Erklärbarkeit. Wenn in einem KYC-Fall die Frage aufkommt, warum zwei Profile verknüpft wurden, sollte die Antwort nicht im KYC-Werkzeug verborgen liegen. Sie sollte auf die Belege der Entity Resolution zurückverweisen: Quelldatensätze, Regelsatz, Score, Schwellenband und Prüfentscheidung.

Welche operativen Kontrollen halten Schwellenwerte 2026 belastbar?

Belastbare Schwellenwerte brauchen operative Kontrollen, nicht nur Modellmetriken. Das Kontrollpaket sollte versionierte Schemata und Regeln, dokumentierte Schwellenbänder, stichprobenbasierte Validierung, Ausnahme-Queues, Leitlinien für Prüfer, Änderungsfreigaben, Monitoring sowie einen Rollback- oder Korrekturpfad umfassen.

BCBS 239 eignet sich als Governance-Referenz, weil der Standard auf die Fähigkeiten zur Aggregation und Berichterstattung von Risikodaten abzielt. Die BIZ-Seite zu den Grundsätzen für die effektive Aggregation von Risikodaten und die Risikoberichterstattung betont, dass Banken Risikopositionen vollständig, schnell und präzise aggregieren und Konzentrationen erkennen müssen. Entity Resolution gehört zu den Datenfundamenten, die das überhaupt ermöglichen.

Überprüfen Sie Schwellenwerte, wenn sich Quellsysteme ändern, ein neues Produkt hinzukommt, sich ein Datenqualitätsmuster verschiebt, die Zahl der Prüfer-Overrides steigt oder eine falsche Zusammenführung eine regulierte Entscheidung berührt. Es geht nicht darum, perfekter Precision hinterherzujagen. Es geht darum, zu wissen, welche Fehler das Institut akzeptiert, welche nicht und warum.

Für regulierte Teams ist konservative Automatisierung mit schneller Prüfung meist die stärkste Position. Lassen Sie offensichtliche Übereinstimmungen durchlaufen. Lehnen Sie offensichtliche Nicht-Übereinstimmungen ab. Halten Sie das unsichere Band sichtbar. Speichern Sie genug Audit-Belege, damit ein späterer Prüfer die Entscheidung nachvollziehen kann, ohne den ursprünglichen Analysten fragen zu müssen, was damals passiert ist.