Your KYC Customer Onboarding Data Template

The Activity Name describes a step in the KYC onboarding workflow, such as 'Application Submitted', 'Document Review Performed', or 'Application Approved'. Each activity represents a distinct action or milestone in the process.

This attribute is critical for constructing the process map, which visually represents the flow of activities. It allows for the analysis of process variants, bottlenecks between specific steps, and the frequency of rework loops. Analyzing activities is key to understanding what is happening in the process.

This attribute forms the backbone of the process map, allowing you to visualize and analyze the sequence of events in the customer onboarding journey.

Typically found in an event log or audit trail table within LexisNexis Risk Solutions that tracks process steps.

The Customer Application is the central identifier that links all related activities and data points for a single customer's onboarding journey. It starts when an application is submitted and follows the case until it is either completed or rejected.

In process mining, this attribute is essential for grouping all events into a cohesive case, allowing for end-to-end analysis of the onboarding lifecycle. It enables the reconstruction of the entire process flow for each applicant, which is fundamental for calculating cycle times, analyzing process variants, and tracking an application's status over time.

This is the fundamental Case ID. Without it, you cannot trace the end-to-end journey of a customer application, making process analysis impossible.

This is the primary case identifier within the LexisNexis Risk Solutions case management module.

This timestamp marks the beginning of an activity, providing the chronological order for all events within a case. It is the foundation for all time-based analysis in process mining.

Using the Event Timestamp, it is possible to calculate the duration of activities, the waiting time between them, and the total end-to-end cycle time of the onboarding process. This data is essential for identifying bottlenecks, monitoring SLA adherence, and understanding process efficiency.

This timestamp is essential for ordering events chronologically and calculating all time-based metrics, such as cycle times and bottlenecks.

Located in the event log or audit trail tables alongside the Activity Name.

This attribute reflects the overall status of the case at a given point in time or its final outcome. Common statuses include 'In Progress', 'Approved', 'Rejected', or 'Pending Information'.

Application Status is vital for tracking the outcomes of the onboarding process. It is used in the 'Application Rejection Reasons & Stages' and 'Daily Throughput and Application Status' dashboards to monitor success rates and operational flow. Analyzing how status changes over time provides insight into the case lifecycle.

Tracks the outcome of each application, which is essential for calculating key KPIs like the Application Rejection Rate and monitoring throughput.

Consult LexisNexis Risk Solutions documentation or system administrator. This is typically a key field on the main case or application object.

This attribute identifies the specific individual who executed a task, such as a compliance officer performing a document review. It helps in analyzing workload distribution and individual performance.

In analysis, Assigned User is key to the 'Resource Allocation and Workload' dashboard. It allows for filtering the process map by user, comparing performance across team members, and identifying opportunities for training or workload rebalancing. It can also help pinpoint bottlenecks caused by specific user groups.

This attribute is crucial for analyzing resource performance, workload distribution, and identifying opportunities for automation or resource optimization.

Consult LexisNexis Risk Solutions documentation or system administrator. Usually found in audit trails or task management tables.

The Department attribute specifies the functional group responsible for an activity, such as 'Compliance', 'Onboarding Operations', or 'Fraud Prevention'.

This attribute is used to analyze the process from a departmental view, enabling analysis of handoffs between different teams. It is a primary dimension in the 'Resource Allocation and Workload' dashboard and helps identify cross-functional inefficiencies or delays in communication between departments.

Allows for analysis of process handoffs and performance by functional area, helping to identify cross-departmental bottlenecks.

Consult LexisNexis Risk Solutions documentation or system administrator. May need to be joined from a user or HR master data table.

This timestamp marks the completion of an activity. The difference between the End Time and the Start Time for an event represents its processing time.

End Time is crucial for accurately calculating how long each step takes, which is a primary input for the 'Activity Processing & Waiting Times' dashboard. It helps differentiate between the time a resource actively worked on a task versus the time the case was waiting for the next step to begin.

Enables the precise calculation of activity processing time, which is essential for identifying inefficient steps and analyzing resource workload.

Consult LexisNexis Risk Solutions documentation or system administrator. Often available in event logs that record both start and end events.

LexisNexis Risk Solutions specializes in assessing risk. This attribute represents the output of that assessment, categorizing each application based on its potential risk profile. The risk level often dictates the required intensity and duration of the due diligence process.

This attribute is the core dimension for the 'Risk Level vs. Onboarding Duration' dashboard. Analyzing the process by risk level can reveal if high-risk applications take significantly longer, as expected, or if low-risk applications are being unnecessarily delayed. It helps in validating and refining risk-based onboarding strategies.

Crucial for risk-based analysis, helping to understand how customer risk profiles impact process complexity, duration, and pathways.

Consult LexisNexis Risk Solutions documentation or system administrator. This is a core output of the risk assessment modules.

The SLA Target Date defines the service level agreement for completing an application. This date is often determined based on factors like the application type, customer segment, or jurisdiction.

This attribute is essential for the 'SLA Target Adherence Monitoring' dashboard and the 'SLA Adherence Rate' KPI. By comparing the actual completion date with the SLA Target Date, organizations can measure their performance against commitments, identify cases at risk of breaching SLAs, and investigate the root causes of delays.

Enables performance measurement against service level agreements, highlighting process inefficiencies that cause SLA breaches.

Consult LexisNexis Risk Solutions documentation or system administrator. This may be stored on the case or calculated based on business rules.

This attribute categorizes applications based on the type of entity being onboarded. Different application types often follow distinct process paths and have different risk profiles and SLA targets.

Analyzing the process by Application Type allows for segmentation of the data to compare the efficiency and complexity of onboarding different kinds of customers. It's a common filter used across most dashboards to provide a more granular view of performance.

Allows for powerful segmentation of the process, revealing how different types of applications are handled and where specific bottlenecks for each type exist.

Consult LexisNexis Risk Solutions documentation or system administrator. This is typically a core field on the application or case object.

The Channel attribute identifies the submission source of the application. The channel can influence data quality, customer behavior, and the types of issues encountered during onboarding.

This attribute is used to compare process performance across different channels. For instance, the 'Onboarding Funnel Conversion Rates' dashboard can be filtered by channel to see if mobile applicants drop off at a higher rate than web applicants, informing channel-specific process improvements.

Helps analyze process performance by submission channel, identifying variations that can inform channel strategy and user experience improvements.

Consult LexisNexis Risk Solutions documentation or system administrator. This information is typically captured at the start of the application process.

While 'AssignedUser' captures the user for any activity, this attribute specifically identifies the compliance specialist involved in critical review steps. This allows for a more focused analysis of the compliance function.

This attribute is key for the 'Compliance Review Duration and Backlog' dashboard. It helps analyze the workload and performance of the compliance team, identifying if specific reviewers are bottlenecks or if the overall team is under-resourced.

Provides focused insight into the compliance function, allowing for detailed analysis of reviewer workload and performance in this critical, often-delayed process stage.

Consult LexisNexis Risk Solutions documentation or system administrator. This can be derived by filtering 'AssignedUser' for compliance-related activities.

This attribute specifies the customer's country, which is a critical factor in KYC due to varying international regulations and risk levels associated with different jurisdictions.

Analyzing the process by Customer Country can reveal significant differences in cycle times and process complexity. For example, applications from high-risk jurisdictions may require additional compliance checks, leading to longer durations. This analysis helps in resource planning and setting realistic SLAs for different regions.

Enables jurisdictional analysis, which is crucial for understanding how regional regulations and risk factors impact process performance.

Consult LexisNexis Risk Solutions documentation or system administrator. This is a standard field in customer master data.

Cycle Time measures the total time elapsed from the very first event (e.g., 'Application Submitted') to the very last event (e.g., 'Customer Onboarding Completed' or 'Application Rejected') for a single case.

This is a primary KPI for measuring overall process health and is visualized in the 'Onboarding End-to-End Cycle Time' dashboard. Tracking average cycle time allows organizations to monitor the impact of process improvements and identify how different factors, like risk level or application type, affect the overall customer experience.

This is a key performance indicator that measures the total time-to-value for the customer, directly impacting customer satisfaction and operational efficiency.

This is a calculated metric, derived by subtracting the timestamp of the first event from the timestamp of the last event for each case.

This boolean attribute distinguishes between tasks executed by system automation (e.g., an initial screening check) and those requiring human intervention (e.g., a manual document review).

'Is Automated' is used to calculate the 'Manual Activity Proportion' KPI and to analyze the effectiveness of automation initiatives. In the process map, it can highlight the interface between automated and manual steps, helping to identify opportunities for further automation to reduce costs and processing times.

Distinguishes between manual and automated tasks, which is key for identifying automation opportunities and measuring their impact.

Consult LexisNexis Risk Solutions documentation or system administrator. This might be a flag in the event log or inferred based on the 'AssignedUser' (e.g., a 'system' user).

This boolean flag is set to true when an activity is repeated within the same case, such as a 'Document Review Performed' occurring a second time after 'Additional Information Requested'. It signifies that the process has moved backward.

'Is Rework' is crucial for the 'Rework and Repetition Analysis' dashboard and the 'Rework Loop Percentage' KPI. It allows for the quantification of wasted effort and helps identify the root causes of rework, such as unclear instructions or poor data quality, enabling targeted process improvements.

Directly quantifies inefficiency and wasted effort in the process, highlighting activities that are frequently repeated and driving up costs and cycle times.

This is a calculated attribute, typically derived within the process mining tool by detecting repeated sequences of activities within a case.

This attribute provides a timestamp for when the dataset was last updated. It is typically applied to the entire dataset during the data extraction and loading process.

This information is critical for dashboard users to understand the freshness of the data they are analyzing. It ensures that decisions are based on data that is as current as required and helps manage expectations about the timeliness of the insights.

Provides crucial context about data freshness, ensuring that analyses are relevant and that decisions are not based on outdated information.

This is usually generated and stamped onto the dataset during the ETL (Extract, Transform, Load) process.

Processing Time is the duration calculated from an activity's start and end timestamps (EndTime - StartTime). It represents the time a resource was actively engaged with a task, as opposed to waiting time.

This calculated metric is a cornerstone of performance analysis and directly feeds the 'Activity Processing & Waiting Times' dashboard. It helps pinpoint which specific activities are the most time-consuming, indicating targets for process improvement, training, or automation. For example, it helps calculate the 'Avg. Doc. Review Processing Time' KPI.

Measures the active work time for activities, helping to distinguish between value-adding time and wasteful waiting time to identify true bottlenecks.

This is a calculated field, derived from the difference between the 'EndTime' and 'EventTimestamp' (StartTime) attributes.

When an application's final status is 'Rejected', this attribute provides the specific reason. Examples include 'Failed Identity Verification', 'Sanctions Match', or 'Incomplete Documentation'.

This data is the primary input for the 'Application Rejection Reasons & Stages' dashboard. Analyzing rejection reasons helps identify common failure points in the process, which can inform improvements to application guidelines, customer communication, or internal review criteria. Understanding why applications are rejected is key to improving the overall approval rate.

Provides direct insight into why onboarding fails, enabling targeted improvements to increase the application approval rate.

Consult LexisNexis Risk Solutions documentation or system administrator. Often found in a field that is populated when the Application Status is set to 'Rejected'.

This attribute categorizes each completed case based on its adherence to the 'SlaTargetDate'. Typical values are 'Met' or 'Breached'.

This calculated field is the foundation of the 'SLA Target Adherence Monitoring' dashboard and the 'SLA Adherence Rate' KPI. It provides a clear, high-level view of performance against service commitments and allows for drill-down analysis to understand the common characteristics of cases that breach their SLAs.

Provides a clear, binary outcome for SLA performance, making it easy to track, report, and analyze compliance with service level targets.

This is a calculated attribute, derived by comparing the timestamp of the final activity to the 'SlaTargetDate' for each case.

This attribute identifies the source system that generated the event data, such as LexisNexis Risk Solutions or an integrated third-party tool. In complex environments, data for a single process may come from multiple systems.

Understanding the source system is useful for data validation, troubleshooting, and analyzing process variations that may be specific to a particular system. It helps ensure data integrity and provides context about how and where an activity was recorded.

Identifies the origin of the data, which is crucial for data governance, validation, and understanding process execution across different IT systems.

This information may be stored as a static value or in a specific field within the data export or API response.