KYC客户入职数据模板
KYC客户入职数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- 数据提取指南
KYC客户入职属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件时间戳
EventTimestamp
|
特定活动开始的准确日期和时间。 | ||
|
说明
此时间戳标记活动的开始时间,用于确定案例中所有事件的先后顺序,也是流程挖掘中所有时间分析的基础。 利用事件时间戳,可以计算活动持续时间、活动之间的等待时间,以及整个入职流程的端到端周期时间。这些数据对于识别瓶颈、监控SLA达成情况和了解流程效率至关重要。
重要性
此时间戳对于按时间顺序排列事件,以及计算周期时间和瓶颈等所有时间指标至关重要。
获取途径
位于事件日志或审计跟踪表中,与活动名称一同记录。
示例
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
|
|||
|
客户申请
CustomerApplication
|
每份客户入职申请的唯一标识符,也是主要案例ID。 | ||
|
说明
客户申请是核心标识符,用于关联单个客户入职旅程中的所有相关活动和数据。申请提交后,该标识符便开始使用,并贯穿整个案例,直至流程完成或申请被拒绝。 在流程挖掘中,此属性对于将所有事件归入同一案例至关重要,可支持端到端分析整个入职周期。它能还原每位申请人的完整流程,进而计算周期时间、分析流程变体并跟踪申请状态的变化。
重要性
这是基础案例ID。没有它,您就无法追踪客户申请的端到端旅程,也无法开展流程分析。
获取途径
这是LexisNexis Risk Solutions案例管理模块中的主要案例标识符。
示例
APP-2023-001234APP-2023-005678APP-2024-009101
|
|||
|
活动名称
ActivityName
|
入职流程中某个时间点发生的具体任务或事件名称。 | ||
|
说明
活动名称用于描述KYC入职工作流中的一个步骤,例如“申请已提交”“已完成文档审核”或“申请已批准”。每项活动都代表流程中的一项独立操作或里程碑。 此属性对于构建流程图至关重要,流程图可以直观呈现各项活动的顺序。它有助于分析流程变体、特定步骤之间的瓶颈以及返工循环的发生频率。分析活动是了解流程实际情况的关键。
重要性
此属性是流程图的基础,可帮助您直观呈现并分析客户入职旅程中的事件顺序。
获取途径
通常可在LexisNexis Risk Solutions中跟踪流程步骤的事件日志或审计轨迹表中找到。
示例
申请已提交已完成初步筛查已请求提供文档已完成合规审核
|
|||
|
SLA目标日期
SlaTargetDate
|
预期完成客户 onboarding 流程的日期。 | ||
|
说明
SLA目标日期规定了完成申请的服务级别协议期限。该日期通常根据申请类型、客户群体或司法管辖区等因素确定。 此属性是“SLA目标达成情况监控”仪表板和“SLA达成率”KPI的必要依据。将实际完成日期与SLA目标日期进行比较,组织可以衡量承诺的达成情况、识别可能违反SLA的案例,并调查延误的根本原因。
重要性
用于衡量服务级别协议的达成情况,并揭示导致SLA违约的流程低效问题。
获取途径
请查阅LexisNexis Risk Solutions文档或咨询系统管理员。此信息可能存储在案例中,也可能根据业务规则计算得出。
示例
2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-12-01T17:00:00Z
|
|||
|
分配用户
AssignedUser
|
负责执行活动的用户或代理的唯一标识符。 | ||
|
说明
此属性用于标识执行任务的具体人员,例如负责审核文档的合规专员。它有助于分析工作负荷分配和个人绩效。 在分析中,分配用户是“资源分配与工作负荷”仪表板的关键属性。您可以按用户筛选流程图、比较团队成员的绩效,并发现培训或重新平衡工作负荷的机会。它还有助于找出由特定用户群体造成的瓶颈。
重要性
此属性对于分析资源绩效、工作负荷分配,以及发现自动化或资源优化机会至关重要。
获取途径
请查阅LexisNexis Risk Solutions文档或咨询系统管理员。通常可在审计跟踪或任务管理表中找到。
示例
j.doem.smithk.chen
|
|||
|
申请状态
ApplicationStatus
|
客户申请当前或最终的状态。 | ||
|
说明
此属性反映案例在特定时间点的整体状态或最终结果。常见状态包括“处理中”“已批准”“已拒绝”或“等待补充信息”。 申请状态对于跟踪客户 onboarding 流程结果至关重要。“申请拒绝原因与阶段”和“每日处理量与申请状态”仪表板会使用此属性监控成功率和运营流程。分析状态随时间的变化,有助于了解案例的完整生命周期。
重要性
跟踪每项申请的结果,是计算申请拒绝率等关键KPI和监控处理量的必要依据。
获取途径
请查阅LexisNexis Risk Solutions文档或咨询系统管理员。此属性通常是案例或申请主对象中的关键字段。
示例
处理中已批准已拒绝等待客户提供信息
|
|||
|
结束时间
EndTime
|
活动完成的具体日期和时间。 | ||
|
说明
此时间戳标记活动完成的时间。事件的结束时间与开始时间之差即为处理时间。 结束时间是准确计算每个步骤耗时的关键数据,也是“活动处理与等待时间”仪表板的主要输入。它有助于区分资源实际处理任务的时间与案例等待下一步开始的时间。
重要性
用于准确计算活动处理时间,这对于发现低效步骤和分析资源工作负荷至关重要。
获取途径
请查阅LexisNexis Risk Solutions文档或咨询系统管理员。通常可在同时记录开始和结束事件的事件日志中找到。
示例
2023-10-26T10:45:10Z2023-10-26T11:55:30Z2023-10-28T09:05:00Z
|
|||
|
部门
Department
|
分配用户所属的业务部门或团队。 | ||
|
说明
部门属性用于指定负责某项活动的职能团队,例如“合规”“客户 onboarding 运营”或“欺诈防范”。 此属性可用于从部门视角分析流程,了解不同团队之间的交接情况。它是“资源分配与工作负荷”仪表板的主要分析维度,有助于发现跨职能效率问题或部门间沟通延迟。
重要性
可按职能领域分析流程交接和绩效,帮助发现跨部门瓶颈。
获取途径
请查阅LexisNexis Risk Solutions文档或咨询系统管理员。可能需要从用户主数据表或人力资源主数据表中关联此属性。
示例
Compliance客户 onboarding 团队KYC分析师客户支持
|
|||
|
风险等级
RiskLevel
|
客户申请的计算风险等级,例如低、中或高。 | ||
|
说明
LexisNexis Risk Solutions专注于风险评估。此属性表示评估结果,根据潜在风险档案对每项申请进行分类。风险等级通常决定尽职调查所需的力度和时长。 此属性是“风险等级与客户 onboarding 时长”仪表板的核心分析维度。按风险等级分析流程,可以了解高风险申请是否如预期耗时更长,以及低风险申请是否遭到不必要的延误。这有助于验证并完善基于风险的客户 onboarding 策略。
重要性
这是基于风险开展分析的关键属性,有助于了解客户风险档案如何影响流程复杂度、时长和路径。
获取途径
请查阅LexisNexis Risk Solutions文档或咨询系统管理员。此属性是风险评估模块的核心输出。
示例
低中高受制裁
|
|||
|
SLA状态
SlaStatus
|
表示已完成的申请是否达到SLA目标。 | ||
|
说明
此属性根据案例是否符合“SlaTargetDate”进行分类。常见值为“已达成”或“已违约”。 此计算字段是“SLA目标达成情况监控”仪表板和“SLA达成率”KPI的基础。它清晰呈现服务承诺的达成情况,并支持逐级下钻分析,了解违反SLA的案例有哪些共同特征。
重要性
以清晰的二元结果呈现SLA绩效,便于跟踪、报告和分析服务级别目标的达成情况。
获取途径
这是一个计算属性,通过比较每个案例中最后一项活动的时间戳与“SlaTargetDate”得出。
示例
已达成已违约有风险
|
|||
|
最近数据更新时间
LastDataUpdate
|
数据上次从源系统刷新或提取的时间戳。 | ||
|
说明
此属性记录数据集最近一次更新的时间戳。通常在数据提取和加载过程中应用于整个数据集。 仪表板用户需要了解所分析数据的新鲜度。此信息有助于确保决策依据的数据满足时效要求,也能帮助用户合理预期分析结果的时效性。
重要性
提供数据时效性的重要背景信息,确保分析结果仍有参考价值,避免依据过时信息做出决策。
获取途径
此时间戳通常在ETL(提取、转换、加载)过程中生成并写入数据集。
示例
2024-01-15T02:00:00Z2024-01-16T02:00:00Z2024-01-17T02:00:00Z
|
|||
|
合规审核人员
ComplianceReviewer
|
专门负责合规审核活动的用户或代理。 | ||
|
说明
“AssignedUser”记录执行任何活动的用户,而此属性专门标识参与关键审核步骤的合规专员,便于更有针对性地分析合规职能。 此属性是“合规审核时长与积压情况”仪表板的关键维度。它有助于分析合规团队的工作负荷和绩效,判断特定审核人员是否造成瓶颈,或团队整体资源是否不足。
重要性
有助于深入分析合规职能,详细了解审核人员的工作负荷和绩效,尤其是这一关键且经常延误的流程阶段。
获取途径
请查阅LexisNexis Risk Solutions文档或咨询系统管理员。可筛选“AssignedUser”中的合规相关活动来推导此属性。
示例
c.joness.patelsystem_escalation
|
|||
|
周期时间
CycleTime
|
客户申请从提交到最终决策的端到端总时长。 | ||
|
说明
周期时间衡量单个案例从首个事件(例如“申请已提交”)到最后一个事件(例如“客户 onboarding 已完成”或“申请已拒绝”)所经过的总时间。 这是衡量整体流程健康度的主要KPI,并通过“客户 onboarding 端到端周期时间”仪表板呈现。跟踪平均周期时间有助于组织监控流程改进的影响,并了解风险等级或申请类型等因素如何影响整体客户体验。
重要性
这是衡量客户获得价值所需总时间的关键绩效指标,直接影响客户满意度和运营效率。
获取途径
这是一个计算指标,通过对每个案例用最后一个事件的时间戳减去第一个事件的时间戳得出。
示例
5天4小时22天8小时1天2小时
|
|||
|
客户所在国家/地区
CustomerCountry
|
客户居住或注册成立所在的国家/地区。 | ||
|
说明
此属性用于指定客户所在的国家/地区。不同司法管辖区的国际法规和风险等级各不相同,因此该属性对KYC至关重要。 按客户所在国家/地区分析流程,可以发现周期时间和流程复杂度方面的显著差异。例如,来自高风险司法管辖区的申请可能需要额外的一致性检查,因此耗时更长。这类分析有助于规划资源,并为不同地区设定合理的SLA。
重要性
支持按司法管辖区开展分析,这对于了解地区法规和风险因素如何影响流程绩效至关重要。
获取途径
请查阅LexisNexis Risk Solutions文档或咨询系统管理员。此属性是客户主数据中的标准字段。
示例
USAGBRDEUSGP
|
|||
|
拒绝原因
RejectionReason
|
说明申请被拒绝原因的代码或描述。 | ||
|
说明
当申请的最终状态为“已拒绝”时,此属性会记录具体原因,例如“身份验证失败”“命中制裁名单”或“文档不完整”。 此数据是“申请拒绝原因与阶段”仪表板的主要输入。分析拒绝原因有助于发现流程中的常见失败环节,为改进申请指南、客户沟通或内部审核标准提供依据。了解申请被拒绝的原因,是提高整体批准率的关键。
重要性
直接揭示客户 onboarding 失败的原因,帮助您有针对性地改进流程,提高申请批准率。
获取途径
请查阅LexisNexis Risk Solutions文档或咨询系统管理员。申请状态设为“已拒绝”时,通常会在相应字段中填写此信息。
示例
命中制裁名单文档不完整身份识别与验证失败高风险档案
|
|||
|
是否自动执行
IsAutomated
|
用于标记活动由系统自动执行还是由用户手动执行。 | ||
|
说明
此布尔属性用于区分系统自动执行的任务(例如初步筛查)和需要人工介入的任务(例如手动审核文档)。 “是否自动执行”用于计算“手动活动占比”KPI,并分析自动化举措的成效。在流程图中,它可以显示自动化步骤与手动步骤的衔接位置,帮助发现进一步自动化的机会,从而降低成本和处理时间。
重要性
区分手动任务和自动化任务,是发现自动化机会并衡量其影响的关键。
获取途径
请查阅LexisNexis Risk Solutions文档或咨询系统管理员。此属性可能是事件日志中的标记,也可能根据“AssignedUser”推断得出(例如用户为“system”)。
示例
truefalse
|
|||
|
是否返工
IsRework
|
用于标记属于返工循环的活动。 | ||
|
说明
当同一案例中的某项活动重复发生时,此布尔标记设为true。例如,在“请求补充信息”之后再次发生“已完成文档审核”,就表示流程出现回退。 “是否返工”是“返工与重复分析”仪表板和“返工循环占比”KPI的关键属性。它可以量化无效工作,并帮助找出返工的根本原因,例如说明不清或数据质量不佳,从而有针对性地改进流程。
重要性
直接量化流程中的低效和无效工作,揭示频繁重复、推高成本和周期时间的活动。
获取途径
这是一个计算属性,通常由流程挖掘工具检测案例中重复的活动序列后得出。
示例
truefalse
|
|||
|
渠道
Channel
|
提交申请的渠道,例如“网页”“移动端”或“网点”。 | ||
|
说明
渠道属性用于标识申请的提交来源。渠道可能影响数据质量、客户行为以及客户 onboarding 过程中遇到的问题类型。 此属性可用于比较不同渠道的流程绩效。例如,在“客户 onboarding 漏斗转化率”仪表板中按渠道筛选,可以了解移动端申请的中途退出率是否高于网页申请,从而为改进特定渠道的流程提供依据。
重要性
按申请提交渠道分析流程绩效,发现差异,为渠道策略和用户体验改进提供依据。
获取途径
请查阅LexisNexis Risk Solutions文档或咨询系统管理员。此信息通常在申请流程开始时记录。
示例
网页门户移动应用网点API
|
|||
|
源系统
SourceSystem
|
事件数据的来源系统或应用程序。 | ||
|
说明
此属性用于标识生成事件数据的源系统,例如LexisNexis Risk Solutions或集成的第三方工具。在复杂环境中,单个流程的数据可能来自多个系统。 了解源系统有助于验证数据、排查问题,并分析特定系统可能导致的流程差异。这有助于确保数据完整性,并了解活动的记录方式和来源。
重要性
标识数据来源,这对于数据治理、数据验证以及了解流程在不同IT系统中的执行情况至关重要。
获取途径
此信息可能以静态值的形式存储,也可能位于数据导出文件或API响应中的特定字段。
示例
LexisNexis Risk SolutionsThreatMetrixBridger Insight XG
|
|||
|
申请类型
ApplicationType
|
客户申请的类型,例如“个人”或“企业”。 | ||
|
说明
此属性根据 onboarding 对象的类型对申请进行分类。不同申请类型通常遵循不同的流程路径,风险档案和SLA目标也各不相同。 按申请类型分析流程,可以细分数据,比较不同客户类型的 onboarding 效率和复杂度。这也是大多数仪表板的常用筛选条件,可帮助您更细致地了解绩效。
重要性
可按申请类型细分流程,了解不同类型申请的处理方式,并发现各类型特有的瓶颈。
获取途径
请查阅LexisNexis Risk Solutions文档或咨询系统管理员。此属性通常是申请或案例对象中的核心字段。
示例
个人企业高净值个人信托
|
|||
KYC客户入职活动
| 活动 | 说明 | ||
|---|---|---|---|
|
客户入职已完成
|
此事件标志着整个入职流程成功结束,确认客户已完全激活。它可能是明确记录的最终状态,也可根据“账户已激活”事件推断。 | ||
|
重要性
这是表示成功状态的主要结束事件。计算所有成功完成入职的客户的端到端周期时间时,必须使用此事件。
获取途径
可根据“账户已激活”的时间戳推断,也可从案例文件中的最终终止状态获取,例如“入职完成”。
采集
可根据最后一个重要的正向事件(例如账户激活)或最终状态更新推断。
事件类型
inferred
|
|||
|
已启动合规审核
|
通常对于高风险申请,系统会将案例分配给合规专员或团队进行人工审核。可根据状态变更为“等待合规审核”或任务分配日志推断此活动。 | ||
|
重要性
这标志着人工审核步骤开始,该步骤通常耗时较长。衡量从此时到审核完成的时间,有助于量化合规相关瓶颈。
获取途径
可从任务分配日志、案例所有权转交给合规团队的记录,或案例历史中的状态更新获取。
采集
可根据状态变更为“合规审核中”等情况推断,也可在案例分配给合规相关用户队列时识别。
事件类型
inferred
|
|||
|
已完成合规审核
|
合规专员完成审核并提出建议,随后案例进入下一阶段。任务标记为“已完成”时可以明确记录此事件;也可根据状态从“等待合规审核”变更为其他状态推断。 | ||
|
重要性
这是重要里程碑,标志着流程中关键且通常由人工完成的环节结束。可据此衡量合规审核时长。
获取途径
可从合规任务完成时间戳中获取,也可根据状态退出“合规审核中”来识别。
采集
可根据表示审核结束的状态变更推断,例如状态变为“已批准”“已拒绝”或“最终决定”。
事件类型
inferred
|
|||
|
已完成风险评估
|
系统根据收集到的信息和检查结果计算客户风险评分。这是LexisNexis的核心功能,通常会作为明确的自动化事件记录在案例历史中。 | ||
|
重要性
评估结果通常决定后续流程路径,例如是否需要加强尽职调查。这是工作流中的关键决策点。
获取途径
查找应用程序审计日志或工作流历史中的事件记录,确认风险评分或评估模块已完成。
采集
风险引擎完成分析并分配风险等级或评分时,系统会记录特定事件。
事件类型
explicit
|
|||
|
已收到文档
|
确认客户已将所需文档上传或提交至系统。通常,文档提交门户会明确生成此事件,代理也可以手动录入。 | ||
|
重要性
此活动结束一段等待时间,并触发后续审核活动,是数据收集阶段的重要里程碑。
获取途径
可从文档管理系统日志中获取,也可查看案例文件中附加新文档时记录的时间戳。
采集
文档成功上传,或在系统中被手动标记为已收到时,系统会记录此事件。
事件类型
explicit
|
|||
|
申请已批准
|
系统记录批准客户申请的最终决定。这是关键业务结果,几乎总是通过明确的状态变更记录。 | ||
|
重要性
此里程碑标志着决策流程成功结束。分析通向批准结果的处理路径,有助于发现最佳实践。
获取途径
查看申请案例记录中的最终状态更新,确认状态是否设为“已批准”或类似的终止状态。
采集
在主申请表或案例表中记录为最终且明确的状态变更。
事件类型
explicit
|
|||
|
申请已拒绝
|
系统记录拒绝客户申请的最终决定。这是终止事件,通过明确的状态变更记录。 | ||
|
重要性
这是表示失败状态的主要结束事件。分析申请在哪些阶段被拒以及相关原因,对于改进流程至关重要。
获取途径
可从申请记录的最终状态字段中获取,例如状态设为“已拒绝”“未获批准”或类似的终止状态。
采集
在主申请表或案例表中记录为最终且明确的状态变更。
事件类型
explicit
|
|||
|
申请已提交
|
客户申请首次进入系统时,KYC入职流程即由此开始。通常,当客户通过门户提交申请表,或通过与LexisNexis集成的内部数据录入系统提交申请时,系统会明确记录此事件。 | ||
|
重要性
这是流程的主要开始事件。分析从该活动到流程完成的时间,对于衡量端到端周期时间和SLA达成情况至关重要。
获取途径
可从系统日志或申请表中获取,这些记录会保存新客户申请的初始创建时间戳。
采集
创建新的申请案例或在核心申请表中新增记录时,系统会记录此事件。
事件类型
explicit
|
|||
|
已启动身份验证
|
系统开始使用LexisNexis服务执行核心身份验证流程,例如与数据库进行比对。通常,调用验证服务时会在事件日志中明确记录此事件。 | ||
|
重要性
此活动标志着关键且通常耗时较长的子流程开始。跟踪其持续时间有助于定位身份核查相关的瓶颈。
获取途径
可从身份验证模块的API调用日志中获取,也可查看显示验证任务已启动的审计轨迹记录。
采集
系统触发身份验证模块或API处理申请时,会记录此事件。
事件类型
explicit
|
|||
|
已完成初步筛查
|
申请提交后,系统立即执行自动检查,以验证基本数据是否完整并进行初步核查。此活动通常会作为明确的自动化步骤记录在流程历史中。 | ||
|
重要性
识别在最早阶段未通过检查的申请,帮助了解数据质量问题,同时标记流程中首个自动化增值步骤。
获取途径
查找自动规则执行日志,或查看申请工作流历史中的状态变更,以确认初步筛查步骤已完成。
采集
系统会将其记录为已完成的自动化任务,或在案例历史中记录特定状态更新。
事件类型
explicit
|
|||
|
已完成文档审核
|
用户或自动化工具会审核已提交的文档,检查其真实性、有效性和完整性。可根据状态从“已收到文档”变更为“审核完成”来推断此活动,也可通过明确的日志记录识别。 | ||
|
重要性
这是常见的瓶颈和返工来源。分析处理时间和重复次数,对于提高效率、发现自动化机会至关重要。
获取途径
可通过跟踪“已收到文档”状态与后续“验证通过”或“需要补充信息”等状态之间的时间来推断。
采集
根据收到文档事件与标记审核完成的事件之间的时间计算。
事件类型
inferred
|
|||
|
已请求提供文档
|
系统或用户会向客户索取特定文档,例如驾驶证或水电费账单。可从系统生成的通信日志中获取此事件,也可通过案例状态变更为等待文档来识别。 | ||
|
重要性
此活动往往会显著增加流程等待时间。分析其发生频率和持续时间,有助于发现由客户响应时间造成的延误。
获取途径
查看发送给客户的通信日志,或申请状态变更记录,例如“等待客户提交文档”。
采集
可根据状态变更为“等待提供文档”推断,也可根据外发通信日志中的时间戳推断。
事件类型
inferred
|
|||
|
已请求补充信息
|
合规专员或审核人员会向客户索取更多信息或要求澄清。此事件是返工的主要原因,通常会通过明确的状态变更或通信日志记录。 | ||
|
重要性
此活动会造成返工循环,延长入职周期时间。跟踪其发生频率,有助于发现要求不明确或申请材料常见缺失等问题。
获取途径
查找状态变更为“等待客户提供信息”的记录,或外发通信事件日志。此操作通常由用户触发。
采集
代理使用“请求信息”功能时会记录此事件。该操作会更改案例状态,也可能生成通信事件记录。
事件类型
explicit
|
|||
|
账户已激活
|
申请获批后,客户账户会在核心银行或服务平台中正式创建并激活。此活动通常记录在审计轨迹中,也可根据账户创建日期推断。 | ||
|
重要性
这是最终向客户交付价值的步骤。从“申请已批准”到此步骤之间的延误,可能表明系统集成存在问题。
获取途径
可从账户创建日志、对其他系统的API调用记录,或账户记录本身的创建时间戳中获取。
采集
此事件会在批准后单独记录,也可通过客户记录中的激活时间戳识别。
事件类型
explicit
|
|||
数据提取指南
优化KYC客户入职流程,减少客户流失
实现顺畅的客户入职,将处理时间缩短至24小时。
无需信用卡,即刻开始优化。