Warum Batch-Entity-Resolution für Echtzeit-KYC nicht ausreicht

Kurzfassung: Batch-Werkzeuge für Entity Resolution wie Splink sind hervorragend in der Offline-Analyse: eine Liste deduplizieren, Ground Truth labeln, Match-Wahrscheinlichkeiten modellieren. KYC-Onboarding und Sanktions-Screening finden aber zur Abfragezeit statt. Wenn sich ein Kunde registriert, müssen Sie ihn innerhalb von Millisekunden gegen Ihre bestehenden Entitäten und gegen Watchlists auflösen – und nicht auf den nächsten nächtlichen Batch warten. Diese Lücke ist architektonisch bedingt und keine Frage der Feinjustierung. Ein Batch-Lauf erzeugt eine einmalige Paarliste; Echtzeit-KYC braucht einen dauerhaften, abfragbaren Entitätsindex. In unserem Benchmark beantwortete dieser Index Suchanfragen auf einem Datensatz mit 1 Mio. Einträgen in 8,6 ms p95. Nutzen Sie Open-Source-Batch-Tools für Offline-Listenanalyse und Modellierung – und Tilores für den produktiven Echtzeitpfad.

Sehen Sie es auf Ihren Daten: Demo buchen, um Echtzeit-KYC-Auflösung auf Ihren eigenen Datensätzen durchzugehen, oder Tilores Studio kostenlos testen, um es lokal auszuprobieren.

Was bedeutet „Batch” für KYC eigentlich?

Batch-Entity-Resolution läuft über eine feste Momentaufnahme der Daten. Sie übergeben einem Deduplizierungs-Tool eine Datei mit Datensätzen, es verknüpft diejenigen, die sich auf dieselbe Entität beziehen, und liefert eine Liste übereinstimmender Paare oder Cluster zurück. Das ist das Modell hinter Splink, der glaubwürdigsten heute verfügbaren Open-Source-Bibliothek für Record Linkage: entwickelt im britischen Justizministerium, probabilistisch, erklärbar und kostenlos. Sie ist hervorragend in dem, was sie tut.

Das Problem: KYC ist keine Momentaufnahme. Ein Interessent füllt ein Onboarding-Formular aus und klickt auf Absenden. In diesem Moment, bevor Sie ein Konto eröffnen und bevor Geld fließt, müssen Sie zwei Fragen beantworten. Haben wir diese Person schon einmal gesehen, unter einem leicht abweichenden Namen oder einer veralteten Adresse? Und: Stimmt diese Person, einmal aufgelöst, mit jemandem auf einer Sanktions- oder PEP-Liste überein? Beides muss jetzt beantwortet werden, gegen den aktuellen Stand Ihrer Daten und den aktuellen Stand der Watchlists.

Eine Batch-Pipeline kann „jetzt” nicht beantworten. Bis der nächste Lauf startet, ist der Kunde längst onboardet. Genau um diese Lücke geht es in diesem Beitrag.

Warum ist Onboarding ein Problem der Abfragezeit und kein Batch-Problem?

Onboarding ist interaktiv. Der Antragsteller wartet, das Frontend blockiert auf eine Entscheidung, und nachgelagerte Systeme (Ihre KYC-Plattform, Ihre Sanktions-Screening-Engine, Ihre Betrugsregeln) brauchen ein einziges aufgelöstes Subjekt, auf das sie sich beziehen können. Wenn Sie das rohe Antragsformular statt der aufgelösten Entität screenen, screenen Sie ein Fragment: eine Schreibweise des Namens, eine Adresse, eine Telefonnummer. Sie übersehen den Aliasnamen, den dieselbe Person vor zwei Jahren nutzte, das unter dem Geburtsnamen eröffnete Doppelkonto, den verknüpften Datensatz, der die Risikoeinstufung verändert hätte.

Erst auflösen, dann screenen – diese Reihenfolge liefert die richtige Antwort. Aber „erst auflösen” funktioniert nur, wenn die Auflösung synchron, im Request-Pfad und auf Ebene eines einzelnen Datensatzes verfügbar ist. Sie lösen nicht eine Million Datensätze neu auf. Sie fragen: „Welche Entität ist – angesichts all dessen, was wir bereits wissen – dieser eine neue Datensatz, und wie sieht sein vollständiger Kontext aus?” Das ist eine Abfrage, und dafür braucht es eine Abfrage-Engine.

Der architektonische Unterschied ist derselbe, den wir in unserem reproduzierbaren Benchmark gegen Splink gefunden haben: Ein Batch-Tool erzeugt eine einmalige Paarliste, während eine Echtzeit-Engine einen dauerhaften, abfragbaren Entitätsindex pflegt. Eine Paarliste ist ein fertiges Artefakt ohne API, um ihr nach dem Lauf eine neue Frage zu stellen. Ein Index ist eine lebende Struktur, die Sie bei jedem eintreffenden Kunden durchsuchen.

Wie schnell muss die Auflösung zur Abfragezeit sein?

Schnell genug, dass sie im Onboarding-Ablauf nicht auffällt. Die Auflösung ist ein Schritt in einer Kette, zu der auch Formularvalidierung, Dokumentenprüfung, Screening-Aufrufe und Risikobewertung gehören; sie darf nicht das langsame Glied sein.

Im Benchmark lag die Suchlatenz gegen den dauerhaften Entitätsindex mit 1 Mio. Datensätzen bei 8,6 ms p95 im LAN. Das ist der Aufwand, einen neuen Datensatz gegen die gesamte bekannte Population aufzulösen und seinen aufgelösten Kontext zurückzuerhalten: ein einzelner Lookup, kein vollständiger Neulauf. Bei dieser Latenz passt Echtzeit-Auflösung bequem in einen synchronen Onboarding-Request – mit reichlich Luft für alles andere in der Kette.

Zum Vergleich: Derselbe Benchmark zeigte, dass Splink alle 1 Mio. Datensätze in 9,24 Sekunden dedupliziert – als eingebettete DuckDB-Bibliothek, mit herausragendem Batch-Durchsatz und kostenlos. Aber 9,24 Sekunden sind ein Batch-Wert: die Zeit, die gesamte Liste einmal zu verarbeiten, nicht die Zeit, eine einzelne Live-Abfrage zu beantworten. Die beiden Zahlen messen Unterschiedliches – und genau das ist der Punkt. Batch optimiert den Durchsatz für die gesamte Liste; KYC braucht Latenz pro Datensatz.

Dimension	Batch-Deduplizierung (z. B. Splink)	Auflösung in Echtzeit (Tilores)
Arbeitseinheit	Gesamter Datenbestand, erneuter Lauf	Einzelner Datensatz / einzelne Abfrage
Ergebnis	Einmalige Paarliste oder Cluster-Datei	Dauerhafter, abfragbarer Entitätsindex
Aktualität	Stand des letzten Laufs	Aktuell, inklusive des gerade übermittelten Datensatzes
Eignung fürs Onboarding	Nachträglich	Synchron, im Request-Pfad
Sanktions-Screening	Gegen eine Momentaufnahme	Gegen die aktuelle aufgelöste Entität
Benchmark-Wert	1 Mio. Datensätze in 9,24 s (Durchsatz)	8,6 ms p95 pro Suche (Latenz)

Wie verändert das Sanktions- und Watchlist-Screening?

Beim Sanktions-Screening ist die Batch-Lücke am gefährlichsten. Watchlists ändern sich ständig. Die OFAC veröffentlicht über ihren Sanctions List Service, das Vereinigte Königreich pflegt die UK Sanctions List, und die EU veröffentlicht eine konsolidierte Liste der Finanzsanktionen. Auch Ihre Kundendaten ändern sich laufend. Einen veralteten, unvollständigen Kundendatensatz gegen eine Liste zu screenen, erzeugt vermeidbare Unklarheit und vermeidbare Lücken.

Eine Unterscheidung ist hier wichtig und verschwimmt leicht: Die Listenquelle ist nicht die Auflösungs-Engine. Woher die Sanktions-, PEP- und Adverse-Media-Daten stammen (OpenSanctions, OFAC, ein kommerzieller Screening-Anbieter), ist eine andere Frage als die nach der Engine, die Ihre Kunden zu sauberen Entitäten auflöst. Tilores veröffentlicht und pflegt keine Watchlists. Tilores sorgt dafür, dass das Subjekt, das Sie screenen, der vollständig aufgelöste Kunde ist – mit allen verknüpften Datensätzen, Aliasnamen und Duplikaten, zusammengefasst in einer Entität. So vergleicht Ihr Screening-Tool das richtige, vollständige Gegenüber mit der Liste.

In der Praxis sieht der Ablauf so aus: Den eingehenden Kunden zur Abfragezeit gegen Ihre bestehenden Entitäten auflösen und dann die aufgelöste Entität (samt bekannter Aliasnamen und zulässiger verknüpfter Datensätze) an Ihre Screening-Engine übergeben. Die Screening-Engine behält die Logik für den Listenabgleich und die Fallentscheidung. Die Auflösung stellt sicher, dass sie eine ganze Person screent und kein Fragment. Die Wolfsberg-Leitlinien zum Sanktions-Screening stellen klar, dass ein Alarm nur ein erster Schritt ist und zusätzlicher Kontext nötig ist, um einen echten Treffer zu bestätigen oder auszuschließen. Eine aufgelöste Entität ist genau dieser Kontext.

Was ist mit Customer 360 beim Onboarding?

Dieselbe Auflösung zur Abfragezeit, die das Screening absichert, baut auch die Customer-360-Sicht genau dann auf, wenn sie am nützlichsten ist: bei der Kontoeröffnung. Wenn ein neuer Antrag eingeht, beantwortet die sofortige Auflösung gegen Ihren Bestand die Frage „Ist das ein wiederkehrender Kunde?”, bevor Sie ein Duplikat anlegen. Das verhindert das stille Wuchern gespaltener Identitäten, die später das Monitoring beschädigen, das Risikoexposure aufblähen und jede nachgelagerte Auswertung untergraben.

Tilores löst und verknüpft Datensätze bei der Datenaufnahme und liefert den aufgelösten Entitätskontext zur Abfragezeit. Tilores steht neben Ihren bestehenden MDM-, CDP-, Data-Warehouse-, KYC- und AML-Systemen und liefert ihnen den aufgelösten Kundenschlüssel, der ihnen fehlt – statt sie zu ersetzen. Ihre KYC-Plattform behält ihre Regeln und ihre Fallbearbeitung; Tilores versorgt sie mit einem sauberen, aktuellen Subjekt. Wie dieses aufgelöste Profil zurück in die Quellsysteme synchronisiert wird, zeigt Tilores Customer 360.

Bleibt die Auflösung für ein Audit ausreichend nachvollziehbar?

Ja – und Erklärbarkeit ist im regulierten Onboarding nicht verhandelbar. Ein Match, den Sie nicht verteidigen können, ist ein Risiko, wenn die Entscheidung eine Kontoeröffnung, eine Zahlungsfreigabe oder eine Sanktionseskalation betrifft. Der Prüfer muss sehen können, warum eine Entität zurückgegeben wurde: welche Quelldatensätze verknüpft wurden, welche Felder übereinstimmten, welche Felder sich widersprechen.

Tilores stellt überprüfbare Signale über seine API bereit. Suchergebnisse enthalten score und hitScore (in der API-Dokumentation spiegelt score die Gesamtqualität der Übereinstimmung innerhalb einer Entität wider, während hitScore die Übereinstimmung mit den Suchparametern abbildet), und recordInsights legt die zugrunde liegenden Belege auf Datensatzebene offen. Das sind Signale, die Ihre Richtlinien informieren und in Ihren Audit-Trail einfließen – keine universellen Schwellenwerte, die man blind anwendet; kalibrieren Sie sie auf Ihre Daten und Ihre Risikobereitschaft. Für KYC zählt vor allem: Die aufgelöste Entität kommt mit ihren Belegen an, sodass eine Analystin oder ein Auditor im Nachhinein die Entscheidung rekonstruieren kann.

Wann also Batch-Tools einsetzen und wann Tilores?

Es hängt davon ab, ob Ihre KYC-Frage in einer Momentaufnahme oder im Request-Pfad lebt.

Wählen Sie	Wenn
Open-Source-Batch (z. B. Splink)	Offline-Listenanalyse · Deduplizierung eines festen Datenbestands · Ground Truth labeln · Match-Wahrscheinlichkeiten modellieren und justieren · kostenlose F&E mit voller Kontrolle, bei der das Ergebnis eine Liste ist und keine Echtzeitanforderung besteht.
Tilores	Echtzeit-KYC-Onboarding · einen einzelnen neuen Datensatz im Request-Pfad gegen Ihren Bestand auflösen · die aufgelöste Entität synchron gegen Watchlists screenen · ein dauerhafter, abfragbarer Entitätsindex · Customer 360 bei der Kontoeröffnung.
Beides	Batch-Werkzeuge für Prototyping, Ground-Truth-Labeling und Offline-Modellarbeit; Tilores für den produktiven Echtzeitpfad.

Nichts davon heißt, dass Batch-Auflösung schlecht ist. Unser Benchmark zeigte, dass Splink eine starke Genauigkeit erreicht (F1 0,8867), und das kostenlos und mit ausgezeichnetem Batch-Durchsatz. Für die Offline-Analyse bleibt Splink eine hervorragende Wahl. Es geht hier um Passung. In dem Moment, in dem Ihre Anforderung lautet „über diesen Kunden jetzt entscheiden, gegen aktuelle Daten und aktuelle Listen”, kann eine Paarliste nicht antworten – ein dauerhafter Index schon. KYC-Onboarding und Sanktions-Screening liegen eindeutig im Echtzeitlager.

FAQ

Kann ich meine Batch-Deduplizierung nicht einfach häufiger laufen lassen?

Ein Batch-Job stündlich oder alle paar Minuten verkleinert die Lücke, schließt sie aber nie – und er skaliert schlecht, weil jeder Lauf den gesamten Datenbestand erneut verarbeitet. KYC-Onboarding ist synchron: Der Antragsteller wartet, und die Entscheidung hängt an der Auflösung. Das erfordert eine Einzelsatz-Abfrage, die in Millisekunden beantwortet wird – eine andere Architektur als ein Batch-Lauf in engerem Takt.

Liefert Tilores die Sanktions- und Watchlist-Daten?

Nein. Die Listenquelle – OpenSanctions, OFAC, die britischen oder EU-Listen oder ein kommerzieller Screening-Anbieter – ist von der Auflösungs-Engine getrennt. Tilores löst Ihre Kundendatensätze zu sauberen, vollständigen Entitäten auf, damit Ihr Screening-Tool das richtige Subjekt mit der von Ihnen genutzten Liste vergleicht. Tilores veröffentlicht und pflegt keine Watchlists.

Wo findet die Auflösung statt – bei der Datenaufnahme oder zur Abfragezeit?

Beides, und zwar bewusst. Datensätze werden bei der Aufnahme aufgelöst und verknüpft, damit der Entitätsindex aktuell bleibt. Zur Abfragezeit ruft der Onboarding- oder Screening-Prozess den aufgelösten Entitätskontext ab – inklusive des gerade übermittelten Datensatzes – statt Identität aus rohen Fragmenten zusammenzusetzen. Die Auflösung bei der Aufnahme hält die Identitätsentscheidung steuerbar; der Lookup zur Abfragezeit macht Echtzeit-KYC überhaupt erst möglich.

Wie schnell ist ein Auflösungs-Lookup in Echtzeit?

In unserem veröffentlichten Benchmark lief die Suche gegen einen dauerhaften Entitätsindex mit 1 Mio. Datensätzen bei 8,6 ms p95 im LAN. Das ist die Latenz, um einen einzelnen neuen Datensatz gegen die gesamte bekannte Population aufzulösen – schnell genug, um neben Validierung, Dokumentenprüfung und Screening in einen synchronen Onboarding-Request zu passen.

Ersetzt Tilores meine KYC- oder Sanktions-Screening-Plattform?

Nein. Tilores ist eine Echtzeit-API für Entity Resolution, die neben Ihren bestehenden MDM-, CDP-, Warehouse-, KYC- und AML-Systemen steht. Sie liefert das aufgelöste, aktuelle Kundensubjekt, das diese Systeme brauchen; die Screening-Regeln, die Fallbearbeitung und die endgültigen Entscheidungen bleiben bei ihnen. Die Auflösung verbessert den Input für das Screening – sie übernimmt das Screening nicht.

Ist der Latenzwert reproduzierbar?

Ja. Der Wert von 8,6 ms p95 stammt – zusammen mit dem vollständigen Genauigkeitsvergleich und der Methodik – aus unserem offenen Benchmark unter github.com/tilotech/tilores-splink-benchmark. Die ausführliche Auswertung finden Sie unter Splink vs. Tilores: Ein reproduzierbarer Benchmark mit 1 Million Datensätzen.