Your KYC Customer Onboarding Data Template

This attribute records the name of a business activity or system event, such as 'Application Submitted', 'Compliance Review Initiated', or 'Application Rejected'. It represents a single step in the overall customer onboarding process.

Analyzing activities is the core of process mining. This attribute is used to build the process map, showing the flow between different steps. It helps identify the sequence of events, measure the frequency of each activity, and pinpoint which tasks are most common or time-consuming.

This attribute defines the steps in the process map, making it possible to visualize, analyze, and understand the process flow.

This information is typically captured in Pega's audit trail (history tables) or can be derived from the status changes of the case.

The Customer Application is the primary case identifier that groups all related activities and events for a single customer's onboarding journey. Each application follows a path from submission to either approval and account activation or rejection.

In process mining, this attribute is essential for reconstructing the end-to-end journey of every application. It allows analysts to view the complete sequence of events, track the status of each application, and compare different paths. Analyzing cases based on this ID helps identify common process variants, bottlenecks, and deviations from the standard procedure.

This ID is the foundation for process mining, as it connects all individual events into coherent, end-to-end process instances for analysis.

This is typically the primary case ID in Pega, often accessible as pzInsKey or a business-friendly equivalent in the main case type work object.

This attribute captures the precise date and time that an activity began. It provides the chronological order for all events within a single customer application case.

Timestamps are fundamental for performance-related process analysis. They are used to calculate the duration of activities, the waiting time between steps, and the total end-to-end cycle time of the onboarding process. This data is critical for identifying bottlenecks, measuring SLA adherence, and understanding process efficiency.

Timestamps provide the chronological context needed to calculate durations, analyze process performance, and identify delays.

This is a standard part of Pega's audit trail, often found as pxTimeCreated in history tables for each event.

This attribute indicates the overall status of the application at the end of the process, such as 'Approved', 'Rejected', or 'Withdrawn'. It can also reflect the last known status for ongoing cases.

This is a critical dimension for outcome analysis. It is used directly in the 'Application Rejection Analysis' dashboard to segment cases and understand why certain outcomes occur. Analyzing process flows leading to different statuses helps identify best practices for approved cases and root causes for rejected ones.

It defines the business outcome of a case, allowing for powerful analysis comparing successful paths versus unsuccessful ones.

This is typically the final status (pyStatusWork) of the case work object in Pega.

This attribute identifies the organizational unit or team to which the performing user belongs, such as 'Screening Team', 'Compliance', or 'Onboarding Operations'.

Analyzing the process by department is critical for the 'Workload Distribution by Department' dashboard. It helps managers understand how work flows between different teams, identify cross-functional bottlenecks, and assess the resource allocation across the entire onboarding process. It is key to optimizing hand-offs and balancing workloads.

It enables analysis of process flow and bottlenecks between different business units, supporting resource management and organizational optimization.

This information is typically associated with the user's profile in Pega (Operator ID record) and can be joined with the event data. The property might be pyWorkGroup.

This attribute captures the precise date and time that an activity ended. It is used in conjunction with the Start Time to calculate the processing time for individual activities.

Having a distinct End Time allows for more accurate performance analysis. It helps differentiate between active processing time (the duration between Start Time and End Time) and waiting time (the duration between one activity's End Time and the next one's Start Time). This is crucial for pinpointing true bottlenecks, distinguishing them from queues.

Enables the precise calculation of activity processing time, which is essential for detailed performance analysis and bottleneck identification.

This may be available in Pega's audit trail or may need to be derived by using the Start Time of the subsequent event as the End Time of the current one.

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

This attribute is the primary driver for the 'Application Rejection Analysis' dashboard. By segmenting rejected cases by reason, the business can identify the most common failure points in the onboarding process. This insight is crucial for implementing targeted improvements to reduce the rejection rate, improve customer experience, and increase operational efficiency.

Provides actionable insights into why applications fail, enabling targeted process improvements to increase the success rate.

This would likely be a specific property set on the case when it transitions to a 'Rejected' status. Consult Pega KYC documentation for standard rejection reason fields.

This attribute represents the assessed risk associated with the customer, often categorized as 'Low', 'Medium', or 'High'. The risk level is typically determined by an automated scoring engine based on customer data and screening results.

The risk level is a powerful driver of process variation. High-risk applications often require additional due diligence steps, such as an enhanced compliance review, leading to longer cycle times. Analyzing the process by risk level helps to justify these variations and ensure that risk controls are operating effectively without causing undue delays.

Explains variations in the process path and duration, as risk level often determines the required level of due diligence.

This would be a calculated property on the case, populated by a Pega decision rule or scoring model. Consult Pega KYC documentation.

This attribute stores the target completion date for an application, as defined by the service level agreement (SLA). The SLA may vary based on factors like customer type, risk level, or product.

This date is essential for the 'SLA Adherence Tracking' dashboard and the associated KPI. It serves as the benchmark against which the actual completion date is compared. Analyzing cases that miss their SLA target helps identify systemic delays and prioritize process improvements to ensure compliance with service commitments.

It provides the benchmark for measuring on-time performance, which is critical for customer satisfaction and operational control.

Pega has a built-in SLA management framework. This date is typically stored in properties like pySLAGoal or a custom-defined SLA property on the case.

This attribute stores the ID of the employee or system user responsible for completing a specific task in the KYC process, such as a compliance officer or an automated screening bot. For automated steps, this might be a system or service account ID.

Analyzing by user helps in understanding workload distribution, individual performance, and training needs. It can also be used to investigate process deviations by identifying which users or teams are involved in non-standard process flows.

This attribute links process activities to specific individuals or teams, enabling workload analysis, performance evaluation, and compliance checks.

This is a standard field in Pega's audit trail, typically stored as pxUpdateOperator or a similar property in history tables.

This attribute categorizes the onboarding application, for example, 'Individual Customer', 'Corporate Client', or 'High-Net-Worth Individual'. Different case types often follow distinct process variations with different steps, SLAs, and risk profiles.

Analyzing the process by Case Type allows for a more meaningful comparison of performance. It helps to understand if certain types of onboarding are more prone to delays or rejections. This segmentation is crucial for tailoring process improvements to the specific needs of different customer journeys.

Allows for the segmentation of the process data into distinct categories, enabling more accurate and relevant performance analysis.

This is typically the class name of the case instance in Pega, or a dedicated property on the case that defines its type.

This attribute stores the country associated with the customer being onboarded. This information is a key input for risk assessment and determining the required level of due diligence.

In analysis, the customer's country can reveal important patterns. Certain jurisdictions may be associated with higher risk, leading to longer and more complex onboarding processes. This dimension allows for geographic-based performance analysis and helps ensure that regional compliance requirements are being met efficiently.

Enables geographical analysis of the process, which is often linked to regulatory complexity and risk levels.

This would be a property on the customer data object associated with the case.

This attribute is the unique ID that links the application to a customer record in the master data system. It represents the entity, whether an individual or an organization, that is the subject of the KYC process.

While the application ID tracks the process, the Customer ID allows for analysis across multiple applications from the same customer or for enriching the process data with customer-specific attributes like segment or history. This enables a customer-centric view of the onboarding process.

Connects the process data to the customer master data, enabling richer analysis based on customer attributes and history.

This would be a core property on the KYC case, linking it to the customer data model within Pega or an external CRM.

This calculated metric measures the end-to-end duration for each customer application, from the very first event to the last. It is typically calculated as the difference between the timestamp of the final activity and the initial activity for a given case.

Cycle Time is a primary key performance indicator (KPI) for process efficiency and customer experience. It is used in the 'Overall Onboarding Cycle Time Analysis' dashboard to monitor average processing times, identify long-running cases, and track the impact of process improvement initiatives over time.

This is a critical KPI that directly measures the overall speed and efficiency of the onboarding process from the customer's viewpoint.

This metric is calculated in the process mining tool by taking the difference between the maximum and minimum timestamps for each case ID.

This attribute tracks the state of the documents required for the KYC process, with values such as 'Pending Customer', 'Received', 'Verified', or 'Rejected'. This status can change multiple times throughout a single case.

This is a key attribute for the 'Onboarding Throughput & Status' dashboard and the 'Document Verification Speed' analysis. It allows for a granular view of one of the most common bottleneck areas. By tracking how long documents remain in each status, the business can identify delays in customer submission or internal review.

Provides visibility into the document handling sub-process, helping to identify and resolve common delays in document verification.

This would likely be a property on a related data object or page list associated with the main case, tracking each required document. Consult Pega KYC documentation.

This boolean attribute is true if the activity was executed by an automated agent, such as a screening engine or a system rule, and false if it was performed by a human user.

Distinguishing between automated and manual activities is crucial for automation analysis. It helps to measure the effectiveness of existing automation, identify manual tasks that are good candidates for future automation, and understand the interaction between human and system actors in the process.

It separates human-driven activities from system-driven ones, which is fundamental for any automation initiative or analysis.

This can be derived from the user ID associated with the event. If the OperatorId corresponds to a known system or agent account, this flag is set to true.

This boolean attribute is true if a specific activity, such as 'Document Review', occurs more than once within the same case. It is often triggered by events like 'Additional Information Requested'.

Identifying rework is essential for spotting process inefficiencies and friction points for the customer. The 'Process Rework and Loops' dashboard uses this attribute to quantify the frequency and impact of rework. Reducing rework is often a key goal, as it leads to faster processing, lower operational costs, and a better customer experience.

Highlights process inefficiencies, redundant tasks, and loops, which are primary targets for process improvement.

This flag is derived during data analysis by checking for repeated activity names within the same case ID. For example, if 'Document Review Completed' appears a second time.

This attribute indicates the most recent time the data was extracted from the source system. It is usually the same for all records within a single data load.

This timestamp is important for understanding the freshness of the data being analyzed. It allows users to know how current the process analysis is and when the next data update is expected, which is critical for operational monitoring dashboards.

Informs users about the timeliness of the data, ensuring they understand if the analysis reflects the current state or a past period.

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

This attribute specifies the product or service that the customer is being onboarded for, such as a 'Retail Bank Account', 'Corporate Loan', or 'Investment Services'.

The product can influence the onboarding process, as different products may have different regulatory requirements and complexity. Analyzing the process by product helps identify if specific product lines have longer cycle times or higher rejection rates, providing insights for product-specific process optimization.

Allows for process analysis to be segmented by product line, revealing performance differences and optimization opportunities.

This would be a property on the case, selected at the start of the application process.

This metric calculates the active working time for an event, measured as the difference between its End Time and Start Time. It represents the time a resource was actively engaged in a task.

Processing Time, also known as cycle time of an activity, is essential for detailed performance analysis. It helps distinguish between long tasks (high processing time) and long queues (high waiting time). This allows for more targeted improvement efforts, such as providing better tools to speed up a task versus reallocating resources to reduce a queue.

Measures the active work duration of activities, helping to distinguish between inefficient tasks and resource or queuing problems.

This metric is calculated as (EndTime - StartTime) for each event. It requires both timestamp fields to be available.

This attribute categorizes each completed case as 'On Time' or 'Late' based on a comparison between its actual completion timestamp and its 'SLA Target Date'.

This is the core metric for the 'SLA Adherence Tracking' dashboard and the 'SLA Adherence Rate' KPI. It provides a clear, at-a-glance view of performance against service level commitments. Analyzing the characteristics of late cases helps to identify the root causes of delays and mitigate risks of future SLA breaches.

Directly measures performance against commitments, which is crucial for operational management, compliance, and customer satisfaction.

This is derived by comparing the timestamp of the final case activity with the SlaTargetDate field. If completion time is after the target, the status is 'Late'.

This attribute specifies the source application where the event was recorded. For this process, the value would consistently be 'Pega KYC'.

While it may seem redundant if all data comes from one system, this attribute is crucial for data governance and becomes vital when integrating data from multiple systems. It ensures clarity on data provenance and helps in troubleshooting data integration issues.

It provides essential context about data origin, ensuring data governance and enabling analysis across multiple source systems.

This is typically a static value added during the data extraction and transformation process to label the dataset's origin.