> 持续流程改进 > KYC 客户开户 > Refinitiv World Check > 数据模板

您的 KYC 客户入职数据模板

Refinitiv World-Check

← 返回改进指南

KYC 客户开户属性 (20) KYC 客户开户活动 (14) 提取指南 (2)

您的 KYC 客户入职数据模板

此模板将引导您收集用于分析 KYC 客户开户流程的核心数据。它概述了需要捕获的关键属性、需要跟踪的核心活动，并提供了如何从源系统中提取这些信息的指导。利用此资源，确保您拥有进行有效流程分析和改进所需的全部数据。

建议收集的属性
需要追踪的关键活动
提取指南

不熟悉事件日志？了解如何创建流程挖掘事件日志.

下载模板

KYC 客户开户属性

为了进行全面的 KYC 客户开户分析，建议在事件日志中包含以下数据字段。

3 必填 5 推荐 12 可选

	名称	描述
	Event 时间 EventTime	指示特定活动或事件发生时间的时间戳。
描述 “Event Time”提供活动记录的精确日期和时间。此 timestamp 是流程的时间主干，支持对 event 进行正确排序以重建 case 历史记录。此属性对于 Process Mining 中所有基于时间的分析都至关重要。它用于计算活动之间的时长（周期时间和等待时间）、衡量整体 case 时长、分析流程绩效随时间的变化，以及检查对服务水平协议 (SLA) 的遵守情况。如果没有准确的 timestamp，就无法了解流程绩效并识别时间上的瓶颈。为何重要每项活动的时间戳对于计算所有基于时长的指标、发现流程顺序以及执行瓶颈分析至关重要。获取方式这是任何事件日志或审计追踪表中的标准字段，通常命名为“Timestamp”、“EventDate”或“CreationDate”。示例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	客户申请 CustomerApplication	单个客户开户申请的唯一标识符，作为主案例 ID。
描述 Customer Application 是核心案例标识符，它将与单个客户开户旅程相关的所有事件和活动归组。它能够按时间顺序完整跟踪每个客户在整个 Know Your Customer (KYC) 流程中的进度，从初次提交到最终决策。在流程挖掘分析中，此属性是重构每笔申请端到端旅程的基础。它支持流程流向的可视化、总周期时间的计算以及流程变体的识别。通过按此标识符分析案例，企业可以了解申请可能采取的不同路径、识别瓶颈并对比各种开户流程的效率。为何重要这是连接所有相关活动的核心案例标识符，使得分析端到端的客户开户流程成为可能。获取方式此标识符通常是 Refinitiv World-Check 系统或集成 CRM 中主申请表或案例管理表的主键。示例 APP-2023-00123APP-2023-00124APP-2023-00125
	活动名称 ActivityName	KYC 开户流程中发生的特定业务事件或任务的名称。
描述 Activity Name 描述了客户开户旅程中的单个步骤或事件，例如“Application Submitted”、“Analyst Review Started”或“Screening Completed - Clear”。这些活动构成了流程图的节点，提供了端到端工作流的详细分解。分析活动是流程挖掘的核心。通过跟踪不同活动的顺序和频率，分析师可以发现真实的流程流向、识别常见路径、检测对标准程序的偏差，并精准定位导致延迟或返工的具体步骤。此属性对于构建流程图和计算活动级指标至关重要。为何重要此属性定义了流程的各个步骤，对于发现和可视化流程流向以及识别瓶颈至关重要。获取方式此信息通常存在于事件日志或审计追踪表中，通常与案例管理实体的状态变更相关联。示例识别到潜在匹配分析师审核已开始确认为误报申请已批准
	SLA 目标日期 SlaTargetDate	客户开户流程应完成的目标日期。
描述 SLA Target Date 是根据客户服务协议或内部政策定义的完成整个开户案例的截止日期。此日期是衡量实际完成时间的基准。此属性是“SLA Adherence and Breach Analysis”仪表板的基础。它用于计算案例是否按时完成。分析 SLA 违规情况有助于识别流程中导致延迟的系统性问题，并允许企业采取纠正措施，提高及时性并满足合规要求。为何重要这是衡量按时完成绩效的基准，对于计算 SLA 遵循率和分析违规情况至关重要。获取方式此日期通常根据申请提交日期和业务规则计算得出，可能作为案例记录中的一个字段存储。示例 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
	事件结束时间 EventEndTime	指示特定活动或事件完成时间的精确时间戳。
描述 Event End Time 标记活动的完成。虽然许多事件可以建模为瞬时发生（即开始时间等于结束时间），但某些活动具有可衡量的持续时间，如“Analyst Review Started”和“Analyst Review Completed”。同时具备开始和结束时间可以精确测量处理时间。在流程分析中，结束时间对于计算活动的精确处理时间（而非包含等待时间的周期时间）至关重要。这有助于区分案例是在被积极处理，还是在队列中闲置。这是资源优化和效率分析的关键。为何重要支持精确计算活动处理时间，将实际工作时间与闲置等待时间分开，从而实现更准确的绩效分析。获取方式对于有耗时的活动，这可能存储在 event 日志或 audit trail 表中诸如“CompletionDate”或“EndDate”之类的独立字段中。示例 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	审核员 ID ReviewerId	执行该活动的个人用户、分析师或自动化代理的标识符。
描述 Reviewer ID（或用户）指明了谁执行了 KYC 流程中的特定任务。这可以是一名合规分析师、一名开户专家，或者用于自动化活动的系统账户。跟踪此信息可以提高工作量分配和个人绩效的可见性。此属性对于基于资源的分析至关重要。它有助于了解不同用户或团队之间的绩效差异、识别培训需求并优化工作负载平衡。它也是分析交接、社交网络以及合规资源利用率的关键组件。为何重要允许分析工作量分布、用户绩效和部门交接，这对于资源优化至关重要。获取方式通常存在于事件日志或审计追踪中，字段名通常为“UserID”、“PerformedBy”或“Owner”。示例 analyst_jdoesystem_auto_screenermanager_bsmith
	部门 DepartmentName	负责执行该活动的部门或职能团队。
描述此属性指定了用户所属的业务单元或团队，例如“Onboarding”、“Compliance”或“Quality Assurance”。它允许在比个人用户更高层的组织级别进行分析。按部门进行分析对于识别部门间的瓶颈和衡量交接时间至关重要。它有助于可视化工作在不同团队之间的流转情况，以及在这些过渡中哪里发生了延迟。该视图对于精简跨职能协作和提高整体流程效率具有不可估量的价值。为何重要支持按部门进行流程绩效分析，对于识别不同团队间交接延误至关重要。获取方式此信息可能存储在系统的用户档案或关联的 HR 系统中，可能需要使用用户 ID 将其与事件数据关联起来。示例开户团队合规审查高层管理
	风险等级 RiskLevel	计算出的客户申请风险等级，例如低、中、高。
描述 Risk Level 是 KYC 流程中的关键信息，决定了所需的尽职调查水平。它通常根据客户类型、地理位置和业务性质等因素确定。此分类会显著影响申请所采取的流程路径。在流程分析中，按风险等级细分案例必不可少。它有助于解释周期时间和流程流向的差异，例如，高风险申请可能需要更多步骤且耗时更长。此属性对于“Application Rejection Rate and Reasons”和“Background Check Initiation Cycle Time”仪表板至关重要，能帮您理解风险如何影响最终结果和效率。为何重要按风险等级对流程进行细分至关重要，这有助于理解为什么某些案例耗时更长或走不同的路径，并便于分析拒绝率。获取方式这是客户申请或案例记录中的核心数据点。请参阅 Refinitiv World-Check 中的案例管理模块。示例低中高
	SLA 违约 SlaBreached	一个布尔标志，指示开户 case 是否在 SLA 目标日期之后完成。
描述此属性是一个计算得出的标记，用于指示案例是否违反了服务水平协议（SLA）。它是通过对比最终完成活动（如“Application Approved”或“Application Rejected”）的时间戳与案例的“SlaTargetDate”来确定的。此标记是“SLA Adherence and Breach Analysis”仪表板和“SLA Adherence Rate”KPI 的基础。它通过允许用户快速筛选所有违规案例来简化分析。通过分析违规案例的流程特征，企业可以识别延迟的根本原因并有效地集中改进力量。为何重要直接衡量对服务水平协议的遵守情况，支持对延迟 case 进行轻松过滤和根本原因分析。获取方式这是在数据转换期间通过将案例的最终活动时间戳与 SlaTargetDate 字段进行对比来计算的。示例 truefalse
	最后数据更新 LastDataUpdate	该事件数据最后一次从源系统刷新或提取的时间戳。
描述此属性表示数据的新鲜度。它记录了最后一次从 Refinitiv World-Check 提取数据的日期和时间。这对于理解流程挖掘仪表板和分析的时效性非常重要。出于分析目的，这让用户知道他们看到的是近乎实时的数据，还是特定时间点的快照。这对于数据治理和管理用户对洞察即时性的预期至关重要。为何重要提供关于数据新鲜度的关键背景信息，确保用户了解流程分析的即时性。获取方式此时间戳是在数据提取（ETL）过程中生成并添加的。示例 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	匹配 ID MatchId	World-Check 筛查过程中发现的潜在匹配的唯一标识符。
描述当自动化筛查程序发现与制裁名单、政治敏感人物 (PEP) 名单或不良媒体信息存在潜在匹配时，通常会生成一个 Match ID 以追踪特定结果。该 ID 将申请案件与触发警报的 World-Check 数据库中的特定记录关联起来。该属性对于详细的合规分析非常有用。它允许分析人员调查匹配的性质，追踪特定警报的处理进度（例如，确认是误报还是真实匹配），并了解哪些类型的警报最常见或处理时间最长。它为“识别到潜在匹配”活动提供了更深层次的细节。为何重要提供与特定筛查结果的细粒度关联，支持对匹配解决时间和警报类型的深入分析。获取方式当发现潜在匹配时，此 ID 将由 World-Check 筛查引擎生成，并记录在申请案例中。示例 WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	客户ID CustomerId	正在办理开户的客户实体的唯一标识符。
描述 Customer ID 是客户档案的唯一标识符。这与 Customer Application ID 不同，因为一个客户可能会随着时间推移提交多笔申请。此属性将开户流程与客户主记录关联起来。在分析中，Customer ID 允许跟踪同一客户的重复申请，并可用于利用 CRM 或主数据系统中的其他客户属性来丰富流程数据。这使得能够超越单一开户案例，从更全面的角度审视客户旅程。为何重要将开户案例与特定客户关联，支持对重复申请的分析，并可利用客户主数据进行丰富补充。获取方式该字段是申请或案件记录中的关键字段，用于关联客户主数据。示例 CUST-98765CUST-98766CUST-98767
	客户国家/地区 CustomerCountry	客户的居住国或注册国。
描述此属性表示客户的地理位置。在 KYC 流程中，国家是风险评估和监管要求的重要因素。不同司法管辖区的规则不同，这会影响流程流向和时长。按国家分析流程允许企业比较不同地区的绩效，识别特定地区的瓶颈，并确保符合当地法规。它为流程分析提供了地理维度，可以揭示重要的业务差异。为何重要支持流程的地理分析，有助于识别不同地区在绩效、风险和合规要求方面的差异。获取方式这是客户档案或申请表上的标准字段。示例美国GBR新加坡DEU
	客户类型 CustomerType	客户类别，例如个人、公司或信托。
描述 “客户类型”对正在办理开户的实体进行分类。不同类型的客户通常有不同的开户要求、风险状况和监管义务。例如，企业法人的开户通常比个人开户更复杂。此属性用于细分分析，特别是“KYC 客户类型绩效”仪表板。它允许跨不同客户细分群体比较流程效率、周期时间和拒绝率。这有助于机构为特定客户类型量身定制并优化开户体验。为何重要允许在不同客户细分群体之间进行绩效比较，有助于为每种类型的客户量身定制并优化开户流程。获取方式这是存储在源系统客户或申请记录中的基础属性。示例个人客户企业法人非营利组织信任
	拒绝原因 RejectionReason	客户申请被拒绝时提供的具体原因。
描述当申请被拒绝时，“拒绝原因”记录了决策依据。原因可能包括“制裁匹配”、“资料不全”或“高风险概况”。这为入职申请质量和筛查流程的有效性提供了宝贵的结构化反馈。该属性是“申请拒绝率及原因”仪表板的主要驱动因素。通过分析这些原因，可以找出拒绝的根本原因，进而推动流程改进、优化与申请人的沟通，并可能减少不必要的拒绝。它为定量的拒绝率 KPI 提供了定性的背景信息。为何重要提供申请被拒绝的根本原因，这对于识别开户流程中的改进点以降低拒绝率至关重要。获取方式该信息通常在“申请被拒绝”事件发生时记录，通常作为案件或申请记录中的一个字段。示例 PEP 匹配制裁名单命中文档验证失败负面新闻
	是否已自动化 IsAutomated	一个标志，指示该活动是由系统执行的 (true) 还是由人工执行的 (false)。
描述此布尔属性用于区分系统自动化任务和用户执行的人工活动。例如，“Automated Screening Performed”将被标记为自动化，而“Analyst Review Started”将被标记为人道。这种区分对于自动化分析至关重要。它有助于衡量自动化对流程效率的影响，识别哪些人工任务是未来自动化的候选对象，并了解人类与系统参与者之间的交互。它允许将系统处理时间与人工处理时间清晰地分开。为何重要区分系统活动和人工活动，这是衡量自动化影响并发现新自动化机会的关键。获取方式这通常是根据活动名称或与事件关联的用户 ID 推断得出的（例如，如果用户是“system”账户）。示例 truefalse
	是否返工 IsRework	一个标志，指示在同一个 case 中，该活动是否是第二次或后续执行。
描述 IsRework 是一个计算得出的布尔属性，用于识别同一客户申请案例中是否存在重复活动。例如，如果单笔申请中多次执行了“Risk Assessment Performed”，则后续操作将被标记为返工。该属性对于识别流程效率低下、循环和不必要的重复至关重要。它直接支持“Risk Assessment Rework and Efficiency”仪表板和“Risk Assessment Rework Rate”KPI。分析返工有助于发现质量、信息清晰度或决策方面的问题，这些问题会导致精力浪费并延长周期。为何重要通过标记重复活动来突出流程中的低效环节，支持对返工循环的分析，从而提高质量并缩短周期时间。获取方式这是在数据转换期间通过分析每个案例中的活动序列并标记活动的任何非初次出现来计算的。示例 truefalse
	活动处理时间 ActivityProcessingTime	在一项活动上实际投入工作的时间长度。
描述此指标计算一项活动从开始到结束所需的实际时间。它是 EventEndTime 与 EventTime 之间的差值。这衡量了任务的“触达时间”或实际工作时间。此计算属性对于性能分析必不可少，并用于许多 KPI，包括“Avg Doc Review Cycle Time”和“Avg Compliance Review Cycle Time”。它有助于区分任务是处于积极处理中，还是在队列中等待。这是识别真实处理低效和进行容量规划的基础。为何重要衡量单项活动的实际工作时间。这有助于精准识别哪些特定任务最耗时，将其与等待时间区分开来。获取方式这是在数据转换期间通过从活动的结束时间戳减去开始时间戳来计算的（例如：EndTime - StartTime）。示例 PT1H30MP2DT4H15MPT25M
	源系统 SourceSystem	提取事件数据的系统，在本例中为 Refinitiv World-Check。
描述此属性标识了流程数据的来源。虽然在单一数据源提取中它可能是一个固定值，但当来自多个系统（如 CRM 和 World-Check）的数据合并以创建全局流程视图时，它就变得至关重要。在分析中，这有助于数据治理、故障排查和理解数据背景。例如，在核心筛查系统中记录的活动可能与在外围系统中记录的活动具有不同的属性或详细程度。它确保了数据血缘清晰且可审计。为何重要识别数据来源，这对于数据治理、校验以及合并多源数据至关重要。获取方式这通常是在数据提取、转换和加载（ETL）过程中添加的静态值，用于标记数据集。示例 Refinitiv World-CheckWorldCheckOne
	申请渠道 ApplicationChannel	客户提交申请的渠道，例如网上门户、线下网点或移动应用。
描述 Application Channel 指明了客户申请的提交来源。不同渠道的数据完整性、质量和客户画像各不相同，这会影响后续流程。此属性对于“Application Throughput by Channel”仪表板至关重要。通过分析不同渠道的申请量、周期时间和结果，企业可以识别哪些渠道最高效，哪些渠道可能需要改进。这种分析为资源分配和渠道投资等战略决策提供了依据。为何重要帮助分析不同提交渠道的性能和效率，为技术投入和客户体验相关的战略决策提供依据。获取方式此信息通常在流程开始时捕获，并作为属性存储在申请记录中。示例在线门户移动应用线下网点客户经理

必填推荐可选

KYC 客户开户活动

为实现精准的流程发现，建议在事件日志中记录以下关键步骤与里程碑。

8 推荐 6 可选

	活动	描述
	分析师审核已开始	合规 analyst 开始对客户申请的潜在匹配项进行人工调查。这包括根据客户信息评估潜在匹配项的详情，以确定相关性。
为何重要这标志着人工合规审查的开始，这是一个常见的瓶颈。测量从“Potential Match Identified”到此活动的时间可以揭示排队延迟，而审查本身的持续时间则反映了分析师的效率。获取方式当分析师从审核队列中“认领”或打开案例时，可以推断出此活动。当案例状态变更为“In Review”或分配给特定用户时，系统可能会在审计追踪中明确记录此事件。捕获根据案例状态变更为“Under Review”或分配给分析师的情况推断得出。事件类型 inferred
	已提交申请	此活动标志着客户提交申请，KYC 开户流程正式启动。此事件通常记录在 CRM 或核心申请系统中，随后触发 Refinitiv World-Check 中的筛查流程。
为何重要这是端到端客户开户旅程的首要启动事件。分析从这一点到完成的时间可以得出整体开户周期，这对于衡量客户体验和 SLA 遵循情况至关重要。获取方式此事件非 World-Check 原生。它必须源自上游系统（如 CRM 或客户账户管理平台），并通过 Customer Application ID 进行关联。捕获初始提交时记录在源申请系统中的 event。事件类型 explicit
	申请已拒绝	客户申请被正式拒绝，通常是因为 World-Check 中“发现匹配”或其他风险因素。此事件是开户流程的最终负面结果。
为何重要这是流程的主要失败终点。分析拒绝事件（特别是原因和前置活动）对于改进流程和减少不必要的拒绝至关重要。获取方式此最终业务决策记录在上游 CRM 或核心申请系统中，而非 World-Check 本身。数据必须从该系统获取。捕获记录在源申请系统中的 event，通常带有相应的拒绝原因代码。事件类型 explicit
	确认匹配	analyst 确认潜在匹配项确实是被筛查的客户，从而识别出潜在风险。这是一个关键里程碑，通常会触发进一步的尽职调查或拒绝申请。
为何重要这是关键的风险缓解结果，也是流程中的核心时刻。它直接影响客户申请的最终决策，对于合规报告和分析至关重要。获取方式这是一项明确的用户操作，分析师将特定匹配处置为“True Match”或“Confirmed Match”。此事件记录在案例审计追踪中。捕获当分析师在系统中正式确认匹配时记录。事件类型 explicit
	筛查完成 - 发现匹配	筛查案例正式以“Match Found”结果结案，表明已识别出确认的风险。此决定会触发不同的后续流程，例如加强尽职调查或直接拒绝。
为何重要这是筛查流程的主要“负面路径”终点。分析这些案例有助于理解风险画像以及筛查控制措施的有效性。获取方式根据最终案例状态变更为“Match Found”、“Risk Identified”或“Closed - Positive”推断得出。使用该最终状态变更的时间戳。捕获源自最终 case 状态的 timestamp，指示确认为匹配项。事件类型 inferred
	筛查完成 - 无记录	筛查案例正式以“Clear”结果结案，意味着未发现真实匹配。此决定将反馈给源系统，允许开户流程继续进行。
为何重要此活动代表筛查流程成功完成（即“理想路径”）。它是衡量标准低风险申请周期时间的关键终点。获取方式根据最终案例状态变更为“Clear”、“Complete”或“Closed - No Match”推断得出。使用该最终状态变更的时间戳。捕获源自最终 case 状态的 timestamp，指示结果正常。事件类型 inferred
	筛查请求已创建	在 Refinitiv World-Check 系统中为客户申请正式创建一个新的 screening case。这由上游系统的 API 调用或人工输入触发，代表风险情报检查的开始。
为何重要这标志着筛查子流程的正式开始。从提交申请到此活动之间的时间揭示了业务线系统与合规职能部门之间交接的延迟。获取方式记录在 World-Check 案例管理日志或审计追踪中。使用特定案例或实体 ID 的创建事件及其时间戳。捕获系统中创建新的筛查案例时自动记录。事件类型 explicit
	账户已激活	客户账户在核心系统中创建并激活，完成开户旅程。此步骤在申请最终获批后进行，标志着账户已可供使用。
为何重要这是流程中最终的价值交付步骤。从提交申请到账户激活的时长是衡量运营效率和客户满意度的关键指标。获取方式 World-Check 不捕获此事件。它记录在核心银行或客户账户系统中，必须通过 Customer Application ID 进行关联。捕获账户激活时记录在核心账户系统中的 event。事件类型 explicit
	Case 已上报审核	初级 analyst 将复杂或高风险的 case 上报给高级 analyst 或经理进行最终决策。这是合规团队内部的一个关键交接点。
为何重要上报往往会造成瓶颈并增加周期时间。分析上报的频率和原因可以凸显初级 analyst 的培训需求，或发现审核政策中含义模糊的地方。获取方式记录为案例工作流或审计追踪中的明确操作。也可以通过案例分配用户的变更（特别是分配给更高权限的用户）来推断得出。捕获通过案例中专门的“Escalate”按钮或工作流操作记录。事件类型 explicit
	已执行自动筛查	World-Check 系统会自动根据其风险情报数据库筛查客户详情。这是一项系统驱动的活动，会生成初始结果，例如潜在匹配或“Clear”状态。
为何重要此活动是筛查流程中的第一个增值步骤。此点之前的延迟通常表示系统或数据就绪存在问题，而其结果决定了后续的人工工作量。获取方式此事件可能在案例审计追踪中明确记录，或者根据案例获得初始筛查结果的时间戳推断得出。捕获自动化数据库扫描完成后生成的系统日志条目。事件类型 explicit
	申请已批准	在 KYC 筛查及其他必要检查成功后，客户申请已获得最终批准。此事件通常在源系统中收到 World-Check 的“Clear”结果后发生。
为何重要这标志着开户流程成功的业务结果。跟踪从提交申请到此环节的时间可以揭示新客户审核的完整周期。获取方式此事件非 World-Check 原生。它必须源自做出最终业务决策的上游 CRM 或核心申请系统。捕获最终批准时记录在源申请系统中的 event。事件类型 explicit
	确认为误报	分析师认定潜在匹配对象并非正在接受筛查的客户。匹配被排除，该特定警报的筛查过程宣告解决。
为何重要这代表了审核流程的一种常见结果。了解处置误报（false positives）所需的时间有助于衡量分析师效率和自动化筛查逻辑的准确性。获取方式这是一项明确的用户操作，分析师将特定匹配处置为“False Positive”或“Not a Match”。此操作通常记录在案例历史中。捕获当分析师在系统中正式排除潜在匹配时记录。事件类型 explicit
	识别到潜在匹配	自动筛查过程发现了一个或多个需要分析师人工审核的潜在匹配。此事件将案例从自动化状态转入人工调查队列。
为何重要此活动是流程中的关键分支点。存在潜在匹配的案例会走一条更长、更复杂的路径，跟踪这一点有助于审核团队的资源规划和瓶颈分析。获取方式根据 World-Check 案例管理模块中状态变更为“Review Required”、“Potential Match”或类似状态推断得出。捕获源自 case 状态变更，指示现在需要人工复核。事件类型 inferred
	请求补充信息	分析师判定需要更多信息才能解决潜在匹配问题，并向业务部门提出请求。这会使案例处于挂起状态，直到信息提供为止。
为何重要该活动频繁发生，说明用于筛查的初始数据质量存在问题。由于该活动依赖外部团队，它会引入重大延误，是导致周期时间过长的主要原因。获取方式这可能是在案例备注或审计日志中记录的明确用户操作。或者，也可以从案例状态变更为“Pending Information”或“RFI”中推断得出。捕获当分析师使用系统功能标记案例需要补充信息时记录。事件类型 explicit

推荐可选

提取指南

如何从 Refinitiv World-Check 获取数据

步骤

登录 World-Check One：使用您的凭据访问 Refinitiv World-Check One 门户。
进入 Case Management：打开 Case Management 板块，这里存储并管理所有的 screening cases。
准备 Case Report 导出：进入 Case Management 中的报告或导出功能。该功能可能被标记为“Export Cases”或“Case Report”。
配置 Case Report：选择要导出的列。确保选中了与 Case ID (CustomerApplication)、创建日期、解决日期、case 状态（如：Clear、Match Found）和风险等级对应的字段。
导出 Case Management 数据：定义日期范围，通常涵盖过去 3 到 6 个月的活动。应用任何必要的过滤器，如按用户组或 case 类型过滤。将数据导出为 CSV 文件，并命名为 case_report.csv。
准备 Audit Trail 导出：进入 World-Check One 的 audit trail 或 audit log 报告板块。这里包含每个 case 的详细 event 历史记录。
配置并导出 Audit Trail：选择所有相关列，包括 Case ID、event 名称或描述、event timestamp 以及执行操作的用户。导出与 case 报告相同日期范围的数据。将文件保存为 audit_trail.csv。
获取外部流程步骤数据：获取发生在 World-Check 之外的活动数据，例如 Application Submitted、Application Approved、Account Activated 和 Application Rejected。这些数据通常来自 CRM 或核心银行系统。导出包含 CustomerApplication ID 和相关 timestamp 的数据。
合并并转换数据：将导出的 CSV 文件（case_report.csv、audit_trail.csv 和外部系统数据）加载到数据准备工具或脚本中。
将 Audit 事件映射到活动：处理 audit_trail.csv 文件。将 audit log 中的原始 event 描述映射到标准化的 ActivityName 值。例如，像“Case Assigned to Analyst”这样的 audit log 条目会变为“Analyst Review Started”。
将 Case 状态变更映射到活动：处理 case_report.csv 文件，根据状态变更生成活动。使用 case 解决日期和最终状态来创建“Screening Completed - Clear”或“Screening Completed - Match Found”事件。
创建最终 Event Log：将来自不同源文件的所有处理后的数据合并到一个 CSV 文件中。确保最终文件包含要求的列：CustomerApplication、ActivityName 和 EventTime，以及任何推荐的属性。保存此文件以便 upload 到流程挖掘工具。

配置

报告类型：您需要生成至少两份独立的报告：一份 Case Management 汇总报告和一份详细的 Audit Trail 报告。
日期范围：进行初步分析时，请选择至少 3-6 个月的日期范围，以获取足够的已完成和进行中的 case。请确保所有导出文件的日期范围保持一致。
导出格式：选择 CSV（逗号分隔值）作为导出格式，以便于后续处理。
关键列（Case 报告）：确保导出的 case 包含 Case ID、创建 timestamp、解决 timestamp、最终状态、分配的 Analyst 和风险等级。
关键列（Audit Trail 报告）：确保导出的 audit log 包含 Case ID、event 描述、event timestamp 和 User ID。
前提条件：需要拥有 World-Check One 门户的访问权限，且用户权限允许查看和导出 case 管理及 audit log 数据。这可能需要比标准 analyst 角色更高的权限。

a 查询示例 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'

步骤

前提条件与环境搭建：确保安装了 Python 3.6+ 以及 requests 和 pandas 库。从您的 Refinitiv 代表或开发者门户获取 World-Check One API Key 和 API Secret。请妥善保存这些凭据。
开发身份验证逻辑：在 Python 脚本中，创建一个向 World-Check One 身份验证端点发送 POST 请求的函数。使用您的 API Key 和 Secret 获取后续 API 调用所需的临时 Bearer Token。
识别源系统数据：流程的开始和结束发生在 World-Check 之外。识别存储初始申请数据的源系统（如 CRM 或核心银行平台）。您需要从该源提取 Application Submitted、Application Approved、Account Activated 和 Application Rejected 等 event。这可以通过数据库查询或另一个 API 来实现。
获取 World-Check Case：使用通过验证的 Token，向 World-Check One API 的 /cases 端点发送 GET 请求。使用查询参数按特定日期范围过滤 case，例如基于它们的创建或修改日期。
处理 API 分页：World-Check API 响应是分页的。您的脚本必须检查响应中的分页详情，并循环遍历所有页面，以检索指定日期范围内的完整 case 列表。
检索 Case 详情与历史记录：对于检索到的每个 case ID，继续向 /cases/{case_system_id} 和 /cases/{case_system_id}/audit-trail 等端点发送 GET 请求。这些端点提供与 case 相关的详细状态变更、解决详情和用户操作。
将原始数据映射到活动：这是一个关键的转换步骤。编写逻辑遍历每个 case 的 API 响应数据（case 详情、audit trail）。将特定的状态变更、结果代码和 audit event 映射到要求的业务活动。例如，case 创建 event 变为 Screening Request Created，结果决议为“False Positive”变为 False Positive Confirmed。
合并数据源：将从 World-Check 提取的数据与来自源系统的数据（步骤 3）合并。使用 CustomerApplication ID 作为公共键，为每个客户创建完整的端到端 event log。
结构化并丰富数据：将所有映射的 event 组装成单个记录列表。对于每条记录，确保填写了所有要求的属性（CustomerApplication、ActivityName、EventTime）和推荐属性。尽可能计算 EventEndTime，例如使用该 case 下一个 event 的 timestamp。
导出为 CSV：将最终的 event 记录列表转换为 pandas DataFrame。重新排列列以符合要求的格式，并将 DataFrame 导出为 CSV 文件。确保文件以 UTF-8 编码保存，以便与 ProcessMind 兼容。

配置

API 凭据：需要有效的 World-Check One Screening API 的 API Key 和 API Secret。这些凭据必须具备读取 case 和 audit 数据的必要权限。
API 基础 URL：脚本必须配置正确的 World-Check API 环境基础 URL，例如 https://api.world-check.com/v2/。
日期范围：在脚本中设置 start_date 和 end_date 参数以控制提取周期。初步分析建议选择 3 到 6 个月。对于日常监测，建议按天或按周增量运行脚本。
源系统连接：需要上游和下游系统（如 CRM、核心银行平台）的连接信息以获取非 screening event。这可以是数据库连接字符串，也可以是其他 API 端点及凭据。
分页处理：在调用 API 获取 case 列表时，脚本必须指定每页大小（通常称为 limit）。通常设为 50 到 100 之间较为高效。逻辑必须能正确处理并检索所有页面。

a 查询示例 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()

您的 KYC 客户入职数据模板

您的 KYC 客户入职数据模板

KYC 客户开户属性

KYC 客户开户活动

提取指南

Refinitiv World-Check One 案例与审计日志导出

步骤

配置

a 查询示例 config

使用 World-Check One Screening API 的 Python 脚本

步骤

配置

a 查询示例 python

准备好开始了吗？

立即优化 KYC 开户流程，提升合规能力

您的 KYC 客户入职数据模板

您的 KYC 客户入职数据模板

KYC 客户开户属性

KYC 客户开户活动

提取指南

Refinitiv World-Check One 案例与审计日志导出

步骤

配置

a 查询示例 config

使用 World-Check One Screening API 的 Python 脚本

步骤

配置

a 查询示例 python

我们重视您的隐私

准备好开始了吗？

立即优化 KYC 开户流程，提升合规能力