> Kontinuierliche Prozessverbesserung > KYC Kunden Onboarding > Refinitiv World Check > Daten Template

Ihr Daten-Template für das KYC-Kunden-Onboarding

Refinitiv World-Check

Attribute des KYC-Kunden-Onboardings (19) Aktivitäten des KYC-Kunden-Onboardings (14) Anleitungen zur Datenextraktion (2)

Ihr Daten-Template für das KYC-Kunden-Onboarding

Dieses Template führt Sie durch die Erfassung der wichtigsten Daten für die Analyse Ihres KYC-Kunden-Onboarding-Prozesses. Es beschreibt die relevanten Attribute, die Sie erfassen sollten, nennt die zentralen Aktivitäten und zeigt, wie Sie diese Informationen aus Ihren Quellsystemen extrahieren. Verwenden Sie diese Ressource, um alle erforderlichen Daten für eine wirksame Prozessanalyse und Verbesserung zusammenzustellen.

Empfohlene Attribute für die Erfassung
Wichtige Aktivitäten für die Nachverfolgung
Anleitung zur Datenextraktion

Neu bei Event Logs? Lernen Sie, wie Sie ein Process-Mining-Event-Log erstellen.

Template herunterladen

Attribute des KYC-Kunden-Onboardings

Dies sind die empfohlenen Datenfelder, die Sie für eine umfassende Analyse des KYC-Kunden-Onboardings in Ihr Event Log aufnehmen sollten.

3 Erforderlich 5 Empfohlen 11 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name eines bestimmten Geschäftsereignisses oder einer Aufgabe, die im KYC-Onboarding-Prozess stattgefunden hat.
Beschreibung Der Aktivitätsname beschreibt einen einzelnen Schritt oder ein Ereignis in der Kundenreise im Onboarding, etwa „Application Submitted“, „Analyst Review Started“ oder „Screening Completed - Clear“. Diese Aktivitäten bilden die Knoten der Prozesslandkarte und liefern eine detaillierte Darstellung des Workflows von Anfang bis Ende. Die Analyse von Aktivitäten bildet den Kern von Process Mining. Durch die Nachverfolgung der Abfolge und Häufigkeit verschiedener Aktivitäten können Analysten den tatsächlichen Prozessablauf ermitteln, häufige Pfade erkennen, Abweichungen vom Standardverfahren feststellen und konkrete Schritte identifizieren, die Verzögerungen oder Nacharbeit verursachen. Dieses Attribut ist entscheidend für den Aufbau von Prozesslandkarten und die Berechnung von Kennzahlen auf Aktivitätsebene. Warum das wichtig ist Dieses Attribut definiert die einzelnen Prozessschritte. Es ist entscheidend, um den Prozessablauf zu ermitteln und zu visualisieren sowie Engpässe zu erkennen. Bezugsquelle Diese Informationen finden sich typischerweise in Event Logs oder Audit-Trail-Tabellen, häufig im Zusammenhang mit Statusänderungen der Case-Management-Entität. Beispiele Potenzieller Match identifiziertAnalystenprüfung gestartetFalse Positive bestätigtAntrag genehmigt
	Ereigniszeit EventTime	Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Die Ereigniszeit enthält das genaue Datum und die Uhrzeit, zu denen eine Aktivität protokolliert wurde. Dieser Timestamp bildet das chronologische Rückgrat des Prozesses und ermöglicht die korrekte Sortierung der Ereignisse zur Rekonstruktion der Case-Historie. Dieses Attribut ist für alle zeitbezogenen Analysen in Process Mining entscheidend. Es dient zur Berechnung der Dauer zwischen Aktivitäten, einschließlich Durchlauf- und Wartezeiten, zur Messung der gesamten Case-Dauer, zur Analyse der Prozessleistung im Zeitverlauf und zur Prüfung der Einhaltung von Service Level Agreements (SLAs). Ohne genaue Timestamps lassen sich Prozessleistung und zeitliche Engpässe nicht zuverlässig beurteilen. Warum das wichtig ist Der Timestamp jeder Aktivität ist entscheidend für die Berechnung aller dauerbasierten Kennzahlen, die Ermittlung der Prozessabfolge und die Engpassanalyse. Bezugsquelle Dies ist ein Standardfeld in jedem Event Log oder jeder Audit-Trail-Tabelle, häufig mit der Bezeichnung „Timestamp“, „EventDate“ oder „CreationDate“. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	Kundenantrag CustomerApplication	Der eindeutige Bezeichner für den Onboarding-Antrag eines einzelnen Kunden, der als primäre Case-ID dient.
Beschreibung Der Kundenantrag ist der zentrale Case-Bezeichner, der alle Ereignisse und Aktivitäten einer einzelnen Kundenreise im Onboarding zusammenfasst. Er ermöglicht die vollständige chronologische Nachverfolgung des Fortschritts jedes Kunden durch den gesamten Know-Your-Customer-Prozess (KYC), von der ersten Einreichung bis zur endgültigen Entscheidung. In der Process-Mining-Analyse ist dieses Attribut grundlegend für die Rekonstruktion der End-to-End-Reise jedes Antrags. Es ermöglicht die Visualisierung von Prozessabläufen, die Berechnung der gesamten Durchlaufzeiten und die Identifizierung von Varianten. Durch die Analyse von Cases, die nach diesem Bezeichner gruppiert sind, können Unternehmen unterschiedliche Pfade eines Antrags nachvollziehen, Engpässe erkennen und die Effizienz verschiedener Onboarding-Prozesse vergleichen. Warum das wichtig ist Dies ist der zentrale Case-Bezeichner, der alle zusammengehörigen Aktivitäten verknüpft und die Analyse des Kunden-Onboarding-Prozesses von Anfang bis Ende ermöglicht. Bezugsquelle Dieser Bezeichner ist in der Regel der Primärschlüssel in der zentralen Antrags- oder Case-Management-Tabelle des Refinitiv-World-Check-Systems oder eines integrierten CRM. Beispiele APP-2023-00123APP-2023-00124APP-2023-00125
	Abteilung DepartmentName	Die Abteilung oder das Funktionsteam, das für die Ausführung der Aktivität verantwortlich ist.
Beschreibung Dieses Attribut gibt die Geschäftseinheit oder das Team an, dem der Benutzer angehört, etwa „Onboarding“, „Compliance“ oder „Quality Assurance“. Es ermöglicht eine Analyse auf einer höheren Organisationsebene als der des einzelnen Benutzers. Die Analyse nach Abteilungen ist entscheidend, um abteilungsübergreifende Engpässe zu erkennen und Übergabezeiten zu messen. Sie macht sichtbar, wie Arbeit zwischen verschiedenen Teams fließt und an welchen Stellen Verzögerungen bei diesen Übergängen entstehen. Diese Sicht unterstützt die Verbesserung der funktionsübergreifenden Zusammenarbeit und der gesamten Prozesseffizienz. Warum das wichtig ist Ermöglicht die Analyse der Prozessleistung nach Abteilung und ist entscheidend, um Verzögerungen bei Übergaben zwischen verschiedenen Teams zu erkennen. Bezugsquelle Diese Informationen können im Benutzerprofil des Systems oder in einem verbundenen HR-System gespeichert sein. Möglicherweise müssen sie über die Benutzer-ID mit den Ereignisdaten verknüpft werden. Beispiele Onboarding-TeamCompliance-PrüfungGeschäftsleitung
	Endzeit des Ereignisses EventEndTime	Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis abgeschlossen wurde.
Beschreibung Die Endzeit des Ereignisses markiert den Abschluss einer Aktivität. Viele Ereignisse können als zeitpunktbezogen modelliert werden, wobei StartTime und EndTime identisch sind. Andere Aktivitäten haben eine messbare Dauer, etwa „Analyst Review Started“ und „Analyst Review Completed“. Start- und Endzeit ermöglichen eine präzise Messung der Bearbeitungszeit. In der Prozessanalyse ist eine Endzeit entscheidend, um die tatsächliche Bearbeitungszeit einer Aktivität zu berechnen, statt nur die Durchlaufzeit einschließlich der Wartezeit zu betrachten. So lässt sich unterscheiden, wie lange ein Case aktiv bearbeitet wird und wie lange er ungenutzt in einer Warteschlange liegt. Das ist wichtig für die Ressourcenoptimierung und Effizienzanalyse. Warum das wichtig ist Ermöglicht die präzise Berechnung der Bearbeitungszeit einer Aktivität und trennt aktive Arbeitszeit von ungenutzter Wartezeit, sodass die Prozessleistung genauer analysiert werden kann. Bezugsquelle Bei Aktivitäten mit einer Dauer kann dieser Wert in einem separaten Feld wie „CompletionDate“ oder „EndDate“ im Event Log oder in den Audit-Trail-Tabellen gespeichert sein. Beispiele 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	Reviewer-ID ReviewerId	Der Bezeichner des Benutzers, Analysten oder automatisierten Agenten, der die Aktivität ausgeführt hat.
Beschreibung Die Reviewer-ID beziehungsweise der Benutzer zeigt an, wer eine bestimmte Aufgabe im KYC-Prozess ausgeführt hat. Dabei kann es sich um einen Compliance-Analysten, einen Onboarding-Spezialisten oder bei automatisierten Aktivitäten um ein Systemkonto handeln. Die Nachverfolgung dieser Information schafft Transparenz über die Arbeitsverteilung und die individuelle Leistung. Dieses Attribut ist für ressourcenbezogene Analysen entscheidend. Es hilft, Leistungsunterschiede zwischen Benutzern oder Teams zu verstehen, Schulungsbedarf zu erkennen und die Arbeitsverteilung zu optimieren. Außerdem ist es eine wichtige Grundlage für die Analyse von Übergaben, sozialen Netzwerken und der Nutzung von Compliance-Ressourcen. Warum das wichtig ist Ermöglicht die Analyse der Arbeitsverteilung, der Benutzerleistung und der Übergaben zwischen Abteilungen. Das ist entscheidend für die Ressourcenoptimierung. Bezugsquelle Findet sich typischerweise in Event Logs oder Audit-Trails, häufig unter Bezeichnungen wie „UserID“, „PerformedBy“ oder „Owner“. Beispiele analyst_jdoesystem_auto_screenermanager_bsmith
	Risikostufe RiskLevel	Die berechnete Risikoklassifizierung des Kundenantrags, etwa niedrig, mittel oder hoch.
Beschreibung Die Risikostufe ist eine zentrale Information in KYC-Prozessen, da sie den Umfang der erforderlichen Due-Diligence-Prüfung bestimmt. Sie wird häufig anhand von Faktoren wie Kundentyp, geografischer Lage und Art der Geschäftstätigkeit ermittelt. Diese Klassifizierung kann den Prozesspfad eines Antrags erheblich beeinflussen. In der Prozessanalyse ist die Segmentierung nach Risikostufe entscheidend. Sie hilft, Unterschiede bei Durchlaufzeiten und Prozessabläufen zu erklären. Anträge mit hohem Risiko können beispielsweise mehr Schritte erfordern und länger dauern. Dieses Attribut ist für die Dashboards „Application Rejection Rate and Reasons“ und „Background Check Initiation Cycle Time“ wichtig, um den Einfluss des Risikos auf Ergebnisse und Effizienz zu verstehen. Warum das wichtig ist Die Segmentierung des Prozesses nach Risikostufe ist entscheidend, um zu verstehen, warum bestimmte Cases länger dauern oder andere Pfade durchlaufen, und um Ablehnungsquoten zu analysieren. Bezugsquelle Dies ist ein zentraler Datenpunkt im Kundenantrag oder Case-Datensatz. Prüfen Sie das Case-Management-Modul in Refinitiv World-Check. Beispiele NiedrigMittelHoch
	SLA-Zieldatum SlaTargetDate	Das Zieldatum, bis zu dem der Kunden-Onboarding-Prozess abgeschlossen sein sollte.
Beschreibung Das SLA-Zieldatum ist die Frist für den Abschluss des gesamten Onboarding-Cases, wie sie in der Service-Level-Vereinbarung mit dem Kunden oder in internen Richtlinien festgelegt ist. Dieses Datum dient als Referenz für den Vergleich mit der tatsächlichen Abschlusszeit. Das Attribut ist grundlegend für das Dashboard „SLA Adherence and Breach Analysis“. Es wird verwendet, um zu berechnen, ob ein Case fristgerecht abgeschlossen wurde. Die Analyse von SLA-Verstößen hilft, systematische Prozessprobleme zu erkennen, die Verzögerungen verursachen, und ermöglicht geeignete Maßnahmen zur Verbesserung der Termintreue und zur Erfüllung von Compliance-Anforderungen. Warum das wichtig ist Dies ist die Referenz für die Messung der Termintreue und entscheidend für die Berechnung der SLA-Einhaltungsquote sowie die Analyse von Verstößen. Bezugsquelle Dieses Datum wird häufig anhand des Einreichungsdatums des Antrags und von Geschäftsregeln berechnet. Es kann als Feld im Case-Datensatz gespeichert sein. Beispiele 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
	Ablehnungsgrund RejectionReason	Der konkrete Grund, der bei der Ablehnung eines Kundenantrags angegeben wird.
Beschreibung Wenn ein Antrag abgelehnt wird, erfasst der Ablehnungsgrund, warum diese Entscheidung getroffen wurde. Mögliche Gründe sind „Sanctions Match“, „Incomplete Documentation“ oder „High Risk Profile“. Diese strukturierten Informationen liefern wertvolles Feedback zur Qualität eingehender Anträge und zur Wirksamkeit des Screening-Prozesses. Dieses Attribut ist der wichtigste Treiber für das Dashboard „Application Rejection Rate and Reasons“. Die Analyse der Gründe hilft, Ursachen für Ablehnungen zu erkennen. Daraus können Prozessverbesserungen, eine klarere Kommunikation mit Antragstellern und möglicherweise weniger unnötige Ablehnungen entstehen. Das Attribut ergänzt die quantitative Ablehnungsquote um qualitativen Kontext. Warum das wichtig ist Liefert die Ursache für die Ablehnung von Anträgen und ist entscheidend, um Verbesserungsbereiche im Onboarding-Prozess zu erkennen und die Ablehnungsquote zu senken. Bezugsquelle Wird erfasst, sobald das Ereignis „Application Rejected“ eintritt, wahrscheinlich als Feld im Case- oder Antragsdatensatz. Beispiele PEP-TrefferTreffer auf einer SanktionslisteDokumentenprüfung fehlgeschlagenNegative Medienberichte
	Antragskanal ApplicationChannel	Der Kanal, über den der Kundenantrag eingereicht wurde, etwa Online-Portal, Filiale oder Mobile App.
Beschreibung Der Antragskanal gibt an, aus welcher Quelle der Kundenantrag eingereicht wurde. Die verschiedenen Kanäle können sich hinsichtlich Vollständigkeit und Qualität der Daten sowie der Kundendemografie unterscheiden, was den nachgelagerten Prozess beeinflussen kann. Dieses Attribut ist entscheidend für das Dashboard „Application Throughput by Channel“. Durch die Analyse von Volumen, Durchlaufzeit und Ergebnissen der Anträge aus verschiedenen Kanälen kann ein Unternehmen erkennen, welche Kanäle besonders effizient sind und wo Prozessverbesserungen erforderlich sein können. Die Analyse unterstützt strategische Entscheidungen zur Ressourcenverteilung und zu Investitionen in einzelne Kanäle. Warum das wichtig ist Unterstützt die Analyse der Leistung und Effizienz verschiedener Einreichungskanäle und liefert eine Grundlage für strategische Entscheidungen zu Technologie und Customer Experience. Bezugsquelle Diese Informationen werden typischerweise zu Beginn des Prozesses erfasst und als Attribut im Antragsdatensatz gespeichert. Beispiele Online-PortalMobile AppFilialeKundenbetreuer
	Automatisiert IsAutomated	Ein Kennzeichen, das angibt, ob die Aktivität von einem System (true) oder einem Menschen (false) ausgeführt wurde.
Beschreibung Dieses boolesche Attribut unterscheidet zwischen automatisierten Systemaufgaben und manuellen Aktivitäten, die von Benutzern ausgeführt werden. Beispielsweise würde „Automated Screening Performed“ als automatisiert und „Analyst Review Started“ als manuell gekennzeichnet. Diese Unterscheidung ist für die Automatisierungsanalyse entscheidend. Sie hilft dabei, die Auswirkungen der Automatisierung auf die Prozesseffizienz zu messen, manuelle Aufgaben mit Potenzial für eine künftige Automatisierung zu identifizieren und das Zusammenspiel menschlicher und systemischer Akteure zu verstehen. Dadurch lässt sich die Systemverarbeitungszeit klar von der manuellen Bearbeitungszeit abgrenzen. Warum das wichtig ist Unterscheidet zwischen System- und menschlichen Aktivitäten. Das ist entscheidend, um die Auswirkungen der Automatisierung zu messen und neue Automatisierungsmöglichkeiten zu identifizieren. Bezugsquelle Dieses Attribut wird in der Regel aus dem Aktivitätsnamen oder der mit dem Ereignis verknüpften Benutzer-ID abgeleitet, beispielsweise wenn der Benutzer ein „system“-Konto ist. Beispiele truefalse
	Ist Nacharbeit IsRework	Ein Kennzeichen dafür, dass eine Aktivität innerhalb desselben Cases zum zweiten Mal oder häufiger ausgeführt wird.
Beschreibung IsRework ist ein berechnetes boolesches Attribut, das wiederholte Aktivitäten innerhalb desselben Kundenantrags-Cases erkennt. Wenn beispielsweise „Risk Assessment Performed“ für einen Antrag mehr als einmal auftritt, werden die nachfolgenden Vorkommen als Nacharbeit gekennzeichnet. Dieses Attribut ist entscheidend, um Ineffizienzen, Schleifen und unnötige Wiederholungen im Prozess zu erkennen. Es unterstützt direkt das Dashboard „Risk Assessment Rework and Efficiency“ und die KPI „Risk Assessment Rework Rate“. Die Analyse von Nacharbeit macht Probleme bei Qualität, Informationsklarheit oder Entscheidungsfindung sichtbar. Diese führen zu zusätzlichem Aufwand und längeren Durchlaufzeiten. Warum das wichtig ist Macht Prozessineffizienzen sichtbar, indem wiederholte Aktivitäten gekennzeichnet werden. So lassen sich Nacharbeitsschleifen analysieren, die Qualität verbessern und Durchlaufzeiten verkürzen. Bezugsquelle Dieses Attribut wird während der Datentransformation berechnet. Dazu wird die Aktivitätsfolge innerhalb jedes Cases analysiert und jedes nicht erstmalige Vorkommen einer Aktivität gekennzeichnet. Beispiele truefalse
	Kunden-ID CustomerId	Ein eindeutiger Bezeichner für die im Onboarding aufgenommene Kundeneinheit.
Beschreibung Die Kunden-ID ist der eindeutige Bezeichner des Kundenprofils. Sie unterscheidet sich von der Customer Application ID, da ein Kunde im Laufe der Zeit mehrere Anträge einreichen kann. Dieses Attribut verknüpft den Onboarding-Prozess mit dem zentralen Kundendatensatz. In der Analyse ermöglicht die Kunden-ID die Nachverfolgung wiederholter Anträge desselben Kunden. Außerdem können Prozessdaten mit weiteren Kundenattributen aus einem CRM- oder Stammdatensystem angereichert werden. So entsteht eine umfassendere Sicht auf die Kundenreise über einen einzelnen Onboarding-Vorgang hinaus. Warum das wichtig ist Verknüpft den Onboarding-Case mit einem bestimmten Kunden und ermöglicht die Analyse wiederholter Anträge sowie die Anreicherung mit Kundendaten aus dem Stammdatensystem. Bezugsquelle Dies ist ein wichtiges Feld im Antrags- oder Case-Datensatz, das den Datensatz mit den Kundendaten aus dem Stammdatensystem verknüpft. Beispiele CUST-98765CUST-98766CUST-98767
	Kundenland CustomerCountry	Das Wohnsitz- oder Gründungsland des Kunden.
Beschreibung Dieses Attribut gibt den geografischen Standort des Kunden an. Das Land ist ein wichtiger Faktor für die Risikobewertung und regulatorische Anforderungen in KYC-Prozessen. In verschiedenen Rechtsordnungen gelten unterschiedliche Regeln, die den Prozessablauf und die Dauer beeinflussen können. Die Analyse nach Ländern ermöglicht es Unternehmen, die Leistung verschiedener Regionen zu vergleichen, standortspezifische Engpässe zu erkennen und die Einhaltung lokaler Vorschriften sicherzustellen. Sie ergänzt die Prozessanalyse um eine geografische Dimension, durch die wichtige operative Unterschiede sichtbar werden können. Warum das wichtig ist Ermöglicht die geografische Analyse des Prozesses und hilft, regionale Unterschiede bei Leistung, Risiko und Compliance-Anforderungen zu erkennen. Bezugsquelle Dies ist ein Standardfeld im Kundenprofil oder Antragsformular. Beispiele USAGBRSGPDEU
	Kundentyp CustomerType	Die Klassifizierung des Kunden, etwa Privatperson, Unternehmen oder Trust.
Beschreibung Der Kundentyp kategorisiert die Einheit, die im Onboarding aufgenommen wird. Verschiedene Kundentypen haben häufig unterschiedliche Onboarding-Anforderungen, Risikoprofile und regulatorische Pflichten. Das Onboarding eines Unternehmens ist beispielsweise typischerweise komplexer als das einer Privatperson. Dieses Attribut wird für die Segmentanalyse verwendet, insbesondere im Dashboard „KYC Customer Type Performance“. Es ermöglicht den Vergleich von Prozesseffizienz, Durchlaufzeiten und Ablehnungsquoten zwischen verschiedenen Kundensegmenten. So können Unternehmen das Onboarding gezielt an die jeweiligen Kundentypen anpassen und optimieren. Warum das wichtig ist Ermöglicht den Leistungsvergleich zwischen verschiedenen Kundensegmenten und unterstützt dabei, den Onboarding-Prozess für jeden Kundentyp gezielt anzupassen und zu optimieren. Bezugsquelle Dies ist ein grundlegendes Attribut im Kunden- oder Antragsdatensatz des Quellsystems. Beispiele EinzelpersonUnternehmenGemeinnützige OrganisationTrust
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, zu dem die Daten für dieses Ereignis zuletzt aus dem Quellsystem aktualisiert oder extrahiert wurden.
Beschreibung Dieses Attribut zeigt die Aktualität der Daten an. Es erfasst Datum und Uhrzeit des letzten Datenabrufs aus Refinitiv World-Check. Das ist wichtig, um die Aktualität der Process-Mining-Dashboards und Analysen einzuordnen. Für analytische Zwecke können Benutzer damit erkennen, ob sie Daten nahezu in Echtzeit oder eine Momentaufnahme zu einem bestimmten Zeitpunkt betrachten. Das Attribut ist für Data Governance wichtig und hilft dabei, Erwartungen an die Aktualität der bereitgestellten Erkenntnisse zu steuern. Warum das wichtig ist Liefert wichtigen Kontext zur Aktualität der Daten und stellt sicher, dass Benutzer den Aktualitätsgrad der Prozessanalyse einordnen können. Bezugsquelle Dieser Timestamp wird während des Datenextraktionsprozesses (ETL) erzeugt und ergänzt. Beispiele 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Match-ID MatchId	Der eindeutige Bezeichner für einen potenziellen Match, der während eines World-Check-Screenings gefunden wurde.
Beschreibung Wenn der automatisierte Screening-Prozess einen potenziellen Match mit Sanktionslisten, PEP-Listen oder Meldungen über negative Medienberichte findet, wird häufig eine Match-ID erzeugt, um den konkreten Treffer nachzuverfolgen. Diese ID verknüpft den Antrags-Case mit dem konkreten Datensatz in der World-Check-Datenbank, der den Alert ausgelöst hat. Dieses Attribut eignet sich für detaillierte Compliance-Analysen. Es ermöglicht Analysten, die Art von Matches zu untersuchen, die Auflösung einzelner Alerts nachzuverfolgen, etwa die Bestätigung eines False Positives oder eines True Matches, und zu erkennen, welche Alert-Typen am häufigsten auftreten oder am längsten bis zur Auflösung benötigen. Es liefert zusätzliche Details zur Aktivität „Potenzieller Match identifiziert“. Warum das wichtig ist Stellt eine detaillierte Verknüpfung zu den konkreten Screening-Ergebnissen her und ermöglicht eine vertiefte Analyse der Auflösungszeiten und Alert-Typen. Bezugsquelle Diese ID wird von der World-Check-Screening-Engine erzeugt und beim Auffinden eines potenziellen Matches im Antrags-Case protokolliert. Beispiele WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	Quellsystem SourceSystem	Das System, aus dem die Ereignisdaten extrahiert wurden, in diesem Fall Refinitiv World-Check.
Beschreibung Dieses Attribut identifiziert die Herkunft der Prozessdaten. Bei einer Extraktion aus nur einer Quelle kann es einen konstanten Wert enthalten. Sobald Daten aus mehreren Systemen, etwa einem CRM und World-Check, kombiniert werden, wird es für eine umfassende Prozesssicht entscheidend. In der Analyse unterstützt es Data Governance, Fehlerbehebung und die Einordnung der Daten. Beispielsweise können Aktivitäten aus einem zentralen Screening-System andere Eigenschaften oder einen anderen Detaillierungsgrad aufweisen als Aktivitäten aus einem peripheren System. So bleibt die Datenherkunft eindeutig und prüfbar. Warum das wichtig ist Identifiziert die Herkunft der Daten. Dies ist für Data Governance, Validierung und die Zusammenführung von Daten aus mehreren Quellen entscheidend. Bezugsquelle Dabei handelt es sich häufig um einen statischen Wert, der während des ETL-Prozesses zur Kennzeichnung des Datensatzes ergänzt wird. Beispiele Refinitiv World-CheckWorldCheckOne
	SLA verletzt SlaBreached	Ein boolesches Kennzeichen, das angibt, ob der Onboarding-Case nach seinem SLA-Zieldatum abgeschlossen wurde.
Beschreibung Dieses Attribut ist ein berechnetes Kennzeichen dafür, ob ein Case gegen sein Service Level Agreement verstoßen hat. Dafür wird der Timestamp der abschließenden Aktivität, beispielsweise „Application Approved“ oder „Application Rejected“, mit dem „SlaTargetDate“ des Cases verglichen. Dieses Kennzeichen bildet die Grundlage für das Dashboard „SLA Adherence and Breach Analysis“ und die KPI „SLA Adherence Rate“. Es vereinfacht die Analyse, da Benutzer schnell alle SLA-Verstöße filtern können. Durch die Analyse der Prozessmerkmale betroffener Cases lassen sich die Ursachen von Verzögerungen identifizieren und Verbesserungsmaßnahmen gezielt ausrichten. Warum das wichtig ist Misst die Einhaltung von Service Level Agreements direkt und ermöglicht eine einfache Filterung sowie Ursachenanalyse verspäteter Cases. Bezugsquelle Dieses Attribut wird während der Datentransformation berechnet, indem der Timestamp der letzten Aktivität eines Cases mit dem Feld SlaTargetDate verglichen wird. Beispiele truefalse

Erforderlich Empfohlen Optional

Aktivitäten des KYC-Kunden-Onboardings

Dies sind die zentralen Prozessschritte und Meilensteine, die Sie für eine präzise Prozesserkennung in Ihrem Event Log erfassen sollten.

8 Empfohlen 6 Optional

	Aktivität	Beschreibung
	Analystenprüfung gestartet	Ein Compliance-Analyst beginnt mit der manuellen Untersuchung potenzieller Matches für einen Kundenantrag. Dabei werden die Details der potenziellen Matches mit den Kundeninformationen abgeglichen, um ihre Relevanz zu bestimmen.
Warum das wichtig ist Dies markiert den Beginn der manuellen Compliance-Prüfung, die häufig einen Engpass darstellt. Die Messung der Zeit zwischen „Potenzieller Match identifiziert“ und dieser Aktivität macht Wartezeiten in der Warteschlange sichtbar. Die Prüfungsdauer zeigt, wie effizient Analysten arbeiten. Bezugsquelle Dieses Ereignis lässt sich ableiten, wenn ein Analyst einen Case aus der Prüfungswarteschlange „übernimmt“ oder öffnet. Das System kann es explizit im Audit-Trail protokollieren, sobald sich der Case-Status in „In Review“ ändert oder der Case einem bestimmten Benutzer zugewiesen wird. Erfassen Abgeleitet aus einer Änderung des Case-Status in „Under Review“ oder aus der Zuweisung des Cases an einen Analysten. Ereignistyp inferred
	Antrag abgelehnt	Der Kundenantrag wird offiziell abgelehnt, häufig aufgrund eines „Match Found“ in World-Check oder anderer Risikofaktoren. Dieses Ereignis stellt das endgültige negative Ergebnis des Onboarding-Prozesses dar.
Warum das wichtig ist Dies ist der zentrale negative Endpunkt des Prozesses. Die Analyse von Ablehnungen, insbesondere ihrer Gründe und der vorausgehenden Aktivitäten, ist entscheidend, um den Prozess zu verbessern und unnötige Ablehnungen zu reduzieren. Bezugsquelle Diese endgültige Geschäftsentscheidung wird im vorgelagerten CRM- oder Kernanwendungssystem erfasst, nicht in World-Check selbst. Die Daten müssen aus diesem System bezogen werden. Erfassen Ereignis, das im Quellanwendungssystem protokolliert wird, häufig zusammen mit einem entsprechenden Ablehnungsgrundcode. Ereignistyp explicit
	Antrag eingereicht	Diese Aktivität markiert den Beginn des KYC-Onboarding-Prozesses, sobald ein Kunde seinen Antrag einreicht. Das Event wird typischerweise in einem CRM- oder Kernanwendungssystem erfasst und löst anschließend den Screening-Prozess in Refinitiv World-Check aus.
Warum das wichtig ist Dies ist das zentrale Start-Event für den durchgängigen Kunden-Onboarding-Prozess. Die Zeit von diesem Punkt bis zum Abschluss ergibt die gesamte Onboarding-Durchlaufzeit. Sie ist entscheidend, um Customer Experience und SLA-Einhaltung zu messen. Bezugsquelle Dieses Event stammt nicht aus World-Check. Es muss aus einem vorgelagerten System wie einem CRM- oder Kundenkontoverwaltungssystem übernommen und über die Customer Application ID zugeordnet werden. Erfassen Event, das bei der ersten Einreichung im Quellsystem erfasst wird. Ereignistyp explicit
	Konto aktiviert	Das Kundenkonto wird im Kernsystem angelegt und aktiviert. Damit ist der Onboarding-Prozess abgeschlossen. Dies erfolgt nach der endgültigen Genehmigung des Antrags und macht das Konto nutzbar.
Warum das wichtig ist Dies ist der letzte wertschöpfende Schritt im Prozess. Die Dauer von der Einreichung des Antrags bis zur Kontoaktivierung ist eine wichtige Kennzahl für die operative Effizienz und die Kundenzufriedenheit. Bezugsquelle Dieses Ereignis wird nicht in World-Check erfasst. Es wird im Kernbank- oder Kundenkontosystem protokolliert und muss über die Customer Application ID zugeordnet werden. Erfassen Ereignis, das bei der Kontoaktivierung im Kernkontosystem protokolliert wird. Ereignistyp explicit
	Screening abgeschlossen, kein Match	Der Screening-Case wird offiziell mit dem Ergebnis „Clear“ geschlossen. Das bedeutet, dass keine True Matches gefunden wurden. Diese Entscheidung wird an das Ursprungssystem übermittelt, sodass der Onboarding-Prozess fortgesetzt werden kann.
Warum das wichtig ist Diese Aktivität steht für den erfolgreichen Abschluss des Screening-Prozesses auf dem Standardpfad. Sie dient als wichtiger Endpunkt zur Messung der Durchlaufzeit bei standardmäßigen Anwendungen mit geringem Risiko. Bezugsquelle Abgeleitet aus der Änderung des finalen Case-Status in „Clear“, „Complete“ oder „Closed - No Match“. Verwendet wird der Timestamp dieser abschließenden Statusänderung. Erfassen Abgeleitet aus dem Timestamp des finalen Case-Status, der ein unauffälliges Ergebnis anzeigt. Ereignistyp inferred
	Screening abgeschlossen, Match gefunden	Der Screening-Case wird offiziell mit dem Ergebnis „Match Found“ geschlossen. Dies zeigt an, dass ein bestätigtes Risiko identifiziert wurde. Die Entscheidung löst einen anderen nachgelagerten Prozess aus, etwa eine erweiterte Due-Diligence-Prüfung oder eine Ablehnung.
Warum das wichtig ist Dies ist der zentrale Endpunkt des negativen Prozesspfads im Screening. Die Analyse dieser Cases hilft, Risikoprofile und die Wirksamkeit der Screening-Kontrollen zu verstehen. Bezugsquelle Abgeleitet aus der Änderung des finalen Case-Status in „Match Found“, „Risk Identified“ oder „Closed - Positive“. Verwendet wird der Timestamp dieser abschließenden Statusänderung. Erfassen Abgeleitet aus dem Timestamp des finalen Case-Status, der einen bestätigten Match anzeigt. Ereignistyp inferred
	Screening-Anfrage erstellt	Im Refinitiv World-Check-System wird für einen Kundenantrag offiziell ein neuer Screening-Case erstellt. Dies wird durch einen API-Aufruf oder eine manuelle Eingabe aus einem vorgelagerten System ausgelöst und markiert den Beginn der Risikoprüfung.
Warum das wichtig ist Dies markiert den offiziellen Beginn des Screening-Teilprozesses. Die Zeit zwischen „Application Submitted“ und dieser Aktivität zeigt Verzögerungen bei Übergaben zwischen dem Fachbereichssystem und der Compliance-Funktion. Bezugsquelle Erfasst in den World-Check-Logs der Case-Verwaltung oder im Audit Trail. Verwendet werden das Erstellungs-Event und sein Timestamp für die jeweilige Case- oder Entity-ID. Erfassen Wird automatisch erfasst, sobald ein neuer Screening-Case im System erstellt wird. Ereignistyp explicit
	True Match bestätigt	Ein Analyst bestätigt, dass ein potenzieller Match tatsächlich dem geprüften Kunden entspricht, und identifiziert damit ein potenzielles Risiko. Dieser kritische Meilenstein löst in der Regel eine weitergehende Due-Diligence-Prüfung oder die Ablehnung des Antrags aus.
Warum das wichtig ist Dies ist ein wichtiges Ergebnis zur Risikominderung und ein entscheidender Moment im Prozess. Es beeinflusst die endgültige Entscheidung über den Kundenantrag unmittelbar und ist für Compliance-Berichte und Analysen von zentraler Bedeutung. Bezugsquelle Dies ist eine explizite Benutzeraktion, bei der der Analyst einen bestimmten Match als „True Match“ oder „Confirmed Match“ klassifiziert. Dieses Ereignis wird im Audit-Trail des Cases protokolliert. Erfassen Wird protokolliert, wenn ein Analyst einen Match im System offiziell bestätigt. Ereignistyp explicit
	Antrag genehmigt	Der Kundenantrag wurde nach erfolgreichem KYC-Screening und allen weiteren erforderlichen Prüfungen vollständig genehmigt. Dieses Ereignis tritt in der Regel im Quellsystem ein, nachdem von World-Check ein „Clear“-Ergebnis eingegangen ist.
Warum das wichtig ist Dies markiert das erfolgreiche Geschäftsergebnis des Onboarding-Prozesses. Die Messung der Zeit von der Einreichung bis zu diesem Punkt zeigt die vollständige „Time-to-Yes“ für einen neuen Kunden. Bezugsquelle Dieses Ereignis ist nicht Bestandteil von World-Check. Es muss aus dem vorgelagerten CRM- oder Kernanwendungssystem bezogen werden, in dem die endgültige Geschäftsentscheidung getroffen wird. Erfassen Ereignis, das nach der endgültigen Genehmigung im Quellanwendungssystem protokolliert wird. Ereignistyp explicit
	Automatisiertes Screening durchgeführt	Das World-Check-System prüft die Kundendaten automatisch gegen seine Risikodatenbank. Diese systemgesteuerte Aktivität erzeugt erste Ergebnisse, etwa mögliche Treffer oder einen unauffälligen Status.
Warum das wichtig ist Diese Aktivität ist der erste wertschöpfende Schritt im Screening-Prozess. Verzögerungen bis zu diesem Punkt weisen auf Probleme mit der System- oder Datenbereitschaft hin, während das Ergebnis den anschließenden manuellen Arbeitsaufwand bestimmt. Bezugsquelle Dieses Ereignis wird möglicherweise explizit im Audit-Trail des Cases protokolliert oder anhand des Timestamps abgeleitet, zu dem die ersten Screening-Ergebnisse für den Case verfügbar werden. Erfassen Systemprotokolleintrag, der nach Abschluss des automatisierten Datenbank-Scans erzeugt wird. Ereignistyp explicit
	Case zur Prüfung eskaliert	Ein Analyst der ersten Ebene eskaliert einen komplexen oder risikoreichen Case zur abschließenden Entscheidung an einen Senior Analysten oder Manager. Dies ist ein wichtiger Übergabepunkt innerhalb des Compliance-Teams.
Warum das wichtig ist Eskalationen verursachen häufig Engpässe und verlängern die Durchlaufzeit. Die Analyse ihrer Häufigkeit und Gründe kann auf Schulungsbedarf bei Junior-Analysten oder auf unklare Prüfungsrichtlinien hinweisen. Bezugsquelle Als explizite Aktion im Case-Workflow oder Audit-Trail aufgezeichnet. Das Ereignis kann auch aus einer Änderung des dem Case zugewiesenen Benutzers abgeleitet werden, insbesondere wenn der neue Benutzer über höhere Berechtigungen verfügt. Erfassen Wird über eine eigene Schaltfläche „Escalate“ oder eine Workflow-Aktion innerhalb des Cases protokolliert. Ereignistyp explicit
	False Positive bestätigt	Der Analyst kommt zu dem Schluss, dass ein potenzieller Match nicht mit dem geprüften Kunden identisch ist. Der Match wird verworfen und der Screening-Prozess für diesen Alert abgeschlossen.
Warum das wichtig ist Dies ist ein häufiges Ergebnis des Prüfungsprozesses. Die Dauer bis zur Entscheidung über False Positives zeigt, wie effizient Analysten arbeiten und wie präzise die automatisierte Screening-Logik ist. Bezugsquelle Dies ist eine explizite Benutzeraktion, bei der der Analyst einen bestimmten Match als „False Positive“ oder „Not a Match“ klassifiziert. Die Aktion wird in der Regel in der Case-Historie protokolliert. Erfassen Wird protokolliert, wenn ein Analyst einen potenziellen Match im System offiziell verwirft. Ereignistyp explicit
	Potenzieller Match identifiziert	Der automatisierte Screening-Prozess hat einen oder mehrere potenzielle Matches gefunden, die eine manuelle Prüfung durch einen Analysten erfordern. Dieses Ereignis überführt den Case aus einem automatisierten Status in eine Warteschlange für die manuelle Untersuchung.
Warum das wichtig ist Diese Aktivität ist ein kritischer Verzweigungspunkt im Prozess. Cases mit potenziellen Matches durchlaufen einen längeren und komplexeren Pfad. Die Nachverfolgung unterstützt die Ressourcenplanung und die Engpassanalyse für das Prüfungsteam. Bezugsquelle Abgeleitet aus einer Änderung des Case-Status in „Review Required“, „Potential Match“ oder einen ähnlichen Status im World-Check-Case-Management-Modul. Erfassen Abgeleitet aus einer Änderung des Case-Status, die anzeigt, dass nun eine manuelle Prüfung erforderlich ist. Ereignistyp inferred
	Zusätzliche Informationen angefordert	Der Analyst stellt fest, dass weitere Informationen erforderlich sind, um den potenziellen Match aufzuklären, und fordert diese bei der zuständigen Geschäftseinheit an. Der Case erhält dadurch den Status „Ausstehend“, bis die Informationen vorliegen.
Warum das wichtig ist Häufige Vorkommen dieser Aktivität weisen auf Probleme mit der Qualität der ursprünglich für das Screening bereitgestellten Daten hin. Da die Aktivität von externen Teams abhängt, verursacht sie erhebliche Verzögerungen und ist ein wesentlicher Treiber langer Durchlaufzeiten. Bezugsquelle Dies kann eine explizite Benutzeraktion sein, die in den Case-Notizen oder im Audit-Log protokolliert wird. Alternativ lässt sich das Ereignis aus einer Änderung des Case-Status in „Pending Information“ oder „RFI“ ableiten. Erfassen Wird protokolliert, wenn ein Analyst eine Funktion verwendet, um zu kennzeichnen, dass für den Case weitere Informationen erforderlich sind. Ereignistyp explicit

Anleitungen zur Datenextraktion

So beziehen Sie Ihre Daten aus Refinitiv World-Check

Schritte

Bei World-Check One anmelden: Öffnen Sie das Portal Refinitiv World-Check One und melden Sie sich mit Ihren Zugangsdaten an.
Zu Case Management wechseln: Öffnen Sie den Bereich Case Management, in dem alle Screening-Cases gespeichert und verwaltet werden.
Export des Case-Reports vorbereiten: Öffnen Sie im Case Management die Funktion für Berichte oder Exporte. Sie kann beispielsweise „Export Cases“ oder „Case Report“ heißen.
Case-Report konfigurieren: Wählen Sie die Spalten für den Export aus. Achten Sie darauf, Felder für die Case-ID (CustomerApplication), das Erstellungsdatum, das Auflösungsdatum, den Case-Status, beispielsweise Clear oder Match Found, sowie die Risikostufe einzubeziehen.
Daten aus Case Management exportieren: Legen Sie den Zeitraum fest, in der Regel die letzten drei bis sechs Monate. Wenden Sie erforderliche Filter an, etwa nach Benutzergruppe oder Case-Typ. Exportieren Sie die Daten als CSV-Datei und nennen Sie sie case_report.csv.
Export des Audit Trails vorbereiten: Öffnen Sie in World-Check One den Bereich für Audit-Trail- oder Audit-Log-Berichte. Dort finden Sie detaillierte Ereignisverläufe für jeden Case.
Audit Trail konfigurieren und exportieren: Wählen Sie alle relevanten Spalten aus, darunter Case-ID, Ereignisname oder -beschreibung, Ereignis-Timestamp und den Benutzer, der die Aktion ausgeführt hat. Exportieren Sie die Daten für denselben Zeitraum wie den Case-Report. Speichern Sie die Datei als audit_trail.csv.
Externe Prozessschritte aus Quellsystemen beziehen: Ermitteln Sie Daten zu Aktivitäten außerhalb von World-Check, etwa Application Submitted, Application Approved, Account Activated und Application Rejected. Diese Daten stammen in der Regel aus einem CRM- oder Kernbankensystem. Exportieren Sie die Daten mit der CustomerApplication-ID und den relevanten Timestamps.
Daten zusammenführen und transformieren: Laden Sie die exportierten CSV-Dateien (case_report.csv, audit_trail.csv und die Daten des externen Systems) in ein Tool oder Skript zur Datenaufbereitung.
Audit-Ereignisse Aktivitäten zuordnen: Verarbeiten Sie die Datei audit_trail.csv. Ordnen Sie die unstrukturierten Ereignisbeschreibungen aus dem Audit Log den standardisierten ActivityName-Werten zu. So wird beispielsweise ein Audit-Log-Eintrag wie „Case Assigned to Analyst“ zu „Analyst Review Started“.
Änderungen des Case-Status Aktivitäten zuordnen: Verarbeiten Sie die Datei case_report.csv, um aus Statusänderungen Aktivitäten zu erzeugen. Verwenden Sie das Auflösungsdatum und den finalen Status des Cases, um die Ereignisse „Screening Completed - Clear“ oder „Screening Completed - Match Found“ zu erstellen.
Finales Event Log erstellen: Führen Sie alle verarbeiteten Daten aus den verschiedenen Quelldateien in einer einzigen CSV-Datei zusammen. Stellen Sie sicher, dass die finale Datei die erforderlichen Spalten CustomerApplication, ActivityName und EventTime sowie alle empfohlenen Attribute enthält. Speichern Sie diese Datei für den Upload in das Process-Mining-Tool.

Konfiguration

Berichtstypen: Sie benötigen mindestens zwei separate Berichte: einen zusammenfassenden Case-Management-Bericht und einen detaillierten Audit-Trail-Bericht.
Zeitraum: Wählen Sie für eine erste Analyse einen Zeitraum von mindestens drei bis sechs Monaten, damit ausreichend abgeschlossene und laufende Cases enthalten sind. Der Zeitraum muss in allen exportierten Dateien übereinstimmen.
Exportformat: Wählen Sie CSV (Comma Separated Values) als Exportformat, um die Daten einfach weiterzuverarbeiten.
Wichtige Spalten im Case-Report: Der Export muss Case-ID, Erstellungs-Timestamp, Auflösungs-Timestamp, finalen Status, zuständigen Analysten und Risikostufe enthalten.
Wichtige Spalten im Audit-Trail-Bericht: Der Audit-Log-Export muss Case-ID, Ereignisbeschreibung, Ereignis-Timestamp und Benutzer-ID enthalten.
Voraussetzungen: Sie benötigen Zugriff auf das World-Check-One-Portal mit Benutzerberechtigungen zum Anzeigen und Exportieren von Case-Management- und Audit-Log-Daten. Dafür können über die Standardrolle eines Analysten hinausgehende Berechtigungen erforderlich sein.

a Beispielabfrage sql

/*
This is a configuration and mapping guide, not an executable script. 
The process relies on manually exporting two reports from World-Check One and combining them with data from an upstream system (e.g., CRM).
*/

-- Step 1: Export 'Case Management Report' as case_report.csv
-- Step 2: Export 'Audit Trail Report' as audit_trail.csv
-- Step 3: Export relevant events from CRM/core system as source_system_events.csv

-- Step 4: Combine and map the files using a script or ETL tool to create the final event log.

-- Mapping logic for final_event_log.csv

-- Part A: Data from source_system_events.csv
SELECT
  ApplicationID AS CustomerApplication,
  'Application Submitted' AS ActivityName,
  SubmissionTimestamp AS EventTime,
  NULL AS EventEndTime,
  OriginatorID AS ReviewerId,
  OriginatingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Submission'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Approved' AS ActivityName,
  ApprovalTimestamp AS EventTime,
  NULL AS EventEndTime,
  ApproverID AS ReviewerId,
  ApprovingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Approval'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Account Activated' AS ActivityName,
  ActivationTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Operations' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Activation'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Rejected' AS ActivityName,
  RejectionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ReviewerID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Rejection'

-- Part B: Data from World-Check audit_trail.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Request Created' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Created%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Automated Screening Performed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Automated Screening Completed%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Potential Match Identified' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Potential Match Found%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Analyst Review Started' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Assigned%' OR EventDescription LIKE '%Review Started%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Additional Information Requested' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Information Requested%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Case Escalated for Review' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Escalated%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'False Positive Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Dismissed as False Positive%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'True Match Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Confirmed as True%'

-- Part C: Data from World-Check case_report.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Clear' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Clear'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Match Found' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Match Found'

Schritte

Voraussetzungen und Einrichtung: Stellen Sie sicher, dass Python 3.6 oder höher sowie die Bibliotheken requests und pandas installiert sind. Beziehen Sie Ihren World-Check-One-API-Key und das API-Secret von Ihrem Refinitiv-Ansprechpartner oder aus dem Entwicklerportal. Speichern Sie diese Zugangsdaten sicher.
Authentifizierungslogik entwickeln: Erstellen Sie in Ihrem Python-Skript eine Funktion, die eine POST-Anfrage an den Authentifizierungsendpunkt von World-Check One sendet. Verwenden Sie Ihren API-Key und Ihr Secret, um ein temporäres Bearer-Token für nachfolgende API-Aufrufe abzurufen.
Daten des Quellsystems identifizieren: Der Prozess beginnt und endet außerhalb von World-Check. Identifizieren Sie das Quellsystem, beispielsweise ein CRM oder eine Kernbankplattform, in dem die ursprünglichen Antragsdaten gespeichert sind. Extrahieren Sie daraus Ereignisse wie Application Submitted, Application Approved, Account Activated und Application Rejected. Dies kann über eine Datenbankabfrage oder eine andere API erfolgen.
World-Check-Cases abrufen: Senden Sie mit dem authentifizierten Token eine GET-Anfrage an den Endpunkt /cases der World-Check-One-API. Verwenden Sie Abfrageparameter, um Cases nach einem bestimmten Zeitraum zu filtern, beispielsweise anhand ihres Erstellungs- oder Änderungsdatums.
API-Paginierung verarbeiten: Antworten der World-Check-API sind paginiert. Ihr Skript muss die Paginierungsinformationen in der Antwort prüfen und alle Seiten durchlaufen, um die vollständige Liste der Cases für den festgelegten Zeitraum abzurufen.
Case-Details und Verlauf abrufen: Senden Sie für jede abgerufene Case-ID weitere GET-Anfragen an Endpunkte wie /cases/{case_system_id} und /cases/{case_system_id}/audit-trail. Diese Endpunkte liefern detaillierte Statusänderungen, Auflösungsinformationen und Benutzeraktionen zum jeweiligen Case.
Rohdaten Aktivitäten zuordnen: Dies ist ein entscheidender Transformationsschritt. Schreiben Sie eine Logik, die die API-Antwortdaten, darunter Case-Details und Audit Trail, für jeden Case durchläuft. Ordnen Sie bestimmte Statusänderungen, Ergebniscodes und Audit-Ereignisse den erforderlichen Geschäftsaktivitäten zu. So wird beispielsweise ein Ereignis zur Case-Erstellung zu Screening Request Created, während eine Ergebnisauflösung mit False Positive zu False Positive Confirmed wird.
Datenquellen zusammenführen: Führen Sie die aus World-Check extrahierten Daten mit den Daten Ihres Quellsystems aus Schritt 3 zusammen. Verwenden Sie die CustomerApplication-ID als gemeinsamen Schlüssel, um für jeden Kunden ein vollständiges End-to-End-Event-Log zu erstellen.
Daten strukturieren und anreichern: Fassen Sie alle zugeordneten Ereignisse in einer einzigen Liste von Datensätzen zusammen. Stellen Sie für jeden Datensatz sicher, dass alle erforderlichen Attribute (CustomerApplication, ActivityName, EventTime) und die empfohlenen Attribute befüllt sind. Berechnen Sie nach Möglichkeit EventEndTime, beispielsweise anhand des Timestamps des nächsten Ereignisses für den jeweiligen Case.
Als CSV exportieren: Konvertieren Sie die finale Liste der Ereignisdatensätze in einen pandas DataFrame. Ordnen Sie die Spalten entsprechend dem erforderlichen Format an und exportieren Sie den DataFrame in eine CSV-Datei. Speichern Sie die Datei mit UTF-8-Kodierung, damit sie mit ProcessMind kompatibel ist.

Konfiguration

API-Zugangsdaten: Für die World-Check-One-Screening-API benötigen Sie einen gültigen API-Key und ein API-Secret. Diese müssen mit den erforderlichen Berechtigungen zum Lesen von Case- und Audit-Daten bereitgestellt werden.
API-Basis-URL: Das Skript muss mit der korrekten Basis-URL Ihrer World-Check-API-Umgebung konfiguriert werden, beispielsweise https://api.world-check.com/v2/.
Zeitraum: Implementieren Sie die Parameter start_date und end_date im Skript, um den Extraktionszeitraum zu steuern. Für eine erste Analyse empfiehlt sich ein Zeitraum von drei bis sechs Monaten. Für die laufende Überwachung sollte das Skript inkrementell für kürzere Zeiträume ausgeführt werden, etwa für den Vortag oder die Vorwoche.
Verbindung zum Quellsystem: Für die vorgelagerten und nachgelagerten Systeme, beispielsweise CRM oder Kernbankplattform, benötigen Sie Verbindungsdaten, um die Ereignisse außerhalb des Screenings abzurufen. Dabei kann es sich um eine Datenbank-Verbindungszeichenfolge oder einen anderen API-Endpunkt samt Zugangsdaten handeln.
Paginierung: Das Skript muss beim Abruf der Case-Liste eine Seitengröße angeben, die häufig limit genannt wird. Ein Wert zwischen 50 und 100 ist in der Regel effizient. Die Logik muss alle Seiten vollständig abrufen.

a Beispielabfrage python

import requests
import pandas as pd
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># --- Configuration and Placeholders ---
WC_API_KEY = class="hl-string">'[Your World-Check API Key]'
WC_API_SECRET = class="hl-string">'[Your World-Check API Secret]'
WC_API_BASE_URL = class="hl-string">'https://api.world-check.com/v2' class=class="hl-string">"hl-comment"># Use correct URL for your environment

class=class="hl-string">"hl-comment"># Date range for the extraction
START_DATE = (datetime.now() - timedelta(days=90)).strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
END_DATE = datetime.now().strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

class=class="hl-string">"hl-comment"># --- MOCK FUNCTIONS (Replace with actual data source connections) ---

def get_source_system_events(application_ids):
    class="hl-string">"""Simulates fetching pre- and post-screening events from a CRM or core system."""
    print(fclass="hl-string">'Fetching source system events for {len(application_ids)} applications...')
    mock_events = []
    for i, app_id in enumerate(application_ids):
        class=class="hl-string">"hl-comment"># Simulate initial application events
        mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Submitted', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i+5)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Sales'})
        class=class="hl-string">"hl-comment"># Simulate final outcome events
        if i % 3 == 0:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Approved', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Onboarding'})
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Account Activated', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i-1)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Operations'})
        else:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Rejected', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Compliance'})
    return mock_events

def get_worldcheck_cases(token):
    class="hl-string">"""Simulates fetching a list of cases from the World-Check API."""
    print(class="hl-string">'Fetching World-Check cases...')
    class=class="hl-string">"hl-comment"># In a real implementation, you would call GET /cases with date filters and handle pagination
    mock_case_list = [
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-001', class="hl-string">'name': class="hl-string">'John Doe', class="hl-string">'caseSystemId': class="hl-string">'WC-001', class="hl-string">'customReference': class="hl-string">'APP-1001', class="hl-string">'creationDate': class="hl-string">'2023-10-01T10:00:00Z', class="hl-string">'riskLevel': class="hl-string">'Medium'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-002', class="hl-string">'name': class="hl-string">'Jane Smith', class="hl-string">'caseSystemId': class="hl-string">'WC-002', class="hl-string">'customReference': class="hl-string">'APP-1002', class="hl-string">'creationDate': class="hl-string">'2023-10-02T11:30:00Z', class="hl-string">'riskLevel': class="hl-string">'Low'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-003', class="hl-string">'name': class="hl-string">'Peter Jones', class="hl-string">'caseSystemId': class="hl-string">'WC-003', class="hl-string">'customReference': class="hl-string">'APP-1003', class="hl-string">'creationDate': class="hl-string">'2023-10-03T09:05:00Z', class="hl-string">'riskLevel': class="hl-string">'High'}
    ]
    return mock_case_list

def get_worldcheck_case_details(case_system_id, token):
    class="hl-string">"""Simulates fetching the audit trail and results for a single World-Check case."""
    print(fclass="hl-string">'Fetching details for case {case_system_id}...')
    class=class="hl-string">"hl-comment"># This mock data simulates a complex history for one case to generate multiple activities
    if case_system_id == class="hl-string">'WC-001':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:05:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:06:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T14:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T15:30:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as False Positive', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T11:00:00Z', class="hl-string">'event': class="hl-string">'ESCALATED', class="hl-string">'details': class="hl-string">'Case escalated to senior analyst', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T09:00:00Z', class="hl-string">'event': class="hl-string">'INFORMATION_REQUESTED', class="hl-string">'details': class="hl-string">'Additional documents requested', class="hl-string">'user': class="hl-string">'senior_analyst'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-05T16:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'senior_analyst'}
            ]
        }
    elif case_system_id == class="hl-string">'WC-003':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:10:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:11:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T10:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T11:25:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as True Positive', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T12:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed with matches', class="hl-string">'user': class="hl-string">'analyst2'}
            ]
        }
    else: class=class="hl-string">"hl-comment"># Simple class="hl-string">'Clear' case
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:35:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:36:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'SYSTEM'}
            ]
        }

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def main():
    class="hl-string">"""Main function to run the extraction process."""
    class=class="hl-string">"hl-comment"># 1. Authenticate (real implementation)
    class=class="hl-string">"hl-comment"># token = get_wc_auth_token()
    token = class="hl-string">'mock_token' class=class="hl-string">"hl-comment"># Using a mock token for this example

    class=class="hl-string">"hl-comment"># 2. Get list of cases from World-Check
    cases = get_worldcheck_cases(token)
    if not cases:
        print(class="hl-string">'No cases found for the specified period.')
        return

    event_log = []

    class=class="hl-string">"hl-comment"># 3. Process each case from World-Check
    for case in cases:
        app_id = case.get(class="hl-string">'customReference')
        if not app_id:
            continue

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Screening Request Created' event
        event_log.append({
            class="hl-string">'CustomerApplication': app_id,
            class="hl-string">'ActivityName': class="hl-string">'Screening Request Created',
            class="hl-string">'EventTime': case[class="hl-string">'creationDate'],
            class="hl-string">'ReviewerId': class="hl-string">'SYSTEM',
            class="hl-string">'DepartmentName': class="hl-string">'Compliance',
            class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
        })

        details = get_worldcheck_case_details(case[class="hl-string">'caseSystemId'], token)
        for event in details.get(class="hl-string">'auditTrail', []):
            activity = None
            user = event.get(class="hl-string">'user', class="hl-string">'SYSTEM')
            department = class="hl-string">'Compliance' if user != class="hl-string">'SYSTEM' else class="hl-string">'System'
            
            class=class="hl-string">"hl-comment"># 4. Map audit trail events to activities
            if event[class="hl-string">'event'] == class="hl-string">'AUTOMATED_SCREENING':
                activity = class="hl-string">'Automated Screening Performed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_FOUND':
                activity = class="hl-string">'Potential Match Identified'
            elif event[class="hl-string">'event'] == class="hl-string">'REVIEW_STARTED':
                activity = class="hl-string">'Analyst Review Started'
            elif event[class="hl-string">'event'] == class="hl-string">'INFORMATION_REQUESTED':
                activity = class="hl-string">'Additional Information Requested'
            elif event[class="hl-string">'event'] == class="hl-string">'ESCALATED':
                activity = class="hl-string">'Case Escalated for Review'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'False Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'False Positive Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'True Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'True Match Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'Clear' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Clear'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'matches' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Match Found'

            if activity:
                event_log.append({
                    class="hl-string">'CustomerApplication': app_id,
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': event[class="hl-string">'timestamp'],
                    class="hl-string">'ReviewerId': user,
                    class="hl-string">'DepartmentName': department,
                    class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
                })
    
    class=class="hl-string">"hl-comment"># 5. Get events from source system
    application_ids = [case[class="hl-string">'customReference'] for case in cases if case.get(class="hl-string">'customReference')]
    source_events = get_source_system_events(application_ids)
    event_log.extend(source_events)

    class=class="hl-string">"hl-comment"># 6. Create and format DataFrame
    if not event_log:
        print(class="hl-string">'No events were generated.')
        return

    df = pd.DataFrame(event_log)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Add EventEndTime by shifting the EventTime of the next event
    df[class="hl-string">'EventEndTime'] = df.groupby(class="hl-string">'CustomerApplication')[class="hl-string">'EventTime'].shift(-1)
    
    class=class="hl-string">"hl-comment"># Add placeholder for non-extractable attribute
    df[class="hl-string">'SlaTargetDate'] = pd.NaT

    class=class="hl-string">"hl-comment"># 7. Finalize and Export
    output_columns = [
        class="hl-string">'CustomerApplication',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'EventEndTime',
        class="hl-string">'ReviewerId',
        class="hl-string">'DepartmentName',
        class="hl-string">'RiskLevel',
        class="hl-string">'SlaTargetDate'
    ]
    class=class="hl-string">"hl-comment"># Ensure all required columns exist, even if empty
    for col in output_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[output_columns]

    output_filename = class="hl-string">'event_log_worldcheck.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%fZ')
    print(fclass="hl-string">'Successfully exported event log to {output_filename}')

if __name__ == class="hl-string">'__main__':
    main()

Bereit für den Start?

Verwenden Sie dieses Daten-Template, um Ihre Process-Mining-Initiative für das KYC-Kunden-Onboarding zu starten. Wenn Sie diese Richtlinien befolgen, gewinnen Sie wertvolle Erkenntnisse und verbessern Ihre Abläufe nachhaltig.

Zurück zum Leitfaden zur Verbesserung Template herunterladen

Optimieren Sie jetzt das KYC-Kunden-Onboarding und stärken Sie die Compliance

Ermöglichen Sie ein reibungsarmes Kunden-Onboarding und verkürzen Sie die Dauer auf nur 24 Stunden.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Testen Sie 14 Tage kostenlos.

Ihr Daten-Template für das KYC-Kunden-Onboarding

Ihr Daten-Template für das KYC-Kunden-Onboarding

Attribute des KYC-Kunden-Onboardings

Aktivitäten des KYC-Kunden-Onboardings

Anleitungen zur Datenextraktion

Export von Case- und Audit-Log-Daten aus Refinitiv World-Check One

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit der World-Check-One-Screening-API

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

Optimieren Sie jetzt das KYC-Kunden-Onboarding und stärken Sie die Compliance

Ihr Daten-Template für das KYC-Kunden-Onboarding

Ihr Daten-Template für das KYC-Kunden-Onboarding

Attribute des KYC-Kunden-Onboardings

Aktivitäten des KYC-Kunden-Onboardings

Anleitungen zur Datenextraktion

Export von Case- und Audit-Log-Daten aus Refinitiv World-Check One

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit der World-Check-One-Screening-API

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

Optimieren Sie jetzt das KYC-Kunden-Onboarding und stärken Sie die Compliance

Ihre Privatsphäre ist uns wichtig