Ihr KYC-Kunden-Onboarding Daten-Template
Ihr KYC-Kunden-Onboarding Daten-Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Extraktionsanleitung
KYC-Kunden-Onboarding-Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivitätsname
ActivityName
|
Der Name eines spezifischen Geschäftsereignisses oder einer Aufgabe, die innerhalb des KYC-Onboarding-Prozesses aufgetreten ist. | ||
|
Beschreibung
Der Activity Name beschreibt einen einzelnen Schritt oder ein Event in der Kunden-Onboarding-Journey, wie zum Beispiel 'Antrag eingereicht', 'Analystenprüfung gestartet' oder 'Screening abgeschlossen - Freigegeben'. Diese Aktivitäten bilden die Knotenpunkte der Prozesslandkarte und bieten eine detaillierte Aufschlüsselung des End-to-End-Workflows.\n\nDie Analyse von Aktivitäten ist der Kern von Process Mining. Durch die Verfolgung der Abfolge und Häufigkeit verschiedener Aktivitäten können Analysten den tatsächlichen Prozessfluss entdecken, gängige Pfade identifizieren, Abweichungen vom Standardverfahren erkennen und spezifische Schritte lokalisieren, die Verzögerungen oder Nacharbeit verursachen. Dieses Attribut ist entscheidend für die Erstellung von Prozesslandkarten und die Berechnung von Aktivitätsmetriken.
Bedeutung
Dieses Attribut definiert die einzelnen Schritte des Prozesses, was entscheidend für die Entdeckung und Visualisierung des Prozessflusses und die Identifizierung von Engpässen ist.
Datenquelle
Diese Information findet sich typischerweise in Event Logs oder Audit Trail Tabellen, oft verbunden mit Statusänderungen in der Case Management Entity.
Beispiele
Potenzieller Treffer identifiziertAnalyseprüfung gestartetFalse Positive ConfirmedApplication Approved
|
|||
|
Ereigniszeit
EventTime
|
Der Zeitstempel, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat. | ||
|
Beschreibung
Event Time liefert das genaue Datum und die Uhrzeit, zu der eine Aktivität erfasst wurde. Dieser Timestamp ist das chronologische Rückgrat des Prozesses und ermöglicht die korrekte Sortierung von Ereignissen, um den Fallverlauf zu rekonstruieren. Dieses Attribut ist entscheidend für alle zeitbasierten Analysen im Process Mining. Es wird verwendet, um Dauern zwischen Aktivitäten (Zykluszeiten und Wartezeiten) zu berechnen, die gesamte Falldauer zu messen, die Prozessleistung über die Zeit zu analysieren und die Einhaltung von Service Level Agreements (SLAs) zu überprüfen. Ohne genaue Timestamps ist es unmöglich, die Prozessleistung zu verstehen und temporale Engpässe zu identifizieren.
Bedeutung
Der Timestamp für jede Aktivität ist essenziell für die Berechnung aller dauerbasierten Metriken, die Entdeckung der Prozesssequenz und die Durchführung der Engpassanalyse.
Datenquelle
Dies ist ein Standardfeld in jedem Event Log oder jeder Audit Trail Tabelle, oft benannt als 'Timestamp', 'EventDate' oder 'CreationDate'.
Beispiele
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
|
|||
|
Kundenantrag
CustomerApplication
|
Der eindeutige Identifikator für den Onboarding-Antrag eines einzelnen Kunden, der als primärer Fall-Identifikator dient. | ||
|
Beschreibung
Die Customer Application ist der zentrale Case-Identifikator, der alle Events und Aktivitäten einer einzelnen Kunden-Onboarding-Journey gruppiert. Sie ermöglicht die vollständige, chronologische Verfolgung des Fortschritts jedes Kunden durch den gesamten Know Your Customer (KYC)-Prozess, von der Ersteinreichung bis zur endgültigen Entscheidung.\n\nIn der Process Mining Analyse ist dieses Attribut fundamental für die Rekonstruktion der End-to-End-Journey jedes Antrags. Es ermöglicht die Visualisierung von Prozessabläufen, die Berechnung von Gesamt-Cycle Times und die Identifizierung von Varianten. Durch die Analyse von Fällen, die nach diesem Identifikator gruppiert sind, können Organisationen verschiedene Wege verstehen, die ein Antrag nehmen kann, Engpässe identifizieren und die Effizienz verschiedener Onboarding-Prozesse vergleichen.
Bedeutung
Dies ist der essentielle Case-Identifikator, der alle related Activities verbindet, making it possible, den End-to-End Customer Onboarding Process zu analysieren.
Datenquelle
Dieser Identifikator ist typischerweise der Primary Key in der Main Application oder Case Management Table innerhalb 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 spezifiziert die Business Unit oder das Team, wie z.B. 'Onboarding', 'Compliance' oder 'Quality Assurance', zu dem der User gehört. Es erlaubt eine Analyse auf einer höheren organisationalen Ebene als der individuelle User.\n\nAnalyzing by Department ist kritisch für die Identifizierung von inter-departmentalen Bottlenecks und die Messung von Handoff Times. Es hilft zu visualisieren, wie Workflows zwischen verschiedenen Teams fließen und wo Delays in diesen Transitions auftreten. This View ist invaluable für das Streamlining von Cross-functional Collaboration und die Verbesserung der Overall Process Efficiency.
Bedeutung
Ermöglicht die Analyse der Prozessleistung nach Abteilung und ist wesentlich für die Identifizierung von Verzögerungen bei Übergaben zwischen verschiedenen Teams.
Datenquelle
Diese Information kann im User-Profil im System oder einem zugehörigen HR-System gespeichert sein. Sie müsste gegebenenfalls mit den Event-Daten unter Verwendung der User ID verknüpft werden.
Beispiele
Onboarding-TeamCompliance ReviewGeschäftsleitung
|
|||
|
Endzeit des Events
EventEndTime
|
Der Zeitstempel, der angibt, wann eine bestimmte Aktivität oder ein Ereignis abgeschlossen wurde. | ||
|
Beschreibung
Die Event End Time markiert den Abschluss einer Aktivität. Während viele Events als augenblicklich modelliert werden können (wo StartTime gleich EndTime ist), haben einige Aktivitäten eine messbare Dauer, wie 'Analystenprüfung gestartet' und 'Analystenprüfung abgeschlossen'. Das Vorhandensein von Start- und Endzeiten ermöglicht eine präzise Messung der Bearbeitungszeit.\n\nIn der Prozessanalyse ist eine Endzeit entscheidend für die Berechnung der exakten Processing Time einer Aktivität, im Gegensatz zur Cycle Time, die Wartezeiten einschließt. Dies hilft, zwischen der Zeit, in der ein Case aktiv bearbeitet wird, und der Zeit, in der er untätig in einer Queue liegt, zu unterscheiden. Dies ist entscheidend für die Ressourcenoptimierung und Effizienzanalyse.
Bedeutung
Ermöglicht die präzise Berechnung der Aktivitätsbearbeitungszeit, trennt aktive Arbeitszeit von ungenutzter Wartezeit für eine genauere Leistungsanalyse.
Datenquelle
Für Aktivitäten mit einer Dauer kann dies 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
|
Der Identifikator des Benutzers, Analysten oder automatisierten Agenten, der die Aktivität durchgeführt hat. | ||
|
Beschreibung
Die Reviewer ID, oder der User, gibt an, wer eine bestimmte Task im KYC-Prozess ausgeführt hat. Dies könnte ein Compliance-Analyst, ein Onboarding-Spezialist oder ein System-Account für automatisierte Aktivitäten sein. Die Verfolgung dieser Informationen bietet Visibility in die Workload-Verteilung und die individuelle Performance.\n\nDieses Attribut ist essenziell für die ressourcenbasierte Analyse. Es hilft, Performance-Unterschiede zwischen Usern oder Teams zu verstehen, Training Needs zu identifizieren und Workload Balancing zu optimieren. Es ist auch eine Key Component für die Analyse von Handoffs, Social Networks und Compliance-Ressourcennutzung.
Bedeutung
Ermöglicht die Analyse der Arbeitslastverteilung, der Benutzerleistung und der Abteilungsübergaben, was für die Ressourcenoptimierung entscheidend ist.
Datenquelle
Typischerweise in Event Logs oder Audit Trails zu finden, oft benannt als 'UserID', 'PerformedBy' oder 'Owner'.
Beispiele
analyst_jdoesystem_auto_screenermanager_bsmith
|
|||
|
Risikostufe
RiskLevel
|
Die berechnete Risikoklassifikation des Kundenantrags, z.B. Niedrig, Mittel oder Hoch. | ||
|
Beschreibung
Die Risikostufe ist eine kritische Information in KYC-Prozessen, die das erforderliche Maß an Due Diligence bestimmt. Sie wird oft basierend auf Faktoren wie Kundentyp, Geografie und der Art des Geschäfts festgelegt. Diese Klassifikation kann den Prozesspfad, den ein Antrag nimmt, erheblich beeinflussen.\n\nIn der Prozessanalyse ist die Segmentierung von Cases nach Risk Level unerlässlich. Sie hilft, Variationen in Cycle Times und Prozessabläufen zu erklären; zum Beispiel können Hochrisiko-Anträge mehr Schritte erfordern und länger dauern. Dieses Attribut ist entscheidend für die 'Application Rejection Rate and Reasons' und 'Background Check Initiation Cycle Time' Dashboards, um zu verstehen, wie Risiko Outcomes und Effizienz beeinflusst.
Bedeutung
Die Segmentierung des Prozesses nach Risikostufe ist entscheidend, um zu verstehen, warum bestimmte Fälle länger dauern oder unterschiedliche Pfade verfolgen, sowie zur Analyse der Ablehnungsraten.
Datenquelle
Dies ist ein Core Data Point im Customer Application oder Case Record. Konsultieren 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
Die SLA Target Date ist die Frist für die Fertigstellung des gesamten Onboarding-Cases, wie durch die Service Level Agreement mit dem Kunden oder interne Policies definiert. Dieses Datum ist der Benchmark, an dem die tatsächlichen Completion Times gemessen werden.\n\nDieses Attribut ist fundamental für das 'SLA Adherence and Breach Analysis' Dashboard. Es wird verwendet, um zu berechnen, ob ein Case pünktlich abgeschlossen wurde oder nicht. Die Analyse von SLA Breaches hilft, systemische Issues im Prozess zu identifizieren, die Delays verursachen, und ermöglicht es der Organisation, Corrective Action zu ergreifen, um die Timeliness zu verbessern und Compliance Requirements zu erfüllen.
Bedeutung
Dies ist der Benchmark für die Messung der On-Time Performance und ist Critical für die Berechnung der SLA Adherence Rate und das Analyzing von Breaches.
Datenquelle
Dieses Datum wird oft basierend auf dem Antragsdatum und den Geschäftsregeln berechnet. Es kann als Feld im Case Record gespeichert werden.
Beispiele
2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
|
|||
|
Ablehnungsgrund
RejectionReason
|
Der spezifische Grund, der angegeben wird, wenn ein Kundenantrag abgelehnt wird. | ||
|
Beschreibung
Wird ein Antrag abgelehnt, erfasst der Ablehnungsgrund, warum diese Entscheidung getroffen wurde. Gründe könnten 'Sanktions-Treffer', 'Unvollständige Dokumentation' oder 'Hohes Risikoprofil' sein. Dies liefert wertvolles, strukturiertes Feedback zur Qualität eingehender Anträge und zur Effektivität des Screening-Prozesses. Dieses Attribut ist der primäre Treiber für das Dashboard 'Ablehnungsrate und -gründe von Anträgen'. Die Analyse dieser Gründe hilft, die Ursachen für Ablehnungen zu identifizieren, was zu Prozessverbesserungen, einer klareren Kommunikation mit den Antragstellern und potenziell einer Reduzierung unnötiger Ablehnungen führen kann. Es bietet einen qualitativen Kontext zur quantitativen KPI der Ablehnungsrate.
Bedeutung
Liefert die Ursache für Antragsablehnungen, was unerlässlich ist, um Verbesserungsbereiche im Onboarding-Prozess zu identifizieren und die Ablehnungsrate zu reduzieren.
Datenquelle
Dies würde recorded werden, wenn das 'Application Rejected' Event occurs, likely als ein Field auf dem Case oder Application Record.
Beispiele
PEP-TrefferTreffer auf SanktionslisteFailed Document VerificationAdverse Media
|
|||
|
Aktivitätsbearbeitungszeit
ActivityProcessingTime
|
Die Dauer der aktiven Bearbeitung einer Aktivität. | ||
|
Beschreibung
Diese Metrik berechnet die Actual Time, die eine Activity took to Complete, von ihrem Start zu ihrem End. Sie wird calculated als die Difference zwischen EventEndTime und EventTime. This measures the 'Touch Time' oder Active Work Time für eine Task.\n\nDieses calculated Attribute ist essential für Performance Analysis und wird in vielen KPIs verwendet, including 'Avg Doc Review Cycle Time' und 'Avg Compliance Review Cycle Time'. Es hilft, zu distinguish zwischen der Time eine Task is being actively processed versus der Time sie ist Waiting in einer Queue. This ist Fundamental für Identifying True Processing Inefficiencies und für Capacity Planning.
Bedeutung
Misst die aktive Bearbeitungszeit für eine Aktivität und hilft dabei, genau festzustellen, welche spezifischen Aufgaben am längsten dauern, getrennt von Wartezeiten.
Datenquelle
Dies wird während der Data Transformation berechnet, indem der Start Timestamp vom End Timestamp einer Activity subtrahiert wird (z.B. EndTime - StartTime).
Beispiele
PT1H30MP2DT4H15MPT25M
|
|||
|
Antragskanal
ApplicationChannel
|
Der Kanal, über den der Kundenantrag eingereicht wurde, z.B. Online-Portal, Filiale oder Mobile App. | ||
|
Beschreibung
Der Application Channel gibt die Einreichungsquelle des Kundenantrags an. Verschiedene Kanäle können unterschiedliche Niveaus an Datenvollständigkeit, -qualität und Kundendemografie aufweisen, was den nachgelagerten Prozess beeinflussen kann.\n\nDieses Attribut ist entscheidend für das 'Application Throughput by Channel' Dashboard. Durch die Analyse von Volumen, Cycle Time und Outcomes von Anträgen aus verschiedenen Kanälen kann eine Organisation identifizieren, welche Kanäle am effizientesten sind und welche Prozessverbesserungen erfordern könnten. Diese Analyse unterstützt strategische Entscheidungen über Ressourcenzuweisung und Kanalinvestitionen.
Bedeutung
Analysiert die Leistung und Effizienz verschiedener Einreichungskanäle, um strategische Entscheidungen bezüglich Technologie und Kundenerfahrung zu fundieren.
Datenquelle
Diese Information wird typischerweise am Anfang des Prozesses erfasst und als Attribut im Application Record gespeichert.
Beispiele
Online-PortalMobile AppFilialeRelationship Manager
|
|||
|
Ist automatisiert
IsAutomated
|
Ein Flag, das anzeigt, ob die Aktivität von einem System (wahr) oder einem Menschen (falsch) durchgeführt wurde. | ||
|
Beschreibung
Dieses boolesche Attribut unterscheidet zwischen automatisierten System Tasks und manuellen Aktivitäten, die von Usern durchgeführt werden. Zum Beispiel würde 'Automated Screening Performed' als automatisiert markiert, während 'Analyst Review Started' manuell wäre.\n\nDiese Distinction ist crucial für Automation Analysis. Es hilft, den Impact von Automation auf Process Efficiency zu messen, zu identifizieren, welche Manual Tasks Candidates für zukünftige Automation sind, und die Interaction zwischen Human und System Actors zu verstehen. Es ermöglicht eine klare Separation von System Processing Time von Manual Handling Time.
Bedeutung
Differenziert zwischen System- und menschlichen Aktivitäten, was entscheidend ist, um den Einfluss von Automatisierung zu messen und neue Automatisierungsmöglichkeiten zu identifizieren.
Datenquelle
Dies wird typischerweise basierend auf dem Activity Name oder der mit dem Event verbundenen User ID abgeleitet (z.B. wenn der User ein 'System' Account ist).
Beispiele
truefalsch
|
|||
|
Ist Nacharbeit
IsRework
|
Ein Flag, das anzeigt, ob eine Aktivität zum zweiten oder einem späteren Mal innerhalb desselben Falles durchgeführt wird. | ||
|
Beschreibung
IsRework ist ein berechnetes boolesches Attribut, das identifiziert, wann eine Aktivität innerhalb desselben Kundenantragsfalls wiederholt wird. Zum Beispiel, wenn 'Risikobewertung durchgeführt' mehr als einmal für einen einzelnen Antrag stattfindet, werden die nachfolgenden Vorkommen als Nacharbeit markiert.\n\nDieses Attribut ist entscheidend, um Prozessineffizienzen, Schleifen und unnötige Wiederholungen zu identifizieren. Es unterstützt direkt das 'Risk Assessment Rework and Efficiency' Dashboard und den 'Risk Assessment Rework Rate' KPI. Die Analyse von Nacharbeit hilft, Probleme mit Qualität, Informationsklarheit oder Entscheidungsfindung aufzudecken, die zu verschwendeter Mühe und längeren Durchlaufzeiten führen.
Bedeutung
Deckt Prozessineffizienzen durch Kennzeichnung wiederholter Aktivitäten auf und ermöglicht die Analyse von Nacharbeitszyklen zur Qualitätsverbesserung und Reduzierung von Durchlaufzeiten.
Datenquelle
Dies wird während der Data Transformation berechnet, indem die Sequence der Activities innerhalb jedes Case analysiert und nicht-erstmalige Occurrences einer Activity gekennzeichnet werden.
Beispiele
truefalsch
|
|||
|
Kunden-ID
CustomerId
|
Ein eindeutiger Identifikator für die zu onboardende Kundeneinheit. | ||
|
Beschreibung
Die Customer ID ist der eindeutige Identifikator für das Kundenprofil. 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 Master-Kundendatensatz.\n\nIn der Analyse ermöglicht die Customer ID die Verfolgung wiederholter Anträge desselben Kunden und kann verwendet werden, um die Prozessdaten mit anderen Kundenattributen aus einem CRM- oder Master Data System anzureichern. Dies ermöglicht eine ganzheitlichere Sicht auf die Customer Journey jenseits einer einzelnen Onboarding-Instanz.
Bedeutung
Verknüpft den Onboarding-Fall mit einem spezifischen Kunden, was die Analyse wiederholter Anträge und die Anreicherung mit Stammdaten des Kunden ermöglicht.
Datenquelle
Dies wäre ein Key Field im Application oder Case Record, linking it zu den Customer Master Data.
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 signifikanter Faktor bei der Risikobewertung und den regulatorischen Anforderungen für KYC-Prozesse. Verschiedene Jurisdiktionen haben unterschiedliche Regeln, die den Prozessfluss und die Duration beeinflussen können.\n\nDie Analyse des Prozesses nach Land ermöglicht es Organisationen, die Performance über verschiedene Regionen hinweg zu vergleichen, Standort-spezifische Bottlenecks zu identifizieren und Compliance mit lokalen Regulations sicherzustellen. Es bietet eine geografische Dimension für die Prozessanalyse, die wichtige Operational Differences aufzeigen kann.
Bedeutung
Ermöglicht eine geografische Analyse des Prozesses und hilft, regionale Unterschiede in Leistung, Risiko und Compliance-Anforderungen zu identifizieren.
Datenquelle
Dies ist ein Standardfeld im Kundenprofil oder Antragsformular.
Beispiele
USAGBRSGPDEU
|
|||
|
Kundentyp
CustomerType
|
Die Klassifikation des Kunden, z.B. Privatperson, Unternehmen oder Stiftung. | ||
|
Beschreibung
„Kundentyp“ kategorisiert die zu onboardende Einheit. Verschiedene Kundentypen haben oft unterschiedliche Onboarding-Anforderungen, Risikoprofile und regulatorische Verpflichtungen. Zum Beispiel ist das Onboarding einer Corporation typischerweise komplexer als das einer Einzelperson. Dieses Attribut wird für die Segmentierungsanalyse verwendet, insbesondere für das Dashboard „KYC Kundentyp-Performance“. Es ermöglicht den Vergleich der Prozesseffizienz, Durchlaufzeiten und Ablehnungsraten über verschiedene Kundensegmente hinweg. Dies hilft Organisationen, das Onboarding-Erlebnis für spezifische Kundentypen anzupassen und zu optimieren.
Bedeutung
Ermöglicht den Leistungsvergleich zwischen verschiedenen Kundensegmenten und hilft, den Onboarding-Prozess für jeden Typ anzupassen und zu optimieren.
Datenquelle
Dies ist ein fundamentales Attribut, das im Kunden- oder Application Record innerhalb des Source Systems gespeichert ist.
Beispiele
PrivatpersonCorporationGemeinnützige OrganisationVertrauen
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, wann die Daten für dieses Event zuletzt aktualisiert oder aus dem Quellsystem extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut gibt die Freshness der Daten an. Es erfasst Date und Time des letzten Data Pull von Refinitiv World-Check. Dies ist wichtig, um die Timeliness der Process Mining Dashboards und Analysen zu verstehen.\n\nFür analytische Zwecke ermöglicht dies Usern zu wissen, ob sie Near Real-Time Data oder einen Snapshot von einem spezifischen Point in Time betrachten. Es ist essenziell für Data Governance und für das Management von User Expectations über die Currency der Erkenntnisse provided.
Bedeutung
Bietet entscheidenden Kontext zur Datenaktualität und stellt sicher, dass Nutzer verstehen, wie aktuell die Prozessanalyse ist.
Datenquelle
Dieser Timestamp wird während des Data Extraction (ETL) Process generiert und hinzugefügt.
Beispiele
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Event-Daten extrahiert wurden, in diesem Fall Refinitiv World-Check. | ||
|
Beschreibung
Dieses Attribut identifiziert die Herkunft der Prozessdaten. Während es bei einer Single-Source-Extraktion ein konstanter Wert sein kann, wird es entscheidend, wenn Daten aus mehreren Systemen (wie einem CRM und World-Check) kombiniert werden, um eine holistische Prozessansicht zu erstellen.\n\nIn der Analyse hilft dies bei der Data Governance, dem Troubleshooting und dem Verständnis des Datenkontexts. Zum Beispiel können Aktivitäten, die in einem Core Screening System protokolliert werden, andere Properties oder Levels of Detail aufweisen als die aus einem Peripheral System. Es stellt sicher, dass die Data Lineage klar und auditable ist.
Bedeutung
Identifiziert die Herkunft der Daten, was entscheidend für Daten-Governance, Validierung und die Zusammenführung von Daten aus mehreren Quellen ist.
Datenquelle
Dies ist oft ein statischer Wert, der während des Data Extraction, Transformation, and Loading (ETL) Process hinzugefügt wird, um den Dataset zu labeln.
Beispiele
Refinitiv World-CheckWorldCheckOne
|
|||
|
SLA verletzt
SlaBreached
|
Ein Boolesches Flag, das anzeigt, ob der Onboarding-Fall nach seinem SLA-Zieldatum abgeschlossen wurde. | ||
|
Beschreibung
Dieses Attribut ist ein berechnetes Flag, das anzeigt, ob ein Case seine Service Level Agreement verletzt hat. Es wird durch den Vergleich des Timestamps der finalen Completion Activity (z.B. 'Antrag genehmigt' oder 'Antrag abgelehnt') mit der 'SlaTargetDate' für den Case bestimmt.\n\nDieses Flag ist die Basis für das 'SLA Adherence and Breach Analysis' Dashboard und den 'SLA Adherence Rate' KPI. Es vereinfacht Analysis, indem es Usern ermöglicht, schnell für alle breached Cases zu filtern. Durch die Analyse der Prozesscharakteristika von breached Cases können Organisationen die Root Causes von Delays identifizieren und Improvement Efforts effektiv fokussieren.
Bedeutung
Misst direkt die Einhaltung von Service Level Agreements und ermöglicht eine einfache Filterung und Ursachenanalyse verzögerter Fälle.
Datenquelle
Dies wird während der Data Transformation berechnet, indem der Final Activity Timestamp für einen Case mit dem SlaTargetDate Field verglichen wird.
Beispiele
truefalsch
|
|||
|
Treffer-ID
MatchId
|
Der eindeutige Identifikator für einen potenziellen Treffer, der während eines World-Check Screenings gefunden wurde. | ||
|
Beschreibung
Wenn der automatisierte Screening-Prozess eine potenzielle Übereinstimmung mit Sanktionslisten, PEP-Listen oder negativen Medienberichten findet, wird oft eine Match ID generiert, um diesen spezifischen Treffer zu verfolgen. Diese ID verknüpft den Antragsfall mit dem spezifischen Datensatz in der World-Check-Datenbank, der den Alert ausgelöst hat. Dieses Attribut ist nützlich für eine detaillierte Compliance-Analyse. Es ermöglicht Analysten, die Art der Übereinstimmungen zu untersuchen, die Lösung spezifischer Alerts zu verfolgen (z. B. die Bestätigung eines False Positive oder eines True Match) und zu verstehen, welche Arten von Alerts am häufigsten sind oder am längsten dauern. Es bietet eine tiefere Detailtiefe für die Aktivität 'Potenzieller Treffer identifiziert'.
Bedeutung
Bietet einen detaillierten Link zu den spezifischen Screening-Ergebnissen, der eine tiefere Analyse der Trefferauflösungszeiten und Alert-Typen ermöglicht.
Datenquelle
Diese ID würde von der World-Check Screening Engine generiert und dem Application Case zugeordnet, wenn ein Potential Match gefunden wird.
Beispiele
WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
|
|||
KYC-Kunden-Onboarding-Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Account Activated
|
Das Konto des Kunden wird im Kernsystem erstellt und aktiviert, wodurch die Onboarding-Journey abgeschlossen wird. Dies folgt der endgültigen Antragsgenehmigung und macht das Konto betriebsbereit. | ||
|
Bedeutung
Dies ist der finale, Value-delivering Step im Process. Die Duration von Application Submission zu Account Activation ist eine Key Metric für Operational Efficiency und Customer Satisfaction.
Datenquelle
Dieses Event wird nicht in World-Check erfasst. Es wird im Kernbanken- oder Kundenkontensystem aufgezeichnet und muss über die Customer Application ID korreliert werden.
Erfassen
Ereignis, das im Kernkontosystem bei Kontoaktivierung protokolliert wurde.
Ereignistyp
explicit
|
|||
|
Analyseprüfung gestartet
|
Ein Compliance-Analyst beginnt die manuelle Untersuchung potenzieller Übereinstimmungen für einen Kundenantrag. Dies beinhaltet die Bewertung der Details der potenziellen Übereinstimmungen anhand der Kundeninformationen, um die Relevanz zu bestimmen. | ||
|
Bedeutung
Dies markiert den Start der Manual Compliance Review, einem Common Bottleneck. Measuring der Time von 'Potential Match Identified' zu dieser Activity reveals Queuing Delays, während die Duration des Reviews Analyst Efficiency anzeigt.
Datenquelle
Dies kann abgeleitet werden, wenn ein Analyst einen Case aus der Review Queue 'claims' oder öffnet. Das System kann dieses Event explizit in einem Audit Trail loggen, wenn der Case Status sich zu 'In Review' ändert oder einem spezifischen User zugewiesen wird.
Erfassen
Abgeleitet aus einer Statusänderung des Falls zu 'In Bearbeitung' oder der Zuweisung des Falls an einen Analysten.
Ereignistyp
inferred
|
|||
|
Application Rejected
|
Der Kundenantrag wird formell abgelehnt, oft infolge eines 'Match Found' in World-Check oder anderer Risikofaktoren. Dieses Ereignis ist das endgültige negative Ergebnis des Onboarding-Prozesses. | ||
|
Bedeutung
Dies ist der primäre Failure Endpoint des Process. Analyzing von Rejection Events, particularly the Reasons und Preceding Activities, ist Crucial für Process Improvement und das Reducing von Unnecessary Rejections.
Datenquelle
Diese finale Geschäftsentscheidung wird im vorgelagerten CRM- oder Kernanwendungssystem erfasst, nicht in World-Check selbst. Daten müssen von diesem System bezogen werden.
Erfassen
Ereignis, das im Quellanwendungssystem protokolliert wurde, oft mit einem entsprechenden Ablehnungsgrundcode.
Ereignistyp
explicit
|
|||
|
Bewerbung eingereicht
|
Diese Aktivität markiert die Initiierung des KYC-Onboarding-Prozesses, wenn ein Kunde seinen Antrag einreicht. Dieses Event wird typischerweise in einem CRM oder einem Kernanwendungssystem erfasst, welches dann den Screening-Prozess in Refinitiv World-Check auslöst. | ||
|
Bedeutung
Dies ist das primäre Start Event für die End-to-End Customer Onboarding Journey. Analyzing der Time von diesem Point zu Completion provides the Overall Onboarding Cycle Time, which is Critical für Measuring Customer Experience und SLA Adherence.
Datenquelle
Dieses Event ist nicht nativ in World-Check. Es muss von einem vorgelagerten System, wie einem CRM oder einer Kundenkontenmanagement-Plattform, bezogen und über die Customer Application ID korreliert werden.
Erfassen
Ereignis, das im Quellanwendungssystem bei erster Einreichung protokolliert wurde.
Ereignistyp
explicit
|
|||
|
Echte Übereinstimmung bestätigt
|
Ein Analyst bestätigt, dass eine potenzielle Übereinstimmung tatsächlich der zu überprüfende Kunde ist, und identifiziert ein potenzielles Risiko. Dies ist ein kritischer Meilenstein, der typischerweise eine weitere Due Diligence oder Antragsablehnung auslöst. | ||
|
Bedeutung
Dies ist ein Key Risk-Mitigation Outcome und ein Pivotal Moment im Process. Es beeinflusst direkt die Final Decision auf die Customer Application und ist Crucial für Compliance Reporting und Analysis.
Datenquelle
Dies ist eine explizite User Action, bei der der Analyst einen spezifischen Match als einen 'True Match' oder 'Confirmed Match' dispositioniert. Dieses Event ist logged im Case Audit Trail.
Erfassen
Protokolliert, wenn ein Analyst einen Treffer im System formell bestätigt.
Ereignistyp
explicit
|
|||
|
Screening abgeschlossen - Freigegeben
|
Der Screening-Fall wird offiziell mit einem 'Freigegeben'-Ergebnis abgeschlossen, was bedeutet, dass keine echten Treffer gefunden wurden. Diese Entscheidung wird an das Ursprungssystem zurückgemeldet, sodass der Onboarding-Prozess fortgesetzt werden kann. | ||
|
Bedeutung
Diese Aktivität stellt den erfolgreichen 'Happy Path'-Abschluss des Screening-Prozesses dar. Sie dient als wichtiger Endpunkt zur Messung der Cycle Time von Standard- und Risikoarmen-Anträgen.
Datenquelle
Abgeleitet aus der endgültigen Statusänderung des Falls zu 'Freigegeben', 'Abgeschlossen' oder 'Geschlossen - Kein Treffer'. Der Timestamp dieser letzten Statusänderung wird verwendet.
Erfassen
Abgeleitet vom Timestamp des finalen Fallstatus, der ein klares Ergebnis anzeigt.
Ereignistyp
inferred
|
|||
|
Screening abgeschlossen - Treffer gefunden
|
Der Screening-Fall wird offiziell mit einem 'Treffer gefunden'-Ergebnis abgeschlossen, was darauf hinweist, dass ein bestätigtes Risiko identifiziert wurde. Diese Entscheidung löst einen anderen nachgelagerten Prozess aus, wie z.B. eine erweiterte Due Diligence oder Ablehnung. | ||
|
Bedeutung
Dies ist der primäre 'Unhappy Path'-Endpoint für den Screening Process. Analyzing dieser Cases hilft, Risk Profiles und die Effectiveness der Screening Controls zu verstehen.
Datenquelle
Abgeleitet aus der endgültigen Statusänderung des Falls zu 'Treffer gefunden', 'Risiko identifiziert' oder 'Geschlossen - Positiv'. Der Timestamp dieser letzten Statusänderung wird verwendet.
Erfassen
Abgeleitet vom Timestamp des finalen Fallstatus, der eine bestätigte Übereinstimmung anzeigt.
Ereignistyp
inferred
|
|||
|
Screening-Anfrage erstellt
|
Ein neuer Screening-Fall wird formell für einen Kundenantrag innerhalb des Refinitiv World-Check Systems erstellt. Dies wird durch einen API-Aufruf oder eine manuelle Eingabe aus einem vorgeschalteten System ausgelöst und stellt den Beginn der Risikoanalyse dar. | ||
|
Bedeutung
Dies markiert den offiziellen Start des Screening Sub-Processes. Die Time zwischen 'Application Submitted' und dieser Activity reveals Delays in Handoffs zwischen dem Line-of-Business System und der Compliance Function.
Datenquelle
Erfasst in den World-Check Fallmanagement-Protokollen oder im Audit-Trail. Das Erstellungsereignis und dessen Timestamp für den spezifischen Fall oder die Entitäts-ID würden verwendet.
Erfassen
Automatisch protokolliert, wenn ein neuer Screening-Fall im System erstellt wird.
Ereignistyp
explicit
|
|||
|
Application Approved
|
Der Kundenantrag wurde nach erfolgreichem KYC-Screening und allen weiteren erforderlichen Prüfungen vollständig genehmigt. Dieses Ereignis tritt typischerweise im Quellsystem auf, nachdem ein 'Freigegeben'-Ergebnis von World-Check erhalten wurde. | ||
|
Bedeutung
Dies markiert das erfolgreiche Business Outcome des Onboarding Process. Tracking der Time zu diesem Point von Submission reveals the Full 'Time-to-Yes' für einen New Customer.
Datenquelle
Dieses Event ist nicht nativ in World-Check. Es muss vom vorgelagerten CRM- oder Kernanwendungssystem bezogen werden, das die endgültige Geschäftsentscheidung trifft.
Erfassen
Ereignis, das im Quellanwendungssystem bei endgültiger Genehmigung protokolliert wurde.
Ereignistyp
explicit
|
|||
|
Automated Screening Performed
|
Das World-Check System gleicht die Kundendaten automatisch mit seiner Risikointelligenz-Datenbank ab. Dies ist eine systemgesteuerte Aktivität, die ein anfängliches Ergebnisset liefert, wie z.B. potenzielle Treffer oder einen eindeutigen Status. | ||
|
Bedeutung
Diese Aktivität ist der erste wertschöpfende Schritt innerhalb des Screening-Prozesses. Verzögerungen vor diesem Punkt deuten auf System- oder Datenbereitschaftsprobleme hin, während das Ergebnis die nachfolgende manuelle Arbeitslast bestimmt.
Datenquelle
Dieses Event kann explizit im Case Audit Trail protokolliert oder aus dem Timestamp abgeleitet werden, wenn erste Screening-Ergebnisse für den Case verfügbar werden.
Erfassen
Systemeintrag, der bei Abschluss des automatisierten Datenbank-Scans generiert wird.
Ereignistyp
explicit
|
|||
|
Fall zur Prüfung eskaliert
|
Ein Erstanalyst eskaliert einen komplexen oder risikoreichen Fall an einen Senior-Analysten oder Manager zur endgültigen Entscheidung. Dies ist ein entscheidender Übergabepunkt innerhalb des Compliance-Teams. | ||
|
Bedeutung
Eskalationen erzeugen oft Engpässe und erhöhen die Durchlaufzeit. Die Analyse der Häufigkeit und der Gründe für Eskalationen kann Schulungsbedarf bei Junior-Analysten oder Unklarheiten in den Überprüfungsrichtlinien aufzeigen.
Datenquelle
Als explizite Aktion im Fall-Workflow oder Audit-Trail erfasst. Dies könnte auch aus einer Änderung des dem Fall zugewiesenen Benutzers abgeleitet werden, insbesondere bei einem Benutzer mit höheren Berechtigungen.
Erfassen
Protokolliert über einen dedizierten 'Eskalieren'-Button oder eine Workflow-Aktion innerhalb des Falls.
Ereignistyp
explicit
|
|||
|
False Positive Confirmed
|
Der Analyst kommt zu dem Schluss, dass ein potenzieller Treffer nicht mit dem geprüften Kunden übereinstimmt. Der Treffer wird verworfen, und der Screening-Prozess für diesen spezifischen Alert ist abgeschlossen. | ||
|
Bedeutung
Dies stellt ein Common Outcome des Review Process dar. Understanding der Time it takes, um False Positives zu dispositionieren, helps measure Analyst Efficiency und die Accuracy der Automated Screening Logic.
Datenquelle
Dies ist eine explizite User Action, bei der der Analyst einen spezifischen Match als 'False Positive' oder 'Not a Match' dispositioniert. Diese Action ist typically logged in der Case History.
Erfassen
Protokolliert, wenn ein Analyst einen potenziellen Treffer im System formell zurückweist.
Ereignistyp
explicit
|
|||
|
Potenzieller Treffer identifiziert
|
Der automatisierte Screening-Prozess hat einen oder mehrere potenzielle Treffer gefunden, die eine manuelle Überprüfung durch einen Analysten erfordern. Dieses Ereignis überführt den Fall von einem automatisierten Zustand in eine manuelle Untersuchungs-Warteschlange. | ||
|
Bedeutung
Diese Aktivität ist ein kritischer Verzweigungspunkt im Prozess. Cases mit potenziellen Matches folgen einem längeren, komplexeren Pfad, und das Tracking hilft bei der Ressourcenplanung und Bottleneck-Analyse für das Review-Team.
Datenquelle
Abgeleitet aus einer Statusänderung des Falls zu 'Überprüfung erforderlich', 'Potenzieller Treffer' oder einem ähnlichen Status innerhalb des World-Check Fallmanagement-Moduls.
Erfassen
Abgeleitet von einer Fallstatusänderung, die anzeigt, dass nun eine manuelle Überprüfung erforderlich ist.
Ereignistyp
inferred
|
|||
|
Zusätzliche Informationen angefordert
|
Der Analyst stellt fest, dass weitere Informationen zur Klärung des potenziellen Treffers erforderlich sind und fordert diese bei der Geschäftseinheit an. Dies versetzt den Fall in einen schwebenden Zustand, bis die Informationen bereitgestellt werden. | ||
|
Bedeutung
Häufiges Auftreten dieser Aktivität deutet auf Probleme mit der Qualität der anfänglichen Daten für das Screening hin. Diese Aktivität führt zu erheblichen Verzögerungen, da sie von externen Teams abhängt, und ist ein wesentlicher Treiber langer Durchlaufzeiten.
Datenquelle
Dies kann eine explizite User Action sein, die in den Case Notes oder im Audit Log protokolliert wird. Alternativ könnte es inferred werden from einem Case Status Change zu 'Pending Information' oder 'RFI'.
Erfassen
Protokolliert, wenn ein Analyst eine Funktion verwendet, um den Fall als informationsbedürftig zu kennzeichnen.
Ereignistyp
explicit
|
|||