Entity Resolution Kaufberatung: API-nativ vs. On-Premise vs. Open Source (2026)

Kurzfassung: Die Wahl einer Entity-Resolution-Plattform läuft 2026 auf fünf Entscheidungen hinaus: das Deployment-Modell (API-nativ, On-Premise oder Open Source im Eigenbetrieb), das Latenzprofil (Real-Time zur Abfragezeit oder nächtlicher Batch), den Matching-Ansatz (deterministisch plus probabilistisch), die Tiefe der Erklärbarkeit und die Pflichten zur Datenresidenz. Nutzen Sie die Bewertungsmatrix weiter unten, um diese Kriterien auf jeden Anbieter anzuwenden, bevor Sie eine Shortlist erstellen.

Welche Kriterien unterscheiden Entity-Resolution-Plattformen 2026 wirklich?

Entity Resolution ist der Prozess, zu entscheiden, ob zwei Datensätze trotz abweichender Schreibweisen bei Name, Adresse oder Kennung dieselbe reale Entität bezeichnen. Jede ernstzunehmende Plattform kombiniert heute deterministische Regeln (exakte Feldübereinstimmung) mit probabilistischem Matching (gewichtete Bewertung über partielle Signale hinweg). Was Anbieter 2026 unterscheidet, ist nicht, ob sie beides beherrschen, sondern wie sie diese Fähigkeiten über sechs operative Dimensionen hinweg zugänglich machen: Deployment-Modell, Latenzprofil, Erklärbarkeit, Eignung für regulierte Anwendungsfälle, Datenresidenz und Gesamtbetriebskosten. Die folgende Bewertungsmatrix erzwingt zu jedem dieser Punkte eine bewusste Entscheidung, statt sie vom Anbietermarketing zu einer einzigen Aussage verschmelzen zu lassen.

API-nativ, On-Premise oder Open Source: Welches Deployment-Modell passt zu Ihrem Team?

Das Deployment-Modell ist der erste Filter, weil es alles Nachgelagerte bestimmt: wer die Infrastruktur betreibt, wer sich um die Skalierung kümmert und wohin Daten physisch wandern.

API-nativ (Cloud-gehostetes SaaS): Der Anbieter betreibt die Matching-Engine. Ihr Team ruft einen Endpunkt auf. Die Einrichtung geht schnell, die Skalierung läuft automatisch. Der Kompromiss: Ihre Datensätze gelangen in eine fremde Umgebung, was bei bestimmten Datenklassifizierungen und für Kunden in der EU, im asiatisch-pazifischen Raum oder in stark regulierten Branchen problematisch ist. Außerdem sind Sie von der Verfügbarkeit und dem Schema des Anbieters abhängig.

On-Premise oder Private-Cloud-Deployment: Die Engine läuft in Ihrer VPC oder Ihrem Rechenzentrum. Datensätze verlassen Ihren Perimeter nie. Das ist die bevorzugte Architektur für Banken, Versicherer und Behörden mit strengen Anforderungen an die Datensouveränität oder dort, wo Kundendaten rechtlich nicht bei einem Drittanbieter liegen dürfen. Der Preis dafür: Ihr Team verantwortet Bereitstellung, Patching und Skalierung. Manche Anbieter führen das als separate SKU, andere sind eigens dafür gebaut.

Open Source im Eigenbetrieb: Frameworks wie Splink (UK Cabinet Office, Apache-Lizenz) erlauben probabilistisches Record Linkage ohne Lizenzgebühr. Die Matching-Logik ist transparent und prüfbar. Die eigentlichen Kosten liegen im Engineering: Sie verantworten Modellkonfiguration, Kalibrierung der Schwellenwerte, Performance-Tuning, Skalierungsinfrastruktur und laufende Wartung – wie unser reproduzierbarer Benchmark Splink vs. Tilores zeigt. Für Teams, die feingranulare Kontrolle über das Matching-Modell brauchen und die Engineering-Kapazität dafür haben, ist Open Source eine ernsthafte Option. Für Teams, die operative Zuverlässigkeit und Real-Time-Latenz ohne eigenes ML-Ops-Team benötigen, ist es meist die falsche Wahl.

Ein viertes Muster gewinnt 2026 an Bedeutung: kommerzielle Plattformen mit Deployment in der eigenen Umgebung. Sie laufen innerhalb Ihrer VPC und verbinden die operative Zuverlässigkeit kommerzieller Produkte mit den Datensouveränitätsgarantien von On-Premise. Die Engine wird in Ihre Umgebung ausgerollt; der Anbieter betreut die Software, nicht Ihre Daten.

Real-Time vs. Batch: Wann spielt das Latenzprofil wirklich eine Rolle?

Entity Resolution umfasst zwei unterschiedliche Phasen, und wer sie verwechselt, trifft schlechte Kaufentscheidungen.

Auflösung bei der Datenaufnahme bedeutet, einen eingehenden Datensatz beim Eintreffen einem bestehenden Entitäts-Cluster zuzuordnen oder ein neues Cluster anzulegen. Das ist eine Schreiboperation. Batch-Systeme erledigen sie in geplanten Läufen, typischerweise nächtlich oder stündlich. Der aufgelöste Zustand, den Sie abfragen, ist immer leicht veraltet.

Abruf zur Abfragezeit bedeutet, den aktuellen aufgelösten Kontext einer Entität zurückzugeben, wenn ein nachgelagertes System oder ein Nutzer danach fragt. Das ist eine Leseoperation. Ein Real-Time-System löst bei der Datenaufnahme auf und stellt das Ergebnis sofort für den Abruf bereit.

Die praktische Frage lautet: Was kostet eine veraltete Auflösung in Ihrem Anwendungsfall?

Kunden-Onboarding und KYC: Veraltete Auflösung ist ein Compliance-Risiko. Trifft ein neues Konto ein, das zu einer sanktionierten Entität passt, und läuft der Auflösungs-Batch erst um Mitternacht, haben Sie ein Zeitfenster mit offenem Risiko. Hier ist Real-Time-Auflösung bei der Datenaufnahme zwingend.
Betrugserkennung: Dieselbe Logik. Eine Transaktion mit Verbindung zu einem bekannten Betrugsring muss sofort markiert werden, nicht erst nach dem nächsten Batch-Lauf.
Customer-360-Analytics und Marketing: Eine Verzögerung von Stunden oder sogar einem Tag ist meist vertretbar. Batch-Auflösung ist angemessen, und die geringere operative Komplexität ist ein Vorteil.
KI-Assistenten und RAG-Pipelines: Ruft ein Large Language Model Entitätskontext ab, um Fragen zu Kunden zu beantworten, muss die Auflösung zum Abrufzeitpunkt aktuell sein. Veralteter aufgelöster Kontext erzeugt überzeugend klingende falsche Antworten.

Eine ausführliche Betrachtung des Kompromisses zwischen Compliance und Latenz im regulierten Onboarding finden Sie in unserer Analyse zu Echtzeit-Entity-Resolution für AML und KYC.

Was bedeutet „erklärbares Matching” in der Praxis, und warum verlangen Compliance-Teams es?

Eine Match-Entscheidung ist erklärbar, wenn ein menschlicher Prüfer genau sehen kann, welche Felder übereinstimmten, welche unscharf waren, welche Gewichte angewendet wurden und welcher Konfidenzwert daraus resultierte. Die Alternative ist ein System, das ein binäres Match oder einen Score ohne belegende Evidenz zurückgibt.

Für Compliance-Teams ist Erklärbarkeit kein Komfortmerkmal. Finanzaufsichtsbehörden erwarten von Instituten, automatisierte Entscheidungen mit Auswirkung auf das Risikorating von Kunden zu erklären, und ein Blackbox-Score genügt dieser Anforderung nicht. Sanktionsscreening erzeugt False Positives: Ein Prüfer muss sehen können, welche Felder mit welcher Gewichtung übereinstimmten, bevor er einen Alert schließen kann. Wenn nach einer Veränderung der Datenqualität die Schwellenwerte neu kalibriert werden müssen, lassen sich Systeme, die Match-Evidenz auf Feldebene offenlegen, weit besser steuern als solche ohne. Deterministische Regeln sind von Natur aus erklärbar; probabilistisches Matching erfordert, dass Feature-Gewichte und einzelne Feld-Scores sichtbar gemacht werden. Beides ist machbar, aber nicht jede Plattform setzt den probabilistischen Fall auf Feldebene um.

Die Abwägung zwischen Precision und Recall in der Entity Resolution hängt unmittelbar damit zusammen: Erklärbarkeit erlaubt es nachzuvollziehen, ob eine Schwellenwertänderung bessere Precision oder besseren Recall bringt – und für welche Datensatztypen.

Wie sieht eine Bewertungsmatrix für die Prüfung beliebiger Entity-Resolution-Anbieter aus?

Nutzen Sie diese Tabelle als Ausgangsrahmen. Bewerten Sie jeden Anbieter je Kriterium auf einer Skala von 1 (nicht vorhanden oder schwach), 2 (teilweise) bis 3 (stark). Ergänzen Sie Gewichtungsspalten für Ihren konkreten Kontext.

Kriterium	Was zu prüfen ist	Regulierte Fintechs / KYC	Data Engineering / Analytics
Deployment-Modell	Kann es in Ihrer Umgebung laufen? Überschreiten Daten den Perimeter des Anbieters?	Kritisch (muss in der eigenen Umgebung oder On-Premise laufen)	Mittel (SaaS akzeptabel, sofern die Datenklassifizierung es zulässt)
Real-Time-Auflösung bei der Datenaufnahme	Aktualisiert sich das Entitäts-Cluster beim Eintreffen eines neuen Datensatzes oder nur im Batch?	Kritisch	Gering (Batch reicht meist)
Real-Time-Abruf zur Abfragezeit	Können nachgelagerte Systeme den aktuellen aufgelösten Zustand ohne Verzögerung per API abfragen?	Kritisch	Mittel
Deterministisches UND probabilistisches Matching	Werden sowohl exakte Regeln als auch unscharfe/gewichtete Bewertung unterstützt? Sind Schwellenwerte konfigurierbar?	Kritisch	Kritisch
Erklärbarkeit (Evidenz auf Feldebene)	Legt jede Match-Entscheidung die beitragenden Felder, Gewichte und den Konfidenzwert offen?	Kritisch	Mittel
Screening auf Sanktionen / PEP / Adverse Media	Native Anbindung an Listen wie OpenSanctions? Alert-Workflow bei Treffern?	Kritisch	Für die meisten nicht relevant
Steuerung der Datenresidenz	Lassen sich Daten auf eine Region oder Jurisdiktion festlegen? Unterstützung für DSGVO Artikel 25 (Data Protection by Design)?	Kritisch (EU AI Act / DSGVO)	Mittel
API-First-Entwicklererfahrung	REST- oder GraphQL-API? Qualität der SDKs? Zeit bis zur ersten Integration?	Hoch	Hoch
Integration in MDM / CDP / Warehouse	Ergänzt es Ihren bestehenden Datenstack oder versucht es, ihn zu ersetzen?	Hoch	Hoch
Gesamtbetriebskosten	Engineering-Stunden für Betrieb, Pflege der Schwellenwerte und Schemaänderungen	Mittel	Kritisch (bei Open Source oft unterschätzt)

Wie sollten regulierte Käufer an Sanktions-, PEP- und Adverse-Media-Screening herangehen?

Sanktionsscreening ist eine spezielle Anwendung von Entity Resolution mit zusätzlichen Anforderungen. Die Kernaufgabe besteht darin, eine eingehende Entität (einen Neukunden, eine Transaktionsgegenpartei, einen wirtschaftlich Berechtigten) mit kuratierten Listen sanktionierter Personen, politisch exponierter Personen und Entitäten mit negativer Medienberichterstattung abzugleichen. Die Schwierigkeit: Listeneinträge und Kundendatensätze stimmen selten exakt überein – Namen werden transliteriert, Geburtsdaten sind unvollständig, Aliasnamen sind die Regel.

Eine leistungsfähige Plattform muss all das abdecken:

Unscharfes Namensmatching über Transliterationsvarianten und Aliasnamen hinweg, nicht nur exakter Zeichenkettenvergleich.
Aktualität der Listen: Sanktionslisten werden fortlaufend aktualisiert. Die OFAC-SDN-Liste, die konsolidierte UN-Liste, die konsolidierte EU-Liste und Open-Source-Listen wie OpenSanctions haben unterschiedliche Aktualisierungsfrequenzen. Die Plattform muss Schritt halten.
Erklärbarkeit von Alerts: Aufsichtsbehörden erwarten, dass ein Institut dokumentiert, warum ein Alert ausgelöst und warum er geschlossen wurde. Für eine belastbare Alert-Bearbeitung ist Match-Evidenz auf Feldebene erforderlich.
False-Positive-Rate: Hohe False-Positive-Raten verursachen erheblichen operativen Aufwand in Compliance-Teams. Die Kalibrierung der Schwellenwerte und die Qualität des probabilistischen Matchings wirken sich direkt darauf aus.
Audit-Log: Jede Screening-Entscheidung, einschließlich Freigaben und Eskalationen, muss mit Zeitstempel und der zum Entscheidungszeitpunkt aufgelösten Evidenz protokolliert werden.

PEP-Screening erfordert zusätzlich eine laufende Überwachung: Wer beim Onboarding keine politisch exponierte Person war, kann später eine werden. Das setzt eine Plattform voraus, die Entitäten gegen aktualisierte Listen erneut auflösen kann und nicht nur bei der Datenaufnahme screent. DSGVO Artikel 25 bringt eine weitere Überlegung mit sich: Datenschutz durch Technikgestaltung verlangt Zweckbindung, sodass ein Auflösungssystem, das Datensätze über den Screening-Zweck hinaus anreichert, ein Risiko schaffen kann. Plattformen, mit denen sich der in jedem Auflösungskontext verwendete Datenumfang eingrenzen lässt, sind hier im Vorteil.

Wie hoch sind die tatsächlichen Gesamtbetriebskosten von Open-Source-Entity-Resolution?

Open-Source-Frameworks wie Splink sind eine legitime Option für Teams mit substanzieller ML-Ops-Kapazität. Die Lizenzkosten liegen nahe null, und die Matching-Logik ist prüfbar. Typischerweise unterschätzt werden: die Kalibrierung der Schwellenwerte (probabilistisches Matching erfordert wiederkehrendes Labeln von Ground-Truth-Daten, wenn sich die Datenqualität verschiebt), die Verantwortung für die Infrastruktur (Bereitstellung, Skalierung, Patching), das Nachrüsten von Real-Time-Ingestion auf Frameworks, die für Batch entworfen wurden, sowie eigens gebaute Instrumentierung für die Audit-Trails auf Feldebene, die Aufsichtsbehörden erwarten. Für die meisten Produktivszenarien mit Anforderungen an Real-Time-Auflösung und Compliance-Audit-Trails übersteigen die vollen Gesamtbetriebskosten von Open Source die kommerzieller Alternativen. Einen bewerteten Vergleich finden Sie in unserem Leitfaden zu Entity-Resolution-Tools für Unternehmen 2026.

Wo steht Tilores in dieser Landschaft?

Tilores ist eine API-native Entity-Resolution-Plattform, die in Ihrer eigenen Umgebung ausgerollt wird. Datensätze werden bei der Datenaufnahme sowohl deterministisch als auch probabilistisch aufgelöst, und der aktuelle aufgelöste Entitätskontext ist zur Abfragezeit per API abrufbar. Die Plattform ist darauf ausgelegt, neben bestehender MDM-, CDP-, KYC-AML- und Data-Warehouse-Infrastruktur zu stehen, nicht sie zu ersetzen. Das Deployment in der eigenen Umgebung bedeutet, dass Daten Ihren Perimeter nicht verlassen, und die Match-Erklärbarkeit auf Feldebene macht jede Entscheidung prüfbar.

Wo Tilores nicht die vollständige Antwort ist: Es ist eine Auflösungs- und Abrufschicht, kein nativer Anbieter von Sanktionslisten. Für Sanktions- und PEP-Screening kombinieren Käufer die Plattform mit einer Listenquelle wie OpenSanctions oder einem kommerziellen Anbieter. Zur weiter gefassten Architektur von Entity Resolution in KI- und RAG-Pipelines siehe unseren IdentityRAG-Leitfaden.

Checkliste für Käufer: sechs Fragen für jedes Shortlist-Gespräch

Wo läuft die Matching-Engine, und überschreiten Datensätze die Grenze Ihrer Umgebung?
Erfolgt die Auflösung bei der Datenaufnahme (und ist sie sofort abrufbar) oder nur im Batch?
Unterstützt die Plattform sowohl deterministisches als auch probabilistisches Matching mit konfigurierbaren Schwellenwerten?
Legt jede Match-Entscheidung Evidenz auf Feldebene für Audit- und Alert-Bearbeitungsprozesse offen?
Für regulierte Käufer: Welches Format hat das Audit-Log, und erfüllt es Ihre regulatorischen Anforderungen?
Wie hoch sind die gesamten Engineering-Kosten für Integration und Betrieb über zwölf Monate, jenseits der Lizenz?

FAQ

Was ist der Unterschied zwischen deterministischer und probabilistischer Entity Resolution?

Deterministisches Matching arbeitet mit exakten oder nahezu exakten Regeln: Zwei Datensätze passen zusammen, wenn festgelegte Felder exakt übereinstimmen (zum Beispiel dieselbe nationale Ausweisnummer). Probabilistisches Matching vergibt gewichtete Scores über mehrere Felder hinweg, sodass eine teilweise Namensübereinstimmung plus Adressübereinstimmung plus zeitliche Nähe des Geburtsdatums zusammen eine belastbare Übereinstimmung ergeben können, auch wenn kein einzelnes Feld für sich entscheidend ist. Die meisten produktiven Plattformen nutzen beides: deterministische Regeln für Fälle mit hoher Sicherheit, probabilistische Bewertung für den mehrdeutigen Rest.

Sollte ich eine API-native oder eine On-Premise-Entity-Resolution-Plattform wählen?

Wenn Ihre Datensätze personenbezogene Daten im Sinne der DSGVO, dem Bankgeheimnis unterliegende Finanzdaten oder Daten enthalten, die nach den Richtlinien Ihres Unternehmens als sensibel eingestuft sind, ist ein On-Premise-Modell oder ein Deployment in der eigenen Umgebung meist die richtige Wahl. Es hält Datensätze innerhalb Ihres Perimeters. Erlaubt Ihre Datenklassifizierung die Verarbeitung durch Dritte, bietet API-natives SaaS eine schnellere Einrichtung und geringeren operativen Aufwand. Die Entscheidung ist in erster Linie eine Frage der Data Governance, keine technische.

Was ist Echtzeit-Entity-Resolution, und wann wird sie gebraucht?

Echtzeit-Entity-Resolution bedeutet, dass ein neu eintreffender Datensatz sofort gegen bestehende Entitäts-Cluster aufgelöst wird und der aktualisierte aufgelöste Kontext innerhalb von Millisekunden abrufbar ist. Sie ist überall dort erforderlich, wo eine veraltete Auflösung Risiken schafft: beim Kunden-Onboarding und bei KYC (wo eine Verzögerung beim Erkennen einer sanktionierten Entität ein Compliance-Risiko erzeugt), bei der Betrugserkennung in Echtzeit und bei KI-Anwendungen, in denen ein Sprachmodell zur Abfragezeit Entitätskontext abruft und aktuelle Daten benötigt.

Wie hängen Sanktionsscreening und Entity Resolution zusammen?

Sanktionsscreening ist eine spezielle Anwendung von Entity Resolution: der Abgleich einer eingehenden Entität mit kuratierten Listen sanktionierter Personen und Organisationen. Die Schwierigkeit liegt darin, dass Namen, Aliasnamen und Kennungen zwischen Listen und Kundendatensätzen selten exakt übereinstimmen. Eine leistungsfähige Entity-Resolution-Plattform setzt Fuzzy Matching und probabilistische Bewertung ein, um False Negatives (übersehene sanktionierte Entitäten) zu reduzieren, während Erklärbarkeit und Schwellenwertsteuerung False Positives (unnötige Alerts) verringern. Die Listenquelle (etwa OpenSanctions, OFAC oder ein kommerzieller Anbieter) ist von der Auflösungs-Engine getrennt.

Wie hoch sind die Gesamtbetriebskosten von Open-Source-Entity-Resolution-Frameworks?

Die Lizenzkosten liegen typischerweise bei null, die Engineering-Kosten sind jedoch erheblich. Sie verantworten Bereitstellung und Skalierung der Infrastruktur, die Kalibrierung der Schwellenwerte (eine wiederkehrende Data-Science-Aufgabe), die Erzeugung regulatorischer Audit-Trails und jede Real-Time-Fähigkeit, die über den nativen Funktionsumfang des Frameworks hinausgeht. Am besten geeignet ist Open Source für Teams mit eigenem ML-Ops-Know-how und ohne Anforderung an Real-Time-Latenz. Für die meisten Produktivszenarien mit Echtzeit-Auflösung, Compliance-Audit-Trails und operativer Zuverlässigkeit übersteigen die vollen Gesamtbetriebskosten von Open Source die kommerzieller Alternativen.

Worin unterscheidet sich Entity Resolution von MDM oder einer CDP?

Master Data Management und Customer Data Platforms verwalten einen kuratierten Golden Record: eine einzige maßgebliche Sicht auf eine Entität mit definierten Governance-Prozessen. Entity Resolution ist die darunterliegende Matching- und Clustering-Schicht, die entscheidet, welche Datensätze zur selben Entität gehören. Beides ergänzt sich: Entity Resolution liefert dem MDM oder der CDP die Match-Entscheidungen, die sie zur Pflege des Golden Record brauchen. Eine Auflösungsplattform steht neben Ihrem bestehenden MDM oder Ihrer CDP, statt es zu ersetzen.

Welche Fragen zur Datenresidenz sollte ich einem Entity-Resolution-Anbieter stellen?

Fragen Sie: Wo läuft die Matching-Engine? Verlassen Datensätze während der Verarbeitung meine Umgebung? Werden die Daten gespeichert, und wenn ja, wo und wie lange? Kann ich eine Region oder Jurisdiktion festlegen? Für Käufer in der EU sind unter anderem DSGVO Artikel 25 (Datenschutz durch Technikgestaltung) und branchenspezifische Anforderungen an die Datenlokalisierung relevant. Ein Deployment in der eigenen Umgebung räumt die Frage der grenzüberschreitenden Übermittlung aus, weil Datensätze über den gesamten Auflösungszyklus hinweg innerhalb Ihres Perimeters bleiben.

Wie bewerte ich die Erklärbarkeit einer Entity-Resolution-Plattform?

Fordern Sie eine Beispiel-Match-Antwort an und prüfen Sie, ob sie Folgendes enthält: die Liste der Felder, die zur Match-Entscheidung beigetragen haben, das jedem Feld zugewiesene Gewicht bzw. den Score, den Gesamtkonfidenzwert und eine eindeutige Entscheidungs-ID, die auf ein Audit-Log verweist. Enthält die Antwort nur einen Boolean oder einen aggregierten Score ohne Evidenz auf Feldebene, bietet die Plattform keine belastbare Erklärbarkeit für Compliance- oder Auditzwecke. Für regulierte Anwendungsfälle sollte das ein hartes Ausschlusskriterium sein, keine Präferenz.