KYC客户准入数据模板
KYC客户准入数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- ACTICO数据提取指南
KYC客户准入属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 指示特定活动开始或发生时间的时间戳。 | ||
| 说明 事件时间是活动记录在系统中的准确日期和时间。它确定单个客户申请案例中所有事件的先后顺序，构成客户入职旅程的时间线。 此属性对于所有基于时间的分析都至关重要。它用于计算活动间的周期时间、识别延迟和等待时间、衡量案例总时长，以及检查服务级别协议（SLA）的达成情况。对于同一案例，按时间戳排序后，流程挖掘工具即可重建实际发生的流程顺序。 重要性 此属性确定事件的先后顺序，是计算时长、发现瓶颈和分析流程时间线的基础。 获取途径 此时间戳位于ACTICO的事件日志表中，与每项已记录活动关联。详情请参阅ACTICO文档。 示例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T15:45:10Z | |||
| 客户申请 CustomerApplication | 单个客户入职申请的唯一标识符，作为流程分析中的案例ID。 | ||
| 说明 客户申请是主要案例标识符，用于归集与单个客户入职旅程相关的所有事件和活动。它代表一个完整的KYC流程实例，从最初提交申请到最终批准或拒绝。 在流程挖掘中，此属性对于重建每个申请的端到端旅程至关重要。分析人员可以据此跟踪活动顺序、衡量总周期时间，并比较不同申请所经历的流程路径或变体。具有相同客户申请ID的所有事件都属于同一个案例。 重要性 这是流程挖掘的基础属性，可将所有相关事件关联为一个完整的流程实例，从而端到端分析每位客户的入职体验。 获取途径 这是ACTICO主申请表或案例管理表中的主键。具体表名和字段名称请参阅ACTICO文档。 示例 APP-2023-001234APP-2023-001235APP-2024-000001 | |||
| 活动名称 ActivityName | 客户入职流程中执行的具体业务事件或任务的名称。 | ||
| 说明 此属性记录KYC流程中每个步骤或活动的名称，例如“已提交申请”“已完成风险评估”或“申请已批准”。这些活动构成流程图中的顺序步骤。 分析活动名称有助于将流程顺序可视化、识别常见或少见的活动，并发现瓶颈或返工循环。它是了解具体执行了哪些操作及其顺序的基础，对于流程变体分析和一致性检查至关重要。 重要性 此属性定义流程图中的步骤，可用于呈现流程顺序、识别偏差，并分析活动的频率和顺序。 获取途径 此信息通常位于ACTICO的事件日志表中，常见于描述事件或任务类型的字段。详情请参阅ACTICO文档。 示例 已提交申请已完成风险评估合规审查已完成申请已拒绝 | |||
| 最近数据更新时间 LastDataUpdate | 数据最近一次从源系统刷新或提取的时间戳。 | ||
| 说明 此属性记录最近一次从ACTICO提取数据的日期和时间。它是适用于整个数据集的元数据字段，而非单个事件的属性，可帮助了解分析所用数据的新旧程度。 在仪表板和报告中，这项信息有助于用户判断数据的时效性，合理预期分析结果的更新时间。对于需要近实时数据的运营监控，它也至关重要。显示此时间戳有助于提升数据呈现的透明度和可信度。 重要性 显示数据的时效性，帮助用户判断分析所依据的信息是否为最新数据，这对运营决策至关重要。 获取途径 此值在数据提取、转换和加载（ETL）过程中生成并保存，记录ETL作业成功完成的时间戳。 示例 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| 源系统 SourceSystem | 事件数据来源的记录系统。 | ||
| 说明 此属性用于标识生成数据的源信息系统。对于此流程，该值始终为“ACTICO”；在涉及多个系统的综合分析中，它有助于区分数据来源。 在流程挖掘中，此属性对数据治理和验证至关重要。它可确保数据正确归属到相应来源，这在合并多个系统的数据以全面了解流程时尤为重要。出现数据质量问题时，也可以据此追溯到源系统，便于排查。 重要性 提供数据来源的关键信息，确保数据沿袭清晰、治理有据；合并多个来源的数据时，这一点尤为重要。 获取途径 通常在数据提取和转换过程中添加此静态值（“ACTICO”），用于标记数据集。 示例 ACTICOACTICO平台Actico KYC模块 | |||
| SLA目标日期 SlaTargetDate | 预计完成客户准入流程的日期。 | ||
| 说明 SLA目标日期是根据内部服务级别协议设定的客户准入完成期限。此日期通常根据申请提交日期加上标准处理时长计算得出。 此属性对于监控SLA达成情况至关重要。将案例的实际完成日期与SLA目标日期比较，即可判断案例是否按时完成或违反SLA。这是“客户准入SLA绩效”仪表板和“客户准入SLA达成率”KPI的计算依据。 重要性 提供按时完成的衡量基准，支持直接监控和报告SLA达成情况。 获取途径 此日期可能存储在ACTICO主案例表的字段中，也可能根据业务规则计算得出，例如提交日期加5个工作日。 示例 2023-11-01T17:00:00Z2023-11-02T17:00:00Z2023-11-03T17:00:00Z | |||
| 发起用户 InitiatingUser | 执行活动的员工用户ID或姓名。 | ||
| 说明 此属性用于标识负责执行活动的具体用户或系统代理，并将流程步骤关联到执行者或团队。 按用户分析绩效是常见需求。借助此属性，您可以创建仪表板，查看工作量分布、个人处理时间以及用户或团队之间的绩效差异。它有助于识别绩效突出的员工，以及可能需要额外培训的人员，也是了解资源分配和使用情况的关键依据。 重要性 将流程活动关联到具体用户，支持按个人或团队分析绩效，并帮助发现培训需求或资源分配不均的问题。 获取途径 通常与每个事件一同存储在ACTICO的事件日志或交易历史表中。请查阅ACTICO文档。 示例 john.doejane.smithSYSTEM_USER | |||
| 拒绝原因 RejectionReason | 拒绝客户申请时提供的具体原因。 | ||
| 说明 当申请的最终状态为“已拒绝”时，此属性用于说明拒绝原因，例如“材料不完整”“身份核验未通过”或“风险等级较高”。 此属性对根因分析至关重要。通过分析各类拒绝原因的出现频率，业务团队可以发现流程或客户提交材料中的系统性问题。例如，因材料不完整而被拒的申请较多，可能说明申请指引不够清晰。这项分析可直接支持“申请拒绝率及原因”仪表板。 重要性 揭示申请被拒的原因，支持根因分析，帮助降低拒绝率、提升流程效率。 获取途径 通常位于ACTICO的主案例表或申请表中，且往往仅在申请状态为“已拒绝”时填写。 示例 材料不完整身份核验未通过制裁名单匹配风险评分较高 | |||
| 申请状态 ApplicationStatus | 客户准入申请的最终结果或当前状态。 | ||
| 说明 此属性表示案例的最终处理结果，通常为“已批准”或“已拒绝”，也可显示处理中案例的状态，是按结果分析的重要维度。 了解申请获批或被拒的原因，是KYC流程挖掘的重要目标。借助此属性，您可以筛选流程图，分别查看已批准和已拒绝申请的典型路径，从而发现导致不理想结果的流程模式。它也是计算“申请拒绝率”KPI的依据。 重要性 定义每个案例的处理结果，支持比较成功与未成功的流程实例，并计算拒绝率。 获取途径 这是案例级属性，通常位于ACTICO的主案例表或申请表中，反映申请的最终状态。 示例 已批准已拒绝处理中待补充信息 | |||
| 结束时间 EndTime | 特定活动完成时的时间戳。 | ||
| 说明 结束时间表示活动完成的时刻。将其与开始时间（EventTime）结合，可精确计算每项任务的持续时间，即处理时间。并非所有事件都有明确的结束时间，有些事件会即时完成。 此属性是绩效分析的基础，尤其适用于衡量各步骤耗时。它可用于创建详细的绩效仪表板，帮助识别耗时最长的活动，也是计算“文档审核平均时间”等KPI的必要数据。 重要性 可精确计算活动持续时间（处理时间），有助于识别绩效瓶颈并分析资源使用效率。 获取途径 与开始时间一样，此数据通常位于ACTICO的事件日志表中。有些系统会在同一事件记录中用不同列分别存储开始时间和结束时间。请查阅ACTICO文档。 示例 2023-10-26T10:15:00Z2023-10-26T12:00:00Z2023-10-27T16:00:15Z | |||
| 部门 Department | 负责执行活动的业务部门或团队。 | ||
| 说明 此属性将活动归属到特定组织单元，例如“合规部”“客户准入团队”或“客户关系部”，为流程提供组织层面的背景信息。 按部门分析有助于了解工作如何在组织的不同部分之间交接。您可以据此发现跨部门瓶颈、衡量部门效率并分析各团队的资源分配情况。管理者还可以按部门筛选仪表板，查看团队的具体绩效。 重要性 提供组织维度，支持识别跨部门延误并评估团队绩效。 获取途径 此信息可能直接存储在事件数据中，也可能通过将用户数据与映射用户和部门关系的人力资源主数据表关联得出。请查阅ACTICO文档。 示例 Compliance客户准入团队客户服务部 | |||
| 风险等级 RiskLevel | 客户申请的计算风险等级，例如低、中或高。 | ||
| 说明 此属性表示对客户评估得出的风险类别，通常决定后续KYC流程的复杂程度和审核力度。与低风险客户相比，高风险客户可能需要接受额外检查和审批。 在流程挖掘中，风险等级是重要的比较维度。分析人员可以检查流程是否按预期根据风险等级采用不同路径。例如，可以验证所有高风险客户是否都经过强化尽职调查步骤。此属性是“风险评估流程路径”仪表板的关键依据。 重要性 支持按风险对案例分组，分析流程是否按合规政策要求适应不同风险状况。 获取途径 这是存储在ACTICO主申请表中的关键案例级数据。 示例 低中高 | |||
| SLA状态 SlaState | 计算得出的状态，用于表示案例已达成、已违反或有违反SLA的风险。 | ||
| 说明 此属性按类别评估案例相对于服务级别协议的表现。系统通过将案例完成时间（未结案例则使用当前时间）与“SlaTargetDate”比较得出此状态。 此属性将日期比较结果转化为易于理解的状态，简化SLA报告。仪表板可用饼图或仪表盘清晰展示“已达成”和“已违反”SLA的案例占比。它是“客户准入SLA绩效”仪表板的重要组成部分，也直接支持“客户准入SLA达成率”KPI。 重要性 清晰呈现每个案例的SLA达成状态，简化报告，并便于直观查看实际表现与目标的差距。 获取途径 此属性根据业务逻辑计算得出，比较案例完成时间戳与“SlaTargetDate”。 示例 已达成已违反有风险 | |||
| 国家/地区 Country | 申请客户准入的客户居住国家/地区。 | ||
| 说明 此属性指定客户所在国家/地区，可能对KYC流程产生重要影响。不同司法管辖区的监管要求各异，可能需要增加或调整流程步骤。 按国家/地区分析流程，可以比较不同地区的绩效，发现某些地区是否持续出现周期时间较长或拒绝率较高的情况，这可能反映监管要求带来的阻碍或特定市场挑战。对于希望统一流程、同时满足当地合规要求的全球化组织而言，这一地理维度十分重要。 重要性 提供地理维度，帮助分析不同监管辖区的流程差异和绩效表现。 获取途径 这是存储在ACTICO系统案例或客户级别的核心客户信息。 示例 USADEUGBRSGP | |||
| 客户类型 CustomerType | 客户类别，例如个人或企业。 | ||
| 说明 此属性将申请人划分为不同类别，例如个人或企业。不同类型的KYC流程往往差异显著，企业客户准入通常更为复杂。 将客户类型作为分析维度，可以在同一数据集中清晰区分并比较不同流程。分析人员可以筛选流程图，仅查看“企业”客户，了解其特有的难点、瓶颈和周期时间，避免较简单的“个人”客户流程影响分析结果。 重要性 支持按不同客户类别细分流程。不同类别的流程路径和复杂程度可能相差很大，细分后分析结果会更准确。 获取途径 这是存储在ACTICO案例或客户级别的基础属性。 示例 个人企业小型企业 | |||
| 是否自动执行 IsAutomated | 用于标记活动由系统自动执行还是由用户手动完成。 | ||
| 说明 此布尔属性用于区分由人工用户执行的任务和由系统自动化完成的任务，例如自动背景调查或风险评分。 分析此属性有助于评估自动化举措的成效。您可以比较自动化步骤与人工步骤的处理时间，识别流程中仍高度依赖人工的环节，并发现进一步自动化的机会，从而提升效率、降低运营成本。 重要性 区分人工任务和系统任务，有助于衡量自动化成效并发现进一步提升效率的机会。 获取途径 可根据“发起用户”属性推断，例如用户为“SYSTEM”时；也可能是事件日志中的专用标记。请查阅ACTICO文档。 示例 truefalse | |||
| 是否返工 IsRework | 计算得出的标记，用于识别活动是否为重复步骤或返工循环的一部分。 | ||
| 说明 此布尔属性用于标记同一案例中第二次或后续重复执行的活动，例如在请求补充信息后再次进行“文档审核”。它可识别返工情况，而返工通常是流程效率低下的原因之一。 识别返工是流程挖掘的主要目标之一。借助此标记，您可以量化返工情况，例如计算“文档返工率”KPI。在流程图中突出显示返工循环，可以看出流程在哪些环节反复回退。这有助于定位质量问题，或发现流程未能“一次做对”的环节。 重要性 突出显示重复工作，便于直接衡量流程效率损失，并识别存在质量或说明不清问题的活动。 获取途径 这是计算得出的属性。可在流程挖掘工具中定义逻辑，或在数据转换期间设置逻辑，以检测同一案例中的重复活动。 示例 truefalse | |||
KYC客户准入活动
| 活动 | 说明 | ||
|---|---|---|---|
| 合规审查已完成 | 标志着合规部门完成人工审查，并作出批准、拒绝或要求进一步处理的决定。通常可根据案例状态从“待合规审查”变为“合规已批准”等后续状态来推断此活动。 | ||
| 重要性 这是合规审查阶段的结束事件，对于计算合规审查总时长和分析团队处理量至关重要。 获取途径 可根据申请状态历史日志推断。请查找案例离开“合规审查中”状态时的时间戳，这表示已作出决定。 采集 根据案例状态从“待合规审查”变为“合规已批准”等状态来推断。 事件类型 inferred | |||
| 客户入职已完成 | 这是流程的最后一项活动，表示客户已完成入职，申请案例已关闭。通常可根据案例被设置为“已完成入职”或“已关闭-已批准”等最终状态来推断。 | ||
| 重要性 作为主要的成功结束事件，此活动对于计算所有成功完成入职的客户的端到端周期时间至关重要，也为理想路径分析提供最终时间戳。 获取途径 可根据客户申请案例的最终状态字段推断。请查找案例进入最终成功状态时对应的时间戳。 采集 根据案例最终状态更新为“已完成”或“已关闭”推断。 事件类型 inferred | |||
| 已上传客户文档 | 客户通过门户或其他与ACTICO集成的渠道提交所需身份证明和支持文件时，会发生此活动。每次文档上传通常都会作为独立的明确事件记录在系统的文档管理日志或案例日志中。 | ||
| 重要性 这是一个由客户参与的关键里程碑。跟踪此事件对于衡量客户响应时间和分析后续文档审查阶段的耗时至关重要。 获取途径 请查找与文档处理或案例附件相关的事件日志。这些记录通常保存在ACTICO数据库专用的文档管理或证据管理表中。 采集 文档附加到案例时由系统记录的事件。 事件类型 explicit | |||
| 已启动合规审查 | 标志着合规部门开始人工审查，通常针对高风险或被标记的申请。通常可根据案例状态变为“待合规审查”，或案例被分配至合规专员的工作队列来推断。 | ||
| 重要性 此活动是衡量合规审查瓶颈的起点。从此时到“合规审查已完成”的耗时，是识别这一关键阶段延迟的重要KPI。 获取途径 可根据申请状态历史或审计轨迹推断。请查找状态变为“合规审查中”或案例被分配给合规相关用户组时的时间戳。 采集 根据案例状态变为“待合规审查”，或案例被分配给合规团队来推断。 事件类型 inferred | |||
| 已完成风险评估 | 此活动表示ACTICO决策引擎已执行，为客户申请计算风险分数或评级。作为系统的核心功能，风险评估规则集执行时会被记录为明确事件。 | ||
| 重要性 风险评估是关键决策点，通常会决定后续流程路径。分析此活动有助于了解风险等级如何影响流程变体和处理时间。 获取途径 这是ACTICO中的核心事件，应记录在决策日志或执行日志中。这些日志通常包含案例ID、已执行的规则和最终风险分数。 采集 ACTICO决策引擎完成风险评分时记录的事件。 事件类型 explicit | |||
| 已提交申请 | 新客户申请正式进入ACTICO系统时，KYC客户入职流程即从此活动开始。系统会将其记录为明确事件，通常在创建新案例或申请记录时生成准确的时间戳。 | ||
| 重要性 作为主要开始事件，此活动对于计算整体入职周期时间和跟踪申请量至关重要。它为后续所有流程绩效指标提供基准时间戳。 获取途径 这通常是ACTICO中申请或案例创建日志里的明确记录。请查找与申请提交事件相关的数据表，或主案例记录的创建时间戳。 采集 创建新的申请案例实例时记录的事件。 事件类型 explicit | |||
| 申请已批准 | 此活动表示最终业务决定，即批准客户的入职申请。这是一个重要里程碑，通常会作为申请生命周期中的独立最终状态变化记录。 | ||
| 重要性 此里程碑是创建账户的前置步骤，标志着申请成功。分析到达此节点所需的时间，对于了解理想路径的耗时至关重要。 获取途径 可根据主申请表或案例表中的最终状态字段推断。请查找“已批准”“审批完成”等最终成功状态。 采集 案例主数据中的最终状态更新为“已批准”。 事件类型 inferred | |||
| 申请已拒绝 | 表示最终决定拒绝客户申请，并终止入职流程。这是一个关键的结束状态，通过申请记录中的最终状态变化捕获。 | ||
| 重要性 这是主要的失败结束事件。分析以此活动结束的案例，对于了解拒绝率和失败原因、提高整体流程成功率至关重要。 获取途径 可根据主申请表或案例表中的最终状态字段推断。请查找“已拒绝”“未获批准”或“已关闭-已拒绝”等最终状态。 采集 案例主数据中的最终状态更新为“已拒绝”。 事件类型 inferred | |||
| 初步申请审核 | 指对已提交申请进行的首次审核，由自动规则或人工经办人员执行，以检查材料是否完整以及申请人是否符合基本条件。通常可根据申请状态变化推断此活动，例如状态从“已提交”变为“审核中”。 | ||
| 重要性 分析完成首次审核所需的时间，有助于发现初始处理延迟，也能了解有多少申请顺利通过这一初步关口。 获取途径 可根据客户申请案例的状态历史表或审计日志推断。比较状态从“新建”或“已提交”变为“审核中”时的时间戳。 采集 在案例历史日志中检测状态从“已提交”变为“审核中”的变化。 事件类型 inferred | |||
| 已创建账户 | 申请获批后，此活动表示在核心银行系统或用户管理系统中完成客户账户的技术创建。ACTICO收到下游系统的成功确认后，通常会将其记录为明确事件。 | ||
| 重要性 此活动确认流程已产生实际业务结果。从“申请已批准”到“已创建账户”的耗时，可以揭示集成延迟或最终开通步骤中的低效环节。 获取途径 相关信息可能位于ACTICO的集成日志或系统接口日志中，这些日志会记录调用外部账户开通系统的结果。 采集 收到核心账户系统的成功API响应时记录的事件。 事件类型 explicit | |||
| 已启动背景调查 | 指启动自动或人工背景调查的时点，例如反洗钱或信用记录筛查。系统触发这些检查时通常会记录为明确事件，检查可能涉及外部服务提供商。 | ||
| 重要性 启动背景调查是尽职调查流程中的重要里程碑。跟踪此活动有助于了解对外部数据提供方的依赖及相关处理周期。 获取途径 请查找系统日志或审计轨迹中触发背景筛查流程的记录。这些记录通常与主申请案例ID关联。 采集 工作流引擎调用背景调查服务时记录的事件。 事件类型 explicit | |||
| 已完成身份验证 | 指通过自动或人工检查，将客户身份与外部或内部数据源进行核验。通常在调用第三方验证服务的API并收到响应时，系统会将其记录为明确事件。 | ||
| 重要性 此活动是关键的合规步骤。分析其耗时和结果，有助于发现对外部服务的依赖，以及身份验证流程中的潜在瓶颈。 获取途径 相关信息通常位于集成日志或专用事件表中，这些记录会保存与申请案例关联的自动检查结果和第三方服务调用信息。 采集 调用第三方身份验证服务时由集成日志记录的事件。 事件类型 explicit | |||
| 已请求补充信息 | 指审查人员（通常来自合规或承保部门）要求客户补充信息或文档。此操作通常会被明确记录，因为往往需要向客户发送通知并暂停案例处理。 | ||
| 重要性 此活动是造成返工和周期时间延长的主要原因之一。跟踪其发生频率和影响，对于发现可改进初始数据收集的环节至关重要。 获取途径 这通常是案例历史或通信日志中的明确事件。请查找“已发送信息请求”（RFI）等事件，或“待客户补充信息”等特定状态变化。 采集 用户触发的明确事件，例如“发送信息请求”，会记录在案例审计轨迹中。 事件类型 explicit | |||
| 文档审查已完成 | 此活动表示经办人员已完成对客户所提交文档的审查。通常可根据文档或整个案例的状态变化推断，例如状态变为“文档已验证”或“审查完成”。 | ||
| 重要性 这是衡量文档处理效率的重要里程碑。从“已上传客户文档”到此活动的耗时，是识别人工处理延迟的关键KPI。 获取途径 可根据申请案例或单份文档的状态历史日志推断。文档状态从“待审查”变为“已批准”或“已审查”，即表示此活动发生。 采集 根据文档状态变为“已验证”或“已审查”推断。 事件类型 inferred | |||
数据提取指南
步骤
- 获取管理员权限：使用具备足够权限的账号登录ACTICO平台，例如Visual Modeler或专用管理控制台，以访问和配置数据导出。
- 找到导出模块：进入系统管理或配置区域，找到负责审计跟踪、日志记录或数据导出的部分。该功能可能标记为“Audit Export”或“Business Object Export”。
- 创建导出配置：新建导出定义，并为配置指定易于识别的名称，例如“KYC_Onboarding_ProcessMind_Export”。
- 定义数据源：指定要导出的主要业务对象，即
CustomerApplication。务必设置日期范围筛选条件，例如最近6个月，以控制文件大小并确保处理性能。 - 配置输出文件：将输出格式设为CSV。指定文件名，例如
kyc_event_log.csv，并确认分隔符，通常为逗号。确保文本字段使用正确的引号，以处理特殊字符。 - 映射案例标识符：将
CustomerApplication业务对象的唯一标识符指定为流程挖掘分析的案例ID，以便将相关事件关联到同一个入职案例。 - 定义属性映射：将事件日志中的每个必需列映射到ACTICO业务对象模型中的对应属性，包括案例ID、活动名称、时间戳，以及状态或风险等级等建议属性。
- 配置事件映射：这是最关键的一步。为14项业务活动分别创建规则或映射。使用系统触发条件，例如将对象创建映射为“Application Submitted”，将工作流步骤的状态变更映射为“Application Approved”，并根据特定审计日志消息模式识别“Identity Verification Performed”等技术事件。
- 保存并验证配置：完成所有映射后，保存配置文件。使用ACTICO提供的验证工具检查语法错误或属性路径是否有误。
- 运行并监控导出任务：启动导出任务，并通过系统任务调度程序或监控界面查看进度。任务完成后检查日志中是否有错误。
- 获取并准备文件：从服务器指定的输出路径下载生成的CSV文件。上传到ProcessMind之前，请打开文件检查结构，并确认时间戳和日期格式一致且解析正确。
配置
- 审计日志级别：系统范围的审计日志级别必须设为详细级别，例如INFO或FINE。WARNING或ERROR等较低详细程度的级别无法记录流程挖掘所需的状态变更和规则执行信息。
- 导出数据源：主要数据源应设为
CustomerApplication业务对象。您可能需要关联或引用CustomerDocument等相关对象，以捕获所有相关事件。 - 日期范围筛选：务必使用日期范围筛选来控制提取的数据量。初步分析建议选择3至6个月；生产环境中可根据业务需求和系统性能调整。
- 事件映射逻辑：提取数据的准确性很大程度上取决于事件映射方式。状态变更（
on="StatusChange"）通常用于推断业务步骤；明确的日志条目（on="LogEntry"）适用于技术事件或服务调用；规则执行（on="RuleExecution"）则适合记录决策步骤。 - 输出格式：选择CSV格式以确保广泛兼容。正确设置分隔符和文本引号，避免数据解析问题。
- 前提条件：此方法要求具备ACTICO平台管理员权限。您还需要充分了解KYC业务对象模型，包括所有相关状态字段和属性名称，才能准确完成配置。
查询示例 xml
<!-- This is a representative ACTICO export configuration in XML format. -->
<!-- Actual syntax may vary based on your ACTICO version. -->
<AuditExportConfiguration name="KYC_ProcessMind_Export">
<DataSource type="BusinessObject">
<ObjectName>CustomerApplication</ObjectName>
<DateRange from="[Start Date YYYY-MM-DD]" to="[End Date YYYY-MM-DD]"/>
</DataSource>
<OutputFile format="CSV" name="kyc_event_log.csv" delimiter=","/>
<CaseId mapping="customerApplication.id"/>
<Attributes>
<Attribute name="CustomerApplication" mapping="customerApplication.id"/>
<Attribute name="ActivityName" mapping="[generated_activity_name]"/>
<Attribute name="EventTime" mapping="[event_timestamp]"/>
<Attribute name="SourceSystem" value="ACTICO"/>
<Attribute name="LastDataUpdate" value="[CURRENT_TIMESTAMP]"/>
<Attribute name="EndTime" mapping="[event_timestamp]"/>
<Attribute name="InitiatingUser" mapping="event.user"/>
<Attribute name="Department" mapping="event.user.department"/>
<Attribute name="ApplicationStatus" mapping="customerApplication.status"/>
<Attribute name="RejectionReason" mapping="customerApplication.rejectionDetails.reasonCode"/>
<Attribute name="RiskLevel" mapping="customerApplication.risk.level"/>
<Attribute name="SlaTargetDate" mapping="customerApplication.slaDate"/>
</Attributes>
<EventMappings>
<Event on="Create" object="CustomerApplication">
<Set name="[generated_activity_name]" value="Application Submitted"/>
<Set name="[event_timestamp]" mapping="customerApplication.creationDate"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Submitted" to="In Review">
<Set name="[generated_activity_name]" value="Initial Application Review"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="Create" object="CustomerDocument">
<Set name="[generated_activity_name]" value="Customer Documents Uploaded"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
<CaseId mapping="event.relatedObject.customerApplication.id"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="IDV Service Call Completed.*">
<Set name="[generated_activity_name]" value="Identity Verification Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Documents Verified">
<Set name="[generated_activity_name]" value="Document Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Background Check Initiated.*">
<Set name="[generated_activity_name]" value="Background Checks Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="RuleExecution" object="CustomerApplication" ruleSet="KYC Risk Assessment">
<Set name="[generated_activity_name]" value="Risk Assessment Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Compliance Review">
<Set name="[generated_activity_name]" value="Compliance Review Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Customer Information">
<Set name="[generated_activity_name]" value="Additional Information Requested"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Pending Compliance Review" to="Compliance Approved">
<Set name="[generated_activity_name]" value="Compliance Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Approved">
<Set name="[generated_activity_name]" value="Application Approved"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Account successfully created.*">
<Set name="[generated_activity_name]" value="Account Created"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Closed - Approved">
<Set name="[generated_activity_name]" value="Customer Onboarding Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Rejected">
<Set name="[generated_activity_name]" value="Application Rejected"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
</EventMappings>
</AuditExportConfiguration>优化KYC客户入职流程：将处理时间缩短至24小时
减少客户放弃申请和误报，让入职流程更加顺畅。
无需信用卡。立即开始优化。