Identity-Resolution-Anbieter für Banken und regulierte Branchen bewerten (2026)

Kurzfassung: Bewerten Sie Identity-Resolution-Anbieter, indem Sie echte regulierte Daten testen, nicht Folien. Eine banktaugliche Schicht sollte deterministisches, probabilistisches und unscharfes Matching kombinieren, Entitäten bei der Datenaufnahme auflösen und zusammensetzen, die Herkunft der Daten nachvollziehbar halten und KYC-, AML-, Risiko- und operativen Systemen erlauben, den aktuellen aufgelösten Kontext abzufragen.

Wie sollte eine Bank Identity-Resolution-Anbieter 2026 bewerten?

Eine Bank sollte Identity-Resolution-Anbieter danach bewerten, ob das System echte Kunden-, Konto-, Gegenpartei- und Beteiligungsdatensätze mit Nachweisen auflösen kann, die ein Risiko-, Compliance- oder Operations-Team prüfen kann.

Der falsche Ausgangspunkt ist eine generische Feature-Checkliste. Der richtige Ausgangspunkt ist der regulierte Prozess: Onboarding, Kundensorgfaltspflichten, Sanktionsscreening, Betrugsprüfung, Bestandsbetreuung, Inkasso, Open Banking, Kreditrisikoprüfung oder Perpetual KYC. Jeder Prozess hat andere Kosten für eine übersehene Verknüpfung und andere Kosten für eine falsche Zusammenführung.

Wenn Sie eine eigene Sicht darauf brauchen, wen Sie überhaupt auf die Shortlist setzen sollten, ist der begleitende Leitfaden zu Identity-Resolution-Anbietern für Finanzdienstleister die passendere Seite. Dieser Leitfaden ist die Bewertungsebene: die Fragen, die ein regulierter Käufer stellen sollte, sobald ein Anbieter bereits im Gespräch ist.

Welche Anforderungen an regulierte Daten kommen zuerst?

Die ersten Anforderungen sind Datenkontrolle, rechtmäßige Verarbeitung, Erklärbarkeit und operative Korrekturmöglichkeit – denn Identitätsdaten im Bankwesen sind personenbezogen, risikosensibel und werden über viele nachgelagerte Kontrollen hinweg weiterverwendet.

Artikel 4 DSGVO definiert personenbezogene Daten weit und schließt Kennungen wie Namen, Kennnummern, Standortdaten und Online-Kennungen ein. Das heißt: Eine Anbieterbewertung darf Matching-Felder nicht als harmlose Verrohrung behandeln. Das Team sollte fragen, wo Daten verarbeitet werden, welche Partei Auftragsverarbeiter ist, welche technischen und organisatorischen Maßnahmen sie schützen und wie Daten bei Bedarf zurückgegeben, gelöscht oder in ihrer Verarbeitung eingeschränkt werden können.

Die Leitlinien der Europäischen Bankenaufsichtsbehörde zum Remote-Onboarding sind ein nützlicher praktischer Anker, weil sie von Kredit- und Finanzinstituten erwarten, Onboarding-Werkzeuge über sichere, wirksame und risikoorientierte Sorgfaltsprozesse auszuwählen. Dieselbe Logik gilt für Identity Resolution: Das Werkzeug muss in das Kontrollumfeld passen, nicht nur in den Demo-Ablauf.

Wie verändern Echtzeit- und Batch-Auflösung die Entscheidung?

Echtzeit- und Batch-Auflösung beantworten unterschiedliche Fragen, deshalb sollte ein regulierter Käufer fragen, wie der Anbieter sowohl historische Nachladungen als auch operative Aktualisierungen handhabt.

Batch-Auflösung ist nützlich, wenn eine Bank erstmals Altsysteme anbindet, ein historisches Portfolio bereinigt oder vor einer Migration einen großen Bestand prüft. Echtzeit-Auflösung zählt, wenn während Onboarding, Kontoänderung, Transaktionsprüfung, Betrugsermittlung oder Kundenservice neue Hinweise eintreffen.

Die Grenze dazwischen ist wichtig. Auflösung und Entitätsbildung sollten stattfinden, wenn Datensätze aufgenommen oder geändert werden. Zur Abfragezeit sollten Anwendungen den aktuellen aufgelösten Kontext abrufen, statt Identität erneut aus Rohfragmenten zusammenzusetzen. Tilores beschreibt dieses API-Muster in seiner GraphQL-Dokumentation, in der Datensätze übermittelt werden und aufgelöste Entitäten über Entity-ID, Record-ID oder Suchparameter abgefragt werden können.

Wie sollten Banken die Match-Qualität an unsauberen Identitätsdaten testen?

Banken sollten die Match-Qualität mit repräsentativen Datensätzen und einem gelabelten Prüfset testen, denn saubere Beispieldaten verbergen genau die Mehrdeutigkeit, die Identity Resolution auflösen soll.

Die Bewertung sollte exakte Kennungen einschließen, wo vorhanden, aber ebenso den gewöhnlichen Wildwuchs im Bankbetrieb: Namensvarianten, geänderte Adressen, gemeinsam genutzte Telefonnummern, Transliteration, Gemeinschaftskonten, Tochtergesellschaften, alte E-Mail-Adressen, fehlende Geburtsdaten und widersprüchliche Felder aus Quellsystemen. Ein rein deterministischer Matcher sieht bei starken Kennungen gut aus und ist überall sonst spröde.

Ein ernstzunehmender Anbieter sollte deterministische Regeln, probabilistische Bewertung und Fuzzy Matching unterstützen. Die Tilores-Referenz zu Fuzzy-Matching-Algorithmen zeigt, welche Verfahren zur Zeichenkettenähnlichkeit und welche phonetischen Werkzeuge für Namen und Adressen eingesetzt werden. Für die Messung nutzt die Evaluierung im Record Linkage üblicherweise True Positives, False Positives, False Negatives, Precision, Recall und F-Score – der Käufer sollte sich also zeigen lassen, wie diese Konzepte auf sein eigenes gelabeltes Sample angewendet werden.

Welche Prüfbarkeit und Erklärbarkeit sollte der Anbieter zeigen?

Prüfbarkeit heißt, dass ein Prüfer sehen kann, warum Datensätze verknüpft wurden, woher die Evidenz stammt, was sich geändert hat und wie sich die Entscheidung korrigieren lässt.

Für regulierte Prozesse genügt eine aufgelöste Entität ohne Herkunftsnachweis nicht. Das Team sollte Quelldatensätze, Kantenevidenz, Duplikate, Scores, Suchtreffer und jede Korrekturhistorie einsehen können, die eine Entität verändert. Tilores stellt Entitäten mit Records, Edges, Duplikaten, Hits und Scores bereit, und sein Schema erlaubt es, Datensätze an das Datenmodell der Anwendung anzupassen.

Der Korrekturweg ist genauso wichtig wie der Match-Weg. Eine falsche Zusammenführung muss sich auftrennen lassen. Eine falsche Verknüpfung muss sich entfernen lassen. Eine künftige Zusammenführung muss sich unter Umständen blockieren lassen. Wenn ein Anbieter nicht beschreiben kann, wie operative Nutzer Entscheidungen mit hohem Risiko prüfen und korrigieren, ist das Werkzeug nicht reif für den regulierten Einsatz.

Wie fügen sich Sanktions-, PEP- und Adverse-Media-Screening ein?

Identity Resolution sollte vor und neben dem Screening stehen, nicht die Screening-Engine ersetzen.

Die Aufgabe der Auflösungsschicht ist zu entscheiden, welche Kunden-, Konto-, Beteiligungs-, Gegenpartei- oder Beziehungsdatensätze dieselbe Entität beschreiben. Dieser sauberere Entitätskontext hilft Screening-Systemen anschließend, Sanktionslisten, PEP-Listen und Adverse-Media-Quellen mit weniger Fragmentierung und weniger überflüssigen Doppelprüfungen abzugleichen.

OpenSanctions eignet sich als Referenz, wenn es um Screening-Daten geht, denn das Projekt beschreibt sich selbst als Open-Source-Datenbank für Sanktionen, Beobachtungslisten und politisch exponierte Personen, die Hunderte von Quellen zusammenführt. Die FAQ zu Adverse Media zieht die Grenze ebenfalls klar: OpenSanctions veröffentlicht kein umfassendes Nachrichtenarchiv, nimmt aber nachteilige Informationen aus Beobachtungslisten außerhalb des Sanktionsbereichs auf, etwa aus Aufsichtslisten und Ausschlussdatenbanken.

Diese Unterscheidung ist für die Sprache des Käufers wichtig. Identity Resolution verbessert, wen Sie screenen. Screening-Daten und Screening-Richtlinie entscheiden, wogegen Sie screenen. Fallbearbeitung, Eskalation und die endgültige Compliance-Entscheidung bleiben außerhalb der Auflösungsschicht.

Wo sollte Identity Resolution in einer regulierten Architektur sitzen?

Identity Resolution sollte eine gemeinsam genutzte Schicht neben den Systemen sein, die Kundendaten erzeugen, steuern, screenen und konsumieren.

Sie sollte weder MDM noch eine CDP, ein Warehouse, KYC-AML-Werkzeuge, Betrugssysteme, Fallbearbeitung oder einen Data-Governance-Prozess ersetzen. Diese Systeme haben ihre eigenen Verantwortlichkeiten für Eigentum, Prozess und Kontrolle. Die Auflösungsschicht liefert einen aktuellen Entitätsgraphen, Herkunftsnachweise und abfragbaren Kontext, den diese Systeme nutzen können.

Es ist dieselbe Unterscheidung, die der Tilores-Leitfaden zu Entity Resolution für KI, KYC und Customer 360 behandelt. Für Prozesse in Finanzdienstleistungen geht der verwandte Leitfaden zu Echtzeit-Entity-Resolution für AML und KYC tiefer auf den Compliance-Prozess ein. Für die laufende Überwachung ist der Leitfaden zu Perpetual KYC eine nützliche Ergänzung.

Welche Bewertungsmatrix kann ein Bankteam nutzen?

Eine brauchbare Bewertungsmatrix macht aus der Anbieterprüfung Evidenz statt Meinung.

Kriterium	Zu stellende Frage	Starke Evidenz	Warnsignal
Matching-Verfahren	Kombiniert das System deterministische Regeln, probabilistische Bewertung und Fuzzy Matching?	Der Anbieter kann Regeln, Scores und unscharfe Evidenz an Ihren Beispieldatensätzen zeigen.	Die Antwort lautet nur exakte Kennungen – oder nur ein Blackbox-Score.
Grenze der Entitätsbildung	Wann werden Datensätze aufgelöst und Entitäten aktualisiert?	Datensätze werden bei Aufnahme oder Änderung aufgelöst, der aktuelle Kontext wird zur Abfragezeit abgerufen.	Der Anbieter setzt Identität erst aus Rohdatensätzen zusammen, wenn eine Anwendung fragt.
Herkunft und Prüfung	Können Prüfer Quelldatensätze, Kanten, Duplikate, Treffer und Match-Evidenz einsehen?	API oder UI legt die Datensätze und die Evidenz hinter jeder aufgelösten Entität offen.	Das System zeigt ein Profil, aber nicht, warum Datensätze zusammengehören.
Screening-Eignung	Wie unterstützt die Schicht Sanktions-, PEP- und Adverse-Media-Prüfungen?	Aufgelöster Entitätskontext wird an Screening-Werkzeuge übergeben, ohne selbst die Screening-Engine sein zu wollen.	Der Anbieter verwischt Identity Resolution, Screening-Daten und Compliance-Entscheidung.
Deployment und Datenkontrolle	Wo werden Daten verarbeitet, wer verarbeitet sie, und welche Schutzmaßnahmen gelten?	Klare Antworten zu Hosting, Auftragsverarbeitung, Zugriffskontrollen, Protokollen, Löschung und Audit-Unterstützung.	Vage Antworten zum Datenstandort oder zur Kontrolle über Unterauftragsverarbeiter.
Latenz und Aktualisierungsmodell	Können operative Systeme den aktuellen aufgelösten Kontext abrufen, wenn Prozesse ihn brauchen?	Batch-Nachladungen und operative Abfragen werden beide unterstützt.	Das Produkt ist ausschließlich für Offline-Deduplizierungsprojekte gebaut.
Korrekturprozesse	Was passiert nach einer falschen Zusammenführung, einer Auftrennung oder einem Prüfbefund mit hohem Risiko?	Es gibt einen dokumentierten Weg, Entitäten aufzutrennen, Verknüpfungen zu entfernen und wiederholte Fehlzusammenführungen zu verhindern.	Korrekturen erfordern manuelle Datenbankeingriffe oder Support-Tickets beim Anbieter.
Passung im Stack	Wie steht es neben MDM-, CDP-, Warehouse- und KYC-AML-Systemen?	Der Anbieter beschreibt eine gemeinsam genutzte Identitätsschicht, die nachgelagerte Systeme konsumieren.	Der Anbieter behauptet, das gesamte Daten- oder Compliance-Betriebsmodell zu ersetzen.

Dieselbe Bewertungslogik gilt für Kreditdaten und auskunfteinahe Prozesse. Der Tilores-Artikel zu Auskunfteien in Echtzeit zeigt, warum aktueller Entitätskontext zählt, wenn sich Identitäts- und Risikodaten laufend ändern.

Wie sollte eine Bank die Bewertung vor der Beschaffung durchführen?

Die sicherste Bewertung ist ein eingegrenzter Nachweis mit repräsentativen Datenmustern, definierten Datenschutzgrenzen und benannten Erfolgskriterien. Das Team sollte ein kleines, aber unsauberes Sample wählen, festlegen, was eine korrekte Übereinstimmung bedeutet, und False Positives und False Negatives gemeinsam mit den Teams prüfen, die das nachgelagerte Risiko tragen.

Lassen Sie den Nachweis nicht zu einem generischen Benchmark werden. Eine Bank, die das Onboarding prüft, interessiert sich für übersehene Duplikate, falsche Zusammenführungen, Auditnachweise und den Kontext für das Sanktionsscreening. Eine Bank, die die Bestandsbetreuung prüft, achtet womöglich stärker auf Abfragegeschwindigkeit, operative Korrektur und darauf, ob Mitarbeiter den aktuellen aufgelösten Kontext abrufen können, ohne Identitätslogik neu zu bauen.

Das Ergebnis des Nachweises sollte ein Entscheidungsprotokoll sein: welche Match-Verfahren genutzt wurden, welche Evidenz sichtbar war, welche Datensätze korrigiert wurden, welche Latenz im Zielprozess beobachtet wurde und was der Anbieter erklären konnte und was nicht. Dieses Protokoll ist nützlicher als eine Demo-Bewertung, weil Risiko, Compliance, Operations und Architektur es gemeinsam prüfen können.

FAQ

Was ist der erste Test für einen Identity-Resolution-Anbieter im Bankwesen?

Der erste Test ist, ob der Anbieter erklären kann, wie er echte Kunden-, Konto- und Gegenparteidatensätze mithilfe deterministischer Kennungen sowie probabilistischer und unscharfer Evidenz auflöst. Eine saubere Demo genügt nicht; der Test sollte repräsentative Datenmuster aus dem regulierten Umfeld verwenden.

Sollte Identity Resolution in Echtzeit oder im Batch erfolgen?

Regulierte Teams brauchen meist beides: Batch-Verarbeitung für historische Nachladungen und Zugriff mit geringer Latenz für operative Prozesse. Die wichtige Grenze ist, dass die Entitätsbildung stattfindet, wenn Daten aufgenommen oder geändert werden, während Anwendungen den aktuellen aufgelösten Kontext zur Abfragezeit abrufen.

Ersetzt Identity Resolution KYC- oder AML-Screening?

Nein. Identity Resolution steht neben KYC- und AML-Screening. Sie löst den Kunden, die Gegenpartei oder die verbundene Entität zunächst sauber auf, damit Screening-Engines Sanktions-, PEP- und Adverse-Media-Daten gegen einen besseren Identitätskontext prüfen können.

Welche Matching-Verfahren sollte eine Bank verlangen?

Verlangen Sie deterministische Regeln für starke Kennungen, probabilistische Bewertung für unvollständige Evidenz, Fuzzy Matching für Namen und Adressen sowie eine Möglichkeit, die Match-Evidenz einzusehen. Ein rein deterministischer Ansatz ist für unsaubere Bankdaten zu spröde.

Wie sollten Teams die Match-Qualität beurteilen?

Nutzen Sie ein gelabeltes Sample und prüfen Sie False Positives, False Negatives, Precision, Recall und Grenzfälle. Der richtige Schwellenwert hängt vom Prozess ab: Onboarding, Screening, Betrugsprüfung und Kundenservice vertragen unterschiedlich viele übersehene Verknüpfungen und falsche Zusammenführungen.

Was sollte Prüfbarkeit umfassen?

Prüfbarkeit sollte die Herkunft der Quelldatensätze, Regel- oder Score-Evidenz, Änderungshistorie, Korrekturwege und klaren Zugriff auf die aktuelle aufgelöste Entität umfassen. Ein Prüfer sollte sehen können, warum Datensätze verknüpft wurden und wie sich die Entscheidung korrigieren lässt.

Wo sollte Identity Resolution neben MDM und einem Warehouse sitzen?

Sie sollte als gemeinsam genutzte Identitätsschicht neben MDM-, CDP-, Warehouse-, KYC-AML- und operativen Systemen sitzen. Diese Systeme behalten ihre eigenen Aufgaben; die Auflösungsschicht liefert den aktuellen Entitätskontext und die Herkunftsnachweise, die sie nutzen können.

Was ist der sicherste nächste Schritt vor dem Kauf?

Führen Sie eine repräsentative Bewertung mit echten Datenmustern, ausdrücklichen Datenschutzgrenzen und benannten Erfolgskriterien durch. Die Bewertungsmatrix sollte Match-Qualität, Latenz, Prüfbarkeit, Deployment-Modell, Screening-Eignung und Korrekturprozesse abdecken, bevor über kommerzielle Konditionen gesprochen wird.