Ihr Daten-Template für das KYC-Kunden-Onboarding
Ihr Daten-Template für das KYC-Kunden-Onboarding
- Empfohlene Attribute für die Erfassung
- Wichtige Aktivitäten zur Nachverfolgung
- Hinweise zur Datenextraktion
Attribute für das KYC-Kunden-Onboarding
| 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
|
|||
Aktivitäten beim KYC-Kunden-Onboarding
| 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
|
|||
Anleitungen zur Datenextraktion
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.
Keine Kreditkarte erforderlich. Testen Sie den Dienst 14 Tage kostenlos.