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

Refinitiv World-Check
Ihr Daten-Template für das KYC-Kunden-Onboarding

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, welche zentralen Attribute Sie erfassen und welche Aktivitäten Sie nachverfolgen sollten. Außerdem erfahren Sie, wie Sie diese Informationen aus Ihren Quellsystemen extrahieren. So stellen Sie sicher, dass Ihnen alle erforderlichen Daten für eine fundierte Prozessanalyse und Verbesserung vorliegen.
  • Empfohlene Attribute für die Erfassung
  • Wichtige Aktivitäten zur Nachverfolgung
  • Hinweise zur Datenextraktion
Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Attribute für das KYC-Kunden-Onboarding

Diese Datenfelder sollten Sie für eine umfassende Analyse des KYC-Kunden-Onboardings in Ihr Event Log aufnehmen.
3 Erforderlich 5 Empfohlen 11 Optional
Name Beschreibung
Aktivitätsname
ActivityName
Name eines bestimmten Geschäftsereignisses oder einer Aufgabe im KYC-Onboarding-Prozess.
Beschreibung

Der Aktivitätsname bezeichnet einen einzelnen Schritt oder ein Ereignis im Kunden-Onboarding, etwa „Antrag eingereicht“, „Analystenprüfung begonnen“ oder „Screening abgeschlossen: unauffällig“. Diese Aktivitäten bilden die Knoten der Prozesslandkarte und schlüsseln den gesamten Workflow detailliert auf.

Die Analyse von Aktivitäten bildet den Kern des Process Mining. Wenn Analysten die Abfolge und Häufigkeit verschiedener Aktivitäten verfolgen, können sie den tatsächlichen Prozessablauf entdecken, häufige Pfade erkennen, Abweichungen von der Standardvorgehensweise 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 legt die einzelnen Prozessschritte fest. Es ist unverzichtbar, um den Prozessablauf zu entdecken und zu visualisieren sowie Engpässe zu erkennen.

Woher beziehen

Diese Informationen finden sich üblicherweise in Event Logs oder Audit-Trail-Tabellen, häufig im Zusammenhang mit Statusänderungen des Fallmanagementobjekts.

Beispiele
Möglicher Treffer identifiziertAnalystenprüfung begonnenFalscher Treffer bestätigtAntrag genehmigt
Ereigniszeit
EventTime
Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung

Die Ereigniszeit gibt das genaue Datum und die Uhrzeit an, zu denen eine Aktivität erfasst wurde. Dieser Timestamp bildet die chronologische Grundlage des Prozesses und ermöglicht es, Ereignisse korrekt zu ordnen und den Fallverlauf zu rekonstruieren.

Dieses Attribut ist für alle zeitbasierten Process-Mining-Analysen entscheidend. Es dient dazu, die Dauer zwischen Aktivitäten zu berechnen, etwa Zyklus- und Wartezeiten, die Gesamtdauer eines Falls zu messen, die Prozessleistung im Zeitverlauf zu analysieren und die Einhaltung von Service Level Agreements (SLAs) zu prüfen. Ohne genaue Timestamps lassen sich weder die Prozessleistung beurteilen noch zeitbedingte Engpässe erkennen.

Warum das wichtig ist

Der Timestamp jeder Aktivität ist unverzichtbar, um alle dauerbasierten Kennzahlen zu berechnen, die Prozessabfolge zu ermitteln und Engpässe zu analysieren.

Woher beziehen

Dieses Standardfeld findet sich in jedem Event Log oder jeder Audit-Trail-Tabelle. Es heißt häufig „Timestamp“, „EventDate“ oder „CreationDate“.

Beispiele
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
Kundenantrag
CustomerApplication
Eindeutige Kennung für den Onboarding-Antrag eines einzelnen Kunden. Sie dient als primäre Fall-ID.
Beschreibung

Der Kundenantrag ist die zentrale Fall-ID, unter der alle Ereignisse und Aktivitäten zum Onboarding eines einzelnen Kunden zusammengefasst werden. Mit ihr lässt sich der gesamte Verlauf jedes Kunden im Know-Your-Customer-Prozess (KYC) chronologisch nachverfolgen, von der ersten Einreichung bis zur endgültigen Entscheidung.

In der Process-Mining-Analyse ist dieses Attribut grundlegend, um den durchgängigen Verlauf jedes Antrags zu rekonstruieren. Es ermöglicht die Visualisierung von Prozessabläufen, die Berechnung der gesamten Zykluszeiten und die Identifizierung von Varianten. Durch die Gruppierung der Fälle nach dieser Kennung können Unternehmen nachvollziehen, welche unterschiedlichen Wege ein Antrag nehmen kann, Engpässe erkennen und die Effizienz verschiedener Onboarding-Prozesse vergleichen.

Warum das wichtig ist

Diese zentrale Fall-ID verknüpft alle zugehörigen Aktivitäten und ermöglicht so die Analyse des gesamten Kunden-Onboarding-Prozesses.

Woher beziehen

Diese Kennung ist üblicherweise der Primärschlüssel in der Haupttabelle für Anträge oder Fälle im Refinitiv-World-Check-System oder in einem integrierten CRM.

Beispiele
APP-2023-00123APP-2023-00124APP-2023-00125
Abteilung
DepartmentName
Abteilung oder 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 „Qualitätssicherung“. Damit ist eine Analyse auf einer höheren Organisationsebene als der des einzelnen Benutzers möglich.

Die Analyse nach Abteilung ist entscheidend, um Engpässe zwischen Abteilungen zu erkennen und Übergabezeiten zu messen. Sie zeigt, wie die Arbeit zwischen verschiedenen Teams fließt und an welchen Übergängen Verzögerungen auftreten. Diese Sicht unterstützt die abteilungsübergreifende Zusammenarbeit und verbessert die Effizienz des Gesamtprozesses.

Warum das wichtig ist

Ermöglicht die Analyse der Prozessleistung nach Abteilung und hilft, Verzögerungen bei Übergaben zwischen Teams zu erkennen.

Woher beziehen

Diese Informationen können im Benutzerprofil des Systems oder in einem zugehörigen HR-System gespeichert sein. Möglicherweise müssen sie anhand der Benutzer-ID mit den Ereignisdaten verknüpft werden.

Beispiele
Onboarding-TeamCompliance-PrüfungGeschäftsleitung
Endzeit des Ereignisses
EventEndTime
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 lassen sich als zeitpunktbezogen modellieren, wobei StartTime und EndTime übereinstimmen. Andere Aktivitäten haben eine messbare Dauer, etwa „Analystenprüfung begonnen“ und „Analystenprüfung abgeschlossen“. Mit Start- und Endzeit lässt sich die Verarbeitungszeit genau messen.

Für die Prozessanalyse ist eine Endzeit wichtig, um die genaue Verarbeitungszeit einer Aktivität zu berechnen. Die Zykluszeit umfasst dagegen auch Wartezeiten. So lässt sich unterscheiden, wie lange ein Fall aktiv bearbeitet wird und wie lange er untätig in einer Warteschlange liegt. Das ist entscheidend für die Ressourcenoptimierung und die Effizienzanalyse.

Warum das wichtig ist

Ermöglicht die genaue Berechnung der Verarbeitungszeit einer Aktivität. So lässt sich die aktive Arbeitszeit von untätigen Wartezeiten trennen und die Leistung präziser analysieren.

Woher beziehen

Bei Aktivitäten mit einer Dauer kann dieser Wert in einem separaten Feld wie „CompletionDate“ oder „EndDate“ in den Event-Log- oder Audit-Trail-Tabellen gespeichert sein.

Beispiele
2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
Prüfer-ID
ReviewerId
Kennung des Benutzers, Analysten oder automatisierten Agenten, der die Aktivität ausgeführt hat.
Beschreibung

Die Prüfer-ID beziehungsweise der Benutzer gibt an, wer eine bestimmte Aufgabe im KYC-Prozess ausgeführt hat. Das kann ein Compliance-Analyst, ein Onboarding-Spezialist oder bei automatisierten Aktivitäten ein Systemkonto sein. Diese Informationen machen die Verteilung der Arbeitslast und die individuelle Leistung sichtbar.

Das Attribut ist für ressourcenbezogene Analysen unverzichtbar. Es hilft, Leistungsunterschiede zwischen Benutzern oder Teams zu verstehen, Schulungsbedarf zu erkennen und die Arbeitslast besser zu verteilen. Außerdem ist es wichtig für die Analyse von Übergaben, sozialen Netzwerken und der Ressourcennutzung im Compliance-Bereich.

Warum das wichtig ist

Ermöglicht die Analyse der Arbeitslastverteilung, der Benutzerleistung und der Übergaben zwischen Abteilungen. Das ist entscheidend für die Ressourcenoptimierung.

Woher beziehen

Findet sich üblicherweise in Event Logs oder Audit-Trails und heißt häufig „UserID“, „PerformedBy“ oder „Owner“.

Beispiele
analyst_jdoesystem_auto_screenermanager_bsmith
Risikostufe
RiskLevel
Berechnete Risikoeinstufung des Kundenantrags, etwa niedrig, mittel oder hoch.
Beschreibung

Die Risikostufe ist eine zentrale Information in KYC-Prozessen und bestimmt den Umfang der erforderlichen Sorgfaltsprüfung. Sie wird häufig anhand von Faktoren wie Kundentyp, geografischer Lage und Geschäftstätigkeit ermittelt. Diese Einstufung kann den Prozesspfad eines Antrags erheblich beeinflussen.

Für die Prozessanalyse ist es wichtig, Fälle nach Risikostufe zu segmentieren. So lassen sich Unterschiede bei Zykluszeiten und Prozessabläufen erklären. Anträge mit hohem Risiko erfordern beispielsweise möglicherweise zusätzliche Schritte und dauern länger. Dieses Attribut ist für die Dashboards „Ablehnungsquote und Ablehnungsgründe bei Anträgen“ und „Zykluszeit bis zum Start der Hintergrundprüfung“ wichtig, um zu verstehen, wie sich das Risiko auf Ergebnisse und Effizienz auswirkt.

Warum das wichtig ist

Die Segmentierung des Prozesses nach Risikostufe ist entscheidend, um zu verstehen, warum bestimmte Fälle länger dauern oder andere Pfade durchlaufen, und um Ablehnungsquoten zu analysieren.

Woher beziehen

Dies ist ein zentrales Datenfeld im Kundenantrag oder Falldatensatz. Prüfen Sie dazu das Fallmanagementmodul von Refinitiv World-Check.

Beispiele
NiedrigMittelHoch
SLA-Zieldatum
SlaTargetDate
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-Falls. Sie ergibt sich aus der Service-Level-Vereinbarung mit dem Kunden oder aus internen Richtlinien. An diesem Datum werden die tatsächlichen Abschlusszeiten gemessen.

Dieses Attribut ist grundlegend für das Dashboard „SLA-Einhaltung und Analyse von SLA-Verstößen“. Damit wird berechnet, ob ein Fall fristgerecht abgeschlossen wurde. Die Analyse von SLA-Verstößen hilft, systemische Prozessprobleme zu erkennen, die Verzögerungen verursachen. So kann das Unternehmen Korrekturmaßnahmen ergreifen, Termine besser einhalten und Compliance-Anforderungen erfüllen.

Warum das wichtig ist

Dient als Maßstab für die fristgerechte Bearbeitung und ist entscheidend für die Berechnung der SLA-Einhaltungsquote und die Analyse von Verstößen.

Woher beziehen

Dieses Datum wird häufig anhand des Einreichungsdatums des Antrags und geltender Geschäftsregeln berechnet. Es kann als Feld im Falldatensatz gespeichert sein.

Beispiele
2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
Ablehnungsgrund
RejectionReason
Konkreter Grund für die Ablehnung eines Kundenantrags.
Beschreibung

Wird ein Antrag abgelehnt, hält der Ablehnungsgrund fest, warum diese Entscheidung getroffen wurde. Mögliche Gründe sind etwa „Sanktionslisten-Treffer“, „Unvollständige Unterlagen“ oder „Hohes Risikoprofil“. Diese strukturierten Angaben geben wertvolle Hinweise zur Qualität eingehender Anträge und zur Wirksamkeit des Screening-Prozesses.

Dieses Attribut ist die wichtigste Grundlage für das Dashboard „Ablehnungsquote und Ablehnungsgründe bei Anträgen“. Die Analyse der Gründe hilft, Ursachen für Ablehnungen zu erkennen. Daraus können Prozessverbesserungen und eine klarere Kommunikation mit Antragstellern folgen. Außerdem lassen sich möglicherweise unnötige Ablehnungen vermeiden. Das Attribut ergänzt die quantitative Kennzahl zur Ablehnungsquote um qualitative Informationen.

Warum das wichtig ist

Zeigt die Ursachen für abgelehnte Anträge auf. Das ist wichtig, um Verbesserungsmöglichkeiten im Onboarding-Prozess zu erkennen und die Ablehnungsquote zu senken.

Woher beziehen

Wird wahrscheinlich als Feld im Fall- oder Antragsdatensatz erfasst, wenn das Ereignis „Antrag abgelehnt“ eintritt.

Beispiele
PEP-TrefferSanktionslisten-TrefferDokumentenprüfung nicht bestandenNegative Medienberichte
Antragskanal
ApplicationChannel
Kanal, über den der Kundenantrag eingereicht wurde, etwa Online-Portal, Filiale oder mobile App.
Beschreibung

Der Antragskanal gibt an, über welchen Weg der Kundenantrag eingereicht wurde. Je nach Kanal können Vollständigkeit und Qualität der Daten sowie die Kundendemografie variieren. Das kann sich auf den weiteren Prozess auswirken.

Dieses Attribut ist wichtig für das Dashboard „Antragsdurchsatz nach Kanal“. Durch die Analyse von Volumen, Zykluszeit und Ergebnissen der Anträge aus verschiedenen Kanälen kann ein Unternehmen erkennen, welche Kanäle am effizientesten sind und wo Prozessverbesserungen nötig sein könnten. Die Analyse unterstützt strategische Entscheidungen zur Ressourcenverteilung und zu Investitionen in die einzelnen 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.

Woher beziehen

Diese Informationen werden üblicherweise zu Prozessbeginn erfasst und als Attribut im Antragsdatensatz gespeichert.

Beispiele
Online-PortalMobile AppIn der FilialeKundenbetreuer
Ist automatisiert
IsAutomated
Kennzeichnet, ob ein System (true) oder ein Mensch (false) die Aktivität ausgeführt hat.
Beschreibung

Dieses boolesche Attribut unterscheidet zwischen automatisierten Systemaufgaben und manuellen Aktivitäten von Benutzern. „Automatisiertes Screening durchgeführt“ wäre beispielsweise als automatisiert gekennzeichnet, „Analystenprüfung gestartet“ dagegen als manuell.

Diese Unterscheidung ist für die Automatisierungsanalyse entscheidend. Sie hilft dabei, die Auswirkungen der Automatisierung auf die Prozesseffizienz zu messen, manuelle Aufgaben mit Automatisierungspotenzial zu identifizieren und das Zusammenspiel menschlicher und technischer Akteure zu verstehen. Außerdem lassen sich so die Verarbeitungszeit des Systems und die manuelle Bearbeitungszeit klar voneinander abgrenzen.

Warum das wichtig ist

Unterscheidet zwischen System- und menschlichen Aktivitäten. Das ist entscheidend, um die Auswirkungen der Automatisierung zu messen und weitere Automatisierungsmöglichkeiten zu erkennen.

Woher beziehen

Der Wert wird üblicherweise anhand des Aktivitätsnamens oder der mit dem Ereignis verknüpften Benutzer-ID ermittelt, zum Beispiel, wenn es sich um ein „system“-Konto handelt.

Beispiele
truefalse
Ist Nacharbeit
IsRework
Kennzeichnet, ob eine Aktivität im selben Fall zum zweiten oder wiederholten Mal ausgeführt wird.
Beschreibung

IsRework ist ein berechnetes boolesches Attribut, das wiederholte Aktivitäten innerhalb desselben Kundenantragsfalls erkennt. Wird beispielsweise „Risikobewertung durchgeführt“ bei einem Antrag mehr als einmal ausgeführt, werden die weiteren Vorkommen als Nacharbeit gekennzeichnet.

Dieses Attribut ist wichtig, um Ineffizienzen, Schleifen und unnötige Wiederholungen im Prozess zu erkennen. Es unterstützt direkt das Dashboard „Nacharbeit und Effizienz bei der Risikobewertung“ sowie die KPI „Nacharbeitsquote bei der Risikobewertung“. Die Analyse von Nacharbeit kann Probleme bei der Qualität, der Verständlichkeit von Informationen oder der Entscheidungsfindung aufdecken, die zu unnötigem Aufwand und längeren Zykluszeiten führen.

Warum das wichtig ist

Macht Prozessineffizienzen sichtbar, indem wiederholte Aktivitäten gekennzeichnet werden. So können Sie Nacharbeitsschleifen analysieren, die Qualität verbessern und Zykluszeiten verkürzen.

Woher beziehen

Das Attribut wird bei der Datentransformation berechnet. Dazu wird die Aktivitätsfolge jedes Falls analysiert und jedes weitere Vorkommen einer Aktivität gekennzeichnet.

Beispiele
truefalse
Kunden-ID
CustomerId
Eindeutige Kennung des Kunden, der in den Onboarding-Prozess aufgenommen wird.
Beschreibung

Die Kunden-ID ist die eindeutige Kennung des Kundenprofils. Sie unterscheidet sich von der Customer Application ID, da ein Kunde im Laufe der Zeit mehrere Anträge stellen kann. Dieses Attribut verknüpft den Onboarding-Prozess mit dem zentralen Kundendatensatz.

In der Analyse ermöglicht die Kunden-ID, wiederholte Anträge desselben Kunden nachzuverfolgen. Außerdem lassen sich damit Prozessdaten um weitere Kundenattribute aus einem CRM- oder Stammdatensystem ergänzen. So entsteht ein umfassenderes Bild der Customer Journey, das über einen einzelnen Onboarding-Vorgang hinausgeht.

Warum das wichtig ist

Verknüpft den Onboarding-Fall mit einem bestimmten Kunden. So lassen sich wiederholte Anträge analysieren und Stammdaten des Kunden ergänzen.

Woher beziehen

Dies ist ein wichtiges Feld im Antrags- oder Falldatensatz, das den Datensatz mit den Kundendaten verknüpft.

Beispiele
CUST-98765CUST-98766CUST-98767
Kundenland
CustomerCountry
Wohnsitzland 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 die regulatorischen Anforderungen bei KYC-Prozessen. In den einzelnen Rechtsräumen gelten unterschiedliche Vorschriften, die sich auf Ablauf und Dauer des Prozesses auswirken können.

Die Analyse nach Ländern ermöglicht es Unternehmen, die Leistung in verschiedenen Regionen zu vergleichen, regionale Engpässe zu erkennen und die Einhaltung lokaler Vorschriften sicherzustellen. Sie ergänzt die Prozessanalyse um eine geografische Dimension und kann wichtige betriebliche Unterschiede sichtbar machen.

Warum das wichtig ist

Ermöglicht die geografische Analyse des Prozesses und hilft, regionale Unterschiede bei Leistung, Risiko und Compliance-Anforderungen zu erkennen.

Woher beziehen

Dieses Standardfeld findet sich im Kundenprofil oder Antragsformular.

Beispiele
USAGBRSGPDEU
Kundentyp
CustomerType
Einstufung des Kunden, etwa als Privatperson, Unternehmen oder Trust.
Beschreibung

Der Kundentyp kategorisiert die Einheit, die aufgenommen wird. Für verschiedene Kundentypen gelten häufig unterschiedliche Onboarding-Anforderungen, Risikoprofile und regulatorische Pflichten. Das Onboarding eines Unternehmens ist beispielsweise meist komplexer als das einer Privatperson.

Dieses Attribut dient der Segmentierungsanalyse, insbesondere für das Dashboard „Leistung nach KYC-Kundentyp“. Damit lassen sich Prozesseffizienz, Zykluszeiten und Ablehnungsquoten verschiedener Kundensegmente vergleichen. So können Unternehmen das Onboarding für die jeweiligen Kundentypen gezielt anpassen und verbessern.

Warum das wichtig ist

Ermöglicht den Leistungsvergleich verschiedener Kundensegmente und hilft, den Onboarding-Prozess für jeden Kundentyp gezielt anzupassen und zu verbessern.

Woher beziehen

Dieses grundlegende Attribut ist im Quellsystem im Kunden- oder Antragsdatensatz gespeichert.

Beispiele
PrivatpersonUnternehmenGemeinnützige OrganisationTrust
Letzte Datenaktualisierung
LastDataUpdate
Timestamp, zu dem die Daten für dieses Ereignis zuletzt aktualisiert oder aus dem Quellsystem extrahiert wurden.
Beschreibung

Dieses Attribut gibt an, wie aktuell die Daten sind. 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 einzuschätzen.

So können Benutzer erkennen, ob sie mit nahezu aktuellen Daten oder mit einer Momentaufnahme aus einem bestimmten Zeitpunkt arbeiten. Das Attribut ist für die Data Governance wichtig und hilft, die Erwartungen der Benutzer an die Aktualität der bereitgestellten Erkenntnisse zu steuern.

Warum das wichtig ist

Gibt wichtigen Aufschluss über die Aktualität der Daten, damit Benutzer den Stand der Prozessanalyse richtig einschätzen können.

Woher beziehen

Dieser Timestamp wird während der Datenextraktion (ETL) erzeugt und hinzugefügt.

Beispiele
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Quellsystem
SourceSystem
Das System, aus dem die Ereignisdaten extrahiert wurden, hier Refinitiv World-Check.
Beschreibung

Dieses Attribut gibt an, woher die Prozessdaten stammen. Bei einer Extraktion aus nur einem System kann es einen konstanten Wert enthalten. Werden Daten aus mehreren Systemen, etwa einem CRM und World-Check, zusammengeführt, ist es entscheidend für eine umfassende Sicht auf den Prozess.

In der Analyse unterstützt dieses Attribut die Data Governance und die Fehlerbehebung und hilft, den Datenkontext zu verstehen. Aktivitäten aus einem zentralen Screening-System können beispielsweise andere Eigenschaften oder einen höheren Detaillierungsgrad aufweisen als Aktivitäten aus einem ergänzenden System. So bleibt die Datenherkunft nachvollziehbar und auditfähig.

Warum das wichtig ist

Gibt die Herkunft der Daten an. Das ist wichtig für die Data Governance und Validierung sowie beim Zusammenführen von Daten aus mehreren Quellen.

Woher beziehen

Dieser statische Wert wird häufig während der Datenextraktion, -transformation und -ladung (ETL) hinzugefügt, um den Datensatz zu kennzeichnen.

Beispiele
Refinitiv World-CheckWorldCheckOne
SLA verletzt
SlaBreached
Boolesches Kennzeichen dafür, ob der Onboarding-Fall nach dem SLA-Zieldatum abgeschlossen wurde.
Beschreibung

Dieses berechnete Kennzeichen zeigt an, ob ein Fall gegen seine Service-Level-Vereinbarung verstoßen hat. Dazu wird der Timestamp der letzten Abschlussaktivität, etwa „Antrag genehmigt“ oder „Antrag abgelehnt“, mit dem Feld „SlaTargetDate“ des Falls verglichen.

Das Kennzeichen bildet die Grundlage für das Dashboard „SLA-Einhaltung und SLA-Verstöße“ sowie die KPI „SLA-Einhaltungsquote“. Es vereinfacht die Analyse, da Benutzer alle Fälle mit SLA-Verstoß schnell filtern können. Durch die Analyse der Prozessmerkmale dieser Fälle können Unternehmen die Ursachen für Verzögerungen ermitteln und Verbesserungsmaßnahmen gezielt ausrichten.

Warum das wichtig ist

Misst direkt die Einhaltung von Service-Level-Vereinbarungen und erleichtert das Filtern sowie die Ursachenanalyse bei verspäteten Fällen.

Woher beziehen

Das Kennzeichen wird bei der Datentransformation berechnet, indem der Timestamp der letzten Aktivität eines Falls mit dem Feld SlaTargetDate verglichen wird.

Beispiele
truefalse
Treffer-ID
MatchId
Eindeutige Kennung eines möglichen Treffers, der beim World-Check-Screening gefunden wurde.
Beschreibung

Wenn der automatisierte Screening-Prozess einen möglichen Treffer in Sanktionslisten, PEP-Listen oder negativen Medienberichten findet, wird häufig eine Match-ID vergeben, um den konkreten Befund nachzuverfolgen. Diese ID verknüpft den Antragsfall mit dem Datensatz in der World-Check-Datenbank, der den Alarm ausgelöst hat.

Dieses Attribut ist für detaillierte Compliance-Analysen hilfreich. Analysten können damit die Art der Treffer untersuchen, die Bearbeitung einzelner Alarme nachverfolgen, etwa um einen Fehlalarm oder einen tatsächlichen Treffer zu bestätigen, und feststellen, welche Alarmtypen am häufigsten auftreten oder am längsten bis zur Klärung benötigen. So lässt sich die Aktivität „Möglichen Treffer identifiziert“ genauer analysieren.

Warum das wichtig ist

Stellt eine genaue Verknüpfung zu den Screening-Ergebnissen her und ermöglicht eine detaillierte Analyse der Bearbeitungsdauer und der Alarmtypen.

Woher beziehen

Diese ID wird von der Screening-Engine von World-Check generiert und beim Antragsfall protokolliert, sobald ein möglicher Treffer gefunden wird.

Beispiele
WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
Erforderlich Empfohlen Optional

Aktivitäten beim KYC-Kunden-Onboarding

Diese wichtigen Prozessschritte und Meilensteine sollten Sie für eine präzise Prozesserkennung in Ihrem Event Log erfassen.
8 Empfohlen 6 Optional
Aktivität Beschreibung
Analystenprüfung begonnen
Ein Compliance-Analyst beginnt mit der manuellen Untersuchung möglicher Treffer zu einem Kundenantrag. Dazu vergleicht er die Angaben zu den möglichen Treffern mit den Kundeninformationen, um ihre Relevanz zu beurteilen.
Warum das wichtig ist

Damit beginnt die manuelle Compliance-Prüfung, die häufig einen Engpass darstellt. Die Zeit zwischen „Möglicher Treffer identifiziert“ und dieser Aktivität macht Wartezeiten in der Warteschlange sichtbar. Die Dauer der Prüfung gibt Aufschluss über die Effizienz der Analysten.

Woher beziehen

Lässt sich daran erkennen, dass ein Analyst einen Fall aus der Prüfwarteschlange übernimmt oder öffnet. Bei einer Statusänderung zu „In Prüfung“ oder der Zuweisung an einen bestimmten Benutzer kann das System dieses Ereignis auch ausdrücklich im Audit-Trail protokollieren.

Erfassung

Wird aus einer Änderung des Fallstatus zu „In Prüfung“ oder der Zuweisung des Falls an einen Analysten abgeleitet.

Ereignistyp inferred
Antrag abgelehnt
Der Kundenantrag wird offiziell abgelehnt, häufig aufgrund eines Treffers in World-Check oder anderer Risikofaktoren. Dieses Ereignis ist das endgültige negative Ergebnis des Onboarding-Prozesses.
Warum das wichtig ist

Dies ist der wichtigste Endpunkt eines nicht erfolgreichen Prozessverlaufs. 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 vermeiden.

Woher beziehen

Diese endgültige Geschäftsentscheidung wird im vorgelagerten CRM- oder Kernantragssystem erfasst, nicht in World-Check selbst. Die Daten müssen aus diesem System stammen.

Erfassung

Ereignis, das im Quellanwendungssystem protokolliert wird, häufig mit einem zugehörigen Ablehnungsgrundcode.

Ereignistyp explicit
Antrag eingereicht
Diese Aktivität markiert den Beginn des KYC-Onboarding-Prozesses, wenn ein Kunde seinen Antrag einreicht. Das Event wird üblicherweise in einem CRM- oder Kernantragssystem erfasst, das anschließend die Prüfung in Refinitiv World-Check auslöst.
Warum das wichtig ist

Dies ist das Start-Event für den gesamten Kunden-Onboarding-Prozess. Wenn Sie die Zeit von diesem Zeitpunkt bis zum Abschluss analysieren, erhalten Sie die gesamte Onboarding-Durchlaufzeit. Sie ist entscheidend, um die Customer Experience und die Einhaltung von SLAs zu messen.

Woher beziehen

Dieses Event stammt nicht direkt aus World-Check. Es muss aus einem vorgelagerten System wie einem CRM oder einer Plattform für die Verwaltung von Kundenkonten übernommen und anhand der Kundenantrags-ID zugeordnet werden.

Erfassung

Event, das bei der ersten Einreichung im Quellsystem des Antrags erfasst wird.

Ereignistyp explicit
Konto aktiviert
Das Kundenkonto wird im Kernsystem angelegt und aktiviert. Damit ist der Onboarding-Prozess abgeschlossen. Dies geschieht nach der endgültigen Genehmigung des Antrags und macht das Konto nutzbar.
Warum das wichtig ist

Dies ist der letzte Schritt im Prozess, der einen konkreten Nutzen schafft. Die Dauer von der Antragseinreichung bis zur Kontoaktivierung ist eine wichtige Kennzahl für die betriebliche Effizienz und die Kundenzufriedenheit.

Woher beziehen

Dieses Ereignis wird nicht in World-Check erfasst. Es wird im Kernbank- oder Kundenkontosystem protokolliert und muss über die Customer Application ID zugeordnet werden.

Erfassung

Ereignis, das nach der Kontoaktivierung im Kernkontosystem protokolliert wird.

Ereignistyp explicit
Prüfanfrage erstellt
Im Refinitiv-World-Check-System wird ein neuer Prüfungsfall für einen Kundenantrag angelegt. Ausgelöst wird dies durch einen API-Aufruf oder eine manuelle Eingabe aus einem vorgelagerten System. Damit beginnt die Prüfung von Risikoinformationen.
Warum das wichtig ist

Damit beginnt der Screening-Teilprozess offiziell. Die Zeit zwischen „Antrag eingereicht“ und dieser Aktivität zeigt Verzögerungen bei der Übergabe zwischen dem Fachsystem und der Compliance-Funktion.

Woher beziehen

Der Eintrag stammt aus den Fallmanagementprotokollen oder dem Audit-Trail von World-Check. Verwendet werden das Erstellungsereignis und sein Timestamp für die jeweilige Fall- oder Entitäts-ID.

Erfassung

Wird automatisch protokolliert, wenn ein neuer Screening-Fall im System angelegt wird.

Ereignistyp explicit
Screening abgeschlossen: Treffer gefunden
Der Screening-Fall wird offiziell mit dem Ergebnis „Treffer gefunden“ geschlossen. Damit wurde ein bestätigtes Risiko festgestellt. Diese Entscheidung löst einen anderen Folgeprozess aus, etwa eine verstärkte Sorgfaltsprüfung oder eine Ablehnung.
Warum das wichtig ist

Dies ist der wichtigste Endpunkt des abweichenden Prozesspfads beim Screening. Die Analyse dieser Fälle gibt Aufschluss über Risikoprofile und die Wirksamkeit der Screening-Kontrollen.

Woher beziehen

Lässt sich an einer Änderung des abschließenden Fallstatus zu „Treffer gefunden“, „Risiko identifiziert“ oder „Geschlossen: positiver Treffer“ erkennen. Verwendet wird der Timestamp dieser letzten Statusänderung.

Erfassung

Wird anhand des Timestamps des abschließenden Fallstatus abgeleitet, der einen bestätigten Treffer anzeigt.

Ereignistyp inferred
Screening abgeschlossen: unauffällig
Der Screening-Fall wird offiziell mit dem Ergebnis „Unauffällig“ geschlossen. Es wurden keine tatsächlichen Treffer gefunden. Diese Entscheidung wird an das Ursprungssystem übermittelt, sodass der Onboarding-Prozess fortgesetzt werden kann.
Warum das wichtig ist

Diese Aktivität markiert den erfolgreichen Abschluss des üblichen Prozesspfads beim Screening. Sie ist ein wichtiger Endpunkt, um die Zykluszeit bei standardmäßigen Anträgen mit geringem Risiko zu messen.

Woher beziehen

Lässt sich an einer Änderung des abschließenden Fallstatus zu „Unauffällig“, „Abgeschlossen“ oder „Geschlossen: kein Treffer“ erkennen. Verwendet wird der Timestamp dieser letzten Statusänderung.

Erfassung

Wird anhand des Timestamps des abschließenden Fallstatus abgeleitet, der ein unauffälliges Ergebnis anzeigt.

Ereignistyp inferred
Treffer bestätigt
Ein Analyst bestätigt, dass der mögliche Treffer tatsächlich mit dem überprüften Kunden übereinstimmt und ein potenzielles Risiko darstellt. Dieser wichtige Meilenstein löst üblicherweise eine verstärkte Sorgfaltsprüfung oder die Ablehnung des Antrags aus.
Warum das wichtig ist

Dies ist ein wichtiges Ergebnis der Risikominderung und ein entscheidender Moment im Prozess. Es wirkt sich direkt auf die endgültige Entscheidung zum Kundenantrag aus und ist für Compliance-Berichte und -Analysen von zentraler Bedeutung.

Woher beziehen

Dies ist eine ausdrückliche Benutzeraktion, bei der der Analyst einen bestimmten Treffer als „Echter Treffer“ oder „Bestätigter Treffer“ bewertet. Das Ereignis wird im Fall-Audit-Trail protokolliert.

Erfassung

Wird protokolliert, wenn ein Analyst einen Treffer im System offiziell bestätigt.

Ereignistyp explicit
Antrag genehmigt
Der Kundenantrag wurde nach einem erfolgreichen KYC-Screening und allen weiteren erforderlichen Prüfungen vollständig genehmigt. Dieses Ereignis tritt üblicherweise im Quellsystem ein, nachdem es von World-Check ein unauffälliges Ergebnis erhalten hat.
Warum das wichtig ist

Damit ist das Onboarding erfolgreich abgeschlossen. Die Zeit von der Einreichung bis zu diesem Punkt zeigt, wie lange es insgesamt dauert, bis ein neuer Kunde angenommen wird.

Woher beziehen

Dieses Ereignis ist nicht Bestandteil von World-Check. Es muss aus dem vorgelagerten CRM- oder Kernantragssystem stammen, in dem die endgültige Geschäftsentscheidung getroffen wird.

Erfassung

Ereignis, das nach der endgültigen Genehmigung im Quellanwendungssystem protokolliert wird.

Ereignistyp explicit
Automatisiertes Screening durchgeführt
Das World-Check-System gleicht die Kundendaten automatisch mit seiner Risikodatenbank ab. Bei dieser systemgesteuerten Aktivität entsteht eine erste Ergebnisliste, etwa mit möglichen Treffern oder dem Status „Unauffällig“.
Warum das wichtig ist

Diese Aktivität ist der erste wertschöpfende Schritt im Screening-Prozess. Verzögerungen davor weisen auf Probleme mit der System- oder Datenbereitschaft hin. Das Ergebnis bestimmt den anschließenden manuellen Arbeitsaufwand.

Woher beziehen

Dieses Ereignis wird möglicherweise ausdrücklich im Fall-Audit-Trail protokolliert. Alternativ lässt es sich anhand des Timestamps ableiten, zu dem die ersten Screening-Ergebnisse für den Fall vorliegen.

Erfassung

Systemprotokolleintrag, der nach Abschluss des automatisierten Datenbankabgleichs erstellt wird.

Ereignistyp explicit
Fall zur Prüfung eskaliert
Ein Analyst der ersten Prüfungsstufe eskaliert einen komplexen Fall oder einen Fall mit hohem Risiko zur abschließenden Entscheidung an einen erfahrenen Analysten oder eine Führungskraft. Dies ist ein wichtiger Übergabepunkt innerhalb des Compliance-Teams.
Warum das wichtig ist

Eskalationen führen häufig zu Engpässen und verlängern die Zykluszeit. Eine Analyse ihrer Häufigkeit und Gründe kann auf Schulungsbedarf bei weniger erfahrenen Analysten oder auf unklare Prüfungsrichtlinien hinweisen.

Woher beziehen

Wird als ausdrückliche Aktion im Fall-Workflow oder Audit-Trail erfasst. Das Ereignis lässt sich auch an einer Änderung des zugewiesenen Benutzers erkennen, insbesondere wenn der neue Benutzer über weitergehende Berechtigungen verfügt.

Erfassung

Wird über eine eigene Schaltfläche „Eskalieren“ oder eine Workflow-Aktion im Fall protokolliert.

Ereignistyp explicit
Falscher Treffer bestätigt
Der Analyst kommt zu dem Schluss, dass der mögliche Treffer nicht mit dem überprüften Kunden übereinstimmt. Der Treffer wird verworfen und das Screening für diese Meldung abgeschlossen.
Warum das wichtig ist

Dies ist ein häufiges Ergebnis der Prüfung. Die Dauer bis zur abschließenden Bewertung falscher Treffer gibt Aufschluss über die Effizienz der Analysten und die Genauigkeit der automatisierten Screening-Logik.

Woher beziehen

Dies ist eine ausdrückliche Benutzeraktion, bei der der Analyst einen bestimmten Treffer als „Falscher Treffer“ oder „Keine Übereinstimmung“ bewertet. Die Aktion wird üblicherweise im Fallverlauf protokolliert.

Erfassung

Wird protokolliert, wenn ein Analyst einen möglichen Treffer im System offiziell verwirft.

Ereignistyp explicit
Möglicher Treffer identifiziert
Beim automatisierten Screening wurde mindestens ein möglicher Treffer gefunden, den ein Analyst manuell prüfen muss. Mit diesem Ereignis wechselt der Fall vom automatisierten Status in die Warteschlange für manuelle Untersuchungen.
Warum das wichtig ist

Diese Aktivität ist ein entscheidender Verzweigungspunkt im Prozess. Fälle mit möglichen Treffern durchlaufen einen längeren und komplexeren Prozesspfad. Ihre Erfassung unterstützt die Ressourcenplanung und die Engpassanalyse im Prüfungsteam.

Woher beziehen

Lässt sich aus einer Änderung des Fallstatus in „Prüfung erforderlich“, „Möglicher Treffer“ oder einen ähnlichen Status im Fallmanagementmodul von World-Check ableiten.

Erfassung

Wird aus einer Änderung des Fallstatus abgeleitet, die anzeigt, dass nun eine manuelle Prüfung erforderlich ist.

Ereignistyp inferred
Zusätzliche Informationen angefordert
Der Analyst stellt fest, dass weitere Informationen benötigt werden, um den möglichen Treffer zu beurteilen, und fordert sie bei der Geschäftseinheit an. Bis die Informationen vorliegen, bleibt der Fall offen und wartet auf Rückmeldung.
Warum das wichtig ist

Häufige Wiederholungen dieser Aktivität weisen auf Qualitätsprobleme bei den ursprünglich für das Screening bereitgestellten Daten hin. Da die Aktivität von externen Teams abhängt, verursacht sie erhebliche Verzögerungen und trägt wesentlich zu langen Zykluszeiten bei.

Woher beziehen

Dabei kann es sich um eine ausdrückliche Benutzeraktion handeln, die in den Fallnotizen oder im Audit-Protokoll erfasst wird. Alternativ lässt sich das Ereignis aus einer Änderung des Fallstatus zu „Informationen ausstehend“ oder „RFI“ ableiten.

Erfassung

Wird protokolliert, wenn ein Analyst eine Funktion verwendet, um den Fall als informationsbedürftig zu kennzeichnen.

Ereignistyp explicit
Empfohlen Optional

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Refinitiv World-Check

Möchten Sie loslegen?

Verwenden Sie dieses Daten-Template als Ausgangspunkt für Ihr Process-Mining-Projekt zum KYC-Kunden-Onboarding. Mit diesen Empfehlungen gewinnen Sie wertvolle Erkenntnisse und können Ihre Abläufe gezielt verbessern.

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

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

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Testen Sie den Dienst 14 Tage kostenlos.