Your KYC Customer Onboarding Data Template

The Activity Name describes a single step or milestone in the customer onboarding journey, such as 'Initial Screening Performed' or 'Application Approved'. This sequence of activities forms the basis of the process map.

Analyzing this attribute allows for the visualization of the process flow, identification of common and alternative paths, and measurement of the frequency of each step. It is crucial for understanding what actions are being performed and in what order.

This attribute defines the steps in the process, allowing for the creation of a process map and analysis of process flow and variations.

This information is typically found in Fenergo's workflow or audit log tables, associated with case state transitions or task completions.

The Customer Application is the central identifier that groups all related activities and events for a single customer's KYC onboarding process. It allows for the end-to-end tracking of an application from initial submission to final resolution, whether approved, rejected, or closed.

In process mining, this attribute is fundamental for reconstructing the complete journey of each application. It enables the analysis of process flows, cycle times, variations, and bottlenecks on a per-application basis, providing a clear view of how individual cases are handled.

This is the essential Case ID that connects all related events, making it possible to analyze the end-to-end customer onboarding process.

This is typically the primary key in Fenergo's core case management or client lifecycle management entity.

This attribute records the precise date and time that a specific activity started. It provides the chronological order necessary to reconstruct the process flow and is essential for all time-based analysis.

In process mining, the start time is used to calculate the duration of activities, the waiting time between them, and the overall cycle time of the case. It forms the temporal backbone of the event log and is critical for performance and bottleneck analysis.

This timestamp is critical for ordering events chronologically and calculating all time-based metrics like cycle times and durations.

Located in Fenergo's audit trail, event log, or workflow history tables, often labeled as 'Timestamp', 'StartDate', or 'CreationDate'.

This attribute records the date and time of the most recent data refresh. It provides context for the freshness of the data being analyzed and is important for understanding the timeliness of the insights.

In dashboards and reports, this information is used to inform users about the data's currency. It helps manage expectations about whether the analysis reflects real-time operations or a historical snapshot.

Provides crucial context on data freshness, ensuring users understand how current the process analysis is.

This value is generated and stamped on the dataset during the data extraction and loading (ETL) process.

This attribute identifies the originating system for the event data. For this process, it will consistently be Fenergo, but in blended datasets, it helps differentiate data sources.

Its main use in analysis is to filter data from specific systems or to verify data provenance. It ensures clarity in environments where data from multiple systems might be combined for a holistic process view.

Identifies the data's origin, which is crucial for data governance, validation, and ensuring the analysis is based on the correct source.

This is typically a static value added during the data extraction process to label the origin of the records.

This attribute indicates the disposition of the application at the end of the process or its current state if ongoing. Common values include 'Approved', 'Rejected', or 'In Progress'.

This is a critical dimension for outcome analysis. It allows for filtering and comparing process flows based on their final result, which is essential for the 'Application Rework and Rejection' dashboard and for calculating KPIs like the Application Rejection Rate.

Defines the outcome of a case, enabling powerful analysis to compare paths of approved vs. rejected applications and understand success rates.

This is typically the final status recorded on the case entity in Fenergo's case management system.

This attribute records the precise date and time that a specific activity finished. It complements the start time to define the active duration of a task.

In process mining, the end time is used with the start time to calculate the processing time for each activity. This is essential for identifying which steps in the process consume the most time and for analyzing resource efficiency.

Enables the calculation of activity processing times, which is fundamental for identifying long-running tasks and performance bottlenecks.

Located in Fenergo's audit trail or workflow history tables, often labeled as 'EndDate', 'CompletionDate', or derived from the start time of the subsequent event.

This attribute identifies the specific employee or system user responsible for executing a given task or event. It can be a unique user ID, a name, or a role.

Analyzing by user helps in understanding workload distribution, individual performance, and identifying training needs. It is key for the 'Staff Activity Distribution' dashboard and for drilling down into activities performed by specific individuals or teams.

Tracks which user performed an action, enabling analysis of workload distribution, team performance, and resource allocation.

This information is typically stored in Fenergo's audit logs or task history tables alongside the event details, often as 'UserID', 'UserName', or 'ModifiedBy'.

The Risk Score is a quantitative measure of the potential risk associated with a customer, calculated based on various factors like jurisdiction, industry, and screening results. Fenergo's rules engine typically computes this score.

This attribute allows for correlation between risk levels and process behavior. For example, analysis can reveal if high-risk customers experience longer cycle times or require more manual intervention, which is useful for the 'Risk & Compliance Review Deep Dive' dashboard.

Quantifies customer risk, enabling analysis of how risk levels impact process duration, rework, and outcomes.

This is a key output of Fenergo's Client Risk Assessment module. It is stored on the case or client entity.

The SLA Target Date represents the agreed-upon deadline for completing the entire onboarding process for a customer application. It is a critical benchmark against which actual performance is measured.

This attribute is essential for the 'SLA Compliance Monitoring' dashboard and for calculating the 'SLA Adherence Rate' KPI. It enables proactive management of cases at risk of breaching their SLA and helps prioritize work.

Defines the target completion date, which is crucial for monitoring SLA compliance and prioritizing overdue cases.

This date is often calculated based on application submission date and business rules configured within Fenergo's SLA management module.

This attribute provides the organizational context for the user who performed an activity, such as 'Compliance', 'Onboarding Operations', or 'Sales'. It is often derived from user profile information.

This dimension is crucial for analyzing process handoffs between different departments and identifying cross-functional bottlenecks. It directly supports the 'Staff Activity Distribution' dashboard by allowing aggregation of work at a team or department level.

Allows for analysis of process performance by department, highlighting inter-departmental handoffs, delays, and workload distribution.

This may need to be joined from a separate user or HR master data table using the 'InitiatingUser' ID. Fenergo may also store this as part of the user's profile.

This metric counts the occurrences of the 'Additional Information Requested' activity for each case. A higher count signifies more back-and-forth communication, which can delay the process and lead to a poor customer experience.

This attribute directly supports the 'Cases with Additional Info Requests' KPI. It is used to identify applications with excessive requests, which may point to issues with initial data collection or complex case requirements. Analyzing this helps streamline information gathering.

Quantifies customer friction and process delays caused by incomplete initial information, helping to improve the data collection step.

This is a calculated metric, derived by counting the number of 'Additional Information Requested' events for each 'CustomerApplication' ID.

This attribute identifies the submission source of the application, for example, via an online portal, a physical branch, or through a relationship manager. The source can influence data quality and processing requirements.

This dimension is used in the 'Application Source & Type Efficiency' dashboard to compare the performance of different channels. It helps businesses understand which channels are most efficient and which may require process optimization.

Identifies the source of applications, allowing for analysis of channel efficiency, cost, and customer experience.

This information might be captured in an initial data entry form within Fenergo or passed from an upstream system.

The Case Owner is the individual or group assigned primary responsibility for an onboarding case. This person is typically accountable for its timely and successful completion.

This attribute helps in analyzing workload and performance at the case manager level. It can be used to see if certain case owners have longer cycle times or higher rejection rates, potentially indicating training needs or resource imbalances.

Identifies the accountable person or team for a case, enabling performance analysis of case managers.

This is usually a specific field on the primary case entity in Fenergo, indicating case assignment.

This attribute specifies the country associated with the customer, which often determines the specific regulatory rules and risk factors that apply to the onboarding process.

Analyzing the process by country allows for jurisdictional comparisons of cycle time, risk levels, and process complexity. It helps in understanding how regional differences impact operational performance and ensuring compliance with local regulations.

Allows for segmentation of the process based on geography, which is key for analyzing regulatory impact and regional performance.

This information is part of the core customer data captured during the application process and stored on the client entity in Fenergo.

The Customer ID is the unique reference for the client entity in the master data system. While the application number is the case ID for the process, the Customer ID links the onboarding activity to a specific client.

This attribute allows for analyzing the onboarding history of a single customer, for example, if they have undergone multiple onboarding processes over time. It also enables joining process data with other customer-related data for a more comprehensive business view.

Links the onboarding process to a unique customer entity, allowing for customer-centric analysis and data enrichment.

This ID is stored on the client or legal entity record within Fenergo and associated with the onboarding case.

This attribute segments customers into different categories based on their legal structure or relationship with the financial institution. Different customer types often follow distinct onboarding paths with varying complexity and due diligence requirements.

Analyzing the process by Customer Type helps identify performance differences between segments. It is key for the 'Application Source & Type Efficiency' dashboard to compare cycle times and approval rates, leading to tailored process improvements.

Enables comparison of process performance across different customer segments, which often have varying complexity and SLAs.

This information is typically stored on the customer or client entity within Fenergo and linked to the application case.

This attribute differentiates between tasks executed automatically by the system (e.g., initial screening, system checks) and those performed manually by a user. This is often determined by checking if the executing user is a system or service account.

Analyzing this flag is crucial for understanding the level of automation in the process. It helps quantify the impact of automation on efficiency, cost, and speed, and identifies opportunities for further automation.

Distinguishes between human and system activities, which is vital for automation analysis and understanding resource costs.

This is typically derived based on the 'InitiatingUser' field. A list of known system user IDs is used to set this flag to true.

This attribute identifies activities that represent a step backward in the process, such as returning to 'Document Review' after a 'Compliance Review' has already started, or any occurrence of 'Additional Information Requested'.

Identifying rework is critical for understanding process inefficiency and friction. This flag allows for the direct calculation of the 'Rework Loop Rate' KPI and helps visualize and quantify the impact of wasteful, repetitive steps in the process flow.

Highlights inefficient rework loops in the process, helping to quantify waste and identify areas for improvement to increase first-time-right rates.

This flag is derived using process mining techniques that analyze the sequence of activities. For example, if 'Activity A' is followed by 'Activity B' and then 'Activity A' appears again for the same case, the second 'Activity A' is rework.

This attribute is a binary indicator of SLA performance for a completed case. It is set to 'true' if the final, closing activity's timestamp is on or before the 'SlaTargetDate', and 'false' otherwise.

This calculated field simplifies SLA monitoring and reporting. It allows for easy aggregation to calculate the overall 'SLA Adherence Rate' KPI and for filtering to analyze the process characteristics of compliant versus non-compliant cases.

Directly measures SLA performance, enabling easy calculation of the SLA Adherence Rate KPI and filtering for non-compliant cases.

This is derived by comparing the timestamp of the final case activity (e.g., 'Application Approved', 'Application Rejected') against the 'SlaTargetDate'.

Processing Time, also known as active time, is the calculated duration between the start and end timestamp of a single activity. It represents the time a resource was actively engaged in a task.

This metric is fundamental for performance analysis. It is used in bottleneck analysis dashboards to pinpoint which specific activities are the most time-consuming, helping to focus improvement efforts where they will have the most impact.

This calculated metric measures the active work time for each activity, which is crucial for identifying performance bottlenecks.

Calculated as the difference between 'EventEndTime' and 'EventStartTime' (EndTime - StartTime).

When an application's final status is 'Rejected', this attribute provides the specific reason. Examples include 'Failed Background Check', 'Incomplete Documentation', or 'High Risk Profile'.

This is a vital attribute for root cause analysis of failed applications. It directly supports the 'Application Rework and Rejection' dashboard by categorizing failures, helping the business to identify common problems and implement corrective actions to improve the first-time pass rate.

Provides critical insight into why applications fail, enabling root cause analysis to reduce rejection rates.

Typically found in a reason code or notes field associated with the final rejection status in Fenergo's case workflow.