KYC客户入职数据模板
KYC客户入职数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- 数据提取指南
KYC客户入职属性
| 名称 | 说明 | ||
|---|---|---|---|
| 客户申请 CustomerApplication | 单个客户开户流程的唯一标识符,也是主要案例标识。 | ||
| 说明 客户申请是核心标识,用于汇总单个客户KYC开户流程中的所有相关活动和事件。无论申请最终获批、被拒绝还是关闭,都可以据此端到端跟踪申请进度。 在流程挖掘中,此属性是还原每个申请完整流程的基础。它支持按申请分析流程路径、周期时间、差异和瓶颈,清晰呈现各个案例的处理情况。 重要性 这是关键的案例ID,用于关联所有相关事件,从而分析客户开户的端到端流程。 获取途径 这通常是Fenergo核心案例管理或客户生命周期管理实体中的主键。 示例 APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| 开始时间 EventStartTime | 表示活动或事件正式开始时间的时间戳。 | ||
| 说明 此属性记录特定活动开始的准确日期和时间,为还原流程顺序提供依据,也是所有时间分析的基础。 在流程挖掘中,开始时间用于计算活动持续时间、活动间等待时间和案例整体周期时间。它构成事件日志的时间基础,对于绩效和瓶颈分析至关重要。 重要性 此时间戳对于按时间顺序排列事件,以及计算周期时间、持续时间等时间指标至关重要。 获取途径 此信息位于Fenergo的审计跟踪、事件日志或工作流历史表中,字段名称通常为“Timestamp”“StartDate”或“CreationDate”。 示例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| 活动名称 ActivityName | 在开户流程的某个时间点发生的具体业务事件或任务名称。 | ||
| 说明 活动名称用于描述客户开户流程中的一个步骤或里程碑,例如“已完成初步筛查”或“申请已批准”。这些活动按顺序构成流程图。 分析此属性有助于直观呈现流程路径、识别常见和替代路径,并衡量各步骤的发生频率。它对于了解执行了哪些操作及其顺序至关重要。 重要性 此属性定义流程中的各个步骤,可用于创建流程图并分析流程路径和差异。 获取途径 此信息通常位于Fenergo的工作流或审计日志表中,与案例状态转换或任务完成记录相关联。 示例 请求数据和文档启动合规审核申请已批准 | |||
| 数据上次更新时间 LastDataUpdate | 表示此流程数据上次刷新或提取时间的时间戳。 | ||
| 说明 此属性记录最近一次数据刷新的日期和时间,帮助了解所分析数据的新鲜度,并判断分析结果的时效性。 在仪表板和报告中,此信息用于告知用户数据的时效情况,帮助用户判断分析反映的是实时运营情况还是历史快照。 重要性 提供数据新鲜度的重要背景信息,帮助用户了解流程分析所依据的数据有多新。 获取途径 此值在数据提取和加载(ETL)过程中生成并写入数据集。 示例 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| 源系统 SourceSystem | 提取数据的记录系统。 | ||
| 说明 此属性标识事件数据的来源系统。对于此流程,来源始终是Fenergo;在混合数据集中,它有助于区分不同数据源。 分析时,此属性主要用于筛选特定系统的数据或验证数据来源。在汇总多个系统的数据以全面了解流程时,它有助于确保信息清晰。 重要性 标识数据来源,对于数据治理、验证以及确保分析基于正确来源至关重要。 获取途径 此值通常在数据提取过程中作为静态值添加,用于标记记录来源。 示例 FenergoFenergo CLM | |||
| SLA目标日期 SlaTargetDate | 预期完成客户开户案例的日期。 | ||
| 说明 SLA目标日期是完成客户申请整个开户流程的约定期限,是衡量实际绩效的重要基准。 此属性是“SLA合规监控”仪表板和计算“SLA达成率”KPI的基础。它支持主动管理有逾期风险的案例,并帮助确定工作优先级。 重要性 定义目标完成日期,对于监控SLA合规情况和优先处理逾期案例至关重要。 获取途径 此日期通常根据申请提交日期以及Fenergo的SLA管理模块中配置的业务规则计算得出。 示例 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| 发起用户 InitiatingUser | 执行活动的人员的用户ID或姓名。 | ||
| 说明 此属性标识负责执行特定任务或事件的员工或系统用户,可以是唯一用户ID、姓名或角色。 按用户分析有助于了解工作量分配、个人绩效和培训需求。它是“员工活动分布”仪表板的关键属性,也支持进一步查看特定个人或团队执行的活动。 重要性 跟踪执行操作的用户,支持分析工作量分配、团队绩效和资源配置。 获取途径 此信息通常与事件详情一同存储在Fenergo审计日志或任务历史表中,字段名称通常为“UserID”“UserName”或“ModifiedBy”。 示例 j.doea.smithSYSTEM | |||
| 用户部门 UserDepartment | 发起用户所属的部门或业务单元。 | ||
| 说明 此属性提供执行活动的用户所属组织信息,例如“合规”“开户运营”或“销售”。通常可从用户资料中获取。 此维度对于分析不同部门间的流程交接和识别跨职能瓶颈至关重要。它支持“员工活动分布”仪表板按团队或部门汇总工作量。 重要性 支持按部门分析流程绩效,揭示部门间的交接、延误和工作量分布。 获取途径 可能需要使用“InitiatingUser”ID,从单独的用户或人力资源主数据表中关联此信息。Fenergo也可能将其存储在用户资料中。 示例 Compliance客户入职质量保证 | |||
| 申请状态 ApplicationStatus | 客户申请当前或最终的处理结果。 | ||
| 说明 此属性表示流程结束时申请的处理结果,或流程进行中的当前状态。常见值包括“已批准”“已拒绝”或“处理中”。 这是结果分析的重要维度。它支持按最终结果筛选和比较流程路径,是“申请返工与拒绝”仪表板以及计算申请拒绝率等KPI的基础。 重要性 定义案例结果,支持比较已批准和被拒绝申请的流程路径,并了解成功率。 获取途径 这通常是Fenergo案例管理系统中案例实体记录的最终状态。 示例 已批准已拒绝等待合规审批已关闭 | |||
| 结束时间 EventEndTime | 表示活动或事件完成时间的时间戳。 | ||
| 说明 此属性记录特定活动结束的准确日期和时间,与开始时间共同确定任务的实际持续时间。 在流程挖掘中,结束时间与开始时间结合使用,可计算各项活动的处理时间。这对于识别流程中耗时最长的步骤和分析资源效率至关重要。 重要性 用于计算活动处理时间,是识别耗时较长的任务和绩效瓶颈的基础。 获取途径 此信息位于Fenergo的审计跟踪或工作流历史表中,字段名称通常为“EndDate”“CompletionDate”,也可根据后续事件的开始时间推导。 示例 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| 风险评分 RiskScore | 表示客户计算所得风险等级的数值。 | ||
| 说明 风险评分是衡量客户潜在风险的量化指标,根据司法管辖区、行业和筛查结果等因素计算得出。此评分通常由Fenergo规则引擎计算。 此属性支持分析风险等级与流程表现之间的关系。例如,分析可以揭示高风险客户的周期时间是否更长,或是否需要更多人工干预。这对于“风险与合规审核深入分析”仪表板很有帮助。 重要性 量化客户风险,支持分析风险等级对流程时长、返工和结果的影响。 获取途径 这是Fenergo客户风险评估模块的重要输出,存储在案例或客户实体中。 示例 154585 | |||
| 国家/地区 Country | 客户申请对应的居住国或司法管辖区。 | ||
| 说明 此属性指定客户所属的国家/地区,这通常决定开户流程适用的监管规则和风险因素。 按国家/地区分析流程,可比较不同司法管辖区的周期时间、风险等级和流程复杂度,了解地区差异对运营绩效的影响,并确保符合当地法规。 重要性 支持按地域细分流程,是分析监管影响和区域绩效的关键。 获取途径 此信息属于申请过程中收集的核心客户数据,存储在Fenergo的客户实体中。 示例 USAGBRSGPDEU | |||
| 客户ID CustomerId | 正在办理开户的客户或法人实体的唯一标识符。 | ||
| 说明 客户ID是主数据系统中客户实体的唯一标识。申请编号是流程中的案例ID,而客户ID则将开户活动关联到特定客户。 此属性支持分析单个客户的开户历史,例如查看客户是否曾多次办理开户。它还支持将流程数据与其他客户相关数据关联,获得更全面的业务视图。 重要性 将开户流程关联到唯一客户实体,支持以客户为中心的分析和数据补充。 获取途径 此ID存储在Fenergo的客户或法人实体记录中,并与开户案例关联。 示例 CUST-98765CUST-98766CUST-98767 | |||
| 客户类型 CustomerType | 开户客户的分类,例如个人、企业或信托。 | ||
| 说明 此属性根据客户的法律结构或与金融机构的关系对客户进行分类。不同类型的客户通常遵循不同的开户路径,流程复杂度和尽职调查要求也各不相同。 按客户类型分析流程,有助于发现不同客户群体的绩效差异。此属性是“申请来源与类型效率”仪表板的关键维度,可用于比较周期时间和审批率,并据此改进流程。 重要性 支持比较不同客户群体的流程绩效,这些群体的流程复杂度和SLA要求通常各不相同。 获取途径 此信息通常存储在Fenergo的客户或客户实体中,并与申请案例关联。 示例 个人企业信托合伙企业 | |||
| 拒绝原因 RejectionReason | 说明申请被拒绝原因的代码或描述。 | ||
| 说明 当申请的最终状态为“已拒绝”时,此属性会记录具体原因。例如“背景调查未通过”“文件不完整”或“风险较高”。 此属性对于分析申请失败的根本原因至关重要。它支持“申请返工与拒绝”仪表板对失败原因进行分类,帮助业务部门发现常见问题并采取纠正措施,提高首次通过率。 重要性 深入了解申请失败的原因,支持根因分析并降低拒绝率。 获取途径 此信息通常记录在Fenergo案例工作流中与最终拒绝状态关联的原因代码或备注字段中。 示例 命中制裁名单文件无效违反政策客户已撤回申请 | |||
| 是否符合SLA IsSlaCompliant | 用于标识案例是否在SLA目标日期前完成的布尔值。 | ||
| 说明 此属性是已完成案例SLA绩效的二元指标。如果最终关闭活动的时间戳不晚于“SlaTargetDate”,则设为“true”,否则设为“false”。 此计算字段简化了SLA监控和报告。它支持轻松汇总数据以计算整体“SLA达成率”KPI,也可用于筛选并分析符合和不符合SLA的案例特征。 重要性 直接衡量SLA绩效,便于计算SLA达成率KPI并筛选不符合SLA的案例。 获取途径 将案例最终活动(例如“申请已批准”“申请已拒绝”)的时间戳与“SlaTargetDate”进行比较,即可得出此值。 示例 truefalse | |||
| 是否自动执行 IsAutomated | 用于标识活动由系统而非人工用户执行的布尔值。 | ||
| 说明 此属性用于区分系统自动执行的任务(例如初步筛查、系统检查)和用户手动执行的任务。通常可通过检查执行用户是否为系统账户或服务账户来判断。 分析此标记对于了解流程自动化程度至关重要。它有助于量化自动化对效率、成本和速度的影响,并发现进一步自动化的机会。 重要性 区分人工活动和系统活动,对于自动化分析和了解资源成本至关重要。 获取途径 此值通常根据“InitiatingUser”字段推导。系统会使用已知系统用户ID列表,将此标记设为true。 示例 truefalse | |||
| 是否返工 IsRework | 用于标识活动是否属于返工循环的布尔值。 | ||
| 说明 此属性用于识别流程中的回退活动,例如“合规审核”已启动后又返回“文件审核”,或发生“请求补充信息”的情况。 识别返工对于了解流程效率低下和阻碍至关重要。此标记可直接用于计算“返工循环率”KPI,并帮助直观呈现和量化流程中重复、无效步骤的影响。 重要性 突出显示流程中的低效返工循环,帮助量化浪费并发现改进空间,从而提高首次正确率。 获取途径 此标记通过分析活动顺序,使用流程挖掘技术推导得出。例如,同一案例中“活动A”之后发生“活动B”,随后再次出现“活动A”,则第二次“活动A”属于返工。 示例 truefalse | |||
| 案例负责人 CaseOwner | 负责在申请整个生命周期中管理申请的主要用户或团队。 | ||
| 说明 案例负责人是被指定主要负责某个开户案例的个人或团队,通常需要确保案例及时、顺利完成。 此属性有助于从案例经理层面分析工作量和绩效。可用于查看某些案例负责人的周期时间是否较长或拒绝率是否较高,从而发现培训需求或资源配置失衡。 重要性 标识对案例负责的人员或团队,支持分析案例经理的绩效。 获取途径 这通常是Fenergo主要案例实体中的专用字段,用于记录案例分配情况。 示例 s.jonesonboarding_team_am.chen | |||
| 申请渠道 ApplicationChannel | 客户提交申请所使用的渠道。 | ||
| 说明 此属性标识申请的提交来源,例如在线门户、实体网点或客户经理。来源渠道可能影响数据质量和处理要求。 此维度用于“申请来源与类型效率”仪表板,以比较不同渠道的绩效,帮助企业了解哪些渠道效率较高,哪些渠道可能需要优化流程。 重要性 标识申请来源,支持分析渠道效率、成本和客户体验。 获取途径 此信息可能记录在Fenergo的初始数据录入表单中,也可能由上游系统传入。 示例 在线门户网点客户经理移动应用 | |||
| 补充信息请求次数 AdditionalInfoRequestCount | 申请被请求补充信息的总次数。 | ||
| 说明 此指标统计每个案例中“请求补充信息”活动的发生次数。次数越多,表示来回沟通越频繁,可能延误流程并影响客户体验。 此属性直接支持“有补充信息请求的案例”KPI,可用于识别补充信息请求过多的申请。这可能表明初始数据收集存在问题,或案例要求较复杂。分析此属性有助于简化信息收集流程。 重要性 量化初始信息不完整造成的客户阻碍和流程延误,帮助改进数据收集环节。 获取途径 这是一个计算指标,通过统计每个“CustomerApplication”ID对应的“请求补充信息”事件数量得出。 示例 013 | |||
KYC客户入职活动
| 活动 | 说明 | ||
|---|---|---|---|
| 创建案例 | 此活动标志着KYC客户入职流程启动,即在Fenergo中正式创建新的客户申请。通常,系统会在首次保存案例记录时生成带有具体时间戳的事件。 | ||
| 重要性 作为开始事件,此活动对于计算整体入职周期时间和分析处理量至关重要。它为后续所有流程指标和SLA跟踪提供基准。 获取途径 通常从Fenergo中主要案例实体的创建时间戳获取,相关数据常见于客户入职案例或工作流表。 采集 使用入职案例记录的创建时间戳。 事件类型 explicit | |||
| 启动合规审核 | 此活动标志着合规部门开始审核,这是一个关键且通常耗时较长的阶段。可根据案例分配至合规工作队列,或状态变为“待合规审核”来推断。 | ||
| 重要性 此活动是衡量“平均合规审核时间”关键绩效指标的起点,有助于了解案例在合规团队开始处理前等待了多久。 获取途径 从Fenergo案例审计日志中获取状态变为“合规审核中”的时间戳,或案例分配给合规专员或团队的时间。 采集 识别状态变为“正在进行合规审核”或发生分配事件时的时间戳。 事件类型 inferred | |||
| 完成合规审核 | 表示合规部门已正式批准,确认所有监管要求均已满足。通常可根据任务完成记录或状态变为“合规已批准”来推断。 | ||
| 重要性 作为重要里程碑,此活动的完成时间对整体周期时间至关重要。它是衡量“平均合规审核时间”以及识别合规职能瓶颈的终点。 获取途径 可根据Fenergo工作流中“合规审核”任务的完成时间戳,或案例历史记录中的状态更新事件推断。 采集 使用合规审核任务完成或状态更新的时间戳。 事件类型 inferred | |||
| 完成文档审核 | 表示已完成对客户提交的所有文档进行真实性和准确性核验的人工或自动流程。通常可根据工作流任务完成记录或Fenergo中的状态变化推断。 | ||
| 重要性 这是容易发生延误的关键里程碑。分析此活动的耗时和结果,有助于准确定位文档处理瓶颈,并支持“首次通过率”等关键绩效指标。 获取途径 可根据案例工作流中“文档核验”任务的完成时间戳,或案例历史记录中状态更新为“文档已批准”的记录推断。 采集 使用文档审核任务的完成时间戳或相关状态变更时间。 事件类型 inferred | |||
| 完成风险评估 | 表示已完成内部风险分类流程,即根据多项因素为客户评定风险等级。通常可根据状态变化或风险等级字段已填写来推断。 | ||
| 重要性 这是影响后续工作流路径的关键决策里程碑。分析其耗时有助于精简关键合规步骤,并确保风险评估的一致性。 获取途径 通过案例历史日志,识别案例状态变为“已完成风险评估”等状态的时间,或“客户风险等级”字段最终填写数值的时间。 采集 使用风险等级字段最终确定或相关状态设置的时间戳。 事件类型 inferred | |||
| 案例已关闭 | 这是最后一项活动,表示开户案例已在Fenergo中完成行政关闭,后续无需采取行动。此状态适用于已批准和已拒绝的申请,可根据最终的“已关闭”状态推断。 | ||
| 重要性 此活动是整个流程的明确终点。无论案例结果如何,它都能确保周期时间计算准确,并确认流程已经结束。 获取途径 可从Fenergo案例审计日志中推断,识别案例状态设为“已关闭”“已完成”或其他终止状态的时间戳。 采集 识别状态最终变更为“已关闭”或“已完成”的时间戳。 事件类型 inferred | |||
| 申请已批准 | 此活动表示最终决定批准客户的入职申请。通常可根据案例状态变为最终的“已批准”或“入职已批准”状态推断。 | ||
| 重要性 这一关键里程碑表示申请已成功通过审批,接下来将进行账户激活。它对于计算审批率和分析成功完成入职的客户属性至关重要。 获取途径 从案例历史记录或审计日志中查找状态最终变为“已批准”或类似最终成功状态时的时间戳。 采集 识别状态最终变为“已批准”时的时间戳。 事件类型 inferred | |||
| 申请已拒绝 | 此活动是终止事件,表示最终决定拒绝客户的申请。通常可根据案例状态变为最终的“已拒绝”或“未获批准”状态推断。 | ||
| 重要性 作为关键流程终点,此活动对于计算“申请拒绝率”和分析失败原因至关重要。它有助于识别常见的拒绝环节并提升申请质量。 获取途径 从案例审计日志中获取状态最终变为“已拒绝”时的时间戳。拒绝原因通常保存在相关字段中。 采集 识别状态最终变为“已拒绝”时的时间戳。 事件类型 inferred | |||
| 启动背景调查 | 此活动标志着外部背景调查、反洗钱(AML)检查或信用检查的启动。通常,在调用第三方服务集成时会记录这一明确事件。 | ||
| 重要性 跟踪这些检查的启动和完成时间,对于了解外部依赖造成的延误至关重要。这有助于区分内部处理时间和外部等待时间。 获取途径 通常可从记录外部筛查服务API调用的系统日志中获取,也可以根据Fenergo案例中创建“背景调查”任务的记录获取。 采集 查找外部服务集成日志或“筛查”任务的创建记录。 事件类型 explicit | |||
| 完成初步筛查 | 表示初步自动或人工检查已完成,例如基本数据验证或制裁名单筛查。通常可根据Fenergo案例工作流中的状态变化推断,例如从“新建”变为“筛查完成”。 | ||
| 重要性 跟踪这一早期里程碑有助于发现初始数据质量问题和资格预审阶段的瓶颈。它还能区分初始自动处理阶段与后续更深入的人工审核。 获取途径 通过案例历史记录或审计日志,识别案例状态变为表示筛查完成的状态时的时间戳,例如“筛查通过”或“等待文档”。 采集 从案例历史记录中查找状态变为“筛查完成”或类似状态的记录。 事件类型 inferred | |||
| 收到文档 | 此活动表示客户已上传或提交所需文档,文档现已可在Fenergo中查看并审核。通常可根据案例状态更新为“已收到文档”或“待审核”来推断。 | ||
| 重要性 这标志着客户等待阶段结束,内部审核周期开始。此时间点对于衡量客户响应时间和内部处理队列等待时间至关重要。 获取途径 可从案例审计记录中推断,该记录会保存状态变为“已收到文档”或类似状态的时间戳。也可以关联文档上传事件。 采集 识别状态变为“已收到文档”或“可供审核”时的时间戳。 事件类型 inferred | |||
| 请求数据和文档 | 此事件表示系统或客户入职专员已正式向客户索取所需信息和文档。通常,系统发送标准化沟通模板时会记录这一明确事件。 | ||
| 重要性 此活动标志着客户参与阶段的开始。测量从此时到收到文档所需的时间,是分析客户体验和发现沟通延误的关键。 获取途径 可从客户沟通相关的事件日志或“请求文档”任务完成日志中获取,也可以根据状态变为“等待客户提供信息”来推断。 采集 查找已记录的客户沟通事件或任务完成记录。 事件类型 explicit | |||
| 请求补充信息 | 表示返工循环,即客户入职团队需要再次联系客户,要求澄清信息或补交文档。这通常是一个明确事件,会在向客户发送沟通信息时记录。 | ||
| 重要性 此活动是流程低效和客户体验不佳的重要信号。跟踪其发生频率有助于找出返工的根本原因,并支持“返工循环率”关键绩效指标。 获取途径 可从客户沟通事件日志或状态变为“等待补充信息”的记录中获取。前者能更准确地记录提出请求的具体时间。 采集 查找已记录的沟通事件,或状态变为“等待客户回复”的记录。 事件类型 explicit | |||
| 账户已激活 | 表示客户账户已在审批后于核心银行系统或相关下游系统中成功创建并激活。可根据Fenergo审批后的最终状态更新推断此活动。 | ||
| 重要性 此活动确认客户开户流程已成功交接,客户状态已转为活跃。衡量从审批到激活所需的时间,有助于发现运营设置中的延误。 获取途径 可根据“账户已激活”或“开户完成”等案例状态推断此活动,也可能是与下游系统集成时记录的明确事件。 采集 查找审批后的状态变更,或集成成功日志事件。 事件类型 inferred | |||
数据提取指南
步骤
- 进入报告模块:使用具有报告与分析模块相应权限的用户账户登录Fenergo应用。进入该模块,通常可在应用主菜单中找到。
- 创建新报告:新建自定义报告,并设置能清楚说明用途的名称和说明,例如“KYC客户入职事件日志(用于流程挖掘)”。
- 指定主要数据源:选择记录案例生命周期信息的核心数据对象或视图,通常是预先配置的视图,例如
[CaseWorkflowHistory]或[LifecycleEventsView]。该对象应包含案例标识、事件名称或状态以及时间戳。 - 配置报告列(属性):使用报告生成器添加列,将Fenergo数据模型中的源字段映射到所需的事件日志属性。例如,将Fenergo的
CaseID映射到CustomerApplication,将EventTimestamp映射到EventStartTime,并将EventPerformer映射到InitiatingUser。 - 设置活动逻辑:这是最关键的一步。报告必须为14项所需活动分别生成一行。您可以为每项活动创建逻辑区块或筛选后的数据集,再通过报告生成器中的UNION或等效功能将其合并。
- 定义“案例已创建”逻辑:创建第一个区块,筛选数据源中的初始案例创建事件。通常可依据案例关联的最早时间戳,或名为“案例已创建”的事件类型进行筛选。将
CreationDate映射到EventStartTime。 - 定义基于状态的活动逻辑:对于根据状态变化推断的活动(例如“已收到文件”“申请已批准”),分别创建区块,筛选特定的
状态字段值,并将StatusChangeDate用作EventStartTime。 - 定义基于任务的活动逻辑:对于与工作流任务相关的活动(例如“合规审查已完成”),创建区块,按
TaskName筛选,并使用TaskCompletionDate作为EventStartTime。 - 设置全局报告筛选条件:应用报告级筛选条件限定数据范围。为
EventStartTime设置特定的Date Range,避免导出数据过多。建议初次分析选择3至6个月的时间范围。筛选特定案例类型,例如“KYC客户入职”。 - 运行并预览报告:在Fenergo界面中运行报告。预览前100至200行,确认数据结构正确、各列均按预期填充,且包含不同活动。
- 导出数据:将完整报告结果导出为CSV或Excel文件,即为原始事件日志文件。
- 准备最终数据:打开导出的CSV文件。如果报告无法直接生成
SourceSystem和LastDataUpdate列,请手动添加。将所有行的SourceSystem设为“Fenergo”,并将导出时间戳填入LastDataUpdate。
配置
- 前提条件:用户需要有权访问Fenergo报告与分析模块,并获准创建和运行自定义报告。
- 核心数据源:报告应主要基于Fenergo的案例管理和工作流历史对象构建。常见数据源包括
[CaseDetails]、[CaseStatusHistory]和[WorkflowTaskHistory]。具体名称可能因Fenergo配置而异。 - 日期范围:务必按事件时间戳设置日期范围筛选条件,以确保运行效率。建议先选择最近3至6个月的数据。进行历史分析时,可分批运行报告,例如按季度或年度运行。
- 关键筛选条件:始终按特定流程或案例类型筛选,例如“KYC客户入职”,以排除无关数据。根据分析目标,您可能还需要按法人实体类型或司法管辖区筛选。
- 活动定义:每项活动都必须根据
状态、TaskName或专用的EventType字段设置具体筛选条件。利用这些字段是区分流程中各项独立事件的关键。 - 性能注意事项:合并多个数据源或扫描较长日期范围的报告可能运行缓慢。条件允许时,请安排在非高峰时段运行。避免导出不必要的列,以缩短处理时间。
查询示例 sql
/*
This is a logical representation of the configuration needed in the Fenergo Reporting & Analytics module.
The module uses a graphical interface, but this query structure illustrates the required data sources, filters, and unions.
Fields like [CaseLifecycleData].[CaseID] are placeholders for actual Fenergo fields selected in the UI.
*/
-- Base data selection for common attributes
WITH CaseAttributes AS (
SELECT
C.CaseID AS CustomerApplication,
C.SlaTargetDate AS SlaTargetDate,
C.FinalRiskScore AS RiskScore,
C.CurrentStatus AS ApplicationStatus
FROM [CaseDetails] C
WHERE C.CaseType = 'KYC Customer Onboarding'
)
-- 1. Case Created
SELECT
A.CustomerApplication,
'Case Created' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
L.CompletionTimestamp AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CASE_CREATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 2. Initial Screening Performed
SELECT
A.CustomerApplication,
'Initial Screening Performed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Initial Screening' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 3. Data & Documents Requested
SELECT
A.CustomerApplication,
'Data & Documents Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Initial Document Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 4. Documents Received
SELECT
A.CustomerApplication,
'Documents Received' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 5. Document Review Completed
SELECT
A.CustomerApplication,
'Document Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Document Verification' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 6. Background Checks Initiated
SELECT
A.CustomerApplication,
'Background Checks Initiated' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'EXTERNAL_CHECK_INITIATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 7. Risk Assessment Completed
SELECT
A.CustomerApplication,
'Risk Assessment Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Risk Assessment' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 8. Compliance Review Initiated
SELECT
A.CustomerApplication,
'Compliance Review Initiated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Compliance Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 9. Additional Information Requested
SELECT
A.CustomerApplication,
'Additional Information Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Additional Information Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 10. Compliance Review Completed
SELECT
A.CustomerApplication,
'Compliance Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Compliance Review' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 11. Application Approved
SELECT
A.CustomerApplication,
'Application Approved' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Approved'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 12. Application Rejected
SELECT
A.CustomerApplication,
'Application Rejected' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Rejected'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 13. Account Activated
SELECT
A.CustomerApplication,
'Account Activated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Active'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 14. Case Closed
SELECT
A.CustomerApplication,
'Case Closed' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Closed'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]' 精简KYC客户入职流程,加快审批
与将客户入职时间缩短至仅24小时的企业同行。
无需信用卡,几分钟即可开始。