您的KYC客户入驻数据模板
您的KYC客户入驻数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- ACTICO数据提取指南
KYC客户准入属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 表示特定活动开始或发生时间的时间戳。 | ||
| 说明 Event Time是活动记录在系统中的准确日期和时间。它确定单个客户申请案例中所有事件的时间顺序，构成客户入职旅程的时间线。 该属性对于所有基于时间的分析都至关重要。它用于计算活动之间的周期时间、识别延误和等待时间、衡量案例总时长，以及检查是否符合服务级别协议（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流程中每个步骤或活动的名称，例如“Application Submitted”“Risk Assessment Performed”或“Application Approved”。它构成流程图的顺序基础。 分析Activity Name可以实现流程顺序可视化，识别常见或少见活动，并发现瓶颈或返工循环。它是了解执行了哪些操作及其顺序的基础，也是开展变体分析和一致性检查的关键。 为什么重要 它定义流程图中的步骤，用于可视化流程顺序、识别偏差，以及分析活动的频率和顺序。 获取位置 此信息通常位于ACTICO的事件日志表中，常见于描述事件或任务类型的字段。请参阅ACTICO文档。 示例 申请已提交已完成风险评估合规审核已完成申请已拒绝 | |||
| 最后数据更新时间 LastDataUpdate | 表示数据最近一次从源系统刷新或提取时间的时间戳。 | ||
| 说明 此属性记录最近一次从ACTICO提取数据的日期和时间。它是适用于整个数据集的元数据字段，而非单个事件字段，用于说明分析数据的新鲜度。 在仪表板和报告中，这一信息有助于用户了解数据的时效性，合理判断洞察的及时程度；对于重视近实时数据的运营监控也至关重要。显示此时间戳能够提升数据呈现的透明度和可信度。 为什么重要 表示数据的新鲜度，帮助用户了解分析的是否为最新信息，这对运营决策至关重要。 获取位置 此值在数据提取、转换和加载（ETL）过程中生成并存储，反映ETL作业成功完成时的时间戳。 示例 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| 源系统 SourceSystem | 事件数据来源的记录系统。 | ||
| 说明 此属性标识生成数据的源信息系统。对于此流程，值通常固定为“ACTICO”；在涉及多个系统的综合分析中，它有助于区分数据来源。 在流程挖掘场景中，它对数据治理和验证至关重要。合并不同系统的数据以构建完整流程视图时，它能确保数据正确归属来源；同时也能通过追溯源系统，帮助排查数据质量问题。 为什么重要 提供数据来源的重要背景信息，确保数据血缘和治理，在合并多个来源的数据时尤为关键。 获取位置 这通常是在数据提取和转换过程中添加的静态值（“ACTICO”），用于标记数据集。 示例 ACTICOACTICO PlatformActico KYC Module | |||
| SLA目标日期 SlaTargetDate | 客户入驻流程预计完成的日期。 | ||
| 说明 SLA目标日期是完成客户入驻的截止日期，由内部服务级别协议定义。该日期通常根据申请提交日期加上标准处理时长计算。 此属性对于监控SLA合规情况至关重要。将案例实际完成日期与SLA目标日期进行比较，系统即可判断案例是否按时完成或违反SLA。这也是“Onboarding SLA Performance”仪表板和“Onboarding SLA Adherence Rate”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 | 负责执行活动的业务部门或团队。 | ||
| 说明 此属性将活动分配给特定组织单元，例如“Compliance”“Onboarding Team”或“Client Relations”，为流程顺序提供组织背景。 部门级分析对于了解工作如何在组织不同部门之间交接至关重要。它有助于识别跨部门瓶颈、衡量部门效率，并分析团队之间的资源配置。仪表板可以按部门筛选，帮助管理者查看其团队的具体绩效。 为什么重要 提供组织维度的分析视角，用于识别跨部门延误并评估团队层面的绩效。 获取位置 此信息可能直接存储在事件数据中，也可能通过将用户数据与把用户映射到部门的人力资源主数据表连接后得出。请参阅ACTICO文档。 示例 Compliance客户 onboarding 团队客户服务 | |||
| 风险等级 RiskLevel | 客户申请计算得出的风险等级，例如低、中或高。 | ||
| 说明 此属性表示对客户评估后的风险类别，通常决定后续KYC流程的复杂程度和审核严格程度。与低风险客户相比，高风险客户可能需要额外检查和审批。 在流程挖掘中，Risk Level是进行对比分析的重要维度。分析人员可以据此检查流程是否按照预期，根据不同风险等级正确进入相应路径。例如，验证所有高风险客户是否都完成强化尽职调查步骤。该属性是“Risk Assessment Process Flows”仪表板的关键数据。 为什么重要 支持按风险对案例进行分组，从而分析流程是否按照合规政策要求，针对不同风险特征正确调整。 获取位置 这是存储在ACTICO主应用表案例级别的重要数据点。 示例 低中高 | |||
| SLA状态 SlaState | 用于表示案例已满足SLA、违反SLA，或存在违反SLA风险的计算状态。 | ||
| 说明 此属性按类别评估案例相对于服务级别协议的表现。它通过比较案例完成时间，或开放案例的当前时间，与“SlaTargetDate”得出。 此属性将日期比较转换为易于理解的状态，简化SLA报告。仪表板可以利用它创建清晰的可视化效果，例如饼图或仪表盘，展示“Met”与“Breached”案例的占比。它是“Onboarding SLA Performance”仪表板的重要组成部分，并直接支持“Onboarding SLA Adherence Rate”KPI。 为什么重要 为每个案例提供清晰的SLA合规分类状态，简化报告，并便于直观展示相对于目标的绩效。 获取位置 这是根据业务逻辑计算得出的属性，用于比较案例完成时间戳与“SlaTargetDate”。 示例 已满足已超时存在风险 | |||
| 国家/地区 Country | 申请入驻客户的居住国家/地区。 | ||
| 说明 此属性指定客户所在国家/地区，可能对KYC流程产生重大影响。不同司法管辖区的监管要求各不相同，可能触发额外或替代流程步骤。 按国家/地区分析流程，可以比较不同区域的表现，帮助识别某些国家/地区是否持续出现更长的周期时间或更高的拒绝率，这可能意味着监管阻力或特定市场挑战。对于希望在尊重本地合规要求的同时实现流程标准化的全球化组织而言，这一地理视角十分重要。 为什么重要 提供地理分析维度，帮助了解不同监管司法管辖区之间的流程差异和绩效差异。 获取位置 这是存储在ACTICO系统案例级别或客户级别的核心客户信息。 示例 USADEUGBRSGP | |||
| 客户类型 CustomerType | 对客户进行分类，例如个人客户或企业客户。 | ||
| 说明 此属性用于将申请人划分为不同类别，例如个人与企业实体。不同客户类型的KYC流程通常存在显著差异，企业客户入驻流程往往复杂得多。 将Customer Type作为维度，可以在同一数据集中清晰区分并比较这些不同流程。分析人员可以筛选流程图，仅查看“Corporate”客户，以了解其独有的挑战、瓶颈和周期时间，避免更简单的“Individual”客户流程影响分析结果。 为什么重要 支持按不同客户类别对流程进行分组。不同类别的流程路径和复杂程度通常差异很大，因此可以提高分析准确性。 获取位置 这是存储在ACTICO案例级别或客户级别的基础属性。 示例 个人企业小型企业 | |||
| 是否自动化 IsAutomated | 用于标识某项活动是由系统自动执行，还是由用户手动完成。 | ||
| 说明 此布尔属性用于区分人工用户执行的任务与系统自动化执行的任务，例如自动背景调查或风险评分。 分析此属性有助于评估自动化举措的成效。您可以比较自动化步骤与人工步骤的处理时长，识别流程中仍高度依赖人工的部分，并发现进一步自动化的机会，从而提升效率、降低运营成本。 为什么重要 区分人工任务与系统任务，对于衡量自动化影响和发现未来提升效率的机会至关重要。 获取位置 该属性可以根据“InitiatingUser”属性推断，例如用户为“SYSTEM”时；也可能是事件日志中的专用标记。请参阅ACTICO文档。 示例 truefalse | |||
| 是否返工 IsRework | 用于识别某项活动是否为重复步骤或返工循环一部分的计算标记。 | ||
| 说明 此布尔属性用于标记同一案例中第二次或后续执行的活动，例如在请求补充信息后再次进行“Document Review”。它可以识别返工实例，而返工通常是流程低效的来源。 识别返工是流程挖掘的主要目标之一。利用此标记可以量化返工情况，例如计算“Document Rework Rate”KPI。在流程图中，可以突出显示返工循环，展示流程反复回退的位置。这有助于定位质量问题，或发现流程未能“一次做对”的环节。 为什么重要 突出显示重复工作实例，支持直接衡量流程低效程度，并识别存在质量或说明不清问题的活动。 获取位置 这是一个计算属性。其逻辑在流程挖掘工具中或数据转换过程中定义，用于检测同一案例中的重复活动。 示例 truefalse | |||
KYC客户准入活动
| 活动 | 说明 | ||
|---|---|---|---|
| 合规审核已完成 | 标志着合规部门结束人工审核，并作出批准、拒绝或要求进一步处理的决定。通常可通过案例状态从“待合规审核”变为“合规已批准”等后续状态来推断。 | ||
| 为什么重要 这是合规审核阶段的结束事件，对于计算合规审核总时长和分析团队处理量至关重要。 获取位置 可从申请状态历史日志中推断。请查找案例离开“合规审核中”状态时的时间戳，这表示已作出决定。 采集 可根据案例状态从“待合规审核”变为“合规已批准”或类似状态推断。 事件类型 inferred | |||
| 客户开户已完成 | 这是流程中的最终活动，表示客户已完成开户，申请案例已关闭。通常可通过案例被赋予“已开户”或“已关闭－已批准”等最终状态来推断。 | ||
| 为什么重要 作为主要成功结束事件，此活动对于计算所有成功开户客户的端到端周期时间至关重要，也为理想路径分析提供最终时间戳。 获取位置 可从客户申请案例的最终状态字段推断。请查找案例转为最终成功状态时对应的时间戳。 采集 可根据案例最终状态更新为“已完成”或“已关闭”推断。 事件类型 inferred | |||
| 客户文档已上传 | 当客户通过与ACTICO集成的门户或其他渠道提供所需身份证明和支持性文档时，此活动发生。每次文档上传通常都会作为系统文档管理日志或案例日志中的独立明确事件被记录。 | ||
| 为什么重要 这标志着一个由客户推动的关键里程碑。跟踪此事件对于衡量客户响应时间和分析后续文档审核阶段的持续时间至关重要。 获取位置 请查找与文档处理或案例附件相关的事件日志。这些记录通常位于ACTICO数据库专用的文档或证据管理表中。 采集 文档附加到案例时由系统记录的事件。 事件类型 explicit | |||
| 已启动合规审核 | 标志着合规部门开始人工审核阶段，通常适用于高风险或被标记的申请。一般可通过案例状态变为“待合规审核”，或案例被分配到合规专员工作队列来推断。 | ||
| 为什么重要 此活动是衡量合规瓶颈的起点。直到“合规审核已完成”所经过的时间，是识别这一关键阶段延误的重要KPI。 获取位置 可从申请状态历史或审计轨迹中推断。请查找状态变为“合规审核中”或分配给合规相关用户组时的时间戳。 采集 可根据案例状态变为“待合规审核”或分配给合规团队推断。 事件类型 inferred | |||
| 已完成风险评估 | 表示执行ACTICO决策引擎，为客户申请计算风险分数或评级。作为系统的核心功能，风险评估规则集执行时会记录为明确事件。 | ||
| 为什么重要 风险评估通常是决定后续流程路径的关键决策点。分析此活动有助于了解风险等级如何影响流程变体和处理时长。 获取位置 这是ACTICO中的核心事件，应记录在决策日志或执行日志中。这些日志通常包含案例ID、已执行的规则以及最终风险分数。 采集 风险评分完成后由ACTICO决策引擎记录的事件。 事件类型 explicit | |||
| 申请已批准 | 表示最终业务决定，即批准客户的开户申请。这是一个关键里程碑，通常会作为申请生命周期中独立且最终的状态变化被记录。 | ||
| 为什么重要 此里程碑先于账户创建，代表流程成功完成。分析达到这一节点所需的时间，对于了解“理想路径”的持续时间至关重要。 获取位置 可从主申请表或案例表中的最终状态字段推断。请查找“已批准”“批准完成”或类似的终止性正向状态。 采集 案例主数据中的最终状态更新为“已批准”。 事件类型 inferred | |||
| 申请已拒绝 | 表示拒绝客户申请的最终决定，并终止开户流程。这是一个关键结束状态，通过申请记录的最终状态变化捕获。 | ||
| 为什么重要 这是主要的失败结束事件。分析以此活动结束的案例，对于了解拒绝率、失败原因和提升整体流程转化率至关重要。 获取位置 可从主申请表或案例表中的最终状态字段推断。请查找“已拒绝”“未通过”或“已关闭－已拒绝”等终止状态。 采集 案例主数据中的最终状态更新为“已拒绝”。 事件类型 inferred | |||
| 申请已提交 | 当ACTICO系统正式收到新客户申请时，此活动标志着KYC开户流程的开始。它会作为明确事件被记录，通常在创建新案例或申请记录时写入精确时间戳。 | ||
| 为什么重要 作为主要开始事件，此活动对于计算整体开户周期时间和跟踪申请量至关重要。它是后续所有流程绩效指标的基准时间戳。 获取位置 这通常是ACTICO申请或案例创建日志中的明确记录。请查找与申请提交事件相关的表，或主案例记录的创建时间戳。 采集 创建新申请案例实例时记录的事件。 事件类型 explicit | |||
| 初始申请审核 | 表示对已提交申请进行的首次审核，可由自动规则或人工代理执行，用于检查完整性和基本资格。此活动通常可通过申请状态变化推断，例如从“已提交”变为“审核中”。 | ||
| 为什么重要 分析完成首次审核所需的时间，有助于识别初始处理延误，也能了解有多少申请顺利通过这一首个关口。 获取位置 可从与客户申请案例关联的状态历史表或审计日志中推断。请比较状态从“新建”或“已提交”变为“审核”状态时的时间戳。 采集 在案例历史日志中检测从“已提交”到“审核中”的状态变化。 事件类型 inferred | |||
| 已启动背景调查 | 表示启动自动或人工背景调查的时间点，例如AML或信用记录筛查。系统触发这些检查时，通常会记录为明确事件，检查可能涉及外部服务提供商。 | ||
| 为什么重要 启动背景调查是尽职调查流程中的重要里程碑。跟踪此活动有助于了解对外部数据提供商的依赖及其处理周期。 获取位置 请查找系统日志或审计轨迹中表示触发背景筛查程序的记录。这些记录通常与主申请案例ID关联。 采集 工作流引擎启动背景调查服务调用时记录的事件。 事件类型 explicit | |||
| 已执行身份验证 | 表示通过外部或内部数据源验证客户身份的自动或人工检查。当系统调用第三方验证服务并收到响应时，通常会将其记录为明确事件。 | ||
| 为什么重要 此活动是关键的合规步骤。分析其持续时间和结果，有助于识别对外部服务的依赖以及验证流程中的潜在瓶颈。 获取位置 相关信息通常位于集成日志或专用事件表中，用于记录与申请案例关联的自动检查结果和第三方服务调用。 采集 调用第三方身份验证服务时由集成日志记录的事件。 事件类型 explicit | |||
| 已请求补充信息 | 表示审核人员，通常是合规或承保人员，需要客户提供更多信息或文档。此操作通常会被明确记录，因为它往往涉及向客户发送通知并暂停案例处理。 | ||
| 为什么重要 此活动是返工增加和周期时间延长的主要原因之一。跟踪其频率和影响，对于识别改进初始数据收集的环节至关重要。 获取位置 这很可能是案例历史或通信日志中的明确事件。请查找“RFI已发送”（信息请求）或“待客户提供信息”等具体状态变化。 采集 “发送RFI”等由用户触发的明确事件会记录在案例审计轨迹中。 事件类型 explicit | |||
| 文档审核已完成 | 表示代理已完成对客户提交文档的审核。通常可通过文档或整体案例的状态变化推断，例如变为“文档已验证”或“审核完成”。 | ||
| 为什么重要 这是衡量文档处理效率的关键里程碑。“客户文档已上传”与此活动之间的时间，是识别人工处理延误的重要KPI。 获取位置 可从申请案例或单个文档的状态历史日志中推断。文档状态从“待审核”变为“已批准”或“已审核”，即表示此活动发生。 采集 可根据文档状态变为“已验证”或“已审核”推断。 事件类型 inferred | |||
| 账户已创建 | 申请获批后，此活动标志着在核心银行系统或用户管理系统中完成客户账户的技术创建。ACTICO收到下游系统的成功确认后，通常会记录为明确事件。 | ||
| 为什么重要 此活动确认流程产生了实际业务结果。“申请已批准”到“账户已创建”之间的时间，可以揭示最终配置步骤中的集成延误或效率问题。 获取位置 相关信息可能位于ACTICO的集成日志或系统接口日志中，这些日志记录了调用外部系统进行账户配置的结果。 采集 收到核心账户系统成功API响应后记录的事件。 事件类型 explicit | |||
提取指南
步骤
- 获取管理员权限：登录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业务对象模型，包括所有相关状态字段和属性名称，才能准确完成配置。
a 示例查询 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小时
消除客户中途放弃和误报，实现顺畅的入驻体验。
无需信用卡，立即开始优化。