Entity Resolution Proof of Concept: 7 PoC-Inputs für Banken im Jahr 2026

Kurzfassung: Ein Entity Resolution Proof of Concept für eine Bank benötigt sieben PoC-Inputs: repräsentative Quellsystemauszüge; stabile Quell-IDs und Provenienz; Vergleichs- und Matching-Felder; bestätigte Match-, Non-Match- und ungeklärte Labels; schwierige Grenzfälle; relevante Änderungsereignisse; und schriftliche Akzeptanzkriterien. Bank und Anbieter sollten Sicherheitskontrollen, Ausgabeformat, Entscheidungsaussage und Verfeinerungsplan separat vereinbaren, bevor die Evaluation beginnt.

Planen Sie Ihren Proof of Concept mit uns. Demo buchen · Tilores Studio kostenlos testen.

Auf dieser Seite

1. Welche sieben Inputs benötigt der PoC?
2. Wie sollte die Bank repräsentative Datensätze auswählen?
3. Wie kann die Bank Kundendaten schützen?
4. Welche Kriterien sollten vor dem Test vereinbart werden?
5. Wie sollten PoC und Verfeinerungsprozess ablaufen?
6. Welche Nachweise sollte die Bank erhalten?
7. Welche weiteren Fragen stellen Bankteams?

Was sollte ein Entity Resolution PoC nachweisen?

Ein Entity Resolution PoC sollte nachweisen, dass eine Bank auf Basis ihrer eigenen Daten eine klar definierte Entscheidung zur Kundenidentität treffen kann. Dabei kann es darum gehen, ob zwei Datensätze zu demselben Kunden gehören, ob ein neuer Antragsteller bereits vorhanden ist oder ob historische Datensätze vor der Migration eines Customer Master konsolidiert werden können.

Der Test benötigt eine schriftlich festgelegte Abgrenzung. Benennen Sie die Quellsysteme, Kundenpopulationen, den Batch- oder Real-Time-Pfad und die nachgelagerte Nutzung. Ein breites Ziel wie „Customer 360 verbessern“ macht es Prüfern unmöglich, ein Matching-Ergebnis von einer Anforderung an Mastering, Workflow oder Datenqualität zu unterscheiden.

Die Evaluation sollte auch die betrieblichen Folgen eines Fehlers abbilden. Ein übersehenes Match kann die Kundensicht fragmentieren. Eine falsche Zusammenführung kann die Finanzdaten einer Person in das Profil einer anderen Person einordnen. Damit ist Präzision sowohl eine Datenschutzkontrolle als auch ein Maß für die Modellqualität.

Welche 7 PoC-Inputs benötigt ein Entity Resolution PoC für Banken?

Ein zweckmäßiges Input-Paket verbindet Kundendatensätze mit dem Kontext, der für ihre Bewertung erforderlich ist. Eine Flat File ohne stabile Identifikatoren, Labels oder Evaluationskriterien kann zeigen, dass die Software läuft, trägt aber keine belastbare Kaufentscheidung.

Input	Was bereitzustellen ist	Warum es wichtig ist
1. Repräsentative Quellsystemauszüge	Datensätze aus jeder relevanten Quelle, wobei die im normalen Betrieb auftretenden Varianten und fehlenden Werte erhalten bleiben.	Unterschiede zwischen Quellen entscheiden häufig darüber, ob eine Konfiguration auch außerhalb eines bereinigten Demonstrationsdatensatzes funktioniert.
2. Stabile Quell-IDs und Provenienz	Eine stabile Quelldatensatz-ID, der Name des Quellsystems und verfügbare Erstellungs- oder Aktualisierungsmetadaten.	Jede vorgeschlagene Verknüpfung, Korrektur und erneute Ausführung muss auf den Datensatz und die Quelle zurückgeführt werden können, aus denen sie entstanden ist.
3. Vergleichs- und Matching-Felder	Namen, Adressen, Geburtsdaten, Telefonnummern, E-Mail-Adressen und relevante Kunden- oder Unternehmensidentifikatoren.	Originalwerte bewahren Schreibweisen, Formatierungen und Transliterationsmuster, die für Normalisierung und Vergleich benötigt werden.
4. Bestätigte Match-, Non-Match- und ungeklärte Labels	Bestätigte Matches, bestätigte Non-Matches und ungeklärte Fälle, jeweils mit dem Grund für jede verfügbare Entscheidung.	Der PoC benötigt Nachweise sowohl für korrekte Verknüpfungen als auch für Verknüpfungen, die niemals entstehen dürfen.
5. Schwierige Grenzfälle	Namensänderungen, Adresswechsel, gemeinsame Haushalte, unvollständige Datumsangaben und doppelte Identifikatoren.	Grenzfälle zeigen, ob der Ansatz bei schwierigen Kundendaten erklärbar und reversibel bleibt.
6. Relevante Änderungsereignisse	Aktualisierungen, Löschungen, Wiedereröffnungen und andere Ereignisse, die die relevanten Kundendatensätze betreffen.	Änderungsereignisse testen, ob der Ansatz bei Veränderungen der Kundendaten nachvollziehbar bleibt.
7. Schriftliche Akzeptanzkriterien	Vereinbarte Messgrößen, Prüfrollen, das Ausgabeformat und Schwellenwerte für die Ausnahmebehandlung zur Bewertung des PoC.	Schriftliche Kriterien verhindern, dass sich die Bewertung ändert, nachdem Ergebnisse sichtbar sind.

Tilores unterstützt deterministisches, Fuzzy und probabilistisches Matching als getrennte Methoden. Die richtige Konfiguration hängt von den verfügbaren Nachweisen und dem Erklärbarkeitsbedarf der Bank ab. Die Produktübersicht zu Entity Resolution erklärt, wie Datensätze zu nachvollziehbaren Entitäten werden, während Quellwerte verfügbar bleiben.

Wie sollte eine Bank repräsentative Kundendatensätze auswählen?

Eine repräsentative Stichprobe deckt die Identitätsmuster ab, auf die das Produktionssystem treffen wird. Sie muss nicht die gesamte Datenlandschaft der Bank abbilden, aber jede Quelle und Variante enthalten, die die Entscheidung verändern könnte.

• Quellenabdeckung: beziehen Sie Datensätze aus jedem relevanten CRM, jeder Kernplattform, jedem Data Warehouse, Anwendungskanal oder Archiv ein.
• Wertevarianten: bewahren Sie Abkürzungen, Transliterationen, Tippfehler, alte Adressen, fehlende Felder und widersprüchliche Identifikatoren.
• Positive und negative Fälle: beziehen Sie bekannte Duplikate ebenso ein wie ähnliche Kunden, die getrennt bleiben müssen.
• Betriebszustände: beziehen Sie Aktualisierungen, Löschungen und erneute Übermittlungen ein, wenn der Produktionsanwendungsfall kontinuierlich ist.
• Risikofälle: beziehen Sie Datensätze ein, die Konsistenzregeln testen, etwa ein widersprüchliches Geburtsdatum oder eine widersprüchliche Steuer-ID.

Bereinigen Sie das Problem nicht vor der Evaluation. Wenn jeder Name und jede Adresse in einem einheitlichen Format ankommt, misst der Test nicht mehr die Normalisierungsarbeit, die Matching im Produktivbetrieb erfordert. Tilores kann Originalwerte zusammen mit normalisierten Werten bewahren und Konsistenzregeln anwenden, die die Bildung einer Entität bei einem Widerspruch zu einer Invariante verhindern.

Für KYC- und Customer-Mastering-Anwendungsfälle sollten Sie Fälle einbeziehen, die zeigen, wie eine aufgelöste Identität mit Workflows für Sanktionen, politisch exponierte Personen (PEP) und Adverse Media verbunden wird. OpenSanctions dokumentiert Entitäts- und Identifikatorstrukturen, die Teams bei der Gestaltung realistischer Screening-Testdaten unterstützen können. Der PoC sollte Identitätsverknüpfung, Screening-Ergebnis und Prüferentscheidung getrennt nachvollziehbar halten.

Wie kann eine Bank Kundendaten während eines PoC schützen?

Beginnen Sie mit Datenminimierung. Artikel 5 der DSGVO verlangt, dass personenbezogene Daten dem Zweck angemessen und erheblich sowie auf das notwendige Maß beschränkt sind. Die Bank sollte jedes angeforderte Feld einer Matching-Regel, einer Evaluationsmessgröße oder einem Untersuchungsbedarf zuordnen. Felder ohne Funktion im Test bleiben außen vor.

Der Schutz muss den getesteten Vergleich erhalten. Irreversibles Hashing kann für Gleichheitsprüfungen stabiler Werte funktionieren, doch ein gehashter Name oder eine gehashte Adresse enthält nicht mehr die Zeichenmuster, die für Fuzzy Matching, Transliteration oder Adressnormalisierung erforderlich sind. Bank und Anbieter sollten Maskierung, Tokenisierung, Verschlüsselung oder kontrollierten Klartextzugriff für jedes Feld einzeln festlegen. NISTIR 8053 beschreibt die Abwägungen bei der De-Identifizierung personenbezogener Informationen.

• Zweck: dokumentieren Sie, warum jedes Feld und jede Datensatzgruppe einbezogen wird.
• Übertragung: vereinbaren Sie einen genehmigten verschlüsselten Übertragungsweg und namentlich benannte Empfänger.
• Zugriff: beschränken Sie den Evaluationsarbeitsbereich auf autorisierte Teilnehmer.
• Aufbewahrung: dokumentieren Sie, wann Inputs, Outputs und temporäre Kopien zurückgegeben oder gelöscht werden.
• Deployment: entscheiden Sie, wo die Evaluation ausgeführt wird und wie Datenresidenz behandelt wird. Prüfen Sie die verfügbaren Tilores Deployment-Optionen im Rahmen dieser Entscheidung.

Die Governance für Anbieter beginnt vor dem Produktionsbetrieb. Die SR 23-4: Interagency Guidance on Third-Party Relationships: Risk Management der US-Bankenaufsichtsbehörden behandelt Planung, Due Diligence, Vertragsgestaltung, Überwachung und Beendigung als zusammenhängende Bestandteile des Risikomanagements. Ein PoC sollte der Bank Nachweise liefern, die in diese Kontrollen übernommen werden können.

Welche Kriterien sollten vor Testbeginn vereinbart werden?

Bank und Anbieter sollten die Scorecard schriftlich festlegen, bevor sie Ergebnisse prüfen. Die Werte richten sich nach Risikobereitschaft und Anwendungsfall der Bank. Ein seriöser Anbieter sollte daher keine universellen Schwellenwerte erfinden.

Kriterium	Frage für die Scorecard	Aufzubewahrende Nachweise
Präzision	Wie häufig sind vorgeschlagene Kundenverknüpfungen korrekt?	Bestätigte und falsche Verknüpfungen sowie die Regel oder der Nachweis hinter jedem Vorschlag.
Recall	Wie viele bekannte Duplikatbeziehungen werden erkannt?	Übersehene Verknüpfungen, Quellmuster und Felder, die das Ergebnis beeinflusst haben.
Erklärbarkeit	Kann ein Prüfer nachvollziehen, warum zwei Datensätze verknüpft wurden?	Feldvergleiche, Regelidentifikatoren, normalisierte Werte und Entscheidungshistorie.
Sicherheit	Welche Konflikte müssen die Bildung einer Entität verhindern?	Ergebnisse von Konsistenzregeln und schwierige negative Fälle.
Stewardship	Welche Fälle erfordern eine menschliche Prüfung und wie werden Korrekturen erfasst?	Prüfentscheidungen, Gründe, Benutzeridentität und Historie der Rücknahmen.
Betriebliche Eignung	Kann eine Konfiguration die erforderlichen Bulk- und Real-Time-Pfade unterstützen?	Reproduzierbare Requests, Outputs und relevante Änderungsereignisse.
Portabilität	Kann die Bank die resultierende Konfiguration behalten und verstehen?	Regeln, Feldzuordnungen und Implementierungsannahmen.

Ein Confidence Score allein erklärt keine Zusammenführung. In Tilores behalten Entitätsverknüpfungen den Regelidentifikator, durch den sie entstanden sind. So können Prüfer von der resultierenden Entität zu den beteiligten Datensätzen und der Regel zurückgehen. Die GraphQL API Reference beschreibt die Schnittstellen zum Suchen, Übermitteln und Anzeigen einer Vorschau von Datensätzen.

Wie sollten PoC und Verfeinerungsprozess ablaufen?

Der Verfeinerungszyklus: Kandidaten verknüpfen, menschliche Prüfung, Regel anpassen, erneute Ausführung und auditierbarer Output.

Der Prozess sollte fachliche Beurteilungen in eine reproduzierbare Konfiguration überführen. Bankspezialisten müssen keine Fuzzy-Logik entwerfen. Sie müssen korrekte und inkorrekte Kundenbeziehungen erkennen und die verwendeten Nachweise erklären können.

1. Entscheidungsaussage formulieren. Definieren Sie die Entscheidung zur Kundenidentität, die betroffenen Systeme, den Betriebsmodus und die Ausschlüsse.
2. Datenpaket vorbereiten. Stellen Sie über den vereinbarten sicheren Weg die sieben PoC-Inputs bereit: repräsentative Quellsystemauszüge; stabile Quell-IDs und Provenienz; Vergleichs- und Matching-Felder; bestätigte Match-, Non-Match- und ungeklärte Labels; schwierige Grenzfälle; relevante Änderungsereignisse; und schriftliche Akzeptanzkriterien.
3. Kontrollen und Kriterien vereinbaren. Dokumentieren Sie Zugriff, Aufbewahrung, Outputs, Prüfrollen und Akzeptanzmessgrößen, bevor Sie Ergebnisse bewerten.
4. Verknüpfungen und Nichtverknüpfungen prüfen. Lassen Sie Fach- und Datenspezialisten über vorgeschlagene Matches, abgelehnte Kandidaten und unsichere Fälle entscheiden und dokumentieren Sie, warum jede Korrektur erforderlich ist.
5. Nachweise verfeinern und nachvollziehen. Überführen Sie entschiedene Fälle in Konfigurationsänderungen, führen Sie den vereinbarten Evaluationsdatensatz erneut aus und dokumentieren Sie Regeln, Ergebnisse und Audit-Historie.

Dieser Zyklus ist wichtig, weil Ausnahmen Strukturen sichtbar machen. Eine gemeinsam genutzte Adresse kann in einem Segment ein Match stützen und in einem anderen zu einer gefährlichen falschen Zusammenführung führen. Ein fehlendes Geburtsdatum kann eine Prüfung erfordern, während ein widersprüchliches Geburtsdatum die Verknüpfung blockieren kann. Jede Korrektur sollte zu einer Regel, Konsistenzprüfung oder dokumentierten Ausnahme werden, die erneut getestet werden kann.

Welche Nachweise sollte die Bank am Ende erhalten?

Der PoC-Output sollte von jemandem reproduziert werden können, der nicht an den Arbeitssitzungen teilgenommen hat. Eine Folie mit einem aggregierten Score reicht für Prüfer aus Architektur, Beschaffung, Datenschutz und Data Governance nicht aus.

• das Input-Manifest, Felddefinitionen und die Quellenherkunft;
• die in der Evaluation verwendete Matching- und Normalisierungskonfiguration;
• verknüpfte, nicht verknüpfte und zur Prüfung vorgesehene Ergebnisse, die an stabile Datensatz-IDs gebunden sind;
• Gründe auf Feldebene und Regelidentifikatoren für vorgeschlagene Verknüpfungen;
• den gelabelten Evaluationsdatensatz und die Entscheidungshistorie;
• dokumentierte Datenkontrollen, Aufbewahrungsstatus und Löschungsnachweise;
• offene Einschränkungen, Implementierungsannahmen und die vorgeschlagene Produktionsabgrenzung.

Die resultierende Konfiguration, Feldzuordnungen und Implementierungsannahmen sollten für die Bank dokumentiert werden. Der Entity Event Stream veröffentlicht Merge- und Split-Ereignisse für die Integration in die umgebende Architektur. So kann die Bank die Matching Engine bewerten, ohne ihr Customer-Master-Betriebsmodell ersetzen zu müssen.

Welche weiteren Fragen stellen Bankteams zu Entity Resolution PoCs?

Muss eine Bank ihre gesamte Kundendatenbank teilen?

Ein Tilores PoC kann einen minimierten Auszug verwenden, der die relevanten Quellen, Varianten und schwierigen Entscheidungen weiterhin abbildet. Die Stichprobe muss die Muster bewahren, die die Engine für die Bewertung benötigt, während unnötige Felder und Datensätze außerhalb des Tests bleiben.

Können Kundendaten vor der Übermittlung gehasht werden?

Ein Tilores PoC kann geschützte Werte verwenden, wenn die Transformation den erforderlichen Vergleich ermöglicht. Irreversibles Hashing entfernt Zeichen- und Strukturvarianten, die für Fuzzy Matching und Normalisierung benötigt werden. Deshalb müssen Bank und Anbieter die Kontrollen für jedes Feld einzeln festlegen.

Welche Labels werden benötigt?

Ein Tilores PoC profitiert von bestätigten Matches, bestätigten Non-Matches und ungeklärten Fällen, die jeweils mit stabilen Quelldatensatz-IDs verknüpft sind. Labels sollten dokumentieren, wer die Entscheidung getroffen hat und warum, insbesondere wenn ähnliche Namen oder gemeinsam genutzte Adressen zu einer falschen Zusammenführung führen könnten.

Sollten Daten zu Sanktionen, PEP und Adverse Media einbezogen werden?

Ein Tilores PoC für KYC oder Customer Mastering sollte testen, ob aufgelöste Identitäten zuverlässig mit Workflows für Sanktionen, PEP und Adverse Media verbunden werden. Screening-Nachweis und Identity-Matching-Entscheidung müssen getrennt bleiben, damit Prüfer jedes Ergebnis zu seiner Quelle zurückverfolgen können.

Was sollte die Bank nach Abschluss des PoC erhalten?

Ein Tilores PoC sollte der Bank reproduzierbare Inputs, die in der Evaluation verwendete Matching-Konfiguration, verknüpfte und nicht verknüpfte Ergebnisse, Erklärungen für jede Entscheidung, die Entscheidungshistorie und ein abgestimmtes Bild des späteren Produktionsumfangs liefern.

Wie kann eine Bank ihre Evaluation vorbereiten?

Beginnen Sie mit der Entscheidung, die die Bank treffen muss. Erstellen Sie anschließend das kleinste Datenpaket, das diese Entscheidung noch repräsentiert. Stabile Identifikatoren, realistische Varianten, schwierige negative Fälle und schriftliche Kriterien sind wichtiger als ein großer Auszug mit schwachem Kontext.

Tilores kann dabei helfen, Anwendungsfall, Datenfelder, Kontrollen und Prüfprozess in einen Evaluationsplan zu überführen. Demo buchen, um die Architektur zu besprechen, oder Tilores Studio kostenlos testen, um mit dem Test zu beginnen.

Quellen

1. Regulation (EU) 2016/679, General Data Protection Regulation, European Union.
2. NISTIR 8053: De-Identification of Personal Information, National Institute of Standards and Technology.
3. SR 23-4: Interagency Guidance on Third-Party Relationships: Risk Management, Board of Governors of the Federal Reserve System.
4. OpenSanctions Documentation, OpenSanctions.
5. Entity Resolution Product Overview, Tilores.
6. Deployment Options, Tilores.
7. GraphQL API Reference, Tilores.
8. Entity Event Stream, Tilores API Reference.