AML und KYC mit Entity Resolution in Echtzeit

Von Steven Renwick, CEO und Mitgründer, Tilores.

Kurzfassung: Entity Resolution in Echtzeit hilft AML- und KYC-Teams, den richtigen Kunden zu prüfen statt einen Haufen fragmentierter Datensätze. Sie verknüpft Identitäten bei der Ingestion, liefert den aktuellen aufgelösten Kontext zur Abfragezeit, zeigt, warum Datensätze übereinstimmen, und gibt Analysten die Belege an die Hand, um zu entscheiden, zu eskalieren und das Ergebnis zu dokumentieren.

Sehen Sie es an Ihren Daten: Buchen Sie eine Demo, um Entity Resolution in Echtzeit für AML und KYC durchzugehen, oder holen Sie sich den Evaluierungs-Build, um aufgelöste Kundendatensätze lokal zu testen – und sehen Sie sich danach die Tilores Entity-Resolution-Software an, um zu erfahren, wie sie Betrugs-, KYC- und AML-Kontrollen unterstützt, während Ihre Screening-Tools ihre Fall-Logik behalten.

Prüfung	Was Echtzeit-Auflösung beiträgt	Was der Analyst weiterhin entscheidet	Artefakt im Audit-Log
Kundensorgfaltspflichten	Löst Duplikate, Aliasse und verknüpfte Datensätze zu einem Kundenkontext auf.	Ob die Belege für Verifizierung und Risikoeinstufung ausreichen.	Aufgelöste Entitäts-ID, Quelldatensatz-IDs, übereinstimmende Felder und Verifizierungsstatus.
Sanktions- und PEP-Screening	Prüft den aktuellen Kundenkontext statt isolierter Fragmente.	Ob der Kandidat eine echte Übereinstimmung, ein False Positive oder ein Eskalationsfall ist.	Listenquelle, übereinstimmende Attribute, Konfidenzsignal, Begründung des Analysten.
Adverse-Media- und Betrugsprüfungen	Verbindet zugehörige Konten, Geräte, Adressen und Beziehungshinweise, soweit zulässig.	Ob das Muster verdächtig, erklärbar oder bereits bekannt ist.	Beziehungsbelege, geprüfte Signale, ergriffene Maßnahme oder Begründung für Nichthandeln.
Laufendes KYC-Monitoring	Aktualisiert den aufgelösten Kontext, sobald neue Datensätze eintreffen oder sich bestehende ändern.	Ob eine Änderung eine Aktualisierung, eine verstärkte Prüfung oder keine Fallmaßnahme auslöst.	Änderungsereignis, vorheriger Kontext, neue Belege und Prüfergebnis.
Audit und aufsichtsrechtliche Prüfung	Hält Match-Belege, Entitätskontext und Entscheidungsartefakte zusammen.	Ob die Kontrolle so funktioniert hat, wie es die Richtlinie vorsieht.	Richtlinienversion, Match-Belege, Entscheidungsverantwortlicher und Zeitstempel.

Wie hilft Entity Resolution AML- und KYC-Teams?

Entity Resolution hilft AML- und KYC-Teams, indem sie den Prüfgegenstand eindeutig macht. Ein Finanzinstitut fragt nicht nur, ob ein Name auf einer Liste steht. Es fragt, welche Person, welches Unternehmen, welches Konto, welchen wirtschaftlich Berechtigten oder welche verbundene Partei der Datensatz abbildet – und ob die Belege stark genug sind, um zu handeln.

Die Pflichten zur Kundensorgfalt (Customer Due Diligence, CDD) sind darauf ausgelegt, Kunden zu identifizieren und zu verifizieren, die Geschäftsbeziehung zu verstehen und laufend zu überwachen. Im Vereinigten Königreich umfasst Regulation 28 ausdrücklich das laufende Monitoring, die Prüfung von Transaktionen und die Aktualisierung der CDD-Informationen. Ein aufgelöster Kundendatensatz gibt diesen Kontrollen eine aktuelle Entität als gemeinsame Grundlage.

Der praktische Nutzen sind weniger unverbundene Entscheidungen. Onboarding, Betrugsabwehr, Sanktionsprüfung, Support und Operations können sich alle auf dieselbe aufgelöste Entitäts-ID beziehen, während das AML- oder KYC-System weiterhin seine eigene Screening-Logik und Fallentscheidung verantwortet.

Wie sollte KYC-Screening in Echtzeit im Jahr 2026 aussehen?

KYC-Screening in Echtzeit sollte zuerst den Kunden auflösen und dann den aufgelösten Kontext prüfen. Das heißt: Das System prüft den aktuellen Kunden, bekannte Aliasse, verknüpfte Datensätze, Hinweise auf Eigentumsverhältnisse und Beziehungsbelege, bevor es einem Analysten oder einer nachgelagerten Kontrolle einen Screening-Kandidaten zurückgibt.

Das ist wichtig, weil sich sowohl amtliche Listendaten als auch Kundendaten verändern. OFAC veröffentlicht Sanktionsdaten über seinen Sanctions List Service; das Vereinigte Königreich pflegt die UK Sanctions List; und die EU veröffentlicht eine konsolidierte Liste der Finanzsanktionen. Veraltete oder unvollständige Kundendatensätze gegen aktuelle Listen zu prüfen, erzeugt vermeidbare Unklarheit.

Echtzeit bedeutet nicht automatische Freigabe. Es bedeutet, dass die Screening-Entscheidung von den aktuellsten aufgelösten Fakten ausgeht. Ob der Kandidat eine echte Übereinstimmung, ein False Positive, ein Eskalationsfall oder ein Fall ohne Maßnahme ist, entscheidet weiterhin der Analyst.

Wie sollten aufgelöste Kundendatensätze Sanktions- und Betrugsprüfungen unterstützen?

Aufgelöste Datensätze sollten Sanktions- und Betrugsprüfungen unterstützen, indem sie die Belege hinter der Kundensicht bewahren. Das Screening-System braucht Namen und Aliasse, aber auch Daten, Adressen, Dokumente, Konten, Geräte, Quellsystem-IDs, verknüpfte Unternehmen und bekannte Beziehungskanten – soweit diese Felder zulässig und relevant sind.

Die Wolfsberg-Leitlinie zum Sanktions-Screening beschreibt Screening als den Abgleich von Kunden- oder Transaktionsdatensätzen mit Sanktionsdaten und stellt zugleich klar, dass ein Alert nur ein erster Schritt ist. Für die Bestätigung oder Entkräftung einer echten Sanktionsübereinstimmung sind zusätzliche Informationen nötig.

Genau hier verändert Entity Resolution die Qualität der Prüfung. Statt einer einzelnen, verrauschten Feldübereinstimmung sieht der Analyst, welche Datensätze verknüpft wurden, welche Felder übereinstimmten, welche Felder sich widersprechen und ob der Beziehungsgraph darauf hindeutet, dass die Person oder das Unternehmen anderswo bereits bekannt ist.

Was macht Matching erklärbar genug für eine regulierte Prüfung?

Erklärbares Matching bedeutet, dass der Prüfer sehen kann, warum die Entität zurückgegeben wurde. Die Belege sollten die Quelldatensätze, übereinstimmenden Felder, Konfliktfelder, Beziehungskanten, Konfidenzsignale und den Regel- oder Modellkontext hinter der Übereinstimmung zeigen. Eine Black-Box-Übereinstimmung, die sich nicht erklären lässt, ist schwer zu verteidigen, wenn die Entscheidung Onboarding, Zahlungsfreigabe, Betrugsprüfung oder Sanktionseskalation betrifft.

Mit nur einem Matching-Stil funktioniert das nicht gut. Echte Kundendaten enthalten Schreibfehler, Aliasse, Transliterationen, Adressvarianten und unvollständige Identifikatoren. Die Tilores-Dokumentation beschreibt probabilistisches Matching und die Kombination aus probabilistischem und deterministischem Abgleich, während die Regel-Dokumentation erklärt, dass die Verknüpfung während des Assembly-Prozesses erfolgt, nachdem Datensätze übermittelt wurden.

Tilores stellt außerdem prüfbare API-Signale bereit. Die Tilores API-Dokumentation zeigt Submit-, Search- und Entity-Operationen, und Suchergebnisse können score und hitScore enthalten. In dieser Dokumentation gibt score die Gesamtqualität der Übereinstimmung innerhalb einer Entität wieder, während hitScore die Übereinstimmung mit den Suchparametern abbildet. Diese Signale sollten in Richtlinien einfließen; sie sollten ohne Kalibrierung nicht als allgemeingültige Schwellenwerte behandelt werden.

Wo sollte Tilores neben AML-, KYC- und Datenplattformen stehen?

Tilores sollte neben AML-, KYC-, Sanktions-Screening-, Betrugs-, MDM-, CDP-, Data-Governance- und Warehouse-Werkzeugen stehen. Es ist die Entity-Resolution-Schicht, die diesen Systemen aufgelösten Kundenkontext zuführt, während jedes System seine eigene Betriebsrolle behält.

Für den Kundenkontext beschreibt Tilores Customer 360, wie verstreute Kundendaten vereinheitlicht und vollständige Profile in die Quellsysteme zurückgespielt werden. Für KI- und Retrieval-Anwendungen konzentriert sich Tilores IdentityRAG darauf, Systemen die richtigen Kundendaten zu liefern statt semantisch ähnlicher Fragmente. In der Compliance gilt dieselbe Unterscheidung: Das Screening-Tool sollte den richtigen aufgelösten Kunden erhalten, nicht eine breite Suchergebnismenge.

Die Auflösung geschieht bei der Ingestion. Die Abfragezeit dient dazu, den aktuellen aufgelösten Entitätskontext über kontrollierte Operationen abzurufen. Diese Trennung hält die Identitätsentscheidung geregelt, wiederholbar und getrennt von der abschließenden Fall-Logik des Screening-Tools.

Wie sieht der auditierbare Screening-Ablauf aus?

Eine AML- und KYC-Architektur in Echtzeit sollte einfach genug sein, um sie zu auditieren. Der folgende Ablauf ist bewusst schmal gehalten: erst auflösen, dann prüfen, dann den Kandidaten erklären, dann den Entscheidungspfad dokumentieren.

1. Lösen Sie Kunde oder Gegenpartei bei der Ingestion auf. Übermitteln Sie neue und geänderte Datensätze in die Entity-Resolution-Schicht, damit Duplikate, Aliasse und Beziehungen schon vor der Screening-Anfrage verbunden sind.
2. Prüfen Sie den aufgelösten Kontext. Führen Sie Sanktions-, PEP-, Adverse-Media- und Betrugsprüfungen gegen die aktuelle Entität durch, einschließlich bekannter Aliasse und zulässiger Beziehungsbelege.
3. Geben Sie erklärbare Entscheidungsbelege zurück. Zeigen Sie übereinstimmende Felder, Widersprüche, Quelldatensätze, Signale im Stil von score oder hitScore, sofern verfügbar, und den Grund, warum der Kandidat zurückgegeben wurde.
4. Erfassen Sie den Audit-Eintrag. Speichern Sie die aufgelöste Entitäts-ID, die geprüften Screening-Quellen, die Maßnahme des Analysten, den Eskalationsgrund sowie die Begründung für ein False Positive oder für den Abschluss.

Was sollten Analysten weiterhin verantworten?

Analysten verantworten weiterhin das Urteil. Entity Resolution kann den Prüfgegenstand klarer und die Belege leichter prüfbar machen, sie sollte aber nicht stillschweigend jede Übereinstimmung in eine Maßnahme verwandeln. Mehrdeutige Übereinstimmungen, schwache Identifikatoren, jurisdiktionsbezogene Fragen, Konfliktfelder und Entscheidungen mit großer Tragweite brauchen eine Prüfung.

Das richtige Betriebsmodell ist belegorientiert. Das System löst Datensätze auf und ruft den aktuellen Entitätskontext ab. Der Analyst entscheidet, ob es sich um eine echte Übereinstimmung, ein False Positive, eine Eskalation, eine Zurückstellung oder einen sauberen Abschluss handelt. Das Audit-Log sollte diese Unterscheidung im Nachhinein sichtbar machen.

Ein tiefer gehendes technisches Muster dazu, wie Sie KI-Systeme und nachgelagerte Prozesse davon abhalten, Kundenkontexte zu vermischen, finden Sie unter So verhindern Sie, dass KI-Agenten zwei Kunden verwechseln.

FAQ

Wie hilft Entity Resolution AML- und KYC-Teams?

Entity Resolution verbindet Datensätze, die sich auf dieselbe Person, dasselbe Unternehmen oder dieselbe Kontobeziehung beziehen, bevor Screening-Entscheidungen fallen. Damit erhalten AML- und KYC-Teams eine aktuelle, erklärbare Kundensicht für Sanktions-, PEP-, Adverse-Media- und Betrugsprüfungen.

Ersetzt Entity Resolution in Echtzeit AML- oder KYC-Screening-Tools?

Nein. Entity Resolution steht neben AML-, KYC-, Sanktions-Screening-, MDM-, CDP-, Data-Governance- und Warehouse-Werkzeugen. Sie versorgt diese Systeme mit sauberem, aufgelöstem Kundenkontext; die Systeme behalten ihre Regeln, ihr Fallmanagement, ihre regulatorische Logik und ihre Analystenentscheidungen.

Sollte sich Sanktions-Screening auf einen einzigen Matching-Stil stützen?

Nein. Regulierter Abgleich braucht in der Regel deterministische Regeln neben probabilistischem oder unscharfem Matching, weil Namen, Aliasse, Adressen, Daten und Identifikatoren zwischen Systemen variieren. Entscheidend sind erklärbare Belege, kalibrierte Schwellenwerte und eine menschliche Prüfung mehrdeutiger Fälle.

Wann sollte die Entität in einem KYC-Prozess in Echtzeit aufgelöst werden?

Die Auflösung sollte bei der Ingestion erfolgen, sobald Kunden- und Ereignisdatensätze in die Identity-Resolution-Schicht gelangen. Zur Abfragezeit ruft der Screening- oder Analystenprozess den aktuellen aufgelösten Entitätskontext ab, statt Identität aus Rohfragmenten zusammenzusetzen.

Was sollte ein Audit-Log für AML-Entscheidungen mit Entity-Resolution-Unterstützung erfassen?

Das Audit-Log sollte die aufgelöste Entitäts-ID erfassen, die verwendeten Quelldatensätze, die übereinstimmenden Felder, Konfidenzsignale wie score oder hitScore, sofern verfügbar, die geprüften Screening-Listen oder Betrugssignale, die Entscheidung des Analysten und den Grund für Eskalation oder Abschluss.