Ihr KYC-Onboarding Daten-Template
Ihr KYC-Onboarding Daten-Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten für das Tracking
- Extraktions-Leitfaden für ACTICO
KYC-Onboarding-Attribute
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der Name des spezifischen Geschäfts-Ereignisse oder den Antrag bearbeitet.er Aufgabe, die innerhalb des Kunden-Onboarding-Prozesses durchgeführt wird. | ||
| Beschreibung Dieses Attribut erfasst den Namen jedes Schritts oder jeder Aktivität, die während des KYC-Prozesses auftritt, wie 'Antrag eingereicht', 'Risikobewertung durchgeführt' oder 'Antrag genehmigt'. Es liefert die sequenziellen Bausteine der Prozessablauf. Die Analyse des Aktivitätsname ermöglicht die Visualisierung des Prozessflusses, die Identifizierung häufiger oder seltener Aktivitäten und die Erkennung von Engpässe oder Rework-Schleifen. Es ist ein Grundlage, um zu verstehen, welche Aktionen in welcher Reihenfolge ausgeführt werden, was für die Variantenanalyse und Compliance-Prüfungen wichtig ist. Bedeutung Es definiert die Schritte in der Prozessablauf, visualisiert den Fluss und ermöglicht die Analyse von Abweichungen sowie der Reihenfolge von Aktivitäten. Datenquelle Diese Information findet sich in der Regel in einer Event-Log-Tabelle innerhalb von ACTICO, oft in einem Feld, das den Event- oder Aufgabentyp beschreibt. Konsultieren Sie die ACTICO-Dokumentation. Beispiele Antrag eingereichtRisikobewertung durchgeführtCompliance-Prüfung abgeschlossenAntrag abgelehnt | |||
| Ereigniszeit EventTime | Der Zeitstempel, der anzeigt, wann eine spezifische Aktivität begann oder stattfand. | ||
| Beschreibung Event Time ist der exakte Zeitpunkt, an dem eine Aktivität im System aufgezeichnet wurde. Sie definiert die chronologische Reihenfolge aller Ereignisse eines Antrags und bildet die Timeline der Onboarding-Prozess ab. Dieses Attribut ist die Basis jeder zeitbezogenen Analyse. Damit werden Durchlaufzeiten berechnet, Verzögerungen identifiziert und die Einhaltung von SLAs geprüft. Erst durch diese Zeitstempel können Process-Mining-Tools den tatsächlichen Prozessfluss rekonstruieren. Bedeutung Dieses Attribut liefert die chronologische Reihenfolge der Ereignisse, was für die Berechnung von Dauern, die Entdeckung von Engpässe und die Analyse der Prozess-Timeline notwendig ist. Datenquelle Der Zeitstempel jeder aufgezeichneten Aktivität in den ACTICO Event-Log-Tabellen. Details finden Sie in der ACTICO-Dokumentation. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T15:45:10Z | |||
| Kundenantrag CustomerApplication | Die eindeutige Kennung für einen einzelnen Kunden-Onboarding-Antrag, die als Case-ID für die Prozessanalyse dient. | ||
| Beschreibung Die Kundenantrag ist der primäre Case-Identifikator, der alle Ereignisse und Aktivitäten einer einzelnen Kunden-Onboarding-Prozess gruppiert. Sie repräsentiert eine vollständige Instanz des KYC-Prozesses, von der initialen Einreichung bis zur finalen Entscheidung über Genehmigung oder Ablehnung. Im Process Mining ist dieses Attribut wichtig, um die End-to-End-Prozesses jedes Antrags zu rekonstruieren. Es ermöglicht Analysten, die Abfolge der Aktivitäten zu verfolgen, die gesamten Durchlaufzeiten zu messen und verschiedene Prozesspfade oder Varianten zu vergleichen, die von verschiedenen Anwendungen durchlaufen wurden. Alle Ereignisse, die dieselbe Kundenantrags-ID teilen, werden als Teil desselben Case betrachtet. Bedeutung Dies ist das wesentliche Attribut für Process Mining, da es alle verwandten Ereignisse zu einer einzigen, zusammenhängenden Prozessinstanz verbindet und eine End-to-End-Analyse der Onboarding-Erfahrung jedes Kunden ermöglicht. Datenquelle Dies ist ein Primärschlüssel in den Hauptanwendungs- oder Case-Management-Tabellen innerhalb von ACTICO. Konsultieren Sie die ACTICO-Dokumentation für spezifische Tabellen- und Feldnamen. Beispiele APP-2023-001, 2, 3, 4APP-2023-001235APP-2024-000001 | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Zeitstempel, der den Antrag bearbeitet.en Zeitpunkt angibt, zu dem die Daten zuletzt aktualisiert oder aus dem Quellsystem extrahiert wurden. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit des letzten Datenabzugs aus ACTICO. Es ist ein MetaDatenfeld, das für den gesamten Datensatz gilt und nicht für einzelne Ereignisse, und liefert Kontext zur Aktualität der Analyse. In Dashboards und Berichten ist diese Information für Benutzer von wichtiger Bedeutung, um zu verstehen, wie aktuell die Daten sind. Es hilft, Erwartungen hinsichtlich der Aktualität von Erkenntnissen zu managen und ist maßgeblich für die operative Überwachung, bei der nahezu EchtzeitDaten wichtig sind. Die Anzeige dieses Zeitstempels stellt ... sicher Transparenz und Vertrauen in die präsentierten Daten. Bedeutung Gibt die Aktualität der Daten an, damit Nutzer wissen, ob sie auf Basis neuester Informationen entscheiden: wichtig für den operativen Betrieb. Datenquelle Dieser Wert wird während des Datenextraktions-, Transformations- und Lade-(ETL)-Prozesses generiert und gespeichert. Er spiegelt den Zeitstempel wider, wann der ETL-Job erfolgreich abgeschlossen wurde. Beispiele 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Quellsystem SourceSystem | Das führende System, aus dem die Event-Daten stammen. | ||
| Beschreibung Dieses Attribut identifiziert das QuellHinweisrmationssystem, in dem die Daten generiert wurden. Für diesen Prozess wird es durchgängig 'ACTICO' sein, aber in breiteren Analysen, die mehrere Systeme umfassen, hilft es, Datenherkünfte zu differenzieren. Im Process Mining Kontext ist es wichtig für die Daten Governance und Validierung. Es stellt sicher, dass Daten ihrer Quelle korrekt zugeordnet werden, was wichtig ist, wenn Daten aus verschiedenen Systemen zusammengeführt werden, um eine vollständige Prozessansicht zu erstellen. Es hilft auch bei der Behebung von Datenqualitätsproblemen, indem diese auf das Ursprungssystem zurückgeführt werden. Bedeutung Liefert wesentlichen Kontext zur Datenherkunft, um Datenherkunft und -governance sicherzustellen, was wichtig ist, wenn Daten aus mehreren Quellen kombiniert werden. Datenquelle Dies ist in der Regel ein statischer Wert ('ACTICO'), der während des Datenextraktions- und Transformationsprozesses hinzugefügt wird, um den Datensatz zu kennzeichnen. Beispiele ACTICOACTICO PlattformActico KYC Modul | |||
| Ablehnungsgrund RejectionReason | Der spezifische Grund, der angegeben wird, wenn ein Kundenantrag abgelehnt wird. | ||
| Beschreibung Wenn der finale Status eines Antrags 'Abgelehnt' ist, liefert dieses Attribut die zugrunde liegende Ursache. Beispiele sind 'Unvollständige Dokumentation', 'Hintergrundprüfung fehlgeschlagen' oder 'Hohes Risikoprofil'. Dies ist ein wesentliches Attribut für die Ursachenanalyse. Durch die Analyse der Häufigkeit verschiedener Ablehnungsgründe kann das Unternehmen systemische Probleme im Prozess oder bei Kundeneinreichungen identifizieren. Zum Beispiel könnte eine hohe Anzahl von Ablehnungen aufgrund unvollständiger Dokumentation darauf hindeuten, dass die Antragsanweisungen unklar sind. Dies unterstützt direkt das Dashboard 'Ablehnungsrate und -gründe von Anträgen'. Bedeutung Liefert das 'Warum' hinter Anwendungsablehnungen und ermöglicht eine Ursachenanalyse, um die Ablehnungsrate zu reduzieren und die Prozesseffizienz zu verbessern. Datenquelle Standarderweise in der Haupt-Case- oder Anwendungstabelle in ACTICO zu finden, oft nur gefüllt, wenn der Bewerbungsstatus 'Abgelehnt' ist. Beispiele Unvollständige DokumentationFehlgeschlagene IdentitätsprüfungSanktionstrefferHoher Risikowert | |||
| Abteilung Department | Die für die Durchführung der Aktivität verantwortliche Fachabteilung oder den Antrag bearbeitet.as Team. | ||
| Beschreibung Dieses Attribut ordnet eine Aktivität einer spezifischen Organisationseinheit zu, wie z. B. 'Compliance', 'Onboarding-Team' oder 'Kundenbeziehungen'. Es bietet einen organisatorischen Kontext für den Prozessfluss. Die Analyse auf Abteilungsebene ist maßgeblich, um zu verstehen, wie Arbeit zwischen verschiedenen Teilen der Organisation übergeben wird. Sie hilft, abteilungsübergreifende Engpässe zu identifizieren, die Effizienz der Abteilung zu messen und die Ressourcenallokation über Teams hinweg zu analysierenn. Dashboards können nach Abteilung gefiltert werden, um Managern eine Ansicht der spezifischen Leistung ihres Teams zu bieten. Bedeutung Bietet eine organisatorische Dimension für die Analyse, die die Identifizierung abteilungsübergreifender Verzögerungen und die Bewertung der Teamleistung ermöglicht. Datenquelle Diese Information könnte direkt mit den Event-Daten gespeichert oder den Antrag bearbeitet.urch das Verknüpfen von BenutzerDaten mit einer HR-StammDatentabelle, die Benutzer Abteilungen zuordnet, abgeleitet werden. Konsultieren Sie die ACTICO-Dokumentation. Beispiele ComplianceOnboarding-TeamKundenservice | |||
| Bewerbungsstatus ApplicationStatus | Das Endergebnis oder den Antrag bearbeitet.er aktuelle Status des Kunden-Onboarding-Antrags. | ||
| Beschreibung Dieses Attribut zeigt die finale Entscheidung eines Case an, in der Regel 'Genehmigt' oder 'Abgelehnt'. Es kann auch den Status von laufenden Fälle anzeigen. Dies ist eine kritische Dimension für ergebnisbasierte Analysen. Zu verstehen, warum Anträge genehmigt oder abgelehnt werden, ist ein Hauptziel des KYC Process Mining. Dieses Attribut ermöglicht das Filtern der Prozessablauf, um die typischen Journeys von genehmigten versus abgelehnten Anträgen zu sehen, was hilft, Prozessmuster zu identifizieren, die zu unerwünschten Resultaten führen. Es ist auch die Basis für die Berechnung des KPIs 'Ablehnungsquote'. Bedeutung Definiert das Ergebnis jedes Falls und ermöglicht Vergleiche zwischen erfolgreichen und erfolglosen Instanzen sowie die Berechnung von Ablehnungsquoten. Datenquelle Dies ist ein Case-Level-Attribut, das oft in der Haupt-Case- oder Anwendungstabelle in ACTICO zu finden ist. Es spiegelt den finalen Status der Anwendung wider. Beispiele GenehmigtAbgelehntIn BearbeitungAusstehende Informationen | |||
| Endzeit EndTime | Der Zeitstempel, der angibt, wann eine bestimmte Aktivität abgeschlossen wurde. | ||
| Beschreibung Die End Time markiert den Abschluss einer Aktivität. Gepaart mit der Start Time (Ereigniszeitpunkt (Event Time)) ermöglicht sie die Berechnung der genauen Dauer jeder Aufgabe, bekannt als Bearbeitungszeit. Nicht alle Ereignisse haben eine eindeutige Endzeit, da einige sofortig sein können. Dieses Attribut ist wesentlich für die Leistungsfähigkeit-Analyse, insbesondere um zu messen, wie lange jeder Schritt dauert. Es ermöglicht die Erstellung detaillierter Leistungsfähigkeit-Dashboards, hilft zu identifizieren, welche Aktivitäten die meiste Zeit in Anspruch nehmen, und ist wichtig für die Berechnung von KPIs wie 'Durchschnittliche Dokumentenprüfzeit'. Bedeutung Ermöglicht die Berechnung exakter Bearbeitungszeiten, was für die Identifizierung von Engpässen und die Analyse der Ressourceneffizienz notwendig ist. Datenquelle Wie die Startzeit findet sich auch diese meist in den Event-Log-Tabellen von ACTICO. Manche Systeme einsetzen separate Spalten für Start- und Endzeit eines Ereignisse. Beispiele 2023-10-26T10:15:00Z2023-10-26T12:00:00Z2023-10-27T16:00:15Z | |||
| Initiierender Benutzer InitiatingUser | Die Benutzer ID oder den Antrag bearbeitet.er Name des Mitarbeiters, der den Antrag bearbeitet.ie Aktivität durchgeführt hat. | ||
| Beschreibung Dieses Attribut identifiziert den spezifischen Benutzer oder Systemagenten, der für die Ausführung einer Aktivität verantwortlich ist. Es verknüpft Prozessschritte mit den Personen oder Teams, die sie ausgeführt haben. Die Analyse der Leistung nach Benutzer ist eine häufige Anforderung. Dieses Attribut ermöglicht die Erstellung von Dashboards, die die Arbeitslastverteilung, individuelle Bearbeitungszeiten und Leistungsvergleiche zwischen Benutzern oder Teams zeigen. Es hilft, leistungsstarke Einzelpersonen sowie diejenigen zu identifizieren, die möglicherweise zusätzliche Schulungen benötigen, und ist maßgeblich für das Verständnis der Ressourcenallokation und -auslastung. Bedeutung Verknüpft Aktivitäten mit Nutzern, was Leistungsfähigkeit-Analysen auf Team-Ebene ermöglicht und hilft, Schulungsbedarf oder Ressourcenengpässe zu finden. Datenquelle Typischerweise zusammen mit jedem Event in ACTICOs Event Log- oder Transaktionshistorien-Tabellen gespeichert. Konsultieren Sie die ACTICO-Dokumentation. Beispiele john.doejane.smithSYSTEM_USER | |||
| Risikostufe RiskLevel | Das berechnete Risikolevel des Kundenantrags, z.B. Niedrig, Mittel oder Hoch. | ||
| Beschreibung Dieses Attribut repräsentiert die bewertete Risikokategorie eines Kunden, die oft die Komplexität und Strenge des nachfolgenden KYC-Prozesses bestimmt. Ein Hochrisikokunde kann zusätzliche Prüfungen und Genehmigungen erfordern im Vergleich zu einem Niedrigrisikokunden. Im Process Mining ist Risk Level eine hilfreiche Dimension für die vergleichende Analyse. Es ermöglicht Analysten zu prüfen, ob der Prozess die verschiedenen Pfade basierend auf dem Risiko wie beabsichtigt korrekt verfolgt. Zum Beispiel kann man überprüfen, ob alle Hochrisikokunden einen erweiterten Due-Diligence-Schritt durchlaufen. Es ist maßgeblich für das 'Risk Assessment Prozessflusss' Dashboard. Bedeutung Ermöglicht die Segmentierung von Fällen nach Risiko, um zu prüfen, ob der Prozess wie vorgeschrieben auf verschiedene Risikoprofile reagiert. Datenquelle Dies ist ein wichtiger Datenpunkt, der auf Fallebene in der Hauptanwendungstabelle innerhalb von ACTICO gespeichert ist. Beispiele NiedrigMittelHoch | |||
| SLA-Zieldatum SlaTargetDate | Das Datum, bis zu dem der Kunden-Onboarding-Prozess voraussichtlich abgeschlossen sein wird. | ||
| Beschreibung Das SLA Target Date ist die Frist für den Abschluss des Kunden-Onboardings, wie in internen Service Level Agreements definiert. Dieses Datum wird oft auf der Grundlage des Antragsdatums plus einer Standardbearbeitungszeit berechnet. Dieses Attribut ist maßgeblich für die Überwachung der SLA-Compliance. Durch den Vergleich des tatsächlichen Abschlussdatums eines Case mit seinem SLA Target Date kann das System feststellen, ob der Case pünktlich abgeschlossen oder den Antrag bearbeitet.ie SLA verletzt wurde. Dies ist die Basis für das 'Onboarding SLA Leistungsfähigkeit' Dashboard und den KPI 'Onboarding SLA-Einhaltung Rate'. Bedeutung Liefert den Benchmark zur Messung der Pünktlichkeit, ermöglicht die direkte Überwachung und Berichterstattung der SLA-Compliance. Datenquelle Dies kann als Feld in der Haupt-Case-Tabelle in ACTICO gespeichert oder basierend auf Geschäftsregeln abgeleitet werden (z.B. Einreichungsdatum + 5 Geschäftstage). Beispiele 2023-11-01T17:00:00Z2023-11-02T17:00:00Z2023-11-03T17:00:00Z | |||
| Ist automatisiert IsAutomated | Ein `Indikator`, der anzeigt, ob eine `Aktivität` automatisch vom `System` oder manuell von einem `Benutzer` durchgeführt wurde. | ||
| Beschreibung Dieses boolesche Attribut unterscheidet zwischen Aufgaben, die von einem menschlichen Benutzer ausgeführt werden, und solchen, die durch Systemautomatisierung erfolgen, wie z. B. eine automatisierte Hintergrundprüfung oder Risikobewertung. Die Analyse dieses Attributs hilft bei der Bewertung der Wirksamkeit von Automatisierungsinitiativen. Sie ermöglicht einen Vergleich der Bearbeitungszeiten zwischen automatisierten und manuellen Schritten, identifiziert, welche Teile des Prozesses noch stark manuell sind, und kann Möglichkeiten für weitere Automatisierungen zur Verbesserung der Effizienz und Reduzierung der Betriebskosten aufzeigen. Bedeutung Unterscheidet zwischen manuellen und System-Aufgaben: essenziell, um den Automatisierungsgrad zu messen und neue Effizienzpotenziale zu finden. Datenquelle Dies kann aus dem Attribut 'InitiatingBenutzer' abgeleitet werden (z.B. wenn der Benutzer 'SYSTEM' ist) oder es könnte ein dediziertes Flag im Event Log sein. Konsultieren Sie die ACTICO-Dokumentation. Beispiele JaNein | |||
| Ist Nacharbeit IsRework | Ein berechnetes Flag, das anzeigt, ob eine Aktivität ein wiederholter Schritt oder Teil einer Rework-Schleife ist. | ||
| Beschreibung Dieses boolesche Attribut kennzeichnet Aktivitäten, die zum zweiten oder wiederholten Mal innerhalb desselben Case ausgeführt werden, wie z. B. eine 'Dokumentenprüfung', die nach einer Anfrage für weitere Informationen stattfindet. Es identifiziert Instanzen von Rework, die in der Regel eine Quelle von Prozesseffizienz sind. Die Identifizierung von Rework ist ein primäres Ziel des Process Mining. Dieses Flag ermöglicht die Quantifizierung von Rework, wie z. B. die Berechnung des KPIs 'Dokumenten-Rework-Rate'. In der Prozessablauf können Rework-Schleifen hervorgehoben werden, um zu zeigen, wo der Prozess sich selbst wiederholt. Dies hilft, Qualitätsprobleme oder Bereiche zu identifizieren, in denen der Prozess nicht 'right first time' ist. Bedeutung Hebt wiederholte Arbeitsschritte hervor, um Ineffizienzen direkt zu messen und Probleme bei der Datenqualität oder Verständlichkeit zu finden. Datenquelle Dies ist ein berechnetes Attribut. Die Logik ist innerhalb des Process-Mining-Tools oder während der Datentransformation definiert, um wiederholte Aktivitäten innerhalb desselben Case zu erkennen. Beispiele JaNein | |||
| Kundentyp CustomerType | Kategorisierung des Kunden, z. B. Einzelperson oder Unternehmen. | ||
| Beschreibung Dieses Attribut klassifiziert den Antragsteller in verschiedene Kategorien, zum Beispiel eine Einzelperson gegenüber einer Unternehmenseinheit. Der KYC-Prozess unterscheidet sich oft erheblich zwischen diesen Typn, wobei das Corporate Onboarding wesentlich komplexer ist. Die Verwendung des Customer Typ als Dimension ermöglicht eine klare Trennung und den Vergleich dieser unterschiedlichen Prozesse innerhalb desselben Datensatzes. Analysten können die Prozessablauf filtern, um nur 'Corporate' Kunden anzuzeigen, um deren einzigartige Herausforderungen, Engpässe und Durchlaufzeiten zu verstehen, ohne dass die Daten durch den viel einfacheren 'Individual' Kundenprozess verzerrt werden. Bedeutung Ermöglicht die Analyse nach Kundenkategorien, da diese oft unterschiedliche Prozessflüsse und Komplexitäten aufweisen. Datenquelle Dies ist ein wesentliches Attribut, das auf Case- oder Kundenebene innerhalb von ACTICO gespeichert ist. Beispiele PrivatpersonUnternehmenKleinunternehmen | |||
| Land Country | Das Wohnsitzland des Kunden, der den Antrag bearbeitet.as Onboarding beantragt. | ||
| Beschreibung Dieses Attribut spezifiziert das Land des Kunden, was einen erheblichen Einfluss auf den KYC-Prozess haben kann. Unterschiedliche Gerichtsbarkeiten haben unterschiedliche regulatorische Anforderungen, die zusätzliche oder alternative Prozessschritte auslösen können. Die Analyse des Prozesses nach Ländern ermöglicht einen Leistungsvergleich über verschiedene Regionen hinweg. Sie kann helfen zu identifizieren, ob bestimmte Länder konsistent längere Durchlaufzeiten oder höhere Ablehnungsraten aufweisen, was potenziell auf regulatorische Reibung oder spezifische Markt-Herausforderungen hindeuten könnte. Diese geografische Sicht ist wichtig für globale Organisationen, die Prozesse standardisieren möchten, während sie lokale Compliance-Anforderungen respektieren. Bedeutung Bietet eine geografische Dimension für die Analyse, die hilft, Prozessvarianten und Leistungsunterschiede in verschiedenen regulatorischen Gerichtsbarkeiten zu verstehen. Datenquelle Dies ist eine zentrale KundenHinweisrmation, die auf Case- oder Kundenebene innerhalb des ACTICO-Systems gespeichert ist. Beispiele USADEUGBRSGP | |||
| SLA-Status SlaState | Ein berechneter Status, der angibt, ob der Case die SLA-Vorgaben erfüllt, verletzt hat oder Gefahr läuft, diese zu verletzen. | ||
| Beschreibung Dieses Attribut bietet eine kategoriale Bewertung der Leistung eines Case im Vergleich zu seinem Service Level Agreement. Es wird abgeleitet, indem die Abschlusszeit des Case (oder den Antrag bearbeitet.ie aktuelle Zeit für offene Fälle) mit dem 'SlaTargetDate' verglichen wird. Dieses Attribut vereinfacht das SLA-Reporting, indem es Datumsvergleiche in einen leicht verständlichen Status umwandelt. Dashboards können dies für klare Visualisierungen wie Tortendiagramme oder Messgeräte einsetzen, die den Prozentsatz der Fälle zeigen, die 'Erfüllt' versus 'Verletzt' sind. Es ist ein Schlüsselelement für das 'Onboarding SLA Leistungsfähigkeit' Dashboard und unterstützt direkt den KPI 'Onboarding SLA-Einhaltung Rate'. Bedeutung Bietet einen klaren, kategorialen Status der SLA-Compliance für jeden Case, was die Berichterstattung vereinfacht und eine einfache Visualisierung der Leistung im Vergleich zu den Zielen ermöglicht. Datenquelle Dies ist ein berechnetes Attribut, abgeleitet aus Geschäftslogik, das den Case-Abschluss-Zeitstempel mit dem 'SlaTargetDate' vergleicht. Beispiele ErfülltVerletztRisikobehaftet | |||
KYC-Onboarding-Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Antrag abgelehnt | Stellt die endgültige Entscheidung dar, den Kundenantrag abzulehnen und den Onboarding-Prozess zu beenden. Dies ist ein kritischer Endzustand, der über eine finale Statusänderung im AntragsDatensatz erfasst wird. | ||
| Bedeutung Dies ist das primäre End-Event bei einem Fehlschlag. Die Analyse von Fälle, die mit dieser Aktivität enden, ist maßgeblich, um Ablehnungsraten, Gründe für den Fehlschlag und die Verbesserung des gesamten Prozessertrags zu verstehen. Datenquelle Wird aus dem finalen Statusfeld abgeleitet. Suchen Sie nach Endzuständen wie „Abgelehnt“ oder „Geschlossen – Abgelehnt“. Erfassen Der finale Status des Case wird in den Case-StammDaten auf 'Abgelehnt' aktualisiert. Ereignistyp inferred | |||
| Antrag eingereicht | Diese Aktivität markiert den Beginn des KYC-Onboarding-Prozesses, wenn ein neuer Kundenantrag formell vom ACTICO-System empfangen wird. Sie wird als explizites Event erfasst, in der Regel mit einem präzisen Zeitstempel bei der Erstellung eines neuen Case oder AntragsDatensatzes protokolliert. | ||
| Bedeutung Als primäres Startereignis ist diese Aktivität essenziell für die Berechnung der Onboarding-Durchlaufzeit und des Antragsvolumens. Sie bildet den Basis-Zeitstempel für alle weiteren Leistungsfähigkeit-Messungen. Datenquelle Dies ist in der Regel ein expliziter Eintrag in einem Anwendungs- oder Case-Erstellungs-Log innerhalb von ACTICO. Suchen Sie nach Tabellen, die mit Antragsereignissen oder den Antrag bearbeitet.em Erstellungs-Zeitstempel des primären Case-Datensatzes verknüpft. Erfassen Ereignis bei Erstellung einer neuen Antrags-Instanz. Ereignistyp explicit | |||
| Application Approved | Diese Aktivität repräsentiert die finale Geschäftsentscheidung, den Kundenantrag für das Onboarding zu genehmigen. Sie ist ein Schlüsselmeilenstein, in der Regel als eine eindeutige und finale Statusänderung im Lebenszyklus des Antrags erfasst. | ||
| Bedeutung Dieser Meilenstein ist ein Vorläufer der Kontoerstellung und signalisiert ein erfolgreiches Ergebnis. Die Analyse der Zeit bis zum Erreichen dieses Punktes ist maßgeblich, um die Dauer des 'Happy Path' zu verstehen. Datenquelle Wird aus dem Feld für den finalen Status abgeleitet. Suchen Sie nach Werten wie „Genehmigt“, „Prüfung abgeschlossen“ oder ähnlichen Endzuständen. Erfassen Der finale Status des Case wird in den Case-StammDaten auf 'Genehmigt' aktualisiert. Ereignistyp inferred | |||
| Compliance-Prüfung abgeschlossen | Markiert das Ende der manuellen Prüfung mit einer Entscheidung. Abgeleitet aus dem Statuswechsel von „Wartet auf Compliance-Prüfung“ zum Folgezustand (z. B. „Compliance genehmigt“). | ||
| Bedeutung Dies ist das abschließende Event für die Compliance-Prüfungsphase. Es ist wesentlich für die Berechnung der gesamten Dauer der Compliance-Prüfung und die Analyse des Team-Durchsatzes. Datenquelle Abgeleitet aus der Status-Historie. Gesucht wird der Zeitstempel, an dem der Case den Status „In Compliance-Prüfung“ verlässt. Erfassen Abgeleitet aus dem Wechsel des Case-Status von „Wartet auf Compliance“ zu „Compliance genehmigt“. Ereignistyp inferred | |||
| Compliance-Prüfung initiiert | Markiert den Start der manuellen Compliance-Prüfung, oft bei High-Risk-Fällen. Dies wird meist aus dem Status „Wartet auf Compliance-Prüfung“ oder den Antrag bearbeitet.er Zuweisung an einen Compliance-Officer abgeleitet. | ||
| Bedeutung Diese Aktivität ist der Startpunkt zur Messung des Compliance-Engpässe. Die verstrichene Zeit bis zur 'Compliance-Prüfung abgeschlossen' ist ein kritischer KPI zur Identifizierung von Verzögerungen in dieser wichtigen Phase. Datenquelle Wird aus der Historie oder den Antrag bearbeitet.em Audit-Trail abgeleitet. Achten Sie auf den Zeitstempel beim Wechsel zu „In Compliance-Prüfung“. Erfassen Abgeleitet aus dem Statuswechsel auf „Wartet auf Compliance“ oder den Antrag bearbeitet.er Zuweisung an das Compliance-Team. Ereignistyp inferred | |||
| Customer Onboarding Completed | Dies ist die finale Aktivität im Prozess, die signalisiert, dass der Kunde vollständig onboarded ist und der Antrags-Case abgeschlossen wurde. Dies wird aus einem finalen, terminierenden Status wie 'Onboarded' oder 'Geschlossen – Genehmigt' abgeleitet, der auf den Case angewendet wird. | ||
| Bedeutung Als primäres Erfolgsereignis am Ende ist diese Aktivität wichtig für die Berechnung der End-to-End-Durchlaufzeit. Sie liefert den finalen Zeitstempel für die Happy-Path-Analyse. Datenquelle Abgeleitet aus dem finalen Statusfeld des Antrags. Gesucht wird der Zeitstempel beim Erreichen eines erfolgreichen Endzustands. Erfassen Abgeleitet aus einem finalen Case-Status-Update auf „Abgeschlossen“ oder „Geschlossen“. Ereignistyp inferred | |||
| KundenDokumente hochgeladen | Diese Aktivität tritt auf, wenn der Kunde die erforderlichen Identifikations- und unterstützenden Dokumente über ein Portal oder einen anderen Kanal bereitstellt, der in ACTICO integriert ist. Jeder Dokumenten-Upload wird in der Regel als ein eigenständiges, explizites Event im Dokumentenmanagement oder Case Log des Systems erfasst. | ||
| Bedeutung Dies markiert einen wichtigen kundenabhängigen Meilenstein. Die Verfolgung dieses Ereignisse ist maßgeblich für die Messung der Kundenreaktionszeiten und die Analyse der Dauer der nachfolgenden Dokumentenprüfungsphase. Datenquelle Suchen Sie nach Logs zum Dokumentenhandling. Diese liegen oft in speziellen Tabellen für das Dokumenten- oder Nachweismanagement in der ACTICO-Datenbank. Erfassen Vom System protokolliertes Ereignis, wenn ein Dokument an den Case angehängt wird. Ereignistyp explicit | |||
| Risikobewertung durchgeführt | Diese Aktivität repräsentiert die Ausführung der Decisioning Engine von ACTICO zur Berechnung eines Risiko-Werts oder einer Einstufung für den Kundenantrag. Als Kernfunktion des Systems wird dies als explizites Event erfasst, wenn der Regelsatz zur Risikobewertung ausgeführt wird. | ||
| Bedeutung Die Risikobewertung ist ein zentraler Entscheidungspunkt, der oft den nachfolgenden Prozesspfad bestimmt. Die Analyse dieser Aktivität hilft zu verstehen, wie Risikolevel Prozessvarianten und Zeitpläne beeinflussen. Datenquelle Dies ist ein Kern-Event innerhalb von ACTICO und sollte in den Entscheidungs- oder Ausführungs-Logs aufgezeichnet werden. Diese Logs enthalten in der Regel die Case-ID, die ausgeführten Regeln und den resultierenden Risiko-Wert. Erfassen Vom ACTICO Decision Engine protokolliertes Ereignis nach Abschluss des Risiko-Scorings. Ereignistyp explicit | |||
| Account Created | Nach der Genehmigung markiert dieser Schritt die technische Kontoeröffnung im Kernbanksystem. Oft ist dies ein explizites Event in ACTICO nach Bestätigung durch das Folgesystem. | ||
| Bedeutung Diese Aktivität bestätigt, dass der Prozess zu einem greifbaren Geschäftsergebnis geführt hat. Die Zeit von 'Antrag genehmigt' bis 'Konto erstellt' kann Integrationsverzögerungen oder Ineffizienzen in den finalen Provisionierungsschritten aufzeigen. Datenquelle Diese Informationen wären wahrscheinlich in Integrations- oder Systeminterfaces-Logs innerhalb von ACTICO zu finden, die das Ergebnis von Aufrufen externer Systeme für die Kontoprovisionierung aufzeichnen. Erfassen Ereignis bei erfolgreicher API-Antwort des Kernbanksystems. Ereignistyp explicit | |||
| Dokumentenprüfung abgeschlossen | Diese Aktivität signalisiert, dass ein Agent die vom Kunden eingereichten Dokumente geprüft hat. Sie wird in der Regel aus einer Statusänderung des Dokuments oder den Antrag bearbeitet.es gesamten Case abgeleitet, wie z. B. 'Dokumente verifiziert' oder 'Prüfung abgeschlossen'. | ||
| Bedeutung Dies ist ein Schlüsselmeilenstein zur Messung der Effizienz des Dokumentenbearbeitungsprozesses. Die Zeit zwischen 'KundenDokumente hochgeladen' und dieser Aktivität ist ein kritischer KPI zur Identifizierung manueller Bearbeitungsverzögerungen. Datenquelle Wird aus den Status-Historien des Fälle oder einzelner Dokumente abgeleitet. Ein Wechsel von „Wartet auf Prüfung“ zu „Genehmigt“ markiert diesen Schritt. Erfassen Abgeleitet aus einer Änderung des Dokumentenstatus zu „Verifiziert“ oder „Geprüft“. Ereignistyp inferred | |||
| Erste Antragsprüfung | Stellt die erste Überprüfung des eingereichten Antrags dar, entweder den Antrag bearbeitet.urch eine automatisierte Regel oder einen menschlichen Agenten, um die Vollständigkeit und grundlegende Eignung zu prüfen. Diese Aktivität wird oft aus einer Statusänderung des Antrags abgeleitet, z. B. von 'Eingereicht' zu 'In Überprüfung'. | ||
| Bedeutung Die Analyse der Zeit bis zum Abschluss dieser ersten Prüfung hilft, Verzögerungen im frühen Prozessstadium zu finden. Zudem zeigt sie, wie viele Anträge die erste Hürde problemlos nehmen. Datenquelle Wird aus Statustabellen oder Audit-Logs abgeleitet. Verglichen wird der Zeitstempel beim Wechsel von „Neu/Eingereicht“ zu „In Prüfung“. Erfassen Erkennt den Statuswechsel von „Eingereicht“ zu „In Prüfung“ im Case-Verlauf. Ereignistyp inferred | |||
| Hintergrundprüfungen eingeleitet | Dies repräsentiert den Punkt, an dem automatisierte oder manuelle Hintergrundprüfungen, wie z. B. AML- oder Bonitätsprüfungen, gestartet werden. Dies wird oft als explizites Event protokolliert, wenn das System diese Prüfungen auslöst, die externe Dienstleister involvieren können. | ||
| Bedeutung Der Start der Hintergrundprüfung ist ein Meilenstein in der Due Diligence. Die Nachverfolgung hilft, Abhängigkeiten und Antwortzeiten externer Datenanbieter zu verstehen. Datenquelle Suchen Sie nach Einträgen in System-Logs oder im Audit-Trail, die den Start von Hintergrundprüfungen anzeigen (meist verknüpft mit der Case-ID). Erfassen Ereignis beim Start der Hintergrundprüfung durch die Workflow-Engine. Ereignistyp explicit | |||
| Identitätsverifizierung durchgeführt | Stellt eine automatisierte oder manuelle Überprüfung zur Validierung der Kundenidentität anhand externer oder interner Datenquellen dar. Dies wird oft als explizites Event erfasst, wenn ein API-Call an einen Drittanbieter-Verifizierungsdienst erfolgt und eine Antwort empfangen wird. | ||
| Bedeutung Diese Aktivität ist ein kritischer Compliance-Schritt. Die Analyse ihrer Dauer und Resultate hilft, Abhängigkeiten von externen Diensten und potenzielle Engpässe im Verifizierungsprozess zu identifizieren. Datenquelle Diese Informationen sind üblicherweise in Integrations-Logs oder spezifischen Event-Tabellen, die die Resultate automatisierter Prüfungen und Drittanbieter-Service-Calls, die mit dem Anwendungs-Case verknüpft sind, aufzeichnen. Erfassen Ereignis aus einem Integrationsaufruf an einen externen Identitätsprüfungsdienst. Ereignistyp explicit | |||
| Zusätzliche Informationen angefordert | Stellt ein Event dar, bei dem ein Prüfer, oft im Bereich Compliance oder Underwriting, weitere Informationen oder Dokumente vom Kunden anfordert. Diese Aktion wird in der Regel explizit erfasst, da sie oft das Senden einer Benachrichtigung an den Kunden und das Pausieren des Case umfasst. | ||
| Bedeutung Diese Aktivität ist ein zentrale Faktor für Rework und erhöhte Durchlaufzeiten. Die Verfolgung ihrer Häufigkeit und Auswirkungen ist maßgeblich, um Bereiche zu identifizieren, in denen die initiale Datenerfassung verbessert werden kann. Datenquelle Dies ist wahrscheinlich ein explizites Event, das in der Case-Historie oder im Kommunikations-Log aufgezeichnet wird. Suchen Sie nach Ereignisse wie 'RFI Gesendet' (Request for Information) oder einer spezifischen Statusänderung wie 'Wartende KundenHinweisrmation'. Erfassen Ein explizites, benutzergesteuertes Ereignis (z. B. „RFI senden“) wird im Audit-Trail des Fälle protokolliert. Ereignistyp explicit | |||
Extraktionsanleitungen
Schritte
- Administrativen Zugang erhalten: Melden Sie sich bei der ACTICO-Plattform, z.B. dem Visual Modeler oder einer dedizierten Verwaltungskonsole, an und verwenden Sie AnmeldeHinweisrmationen mit ausreichenden Berechtigungen, um Datenexporte zu konfigurieren und darauf zuzugreifen.
- Exportmodul finden: Navigieren Sie zum Verwaltungs- oder Konfigurationsbereich des Systems. Suchen Sie den Abschnitt, der für Audit-Trails, Logging oder Datenexporte zuständig ist. Dieser kann als 'Audit Export' oder 'Business Object Export' bezeichnet sein.
- Neue ExportKonfiguration erstellen: Starten Sie den Prozess zur Erstellung einer neuen Exportdefinition. Geben Sie einen aussagekräftigen Namen für die Konfiguration an, zum Beispiel 'KYC_Onboarding_ProcessMind_Export'.
- Datenquelle definieren: Geben Sie das primäre Geschäftsobjekt an, das exportiert werden soll, nämlich der
Konfiguration
- Audit-Log-Level: Das systemweite Audit-Log-Level muss auf eine detaillierte Einstellung wie INFO oder FINE gesetzt werden. Ein weniger detailliertes Level wie WARNING oder ERROR erfasst nicht die notwendigen Statusänderungen und Regelausführungen, die für Process Mining erforderlich sind.
- Export-Datenquelle: Die primäre Datenquelle sollte so konfiguriert werden, dass sie das Geschäftsobjekt
Kundenantragverwendet. Gegebenenfalls müssen Sie verknüpfte Objekte wieKundendokumentverbinden oder referenzieren, um alle relevanten Ereignisse zu erfassen. - Datumsbereichsfilter: Verwenden Sie stets einen Datumsbereichsfilter, um die Menge der extrahierten Daten zu steuern. Für die initiale Analyse wird ein Zeitraum von 3 bis 6 Monaten empfohlen. Für den Produktivbetrieb kann dies je nach Geschäftsanforderungen und Systemleistung angepasst werden.
- Event-Mapping-Logik: Die Genauigkeit der Extraktion hängt stark davon ab, wie Ereignisse zugeordnet werden. Statusänderungen (
on="StatusChange") sind üblich zur Ableitung von Geschäftsschritten. Explizite Log-Einträge (on="LogEntry") sind nützlich für technische oder Service-Call-Ereignisse. Regelausführungen (on="RuleExecution") sind ideal zur Erfassung von Entscheidungsschritten. - Ausgabeformat: Wählen Sie CSV als Ausgabeformat für breite Kompatibilität. Stellen Sie sicher, dass die Konfiguration für Trennzeichen und Text-Quoting korrekt eingestellt ist, um Daten-Parsing-Probleme zu vermeiden.
- Voraussetzungen: Diese Methode erfordert administrative Berechtigungen für die ACTICO-Plattform. Ein fundiertes Verständnis des KYC-Geschäftsobjektmodells, einschließlich aller relevanten Statusfelder und Attributnamen, ist für eine präzise Konfiguration unerlässlich.
a Beispielabfrage config
<!-- This is a representative ACTICO export configuration in XML format. -->
<!-- Actual syntax may vary based on your ACTICO version. -->
<AuditExportConfiguration name="KYC_ProcessMind_Export">
<DataSource type="BusinessObject">
<ObjectName>CustomerApplication</ObjectName>
<DateRange from="[Start Date YYYY-MM-DD]" to="[End Date YYYY-MM-DD]"/>
</DataSource>
<OutputFile format="CSV" name="kyc_event_log.csv" delimiter=","/>
<CaseId mapping="customerApplication.id"/>
<Attributes>
<Attribute name="CustomerApplication" mapping="customerApplication.id"/>
<Attribute name="ActivityName" mapping="[generated_activity_name]"/>
<Attribute name="EventTime" mapping="[event_timestamp]"/>
<Attribute name="SourceSystem" value="ACTICO"/>
<Attribute name="LastDataUpdate" value="[CURRENT_TIMESTAMP]"/>
<Attribute name="EndTime" mapping="[event_timestamp]"/>
<Attribute name="InitiatingUser" mapping="event.user"/>
<Attribute name="Department" mapping="event.user.department"/>
<Attribute name="ApplicationStatus" mapping="customerApplication.status"/>
<Attribute name="RejectionReason" mapping="customerApplication.rejectionDetails.reasonCode"/>
<Attribute name="RiskLevel" mapping="customerApplication.risk.level"/>
<Attribute name="SlaTargetDate" mapping="customerApplication.slaDate"/>
</Attributes>
<EventMappings>
<Event on="Create" object="CustomerApplication">
<Set name="[generated_activity_name]" value="Application Submitted"/>
<Set name="[event_timestamp]" mapping="customerApplication.creationDate"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Submitted" to="In Review">
<Set name="[generated_activity_name]" value="Initial Application Review"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="Create" object="CustomerDocument">
<Set name="[generated_activity_name]" value="Customer Documents Uploaded"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
<CaseId mapping="event.relatedObject.customerApplication.id"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="IDV Service Call Completed.*">
<Set name="[generated_activity_name]" value="Identity Verification Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Documents Verified">
<Set name="[generated_activity_name]" value="Document Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Background Check Initiated.*">
<Set name="[generated_activity_name]" value="Background Checks Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="RuleExecution" object="CustomerApplication" ruleSet="KYC Risk Assessment">
<Set name="[generated_activity_name]" value="Risk Assessment Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Compliance Review">
<Set name="[generated_activity_name]" value="Compliance Review Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Customer Information">
<Set name="[generated_activity_name]" value="Additional Information Requested"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Pending Compliance Review" to="Compliance Approved">
<Set name="[generated_activity_name]" value="Compliance Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Approved">
<Set name="[generated_activity_name]" value="Application Approved"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Account successfully created.*">
<Set name="[generated_activity_name]" value="Account Created"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Closed - Approved">
<Set name="[generated_activity_name]" value="Customer Onboarding Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Rejected">
<Set name="[generated_activity_name]" value="Application Rejected"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
</EventMappings>
</AuditExportConfiguration>