Your KYC Customer Onboarding Data Template

The Activity Name describes a distinct step or milestone in the customer onboarding journey, such as 'Application Submitted', 'Compliance Review Initiated', or 'Application Approved'. Each activity represents a specific action taken by a user or a system that moves the application forward in the process.

This attribute is fundamental for visualizing the process map, which forms the core of process mining. By analyzing the sequence and frequency of different activities, analysts can understand the actual process flow, identify common pathways, discover process deviations, and pinpoint areas of rework or repetition. The clarity and consistency of activity names are crucial for building a meaningful and understandable process model.

It defines the steps of the process, allowing for the visualization and analysis of the process flow, bottlenecks, and variations.

Found in event logs, audit trails, or transaction tables that record business process steps.

The Customer Application ID is a unique key assigned to each new customer onboarding request from the moment it is initiated until it is completed or terminated. This identifier acts as the central thread that connects all individual activities, events, and data points related to a single onboarding journey, making it the most critical attribute for process mining.

In analysis, this ID allows the reconstruction of the end-to-end process for each customer. It enables tracking of the application's progress, calculation of its total cycle time, and comparison of its path against others. All process variants, bottlenecks, and performance metrics are analyzed on a per-application basis, which is only possible by correctly identifying and using this attribute as the case ID.

It is essential for grouping all related events into a single end-to-end process, forming the basis of all process mining analysis.

Typically found in the header or primary table of the customer application or case management system.

The Event Start Time is the precise date and time that marks the beginning of an activity. It is one of the three essential pillars of process mining, alongside the Case ID and Activity Name. This timestamped data allows for the chronological ordering of events within each case, which is necessary to reconstruct the process flow as it happened in reality.

This attribute is the basis for all time-related analysis. It is used to calculate the duration of activities (when an end time is available), the waiting time between activities (handoff time), and the total cycle time of the entire onboarding process. Analyzing these durations helps identify bottlenecks, measure SLA adherence, and monitor overall process performance.

It provides the chronological order of events, which is essential for discovering the process model and calculating all time-based performance metrics.

Located in event logs, application audit trails, or transaction tables, often labeled as 'Timestamp', 'Creation Date', or 'Start Time'.

This attribute records the date and time of the most recent data extraction or refresh. It is not part of the business process itself but is crucial metadata for data validation and governance. It provides transparency about the freshness of the data being analyzed.

In process analysis, knowing the last data update time is essential for understanding the timeliness of the insights generated. It helps users trust the data by confirming how current it is and prevents misinterpretations based on outdated information. For ongoing monitoring, this attribute can be used to set up alerts if data refreshes are delayed or fail, ensuring the continuous reliability of the process mining dashboards.

It ensures data transparency by indicating the freshness of the dataset, which is critical for the relevance and accuracy of the analysis.

Generated during the data extraction, transformation, and loading (ETL) process; often found in the metadata of the dataset.

The Source System attribute specifies the application or platform that generated the data for a given activity. In complex environments, the KYC process may span multiple systems, such as a CRM for application submission, a dedicated KYC platform for risk assessment, and a core banking system for account creation.

Analyzing the process by source system helps understand the technological landscape and its impact on the process. It can highlight integration issues, data delays between systems, or discrepancies in how different systems record information. This view is valuable for IT and process improvement teams looking to streamline the system architecture supporting the onboarding journey.

It provides context about where each process step occurs, helping to identify cross-system inefficiencies and data integration challenges.

Often included in data extracts or event logs, especially in environments with multiple integrated systems.

The Application Status indicates the ultimate disposition of an application, such as 'Approved', 'Rejected', or 'Withdrawn'. It represents the business outcome of the process and is a critical dimension for performance measurement.

This attribute is essential for outcome-based analysis. It allows for the comparison of process paths that lead to successful outcomes versus those that result in rejections. Analysts can use this to identify process patterns associated with high rejection rates, calculate KPIs like the 'Application Rejection Rate', and build an 'Onboarding Funnel Analysis' to see where applicants drop off. Understanding why applications fail is the first step toward improving the process to increase the success rate.

It defines the business outcome of each case, enabling analysis of why applications are rejected and how to improve the approval rate.

Typically found in the main case or application table, indicating the final state of the record.

The Customer Type classifies the applicant into distinct categories, for example, 'Individual', 'Corporate', 'Trust', or 'Non-Profit'. Different customer types often have vastly different onboarding requirements and process complexities.

This is a key segmentation attribute for analysis. By filtering the process map and KPIs by Customer Type, organizations can uncover significant variations. For example, onboarding a corporate client typically involves more complex steps like verifying beneficial ownership, which is not required for an individual. This analysis ensures that each process variant is as efficient as possible for its specific segment and helps in tailoring process improvements.

It allows for the segmentation of the process to compare and optimize the onboarding journey for different types of customers.

Usually captured at the beginning of the application process and stored in the main customer or application table.

The Event End Time marks the precise date and time an activity concluded. When paired with the Event Start Time, it allows for the exact calculation of processing time for each individual task. Not all systems provide both start and end times; some may only offer a single timestamp representing completion.

Having an end time is highly valuable for performance analysis. It enables the creation of detailed metrics such as 'Average Compliance Review Time' by distinguishing between the time an employee actively worked on a task (processing time) and the time the task was waiting in a queue (wait time). This level of detail is crucial for accurately identifying bottlenecks and focusing improvement efforts on either resource capacity or process handoffs.

It enables the precise calculation of activity processing times, which helps differentiate between active work time and idle wait time.

Found in event logs or transaction tables alongside the start time. May be labeled 'End Time', 'Completion Date', or 'Modified On'.

The Risk Level is a critical output of the KYC process, categorizing customers based on factors like their industry, geography, and transaction patterns. This classification determines the level of scrutiny and due diligence required for their application.

In process mining, this attribute is a powerful dimension for conformance and variant analysis. The process for a high-risk customer should, by design, be different and more rigorous than for a low-risk one. By comparing the actual process flows for different risk levels against the expected procedures, organizations can check for compliance with internal policies and regulations. It helps answer questions like, 'Are high-risk customers always undergoing enhanced due diligence?' or 'Are we spending too much time on low-risk customers?'.

It is essential for compliance and risk management, allowing analysis of whether due diligence processes vary appropriately for different risk profiles.

Calculated by a risk engine or manually assigned by a compliance officer. Stored in the main customer or application record.

The User Department specifies the functional group or team to which the user who performed the activity belongs, such as 'Compliance', 'Client Onboarding', or 'Operations'. This provides a higher-level organizational context compared to the individual User ID.

Analyzing the process from a departmental view is critical for understanding cross-functional collaboration and identifying systemic bottlenecks. It helps visualize the handoffs between different teams, which are often a major source of delays and inefficiencies. This information is key for optimizing team structures, clarifying responsibilities, and improving communication channels to create a smoother onboarding experience.

It enables analysis of process performance and handoffs between different teams, highlighting opportunities for improving cross-functional collaboration.

Often available in user profile data linked to the User ID, or it may be recorded directly on the transaction.

The User ID identifies the person or system bot responsible for executing a specific activity in the process. This could be a compliance officer, a data entry clerk, or an automated risk scoring engine. Consistency in user identification is key for accurate resource analysis.

This attribute provides a human-centric view of the process. It is essential for analyzing workload distribution, individual and team performance, and resource allocation. By filtering the process map by User ID, managers can understand how different employees handle tasks, identify training opportunities, and ensure work is balanced. It also helps in collaboration analysis, revealing how work is handed off between different people.

It allows for analysis of workload, resource performance, and collaboration patterns, enabling better resource management and training.

Available in system audit trails or transaction logs, often linked to the user who created or last modified a record.

This attribute identifies the method used by the customer to submit their application, such as 'Web Portal', 'Mobile App', or 'In-Branch'. Different channels may have different data capture processes and customer experiences.

Analyzing the process by channel helps evaluate the performance and efficiency of each customer touchpoint. It can answer questions like, 'Do mobile applications get processed faster than web applications?' or 'Is the rework rate higher for applications submitted in-branch?'. These insights are valuable for optimizing the customer journey across all channels and allocating resources effectively.

It enables comparison of process efficiency and customer experience across different submission channels, such as web, mobile, or in-person.

Typically recorded at the very beginning of the process when the application is first created.

The Customer Country specifies the geographic location of the applicant. This is a vital piece of information in KYC processes, as regulations and risk factors can vary significantly from one country to another.

Geographic analysis provides another important layer of insight. Onboarding processes may differ based on country-specific legal requirements. By filtering by Customer Country, companies can verify that these jurisdictional variants are being followed correctly. It can also reveal performance differences, such as longer cycle times for applications from high-risk countries, which may be expected due to enhanced due diligence requirements.

It allows for analysis of process variations and performance based on geography, which is critical for ensuring compliance with local regulations.

Captured from the customer during the application process and stored on the customer or application record.

The Customer ID is a unique identifier for the customer that persists across multiple interactions or applications. While the Customer Application ID tracks a single onboarding journey, the Customer ID can link multiple onboarding attempts or other processes for the same customer.

This attribute provides a customer-centric analysis that extends beyond a single case. It is useful for understanding repeat applicants, analyzing the long-term relationship of a customer, or connecting the onboarding process to other processes like 'Loan Application' or 'Account Maintenance'. While not essential for a single-process view, it enriches the data for more complex, object-centric process mining.

It allows for a customer-centric view, linking multiple onboarding attempts or different processes related to the same customer.

Usually found in a central customer master data system and linked to the application record.

This boolean attribute distinguishes between tasks executed by software or bots and those performed by human users. Automated activities might include initial data validation, sanctions screening, or sending standardized communications.

Analyzing this attribute is crucial for evaluating the effectiveness of automation initiatives. By comparing the speed and outcomes of automated steps versus manual ones, businesses can identify opportunities for further automation to reduce costs and cycle times. It also helps in monitoring the performance of automated systems and ensuring they are functioning as expected within the end-to-end process.

It helps measure the impact and efficiency of automation in the process, identifying opportunities for further robotic or systematic improvements.

Can be a dedicated field in the event log or derived based on the User ID, for instance, if the ID is 'SYSTEM' or 'BOT'.

When an application's status is 'Rejected', the Rejection Reason provides the specific cause, such as 'Incomplete Documentation', 'High Risk Profile', or 'Sanctions Match'. This attribute adds crucial context to failed processes.

Analyzing rejection reasons is fundamental to the 'Application Rejection Analysis' dashboard. It helps businesses perform root cause analysis to understand the most common failure points in the onboarding process. By categorizing and quantifying these reasons, organizations can prioritize improvements. For example, if 'Incomplete Documentation' is a top reason, the company might focus on clarifying instructions for customers or improving the document submission portal.

It provides the root cause for failed applications, enabling targeted improvements to reduce the rejection rate and improve customer experience.

Usually stored in the main application or case table, often populated when the status is set to 'Rejected'.

The Service Level Agreement (SLA) Target Date is the deadline set for completing the customer onboarding process. This date is often determined by internal policies or contractual obligations and serves as a benchmark for measuring timeliness.

This attribute is the foundation for the 'SLA Performance Monitoring' dashboard. By comparing the actual completion date of an application with its SLA Target Date, the 'SLA Adherence Rate' can be calculated. Analyzing cases that missed their SLA helps identify the specific activities or departments causing delays. This allows for proactive management of work queues and resource allocation to minimize SLA breaches and improve customer satisfaction.

It provides a performance benchmark, enabling the measurement of SLA adherence and the identification of cases at risk of delay.

Often calculated and stored on the main application record when the case is created, based on application type or other criteria.