> Continuous Process Improvement > KYC Customer Onboarding > Refinitiv World Check > Data Template

Your KYC Customer Onboarding Data Template

Refinitiv World-Check

KYC Customer Onboarding Attributes (20) KYC Customer Onboarding Activities (14) Extraction Guides (2)

Your KYC Customer Onboarding Data Template

This template guides you through collecting the essential data for analyzing your KYC Customer Onboarding process. It outlines the crucial attributes to capture, the key activities to track, and provides guidance on how to extract this information from your source systems. Utilize this resource to ensure you have all the necessary data for effective process analysis and improvement.

Recommended attributes to collect
Key activities to track
Extraction guidance

New to event logs? Learn how to create a process mining event log.

Download Template

KYC Customer Onboarding Attributes

These are the recommended data fields to include in your event log for comprehensive KYC Customer Onboarding analysis.

3 Required 5 Recommended 12 Optional

	Name	Description
	Activity Name ActivityName	The name of a specific business event or task that occurred within the KYC onboarding process.
Description The Activity Name describes a single step or event in the customer onboarding journey, such as 'Application Submitted', 'Analyst Review Started', or 'Screening Completed - Clear'. These activities form the nodes of the process map, providing a detailed breakdown of the end-to-end workflow. Analyzing activities is the core of process mining. By tracking the sequence and frequency of different activities, analysts can discover the actual process flow, identify common paths, detect deviations from the standard procedure, and pinpoint specific steps that cause delays or rework. This attribute is crucial for building process maps and calculating activity-level metrics. Why it matters This attribute defines the individual steps of the process, which is essential for discovering and visualizing the process flow and identifying bottlenecks. Where to get This information is typically found in event logs or audit trail tables, often associated with status changes in the case management entity. Examples Potential Match IdentifiedAnalyst Review StartedFalse Positive ConfirmedApplication Approved
	Customer Application CustomerApplication	The unique identifier for a single customer's onboarding application, serving as the primary case identifier.
Description The Customer Application is the central case identifier that groups all events and activities related to a single customer's onboarding journey. It allows for the complete, chronological tracking of each customer's progress through the entire Know Your Customer (KYC) process, from the initial submission to the final decision. In process mining analysis, this attribute is fundamental for reconstructing the end-to-end journey of each application. It enables the visualization of process flows, calculation of total cycle times, and identification of variants. By analyzing cases grouped by this identifier, organizations can understand different paths an application can take, identify bottlenecks, and compare the efficiency of various onboarding processes. Why it matters This is the essential case identifier that connects all related activities, making it possible to analyze the end-to-end customer onboarding process. Where to get This identifier is typically the primary key in the main application or case management table within the Refinitiv World-Check system or an integrated CRM. Examples APP-2023-00123APP-2023-00124APP-2023-00125
	Event Time EventTime	The timestamp indicating when a specific activity or event occurred.
Description Event Time provides the precise date and time that an activity was recorded. This timestamp is the chronological backbone of the process, allowing events to be ordered correctly to reconstruct the case history. This attribute is critical for all time-based analysis in process mining. It is used to calculate durations between activities (cycle times and waiting times), measure the overall case duration, analyze process performance over time, and check for compliance with Service Level Agreements (SLAs). Without accurate timestamps, it is impossible to understand process performance and identify temporal bottlenecks. Why it matters The timestamp for each activity is essential for calculating all duration-based metrics, discovering the process sequence, and performing bottleneck analysis. Where to get This is a standard field in any event log or audit trail table, often named 'Timestamp', 'EventDate', or 'CreationDate'. Examples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	Department DepartmentName	The department or functional team responsible for performing the activity.
Description This attribute specifies the business unit or team, such as 'Onboarding', 'Compliance', or 'Quality Assurance', that the user belongs to. It allows for analysis at a higher organizational level than the individual user. Analyzing by department is critical for identifying inter-departmental bottlenecks and measuring handoff times. It helps visualize how work flows between different teams and where delays occur in these transitions. This view is invaluable for streamlining cross-functional collaboration and improving overall process efficiency. Why it matters Enables the analysis of process performance by department and is essential for identifying delays in handoffs between different teams. Where to get This information may be stored with the user's profile in the system or an associated HR system. It might need to be joined with the event data using the user ID. Examples Onboarding TeamCompliance ReviewSenior Management
	Event End Time EventEndTime	The timestamp indicating when a specific activity or event was completed.
Description The Event End Time marks the completion of an activity. While many events can be modeled as instantaneous (where StartTime equals EndTime), some activities have a measurable duration, like 'Analyst Review Started' and 'Analyst Review Completed'. Having both start and end times allows for precise measurement of processing time. In process analysis, having an end time is vital for calculating the exact processing time of an activity, as opposed to the cycle time which includes waiting time. This helps differentiate between the time a case spends being actively worked on versus the time it sits idle in a queue. This is key for resource optimization and efficiency analysis. Why it matters Enables the precise calculation of activity processing time, separating active work time from idle waiting time for more accurate performance analysis. Where to get For activities with a duration, this may be stored in a separate field like 'CompletionDate' or 'EndDate' in the event log or audit trail tables. Examples 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	Reviewer ID ReviewerId	The identifier of the user, analyst, or automated agent who performed the activity.
Description The Reviewer ID, or user, indicates who executed a particular task in the KYC process. This could be a compliance analyst, an onboarding specialist, or a system account for automated activities. Tracking this information provides visibility into workload distribution and individual performance. This attribute is essential for resource-based analysis. It helps in understanding performance differences between users or teams, identifying training needs, and optimizing workload balancing. It is also a key component for analyzing handoffs, social networks, and compliance resource utilization. Why it matters Allows for analysis of workload distribution, user performance, and departmental handoffs, which is crucial for resource optimization. Where to get Typically found in event logs or audit trails, often named 'UserID', 'PerformedBy', or 'Owner'. Examples analyst_jdoesystem_auto_screenermanager_bsmith
	Risk Level RiskLevel	The calculated risk classification of the customer application, such as Low, Medium, or High.
Description The Risk Level is a critical piece of information in KYC processes, determining the level of due diligence required. It is often determined based on factors like customer type, geography, and the nature of their business. This classification can significantly influence the process path an application takes. In process analysis, segmenting cases by Risk Level is essential. It helps explain variations in cycle times and process flows, for example, high-risk applications may require more steps and take longer. This attribute is key for the 'Application Rejection Rate and Reasons' and 'Background Check Initiation Cycle Time' dashboards to understand how risk impacts outcomes and efficiency. Why it matters Segmenting the process by risk level is crucial for understanding why certain cases take longer or follow different paths, and for analyzing rejection rates. Where to get This is a core data point on the customer application or case record. Consult the case management module in Refinitiv World-Check. Examples LowMediumHigh
	SLA Target Date SlaTargetDate	The target date by which the customer onboarding process should be completed.
Description The SLA Target Date is the deadline for completing the entire onboarding case, as defined by the service level agreement with the customer or internal policies. This date is the benchmark against which actual completion times are measured. This attribute is fundamental for the 'SLA Adherence and Breach Analysis' dashboard. It is used to calculate whether a case was completed on time or not. Analyzing SLA breaches helps to identify systemic issues in the process that cause delays and allows the organization to take corrective action to improve timeliness and meet compliance requirements. Why it matters This is the benchmark for measuring on-time performance and is critical for calculating the SLA adherence rate and analyzing breaches. Where to get This date is often calculated based on the application submission date and business rules. It may be stored as a field on the case record. Examples 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
	Activity Processing Time ActivityProcessingTime	The duration of time spent actively working on an activity.
Description This metric calculates the actual time an activity took to complete, from its start to its end. It is calculated as the difference between the EventEndTime and the EventTime. This measures the 'touch time' or active work time for a task. This calculated attribute is essential for performance analysis and is used in many KPIs, including 'Avg Doc Review Cycle Time' and 'Avg Compliance Review Cycle Time'. It helps to distinguish between the time a task is being actively processed versus the time it is waiting in a queue. This is fundamental for identifying true processing inefficiencies and for capacity planning. Why it matters Measures the active work time for an activity, helping to pinpoint which specific tasks are taking the most time to complete, separate from waiting time. Where to get This is calculated during data transformation by subtracting the start timestamp from the end timestamp of an activity (e.g., EndTime - StartTime). Examples PT1H30MP2DT4H15MPT25M
	Application Channel ApplicationChannel	The channel through which the customer application was submitted, such as Online Portal, In-Branch, or Mobile App.
Description The Application Channel indicates the submission source of the customer application. Different channels can have varying levels of data completeness, quality, and customer demographics, which can impact the downstream process. This attribute is essential for the 'Application Throughput by Channel' dashboard. By analyzing the volume, cycle time, and outcomes of applications from different channels, an organization can identify which channels are most efficient and which may require process improvements. This analysis supports strategic decisions on resource allocation and channel investment. Why it matters Helps analyze the performance and efficiency of different submission channels, informing strategic decisions about technology and customer experience. Where to get This information is typically captured at the beginning of the process and stored as an attribute on the application record. Examples Online PortalMobile AppIn-BranchRelationship Manager
	Customer Country CustomerCountry	The country of residence or incorporation for the customer.
Description This attribute indicates the geographical location of the customer. The country is a significant factor in risk assessment and regulatory requirements for KYC processes. Different jurisdictions have different rules, which can affect the process flow and duration. Analyzing the process by country allows organizations to compare performance across different regions, identify location-specific bottlenecks, and ensure compliance with local regulations. It provides a geographical dimension to the process analysis, which can reveal important operational differences. Why it matters Enables geographical analysis of the process, helping to identify regional variations in performance, risk, and compliance requirements. Where to get This is a standard field on the customer profile or application form. Examples USAGBRSGPDEU
	Customer ID CustomerId	A unique identifier for the customer entity being onboarded.
Description The Customer ID is the unique identifier for the customer profile. This is distinct from the Customer Application ID, as one customer may submit multiple applications over time. This attribute links the onboarding process to the master customer record. In analysis, the Customer ID allows for tracking repeat applications from the same customer and can be used to enrich the process data with other customer attributes from a CRM or master data system. This enables a more holistic view of the customer journey beyond a single onboarding instance. Why it matters Links the onboarding case to a specific customer, enabling analysis of repeat applications and enrichment with master customer data. Where to get This would be a key field on the application or case record, linking it to the customer master data. Examples CUST-98765CUST-98766CUST-98767
	Customer Type CustomerType	The classification of the customer, such as Individual, Corporation, or Trust.
Description Customer Type categorizes the entity being onboarded. Different types of customers often have different onboarding requirements, risk profiles, and regulatory obligations. For example, onboarding a corporation is typically more complex than onboarding an individual. This attribute is used for segmentation analysis, particularly for the 'KYC Customer Type Performance' dashboard. It allows for comparing process efficiency, cycle times, and rejection rates across different customer segments. This helps organizations tailor and optimize the onboarding experience for specific customer types. Why it matters Allows for performance comparison between different customer segments, helping to tailor and optimize the onboarding process for each type. Where to get This is a fundamental attribute stored on the customer or application record within the source system. Examples IndividualCorporationNon-ProfitTrust
	Is Automated IsAutomated	A flag indicating whether the activity was performed by a system (true) or a human (false).
Description This boolean attribute distinguishes between automated system tasks and manual activities performed by users. For example, 'Automated Screening Performed' would be marked as automated, while 'Analyst Review Started' would be manual. This distinction is crucial for automation analysis. It helps to measure the impact of automation on process efficiency, identify which manual tasks are candidates for future automation, and understand the interaction between human and system actors. It allows for a clear separation of system processing time from manual handling time. Why it matters Differentiates between system and human activities, which is key to measuring the impact of automation and identifying new automation opportunities. Where to get This is typically derived based on the activity name or the user ID associated with the event (e.g., if the user is a 'system' account). Examples truefalse
	Is Rework IsRework	A flag indicating if an activity is being performed for a second or subsequent time within the same case.
Description IsRework is a calculated boolean attribute that identifies when an activity is repeated within the same customer application case. For example, if 'Risk Assessment Performed' happens more than once for a single application, the subsequent occurrences are marked as rework. This attribute is critical for identifying process inefficiencies, loops, and unnecessary repetitions. It directly supports the 'Risk Assessment Rework and Efficiency' dashboard and the 'Risk Assessment Rework Rate' KPI. Analyzing rework helps to uncover issues with quality, clarity of information, or decision-making, which lead to wasted effort and longer cycle times. Why it matters Highlights process inefficiencies by flagging repeated activities, enabling the analysis of rework loops to improve quality and reduce cycle times. Where to get This is calculated during data transformation by analyzing the sequence of activities within each case and flagging any non-initial occurrences of an activity. Examples truefalse
	Last Data Update LastDataUpdate	The timestamp when the data for this event was last refreshed or extracted from the source system.
Description This attribute indicates the freshness of the data. It records the date and time of the last data pull from Refinitiv World-Check. This is important for understanding the timeliness of the process mining dashboards and analyses. For analytical purposes, this allows users to know if they are looking at near real-time data or a snapshot from a specific point in time. It is essential for data governance and for managing user expectations about the currency of the insights provided. Why it matters Provides crucial context on data freshness, ensuring users understand how up-to-date the process analysis is. Where to get This timestamp is generated and added during the data extraction (ETL) process. Examples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Match ID MatchId	The unique identifier for a potential match found during a World-Check screening.
Description When the automated screening process finds a potential match against sanctions lists, PEP lists, or adverse media, a Match ID is often generated to track the specific finding. This ID links the application case to the specific record in the World-Check database that triggered the alert. This attribute is useful for detailed compliance analysis. It allows analysts to investigate the nature of matches, track the resolution of specific alerts (e.g., confirming a false positive or a true match), and understand which types of alerts are most common or take the longest to resolve. It provides a deeper level of detail into the 'Potential Match Identified' activity. Why it matters Provides a granular link to the specific screening results, enabling deeper analysis of match resolution times and types of alerts. Where to get This ID would be generated by the World-Check screening engine and logged against the application case when a potential match is found. Examples WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	Rejection Reason RejectionReason	The specific reason provided when a customer application is rejected.
Description When an application is rejected, the Rejection Reason captures why that decision was made. Reasons could include 'Sanctions Match', 'Incomplete Documentation', or 'High Risk Profile'. This provides valuable, structured feedback on the quality of incoming applications and the effectiveness of the screening process. This attribute is the primary driver for the 'Application Rejection Rate and Reasons' dashboard. Analyzing these reasons helps identify root causes for rejections, which can lead to process improvements, clearer communication with applicants, and potentially a reduction in unnecessary rejections. It provides qualitative context to the quantitative rejection rate KPI. Why it matters Provides the root cause for application rejections, which is essential for identifying areas to improve in the onboarding process to reduce the rejection rate. Where to get This would be recorded when the 'Application Rejected' event occurs, likely as a field on the case or application record. Examples PEP MatchSanctions List HitFailed Document VerificationAdverse Media
	SLA Breached SlaBreached	A boolean flag indicating if the onboarding case was completed after its SLA Target Date.
Description This attribute is a calculated flag that indicates whether a case has violated its Service Level Agreement. It is determined by comparing the timestamp of the final completion activity (e.g., 'Application Approved' or 'Application Rejected') with the 'SlaTargetDate' for the case. This flag is the basis for the 'SLA Adherence and Breach Analysis' dashboard and the 'SLA Adherence Rate' KPI. It simplifies analysis by allowing users to quickly filter for all breached cases. By analyzing the process characteristics of breached cases, organizations can identify the root causes of delays and focus improvement efforts effectively. Why it matters Directly measures compliance with service level agreements, allowing for easy filtering and root cause analysis of delayed cases. Where to get This is calculated during data transformation by comparing the final activity timestamp for a case to the SlaTargetDate field. Examples truefalse
	Source System SourceSystem	The system from which the event data was extracted, in this case, Refinitiv World-Check.
Description This attribute identifies the origin of the process data. While it might be a constant value in a single-source extraction, it becomes crucial when data from multiple systems (like a CRM and World-Check) is combined to create a holistic process view. In analysis, this helps in data governance, troubleshooting, and understanding the context of the data. For instance, activities logged in a core screening system may have different properties or levels of detail than those from a peripheral system. It ensures data lineage is clear and auditable. Why it matters Identifies the data's origin, which is crucial for data governance, validation, and when merging data from multiple sources. Where to get This is often a static value added during the data extraction, transformation, and loading (ETL) process to label the dataset. Examples Refinitiv World-CheckWorldCheckOne

Required Recommended Optional

KYC Customer Onboarding Activities

These are the key process steps and milestones to capture in your event log for accurate process discovery.

8 Recommended 6 Optional

	Activity	Description
	Account Activated	The customer's account is created and activated in the core system, completing the onboarding journey. This follows the final application approval and makes the account ready for use.
Why it matters This is the final, value-delivering step in the process. The duration from application submission to account activation is a key metric for operational efficiency and customer satisfaction. Where to get This event is not captured in World-Check. It is recorded in the core banking or customer account system and must be correlated by the Customer Application ID. Capture Event logged in the core account system upon account activation. Event type explicit
	Analyst Review Started	A compliance analyst begins the manual investigation of potential matches for a customer application. This involves assessing the details of the potential matches against the customer's information to determine relevance.
Why it matters This marks the start of the manual compliance review, a common bottleneck. Measuring the time from 'Potential Match Identified' to this activity reveals queuing delays, while the duration of the review indicates analyst efficiency. Where to get This can be inferred when an analyst 'claims' or opens a case from the review queue. The system may log this event explicitly in an audit trail when the case status changes to 'In Review' or is assigned to a specific user. Capture Inferred from a case status change to 'Under Review' or the assignment of the case to an analyst. Event type inferred
	Application Rejected	The customer application is formally rejected, often as a result of a 'Match Found' in World-Check or other risk factors. This event is the final negative outcome of the onboarding process.
Why it matters This is the primary failure endpoint of the process. Analyzing rejection events, particularly the reasons and preceding activities, is crucial for process improvement and reducing unnecessary rejections. Where to get This final business decision is recorded in the upstream CRM or core application system, not in World-Check itself. Data must be sourced from that system. Capture Event logged in the source application system, often with a corresponding rejection reason code. Event type explicit
	Application Submitted	This activity marks the initiation of the KYC onboarding process when a customer submits their application. This event is typically captured in a CRM or a core application system, which then triggers the screening process in Refinitiv World-Check.
Why it matters This is the primary start event for the end-to-end customer onboarding journey. Analyzing the time from this point to completion provides the overall onboarding cycle time, which is critical for measuring customer experience and SLA adherence. Where to get This event is not native to World-Check. It must be sourced from an upstream system, like a CRM or customer account management platform, and correlated by the Customer Application ID. Capture Event logged in the source application system upon initial submission. Event type explicit
	Screening Completed - Clear	The screening case is officially closed with a 'Clear' result, meaning no true matches were found. This decision is communicated back to the originating system, allowing the onboarding process to proceed.
Why it matters This activity represents the successful, 'happy path' completion of the screening process. It serves as a key endpoint for measuring the cycle time of standard, low-risk applications. Where to get Inferred from the final case status changing to 'Clear', 'Complete', or 'Closed - No Match'. The timestamp of this final status change is used. Capture Derived from the timestamp of the final case status indicating a clear result. Event type inferred
	Screening Completed - Match Found	The screening case is officially closed with a 'Match Found' result, indicating that a confirmed risk was identified. This decision triggers a different downstream process, such as enhanced due diligence or rejection.
Why it matters This is the primary 'unhappy path' endpoint for the screening process. Analyzing these cases helps understand risk profiles and the effectiveness of the screening controls. Where to get Inferred from the final case status changing to 'Match Found', 'Risk Identified', or 'Closed - Positive'. The timestamp of this final status change is used. Capture Derived from the timestamp of the final case status indicating a confirmed match. Event type inferred
	Screening Request Created	A new screening case is formally created for a customer application within the Refinitiv World-Check system. This is triggered by an API call or manual entry from an upstream system and represents the start of the risk intelligence check.
Why it matters This marks the official start of the screening sub-process. The time between Application Submitted and this activity reveals delays in handoffs between the line-of-business system and the compliance function. Where to get Recorded in the World-Check case management logs or audit trail. The creation event and its timestamp for the specific case or entity ID would be used. Capture Logged automatically when a new screening case is created in the system. Event type explicit
	True Match Confirmed	An analyst confirms that a potential match is indeed the customer being screened, identifying a potential risk. This is a critical milestone that typically triggers further due diligence or application rejection.
Why it matters This is a key risk-mitigation outcome and a pivotal moment in the process. It directly influences the final decision on the customer application and is crucial for compliance reporting and analysis. Where to get This is an explicit user action where the analyst dispositions a specific match as a 'True Match' or 'Confirmed Match'. This event is logged in the case audit trail. Capture Logged when an analyst formally confirms a match in the system. Event type explicit
	Additional Information Requested	The analyst determines that more information is needed to resolve the potential match and requests it from the business unit. This places the case in a pending state until the information is provided.
Why it matters Frequent occurrences of this activity indicate issues with the quality of initial data provided for screening. This activity introduces significant delays, as it depends on external teams, and is a key driver of long cycle times. Where to get This may be an explicit user action logged in the case notes or audit log. Alternatively, it could be inferred from a case status change to 'Pending Information' or 'RFI'. Capture Logged when an analyst uses a feature to flag the case as needing more information. Event type explicit
	Application Approved	The customer application has been fully approved following a successful KYC screening and any other required checks. This event typically occurs in the source system after receiving a 'Clear' result from World-Check.
Why it matters This marks the successful business outcome of the onboarding process. Tracking the time to this point from submission reveals the full 'time-to-yes' for a new customer. Where to get This event is not native to World-Check. It must be sourced from the upstream CRM or core application system, which makes the final business decision. Capture Event logged in the source application system upon final approval. Event type explicit
	Automated Screening Performed	The World-Check system automatically screens the customer's details against its risk intelligence database. This is a system-driven activity that produces an initial set of results, such as potential matches or a clear status.
Why it matters This activity is the first value-add step within the screening process. Delays before this point indicate system or data readiness issues, while the outcome determines the subsequent manual workload. Where to get This event may be logged explicitly in the case audit trail or inferred from the timestamp when initial screening results become available for the case. Capture System log entry generated upon completion of the automated database scan. Event type explicit
	Case Escalated for Review	A first-level analyst escalates a complex or high-risk case to a senior analyst or manager for a final decision. This is a key handoff point within the compliance team.
Why it matters Escalations often create bottlenecks and increase cycle time. Analyzing the frequency and reasons for escalations can highlight training needs for junior analysts or ambiguity in review policies. Where to get Recorded as an explicit action in the case workflow or audit trail. This could also be inferred by a change in the user assigned to the case, especially to a user with higher permissions. Capture Logged via a dedicated 'Escalate' button or workflow action within the case. Event type explicit
	False Positive Confirmed	The analyst concludes that a potential match is not the same as the customer being screened. The match is dismissed, and the screening process for that specific alert is resolved.
Why it matters This represents a common outcome of the review process. Understanding the time it takes to disposition false positives helps measure analyst efficiency and the accuracy of the automated screening logic. Where to get This is an explicit user action where the analyst dispositions a specific match as 'False Positive' or 'Not a Match'. This action is typically logged in the case history. Capture Logged when an analyst formally dismisses a potential match in the system. Event type explicit
	Potential Match Identified	The automated screening process has found one or more potential matches requiring manual review by an analyst. This event transitions the case from an automated state to a manual investigation queue.
Why it matters This activity is a critical branching point in the process. Cases with potential matches follow a longer, more complex path, and tracking this helps in resource planning and bottleneck analysis for the review team. Where to get Inferred from a change in the case status to 'Review Required', 'Potential Match', or a similar state within the World-Check case management module. Capture Derived from a case status change indicating that manual review is now needed. Event type inferred

Recommended Optional

Extraction Guides

How to get your data from Refinitiv World-Check

Steps

Log in to World-Check One: Access the Refinitiv World-Check One portal using your credentials.
Navigate to Case Management: Open the Case Management section where all screening cases are stored and managed.
Prepare the Case Report Export: Go to the reporting or export feature within Case Management. This may be labeled as 'Export Cases' or 'Case Report'.
Configure the Case Report: Select the columns to include in the export. Ensure you select fields corresponding to the Case ID (CustomerApplication), creation date, resolution date, case status (e.g., Clear, Match Found), and risk level.
Export the Case Management Data: Define your date range, typically covering the last 3 to 6 months of activity. Apply any necessary filters, such as by user group or case type. Export the data as a CSV file and name it case_report.csv.
Prepare the Audit Trail Export: Navigate to the audit trail or audit log reporting section of World-Check One. This contains detailed event histories for each case.
Configure and Export the Audit Trail: Select all relevant columns, including the Case ID, event name or description, event timestamp, and the user who performed the action. Export this data for the same date range as the case report. Save the file as audit_trail.csv.
Source External Process Steps: Obtain data for activities that occur outside of World-Check, such as Application Submitted, Application Approved, Account Activated, and Application Rejected. This data typically comes from a CRM or core banking system. Export this data with the CustomerApplication ID and relevant timestamps.
Combine and Transform Data: Load the exported CSV files (case_report.csv, audit_trail.csv, and the external system data) into a data preparation tool or script.
Map Audit Events to Activities: Process the audit_trail.csv file. Map the raw event descriptions from the audit log to the standardized ActivityName values. For example, an audit log entry like 'Case Assigned to Analyst' becomes 'Analyst Review Started'.
Map Case Status Changes to Activities: Process the case_report.csv file to generate activities based on status changes. Use the case resolution date and final status to create the 'Screening Completed - Clear' or 'Screening Completed - Match Found' events.
Create the Final Event Log: Union all processed data from the different source files into a single CSV file. Ensure the final file contains the required columns: CustomerApplication, ActivityName, and EventTime, along with any recommended attributes. Save this file for upload to the process mining tool.

Configuration

Report Types: You will need to generate at least two separate reports: a Case Management summary report and a detailed Audit Trail report.
Date Range: For an initial analysis, select a date range of at least 3-6 months to capture enough completed and in-progress cases. Ensure the date range is consistent across all exported files.
Export Format: Choose CSV (Comma Separated Values) as the export format for easy processing.
Key Columns (Case Report): Ensure your case export includes Case ID, Creation Timestamp, Resolution Timestamp, Final Status, Assigned Analyst, and Risk Level.
Key Columns (Audit Trail Report): Ensure your audit log export includes Case ID, Event Description, Event Timestamp, and User ID.
Prerequisites: Access to the World-Check One portal with user permissions that allow for viewing and exporting case management and audit log data is required. This may require elevated privileges beyond a standard analyst role.

a Sample Query config

/*
This is a configuration and mapping guide, not an executable script. 
The process relies on manually exporting two reports from World-Check One and combining them with data from an upstream system (e.g., CRM).
*/

-- Step 1: Export 'Case Management Report' as case_report.csv
-- Step 2: Export 'Audit Trail Report' as audit_trail.csv
-- Step 3: Export relevant events from CRM/core system as source_system_events.csv

-- Step 4: Combine and map the files using a script or ETL tool to create the final event log.

-- Mapping logic for final_event_log.csv

-- Part A: Data from source_system_events.csv
SELECT
  ApplicationID AS CustomerApplication,
  'Application Submitted' AS ActivityName,
  SubmissionTimestamp AS EventTime,
  NULL AS EventEndTime,
  OriginatorID AS ReviewerId,
  OriginatingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Submission'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Approved' AS ActivityName,
  ApprovalTimestamp AS EventTime,
  NULL AS EventEndTime,
  ApproverID AS ReviewerId,
  ApprovingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Approval'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Account Activated' AS ActivityName,
  ActivationTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Operations' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Activation'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Rejected' AS ActivityName,
  RejectionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ReviewerID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Rejection'

-- Part B: Data from World-Check audit_trail.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Request Created' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Created%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Automated Screening Performed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Automated Screening Completed%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Potential Match Identified' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Potential Match Found%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Analyst Review Started' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Assigned%' OR EventDescription LIKE '%Review Started%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Additional Information Requested' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Information Requested%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Case Escalated for Review' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Escalated%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'False Positive Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Dismissed as False Positive%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'True Match Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Confirmed as True%'

-- Part C: Data from World-Check case_report.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Clear' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Clear'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Match Found' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Match Found'

Steps

Prerequisites and Setup: Ensure you have Python 3.6+ installed along with the requests and pandas libraries. Obtain your World-Check One API Key and API Secret from your Refinitiv representative or the developer portal. Store these credentials securely.
Develop Authentication Logic: In your Python script, create a function to send a POST request to the World-Check One authentication endpoint. Use your API Key and Secret to obtain a temporary bearer token required for subsequent API calls.
Identify Source System Data: The process starts and ends outside of World-Check. Identify the source system, such as a CRM or core banking platform, that stores initial application data. You will need to extract events like Application Submitted, Application Approved, Account Activated, and Application Rejected from this source. This can be done via a database query or another API.
Fetch World-Check Cases: Using the authenticated token, make a GET request to the /cases endpoint of the World-Check One API. Use query parameters to filter cases by a specific date range, for example, based on their creation or modification date.
Handle API Pagination: World-Check API responses are paginated. Your script must check the response for pagination details and loop through all pages to retrieve the complete list of cases for your specified date range.
Retrieve Case Details and History: For each case ID retrieved, make subsequent GET requests to endpoints like /cases/{case_system_id} and /cases/{case_system_id}/audit-trail. These endpoints provide the detailed status changes, resolution details, and user actions associated with the case.
Map Raw Data to Activities: This is a critical transformation step. Write logic to iterate through the API response data (case details, audit trail) for each case. Map specific status changes, result codes, and audit events to the required business activities. For example, a case creation event becomes Screening Request Created, and a result resolution of False Positive becomes False Positive Confirmed.
Combine Data Sources: Merge the data extracted from World-Check with the data from your source system (from step 3). Use the CustomerApplication ID as the common key to create a complete end-to-end event log for each customer.
Structure and Enrich Data: Assemble all the mapped events into a single list of records. For each record, ensure all required attributes (CustomerApplication, ActivityName, EventTime) and recommended attributes are populated. Calculate EventEndTime where possible, perhaps by using the timestamp of the next event for that case.
Export to CSV: Convert the final list of event records into a pandas DataFrame. Reorder the columns to match the required format and export the DataFrame to a CSV file. Ensure the file is saved with UTF-8 encoding to be compatible with ProcessMind.

Configuration

API Credentials: A valid API Key and API Secret for the World-Check One Screening API are required. These must be provisioned with the necessary permissions to read case and audit data.
API Base URL: The script must be configured with the correct base URL for your World-Check API environment, for example, https://api.world-check.com/v2/.
Date Range: Implement start_date and end_date parameters in the script to control the extraction period. For initial analysis, a range of 3 to 6 months is recommended. For ongoing monitoring, run the script incrementally for shorter periods, like the previous day or week.
Source System Connection: Connection details for the upstream and downstream systems (e.g., CRM, core banking platform) are needed to fetch the non-screening events. This could be a database connection string or another API endpoint and credentials.
Pagination Handling: The script must specify a page size, often called limit, when making API calls to list cases. A value between 50 and 100 is typically efficient. The logic must properly handle retrieving all pages.

a Sample Query python

import requests
import pandas as pd
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># --- Configuration and Placeholders ---
WC_API_KEY = class="hl-string">'[Your World-Check API Key]'
WC_API_SECRET = class="hl-string">'[Your World-Check API Secret]'
WC_API_BASE_URL = class="hl-string">'https://api.world-check.com/v2' class=class="hl-string">"hl-comment"># Use correct URL for your environment

class=class="hl-string">"hl-comment"># Date range for the extraction
START_DATE = (datetime.now() - timedelta(days=90)).strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
END_DATE = datetime.now().strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

class=class="hl-string">"hl-comment"># --- MOCK FUNCTIONS (Replace with actual data source connections) ---

def get_source_system_events(application_ids):
    class="hl-string">"""Simulates fetching pre- and post-screening events from a CRM or core system."""
    print(fclass="hl-string">'Fetching source system events for {len(application_ids)} applications...')
    mock_events = []
    for i, app_id in enumerate(application_ids):
        class=class="hl-string">"hl-comment"># Simulate initial application events
        mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Submitted', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i+5)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Sales'})
        class=class="hl-string">"hl-comment"># Simulate final outcome events
        if i % 3 == 0:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Approved', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Onboarding'})
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Account Activated', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i-1)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Operations'})
        else:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Rejected', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Compliance'})
    return mock_events

def get_worldcheck_cases(token):
    class="hl-string">"""Simulates fetching a list of cases from the World-Check API."""
    print(class="hl-string">'Fetching World-Check cases...')
    class=class="hl-string">"hl-comment"># In a real implementation, you would call GET /cases with date filters and handle pagination
    mock_case_list = [
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-001', class="hl-string">'name': class="hl-string">'John Doe', class="hl-string">'caseSystemId': class="hl-string">'WC-001', class="hl-string">'customReference': class="hl-string">'APP-1001', class="hl-string">'creationDate': class="hl-string">'2023-10-01T10:00:00Z', class="hl-string">'riskLevel': class="hl-string">'Medium'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-002', class="hl-string">'name': class="hl-string">'Jane Smith', class="hl-string">'caseSystemId': class="hl-string">'WC-002', class="hl-string">'customReference': class="hl-string">'APP-1002', class="hl-string">'creationDate': class="hl-string">'2023-10-02T11:30:00Z', class="hl-string">'riskLevel': class="hl-string">'Low'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-003', class="hl-string">'name': class="hl-string">'Peter Jones', class="hl-string">'caseSystemId': class="hl-string">'WC-003', class="hl-string">'customReference': class="hl-string">'APP-1003', class="hl-string">'creationDate': class="hl-string">'2023-10-03T09:05:00Z', class="hl-string">'riskLevel': class="hl-string">'High'}
    ]
    return mock_case_list

def get_worldcheck_case_details(case_system_id, token):
    class="hl-string">"""Simulates fetching the audit trail and results for a single World-Check case."""
    print(fclass="hl-string">'Fetching details for case {case_system_id}...')
    class=class="hl-string">"hl-comment"># This mock data simulates a complex history for one case to generate multiple activities
    if case_system_id == class="hl-string">'WC-001':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:05:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:06:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T14:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T15:30:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as False Positive', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T11:00:00Z', class="hl-string">'event': class="hl-string">'ESCALATED', class="hl-string">'details': class="hl-string">'Case escalated to senior analyst', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T09:00:00Z', class="hl-string">'event': class="hl-string">'INFORMATION_REQUESTED', class="hl-string">'details': class="hl-string">'Additional documents requested', class="hl-string">'user': class="hl-string">'senior_analyst'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-05T16:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'senior_analyst'}
            ]
        }
    elif case_system_id == class="hl-string">'WC-003':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:10:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:11:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T10:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T11:25:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as True Positive', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T12:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed with matches', class="hl-string">'user': class="hl-string">'analyst2'}
            ]
        }
    else: class=class="hl-string">"hl-comment"># Simple class="hl-string">'Clear' case
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:35:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:36:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'SYSTEM'}
            ]
        }

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def main():
    class="hl-string">"""Main function to run the extraction process."""
    class=class="hl-string">"hl-comment"># 1. Authenticate (real implementation)
    class=class="hl-string">"hl-comment"># token = get_wc_auth_token()
    token = class="hl-string">'mock_token' class=class="hl-string">"hl-comment"># Using a mock token for this example

    class=class="hl-string">"hl-comment"># 2. Get list of cases from World-Check
    cases = get_worldcheck_cases(token)
    if not cases:
        print(class="hl-string">'No cases found for the specified period.')
        return

    event_log = []

    class=class="hl-string">"hl-comment"># 3. Process each case from World-Check
    for case in cases:
        app_id = case.get(class="hl-string">'customReference')
        if not app_id:
            continue

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Screening Request Created' event
        event_log.append({
            class="hl-string">'CustomerApplication': app_id,
            class="hl-string">'ActivityName': class="hl-string">'Screening Request Created',
            class="hl-string">'EventTime': case[class="hl-string">'creationDate'],
            class="hl-string">'ReviewerId': class="hl-string">'SYSTEM',
            class="hl-string">'DepartmentName': class="hl-string">'Compliance',
            class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
        })

        details = get_worldcheck_case_details(case[class="hl-string">'caseSystemId'], token)
        for event in details.get(class="hl-string">'auditTrail', []):
            activity = None
            user = event.get(class="hl-string">'user', class="hl-string">'SYSTEM')
            department = class="hl-string">'Compliance' if user != class="hl-string">'SYSTEM' else class="hl-string">'System'
            
            class=class="hl-string">"hl-comment"># 4. Map audit trail events to activities
            if event[class="hl-string">'event'] == class="hl-string">'AUTOMATED_SCREENING':
                activity = class="hl-string">'Automated Screening Performed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_FOUND':
                activity = class="hl-string">'Potential Match Identified'
            elif event[class="hl-string">'event'] == class="hl-string">'REVIEW_STARTED':
                activity = class="hl-string">'Analyst Review Started'
            elif event[class="hl-string">'event'] == class="hl-string">'INFORMATION_REQUESTED':
                activity = class="hl-string">'Additional Information Requested'
            elif event[class="hl-string">'event'] == class="hl-string">'ESCALATED':
                activity = class="hl-string">'Case Escalated for Review'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'False Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'False Positive Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'True Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'True Match Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'Clear' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Clear'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'matches' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Match Found'

            if activity:
                event_log.append({
                    class="hl-string">'CustomerApplication': app_id,
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': event[class="hl-string">'timestamp'],
                    class="hl-string">'ReviewerId': user,
                    class="hl-string">'DepartmentName': department,
                    class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
                })
    
    class=class="hl-string">"hl-comment"># 5. Get events from source system
    application_ids = [case[class="hl-string">'customReference'] for case in cases if case.get(class="hl-string">'customReference')]
    source_events = get_source_system_events(application_ids)
    event_log.extend(source_events)

    class=class="hl-string">"hl-comment"># 6. Create and format DataFrame
    if not event_log:
        print(class="hl-string">'No events were generated.')
        return

    df = pd.DataFrame(event_log)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Add EventEndTime by shifting the EventTime of the next event
    df[class="hl-string">'EventEndTime'] = df.groupby(class="hl-string">'CustomerApplication')[class="hl-string">'EventTime'].shift(-1)
    
    class=class="hl-string">"hl-comment"># Add placeholder for non-extractable attribute
    df[class="hl-string">'SlaTargetDate'] = pd.NaT

    class=class="hl-string">"hl-comment"># 7. Finalize and Export
    output_columns = [
        class="hl-string">'CustomerApplication',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'EventEndTime',
        class="hl-string">'ReviewerId',
        class="hl-string">'DepartmentName',
        class="hl-string">'RiskLevel',
        class="hl-string">'SlaTargetDate'
    ]
    class=class="hl-string">"hl-comment"># Ensure all required columns exist, even if empty
    for col in output_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[output_columns]

    output_filename = class="hl-string">'event_log_worldcheck.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%fZ')
    print(fclass="hl-string">'Successfully exported event log to {output_filename}')

if __name__ == class="hl-string">'__main__':
    main()

Your KYC Customer Onboarding Data Template

Your KYC Customer Onboarding Data Template

KYC Customer Onboarding Attributes

KYC Customer Onboarding Activities

Extraction Guides

Refinitiv World-Check One Case and Audit Log Export

Steps

Configuration

a Sample Query config

Python Script using the World-Check One Screening API

Steps

Configuration

a Sample Query python

Ready to Get Started?

Optimize KYC Customer Onboarding Now, Boost Compliance

Your KYC Customer Onboarding Data Template

Your KYC Customer Onboarding Data Template

KYC Customer Onboarding Attributes

KYC Customer Onboarding Activities

Extraction Guides

Refinitiv World-Check One Case and Audit Log Export

Steps

Configuration

a Sample Query config

Python Script using the World-Check One Screening API

Steps

Configuration

a Sample Query python

We value your privacy

Ready to Get Started?

Optimize KYC Customer Onboarding Now, Boost Compliance