Ihr KYC-Onboarding Daten-Template
Ihr KYC-Onboarding Daten-Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten für das Tracking
- Extraktionsanleitung
KYC-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 Aktivitätsname beschreibt einen einzelnen Schritt oder ein Ereignis in der Kunden-Onboarding-Prozess, wie zum Beispiel 'Antrag eingereicht', 'Analystenprüfung gestartet' oder 'Screening abgeschlossen – Freigegeben'. Diese Aktivitäten bilden die Knotenpunkte der Prozessablauf 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 finden, die Verzögerungen oder Nacharbeit verursachen. Dieses Attribut ist maßgeblich für die Erstellung von Prozessablaufn und die Berechnung von Aktivitätsmetriken.
Bedeutung
Dieses Attribut definiert die einzelnen Schritte des Prozesses, was wichtig für die Entdeckung und Visualisierung des Prozessflusses und die Identifizierung von Engpässen ist.
Datenquelle
Diese Information findet sich in der Regel 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 Zeitstempel ist das chronologische Basis des Prozesses und ermöglicht die korrekte Sortierung von Ereignissen, um den Fallverlauf zu rekonstruieren. Dieses Attribut ist maßgeblich für alle zeitbasierten Analysen im Process Mining. Es wird verwendet, um Zeitspannen zwischen Aktivitäten (Durchlaufzeiten und Wartezeiten) zu berechnen, die gesamte Falldauer zu messen, die Prozessleistung über die Zeit zu analysierenn und die Einhaltung von Service Level Agreements (SLAs) zu überprüfen. Ohne genaue Zeitstempels ist es unmöglich, die Prozessleistung zu verstehen und temporale Engpässe zu identifizieren.
Bedeutung
Der Zeitstempel für jede Aktivität ist wichtig für die Berechnung aller zeitbasierten Kennzahlen, 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 'Zeitstempel', '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 Case-ID dient. | ||
|
Beschreibung
Die Customer Application ist der zentrale Case-ID, der alle Ereignisse und Aktivitäten einer einzelnen Kunden-Onboarding-Prozess 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 wesentlich für die Rekonstruktion der End-to-End-Prozesses jedes Antrags. Es ermöglicht die Visualisierung von Prozessabläufen, die Berechnung von Gesamt-Durchlaufzeits 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 wesentliche Case-ID, der alle related Aktivitäten verbindet, wodurch der gesamte Kunden-Onboarding-Prozess analysiert werden kann.
Datenquelle
Dieser Identifikator ist in der Regel 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 den Antrag bearbeitet.as Funktionsteam, das für die Ausführung der Aktivität verantwortlich ist. | ||
|
Beschreibung
Dieses Attribut spezifiziert die Business Unit oder den Antrag bearbeitet.as Team, wie z.B. 'Onboarding', 'Compliance' oder 'Quality Assurance', zu dem der Benutzer gehört. Es erlaubt eine Analyse auf einer höheren organisationalen Ebene als der individuelle Benutzer.\n\nAnalyzing by Department ist kritisch für die Identifizierung von inter-departmentalen Engpässe und die Messung von Handoff Times. Es hilft zu visualisieren, wie Workflows zwischen verschiedenen Teams fließen und wo Verzögerungen in diesen Transitions auftreten. This View ist invaluable für das Streamlining von Cross-functional Zusammenarbeit 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 Benutzer-Profil im System oder einem zugehörigen HR-System gespeichert sein. Sie müsste gegebenenfalls mit den Event-Daten unter Verwendung der Benutzer ID verknüpft werden.
Beispiele
Onboarding-TeamCompliance-PrüfungGeschäftsleitung
|
|||
|
Endzeit des Ereignisse
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 Ereignisse 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 wichtig für die Berechnung der exakten Bearbeitungszeit einer Aktivität, im Gegensatz zur Durchlaufzeit, 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 maßgeblich für die Ressourcenoptimierung und Effizienzanalyse.
Bedeutung
Ermöglicht die präzise Berechnung der Aktivitätsbearbeitungszeit, trennt aktive Arbeitszeit von ungeverwendeter 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 den Antrag bearbeitet.ie Aktivität durchgeführt hat. | ||
|
Beschreibung
Die Reviewer ID, oder den Antrag bearbeitet.er Benutzer, gibt an, wer eine bestimmte Aufgabe 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 Einblick in die Arbeitslastverteilung und die individuelle Leistungsfähigkeit.\n\nDieses Attribut ist wichtig für die Ressourcenbasierte Analyse. Es hilft, Leistungsfähigkeit-Unterschiede zwischen Benutzern oder Teams zu verstehen, Schulungsbedarf zu identifizieren und Workload Balancing zu optimieren. Es ist auch eine Key Component für die Analyse von Übergaben, Social Networks und Compliance-Ressourcennutzung.
Bedeutung
Ermöglicht die Analyse der Arbeitslastverteilung, der Benutzerleistung und der Abteilungsübergaben, was für die Ressourcenoptimierung wichtig ist.
Datenquelle
Typischerweise in Event-Logs oder Audit-Trails zu finden, oft benannt als 'BenutzerID', 'PerformedBy' oder 'Owner'.
Beispiele
analyst_jdoesystem_auto_screenermanager_bsmith
|
|||
|
Risikostufe
RiskLevel
|
Die berechnete Risikoklassifizierung des Kundenantrags, wie 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 Fälle nach Risk Level unerlässlich. Sie hilft, Variationen in Durchlaufzeits und Prozessabläufen zu erklären; zum Beispiel können Hochrisiko-Anträge mehr Schritte erfordern und länger dauern. Dieses Attribut ist maßgeblich für die 'Application Rejection Rate and Reasons' und 'Background Check Initiation Durchlaufzeit' Dashboards, um zu verstehen, wie Risiko Resultate und Effizienz beeinflusst.
Bedeutung
Die Segmentierung des Prozesses nach Risikostufe ist maßgeblich, um zu verstehen, warum bestimmte Fälle länger dauern oder unterschiedliche Pfade verfolgen, sowie zur Analyse der Ablehnungsraten.
Datenquelle
Dies ist ein Core Daten Point im Customer Application oder Case Datensatz. 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
Das SLA-Zieldatum ist die Frist für die Fertigstellung des gesamten Onboarding-Fälle, 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 wesentlich für das 'SLA-Einhaltung 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 Verzögerungen 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 Leistungsfähigkeit und ist wichtig für die Berechnung der SLA-Einhaltung Rate und das Analyse von Verstößen.
Datenquelle
Dieses Datum wird oft basierend auf dem Antragsdatum und den Geschäftsregeln berechnet. Es kann als Feld im Case Datensatz 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 Hauptfaktor 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 Prozessoptimierungen, 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 notwendig ist, um Verbesserungsbereiche im Onboarding-Prozess zu identifizieren und die Ablehnungsrate zu reduzieren.
Datenquelle
Dies würde erfasst werden, wenn das 'Antrag abgelehnt' Event occurs, likely als ein Field auf dem Case oder Application Datensatz.
Beispiele
PEP-ÜbereinstimmungTreffer auf SanktionslisteFailed Document VerificationAdverse Media
|
|||
|
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 maßgeblich für das 'Application Throughput by Channel' Dashboard. Durch die Analyse von Volumen, Durchlaufzeit und Resultate von Anträgen aus verschiedenen Kanälen kann eine Organisation identifizieren, welche Kanäle am effizientesten sind und welche Prozessoptimierungen 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 in der Regel am Anfang des Prozesses erfasst und als Attribut im Application Datensatz gespeichert.
Beispiele
Online-PortalMobile AppIn der FilialeRelationship Manager
|
|||
|
Ist automatisiert
IsAutomated
|
Ein Flag, das anzeigt, ob die Aktivität von einem System (wahr) oder einem Menschen (Nein) durchgeführt wurde. | ||
|
Beschreibung
Dieses boolesche Attribut unterscheidet zwischen automatisierten System Aufgaben und manuellen Aktivitäten, die von Benutzern 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 Automatisierung Analysis. Es hilft, den Impact von Automatisierung auf Process Efficiency zu messen, zu identifizieren, welche Manual Aufgaben Candidates für zukünftige Automatisierung sind, und die Interaction zwischen Human und System Actors zu verstehen. Es ermöglicht eine klare Separation von System Bearbeitungszeit von Manual Handling Time.
Bedeutung
Differenziert zwischen System- und menschlichen Aktivitäten, was wichtig ist, um den Einfluss von Automatisierung zu messen und neue Automatisierungsmöglichkeiten zu identifizieren.
Datenquelle
Dies wird in der Regel basierend auf dem Aktivitätsname oder den Antrag bearbeitet.er mit dem Event verbundenen Benutzer ID abgeleitet (z.B. wenn der Benutzer ein 'System' Account ist).
Beispiele
JaNein
|
|||
|
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 maßgeblich, 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 Daten Transformation berechnet, indem die Sequence der Aktivitäten innerhalb jedes Case analysiert und nicht-erstmalige Occurrences einer Activity gekennzeichnet werden.
Beispiele
JaNein
|
|||
|
Kunden-ID
CustomerId
|
Eine eindeutige Kennung 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 Daten System anzureichern. Dies ermöglicht eine umfassendere 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 Datensatz, linking it zu den Customer Master Daten.
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 Dauer beeinflussen können.\n\nDie Analyse des Prozesses nach Land ermöglicht es Organisationen, die Leistungsfähigkeit über verschiedene Regionen hinweg zu vergleichen, Standort-spezifische Engpässe 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 in der Regel komplexer als das einer Einzelperson. Dieses Attribut wird für die Segmentierungsanalyse verwendet, insbesondere für das Dashboard „KYC Kundentyp-Leistungsfähigkeit“. 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 wesentliches Attribut, das im Kunden- oder Application Datensatz innerhalb des Quellsystems gespeichert ist.
Beispiele
PrivatpersonCorporationGemeinnützige OrganisationTrust
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Zeitstempel, 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 Daten 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 Benutzern zu wissen, ob sie Near Real-Time Daten oder einen Momentaufnahme von einem spezifischen Point in Time betrachten. Es ist wichtig für Daten Governance und für das Management von Benutzer Expectations über die Currency der Erkenntnisse provided.
Bedeutung
Bietet wichtigen Kontext zur Datenaktualität und stellt sicher, dass Nutzer verstehen, wie aktuell die Prozessanalyse ist.
Datenquelle
Dieser Zeitstempel wird während des Daten Extraktion (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 wichtig, 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 Daten Governance, dem Fehlerbehebung 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 Daten Lineage klar und auditable ist.
Bedeutung
Identifiziert die Herkunft der Daten, was wichtig 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 Daten Extraktion, Transformation, and Loading (ETL) Process hinzugefügt wird, um den Datenset 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 Zeitstempels 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-Einhaltung and Breach Analysis' Dashboard und den 'SLA-Einhaltung Rate' KPI. Es vereinfacht Analysis, indem es Benutzern ermöglicht, schnell für alle breached Fälle zu filtern. Durch die Analyse der Prozesscharakteristika von breached Fälle können Organisationen die Root Causes von Verzögerungen 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 Daten Transformation berechnet, indem der Final Activity Zeitstempel für einen Case mit dem SlaTargetDate Field verglichen wird.
Beispiele
JaNein
|
|||
|
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-Listeen 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 Antrag bearbeitet.en 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-Resultaten, der eine tiefere Analyse der Trefferauflösungszeiten und Alert-Typn 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-Onboarding-Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Account Activated
|
Das Konto des Kunden wird im Kernsystem erstellt und aktiviert, wodurch die Onboarding-Prozess abgeschlossen wird. Dies folgt der endgültigen Antragsgenehmigung und macht das Konto betriebsbereit. | ||
|
Bedeutung
Dies ist der finale, Value-delivering Step im Process. Die Dauer 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 KundenHinweisrmationen, 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 Verzögerungen, während die Dauer 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 Benutzer zugewiesen wird.
Erfassen
Abgeleitet aus einer Statusänderung des Falls zu 'In Bearbeitung' oder den Antrag bearbeitet.er Zuweisung des Falls an einen Analysten.
Ereignistyp
inferred
|
|||
|
Antrag abgelehnt
|
Der Kundenantrag wird formell abgelehnt, oft Hinweislge 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 Ereignisse, particularly the Reasons und Preceding Aktivitäten, 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
|
|||
|
Antrag eingereicht
|
Diese Aktivität markiert die Initiierung des KYC-Onboarding-Prozesses, wenn ein Kunde seinen Antrag einreicht. Dieses Event wird in der Regel 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-Prozess. Analyzing der Time von diesem Point zu Completion provides the Overall Onboarding Durchlaufzeit, which is Critical für Measuring Customer Experience und SLA-Einhaltung.
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 in der Regel eine weitere Due Diligence oder Antragsablehnung auslöst. | ||
|
Bedeutung
Dies ist ein Key Risk-Mitigation Ergebnisse 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 Benutzer Action, bei der den Antrag bearbeitet.er 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 Durchlaufzeit von Standard- und Risikoarmen-Anträgen.
Datenquelle
Abgeleitet aus der endgültigen Statusänderung des Falls zu 'Freigegeben', 'Abgeschlossen' oder 'Geschlossen – Kein Treffer'. Der Zeitstempel dieser letzten Statusänderung wird verwendet.
Erfassen
Abgeleitet vom Zeitstempel 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 Fälle 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 Zeitstempel dieser letzten Statusänderung wird verwendet.
Erfassen
Abgeleitet vom Zeitstempel 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 Verzögerungen in Übergaben zwischen dem Line-of-Business System und der Compliance Funktion.
Datenquelle
Erfasst in den World-Check Fallmanagement-Protokollen oder im Audit-Trail. Das Erstellungsereignis und dessen Zeitstempel für den spezifischen Fall oder den Antrag bearbeitet.ie 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 in der Regel im Quellsystem auf, nachdem ein 'Freigegeben'-Ergebnis von World-Check erhalten wurde. | ||
|
Bedeutung
Dies markiert das erfolgreiche Business Ergebnisse 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 Resultatet 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 Zeitstempel abgeleitet werden, wenn erste Screening-Resultate 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 wichtiger Ü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 Ergebnisse 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 Benutzer Action, bei der den Antrag bearbeitet.er 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. Fälle mit potenziellen Matches folgen einem längeren, komplexeren Pfad, und das Tracking hilft bei der Ressourcenplanung und Engpassanalyse 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 Benutzer 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 Hinweisrmationsbedürftig zu kennzeichnen.
Ereignistyp
explicit
|
|||