您的 KYC 客户准入数据模板
您的 KYC 客户准入数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 提取指南
KYC 客户准入属性
| 名称 | 描述 | ||
|---|---|---|---|
|
事件timestamp
EventTimestamp
|
特定活动开始的精确日期和时间。 | ||
|
描述
此 timestamp 标志着活动的开始,为 case 内的所有事件提供时间顺序。它是流程挖掘中所有基于时间的分析的基础。 利用 Event Timestamp,可以计算活动的持续时间、活动间的等待时间以及准入流程的完整端到端周期时间。这些数据对于识别瓶颈、监控 SLA 达成情况以及了解流程效率必不可少。
为何重要
此 timestamp 对于按时间顺序排列事件以及计算所有基于时间的指标(如周期时间和瓶颈)至关重要。
获取方式
位于事件日志或审计追踪表中,紧邻 Activity Name。
示例
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
|
|||
|
客户申请
CustomerApplication
|
每份客户准入申请的唯一标识符,作为主要 case ID。 | ||
|
描述
Customer Application 是连接单个客户准入路径中所有相关活动和数据点的核心标识符。它从提交申请开始,一直追踪该 case 直至完成或拒绝。 在流程挖掘中,此属性对于将所有事件归类为完整的 case 至关重要,从而支持准入生命周期的端到端分析。它能够重构每个申请人的完整流程流,这是计算周期时间、分析流程变体以及追踪申请状态随时间变化的基础。
为何重要
这是基础的 Case ID。没有它,您就无法追踪客户申请的端到端路径,从而导致流程分析无法进行。
获取方式
这是 LexisNexis Risk Solutions case 管理模块中的主要 case 标识符。
示例
APP-2023-001234APP-2023-005678APP-2024-009101
|
|||
|
活动名称
ActivityName
|
在准入流程中某一时刻发生的特定任务或事件的名称。 | ||
|
描述
Activity Name 描述了 KYC 准入工作流中的一个步骤,例如“申请已提交”、“已执行文件审核”或“申请已批准”。每个活动代表流程中一个独立的操作或里程碑。 此属性对于构建流程地图至关重要,该地图能可视化呈现活动流。通过它,可以分析流程变体、特定步骤间的瓶颈以及返工循环的频率。分析活动是深入了解流程运行状况的关键。
为何重要
此属性构成了流程地图的骨干,让您可以可视化并分析客户准入路径中的事件序列。
获取方式
通常位于 LexisNexis Risk Solutions 中用于追踪流程步骤的事件日志或审计追踪表中。
示例
已提交申请已执行初始筛查已请求文件合规审核已完成
|
|||
|
SLA 目标日期
SlaTargetDate
|
预计完成客户准入流程的日期。 | ||
|
描述
SLA Target Date 定义了完成申请的服务水平协议。该日期通常根据申请类型、客户细分或管辖区等因素确定。 此属性对于“SLA 目标达成监控”仪表板和“SLA 达成率”KPI 至关重要。通过对比实际完成日期与 SLA 目标日期,企业可以衡量其履行承诺的情况,识别有 SLA 违约风险的 case,并调查延迟的根本原因。
为何重要
支持根据服务水平协议进行性能评估,突出显示导致违反 SLA 的流程低效环节。
获取方式
请咨询 LexisNexis Risk Solutions 文档或系统管理员。这可能存储在案件上,或根据业务规则计算得出。
示例
2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-12-01T17:00:00Z
|
|||
|
申请状态
ApplicationStatus
|
客户申请的当前或最终状态。 | ||
|
描述
此属性反映 case 在特定时间点的整体状态或其最终结果。常见状态包括“处理中”、“已批准”、“已拒绝”或“等待信息”。 Application Status 对于追踪准入流程的结果至关重要。它被用于“申请拒绝原因与阶段”以及“每日吞吐量与申请状态”仪表板,以监控成功率和运营流。分析状态随时间的变化可以洞察 case 的生命周期。
为何重要
追踪每份申请的结果,这对于计算“申请拒绝率”等关键 KPI 以及监控吞吐量至关重要。
获取方式
请咨询 LexisNexis Risk Solutions 文档或系统管理员。这通常是主案件或申请对象上的关键字段。
示例
进行中已批准已驳回待处理客户信息
|
|||
|
结束时间
EndTime
|
活动完成的准确日期与时间。 | ||
|
描述
此 timestamp 标志着活动的完成。事件的结束时间与开始时间之差即代表其处理时间。 End Time 对于准确计算每个步骤的耗时至关重要,是“活动处理与等待时间”仪表板的主要输入项。它有助于区分资源主动处理任务的时间与 case 等待进入下一步的时间。
为何重要
支持精确计算活动处理时间,这对于识别低效步骤和分析资源工作负载至关重要。
获取方式
请咨询 LexisNexis Risk Solutions 文档或系统管理员。通常可以在记录开始和结束事件的事件日志中找到。
示例
2023-10-26T10:45:10Z2023-10-26T11:55:30Z2023-10-28T09:05:00Z
|
|||
|
被分配用户
AssignedUser
|
负责执行该活动的个人用户或代理人的唯一标识符。 | ||
|
描述
此属性识别执行任务的具体人员,例如执行文件审核的合规官。它有助于分析工作量分配和个人绩效。 在分析中,Assigned User 是“资源配置与工作量”仪表板的关键。它支持按用户过滤流程地图,比较团队成员间的绩效,并识别培训或工作量重新平衡的机会。它还能帮助精准定位由特定用户群体导致的瓶颈。
为何重要
此属性对于分析资源绩效、工作量分配以及识别自动化或资源优化机会至关重要。
获取方式
请咨询 LexisNexis Risk Solutions 文档或系统管理员。通常位于审计追踪或任务管理表中。
示例
j.doem.smithk.chen
|
|||
|
部门
Department
|
被指派用户所属的业务部门或团队。 | ||
|
描述
Department 属性指定负责某项活动的职能小组,如“合规部”、“准入运营部”或“欺诈预防部”。 此属性用于从部门视角分析流程,从而支持对不同团队间交接环节的分析。它是“资源配置与工作量”仪表板的主要维度,有助于识别跨部门的低效环节或沟通延迟。
为何重要
支持按职能区域分析流程交接和性能,有助于识别跨部门瓶颈。
获取方式
请咨询 LexisNexis Risk Solutions 文档或系统管理员。可能需要从用户或 HR 主数据表中联接。
示例
Compliance准入团队KYC 分析师客户支持
|
|||
|
风险等级
RiskLevel
|
计算出的客户申请风险等级,如低、中或高。 | ||
|
描述
LexisNexis Risk Solutions 专注于风险评估。此属性代表评估结果,根据每份申请的潜在风险状况进行分类。风险等级通常决定了尽职调查所需的强度和耗时。 该属性是“风险等级 vs 准入时长”仪表板的核心维度。通过风险等级分析流程,可以揭示高风险申请是否如预期般耗时更长,或者低风险申请是否存在不必要的延迟。这有助于验证并精炼基于风险的准入策略。
为何重要
对于基于风险的分析至关重要,有助于了解客户风险概况如何影响流程复杂度、持续时间和路径。
获取方式
请咨询 LexisNexis Risk Solutions 文档或系统管理员。这是风险评估模块的核心输出。
示例
低中高受制裁
|
|||
|
SLA 状态
SlaStatus
|
指示已完成的申请是否达到了其 SLA 目标。 | ||
|
描述
该属性根据每个已完成 case 对 'SlaTargetDate' 的遵守情况进行分类。典型值为“已达成”或“已违约”。 该计算字段是“SLA 目标达成监控”仪表板和“SLA 达成率”KPI 的基础。它提供了履行服务承诺情况的清晰、高层级视图,并支持钻取分析,以深入了解 SLA 违约 case 的共同特征。
为何重要
为 SLA 绩效提供清晰的二元结果,便于追踪、报告和分析服务水平目标的达成情况。
获取方式
这是一个计算属性,通过对比每个 case 的最后一项活动的 timestamp 与 'SlaTargetDate' 得出。
示例
已达成已超期存在风险
|
|||
|
最后数据更新
LastDataUpdate
|
用于指示数据上次从源系统刷新或抽取时间的时间戳。 | ||
|
描述
此属性提供数据集最后更新的 timestamp。通常在数据提取和加载过程中应用于整个数据集。 这些信息对于仪表板用户了解所分析数据的新鲜度至关重要。它确保决策基于符合时效要求的数据,并有助于管理对洞察及时性的预期。
为何重要
提供关于数据新鲜度的关键背景,确保分析具有相关性,避免基于过时信息做出决策。
获取方式
这通常在 ETL(提取、转换、加载)过程中生成并标记到数据集中。
示例
2024-01-15T02:00:00Z2024-01-16T02:00:00Z2024-01-17T02:00:00Z
|
|||
|
合规审核员
ComplianceReviewer
|
被专门指派负责合规审核活动的个人用户或代理人。 | ||
|
描述
虽然 'AssignedUser' 捕获了所有活动的用户,但此属性专门识别参与关键审核步骤的合规专家。这使得对合规职能的分析更加聚焦。 该属性是“合规审核时长与积压”仪表板的关键。它有助于分析合规团队的工作量和绩效,识别特定的审核员是否成为瓶颈,或者整个团队是否资源不足。
为何重要
提供对合规职能的专项洞察,支持对这一关键且常发生延迟的流程阶段进行详细的审核员工作量和绩效分析。
获取方式
请咨询 LexisNexis Risk Solutions 文档或系统管理员。这可以通过针对合规相关活动筛选“被分配用户”来得出。
示例
c.joness.patelsystem_escalation
|
|||
|
周期时间
CycleTime
|
客户申请的完整端到端时长,从提交到做出最终决定。 | ||
|
描述
周期时间衡量单个案件从第一个事件(例如“申请已提交”)到最后一个事件(例如“客户入职已完成”或“申请已拒绝”)所经历的总时长。 这是衡量流程整体健康状况的主要 KPI,并在“入职端到端周期时间”仪表板中直观展示。通过追踪平均周期时间,机构可以监控流程改进的效果,并识别不同因素(如风险等级或申请类型)如何影响整体客户体验。
为何重要
这是一个关键绩效指标,用于衡量客户获得价值的总时长,直接影响客户满意度和运营效率。
获取方式
这是一个计算指标,通过从每个 case 的最后一个事件 timestamp 中减去第一个事件的 timestamp 得出。
示例
5 天 4 小时22 天 8 小时1 天 2 小时
|
|||
|
处理时间
ProcessingTime
|
在一项活动上实际投入工作的时间长度。 | ||
|
描述
Processing Time 是根据活动的开始和结束 timestamp(EndTime - StartTime)计算出的持续时间。它代表资源主动处理任务的时间,而非等待时间。 这一计算指标是绩效分析的基石,直接为“活动处理与等待时间”仪表板提供数据。它有助于精准定位哪些特定活动最耗时,从而明确流程改进、培训或自动化的目标。例如,它有助于计算“平均文件审核处理时间”这一 KPI。
为何重要
衡量活动的实际工作时间,有助于区分增值时间和无效等待时间,从而识别真正的瓶颈。
获取方式
这是一个计算字段,源自 'EndTime' 与 'EventTimestamp' (StartTime) 属性之间的差值。
示例
25 分钟1 小时 15 分钟3天
|
|||
|
客户国家/地区
CustomerCountry
|
客户的居住国或注册国。 | ||
|
描述
此属性指定客户所属国家。由于不同管辖区的国际法规和风险等级各异,这是 KYC 中的关键因素。 按 Customer Country 分析流程可以揭示周期时间和流程复杂程度的显著差异。例如,来自高风险管辖区的申请可能需要额外的合规检查,从而导致耗时更长。这种分析有助于资源规划并为不同地区设定合理的 SLA。
为何重要
支持司法管辖区分析,这对于了解地区法规和风险因素如何影响流程性能至关重要。
获取方式
请咨询 LexisNexis Risk Solutions 文档或系统管理员。这是客户主数据中的标准字段。
示例
美国GBRDEUSGP
|
|||
|
拒绝原因
RejectionReason
|
解释申请被拒绝原因的代码或描述。 | ||
|
描述
当申请的最终状态为“已拒绝”时,此属性提供具体原因。示例包括“身份验证失败”、“制裁名单匹配”或“文件不全”。 这些数据是“申请拒绝原因与阶段”仪表板的主要输入项。分析拒绝原因有助于识别流程中的常见故障点,从而为改进申请指南、客户沟通或内部审核标准提供依据。了解申请被拒的原因是提高整体审批通过率的关键。
为何重要
直观展示准入失败的原因,以便进行针对性改进,提升申请审批通过率。
获取方式
请咨询 LexisNexis Risk Solutions 文档或系统管理员。通常位于当申请状态设为“已拒绝”时填充的字段中。
示例
制裁名单匹配文档不完整ID&V 失败高风险概况
|
|||
|
是否已自动化
IsAutomated
|
标识某项活动由系统自动执行还是由用户手动完成的标记。 | ||
|
描述
此布尔属性区分由系统自动执行的任务(如初始筛查)和需要人工干预的任务(如人工文件审核)。 'Is Automated' 用于计算“人工活动占比”KPI 并分析自动化举措的有效性。在流程地图中,它可以凸显自动化与人工步骤之间的交接界面,有助于识别进一步自动化的机会,从而降低成本并缩短处理时间。
为何重要
区分人工和自动任务,这是识别自动化机会并衡量其影响的关键。
获取方式
请咨询 LexisNexis Risk Solutions 文档或系统管理员。这可能是事件日志中的一个标记,或基于“被分配用户”(例如“系统”用户)推断得出。
示例
truefalse
|
|||
|
是否返工
IsRework
|
用于识别属于返工循环一部分的活动的标记。 | ||
|
描述
当同一个 case 内重复出现某项活动时(例如在“请求补充信息”后第二次执行“执行文件审核”),该布尔标志被设置为 true。这表示流程发生了倒流。 'Is Rework' 对于“返工与重复分析”仪表板以及“返工循环百分比”KPI 至关重要。它支持量化无效劳动,并有助于识别返工的根本原因(如指令不明或数据质量差),从而实现针对性的流程改进。
为何重要
直接量化流程中的低效和精力浪费,突出显示频繁重复、抬高成本并延长周期时间的活动。
获取方式
这是一个计算属性,通常在流程挖掘工具内通过检测 case 中重复出现的活动序列得出。
示例
truefalse
|
|||
|
渠道
Channel
|
提交申请的渠道,例如“网页”、“移动端”或“线下网点”。 | ||
|
描述
Channel 属性标识申请的提交来源。渠道会影响数据质量、客户行为以及准入过程中遇到的问题类型。 此属性用于比较不同渠道的流程绩效。例如,可以按渠道过滤“准入漏斗转化率”仪表板,观察移动端申请人的流失率是否高于网页端,从而为特定渠道的流程改进提供依据。
为何重要
有助于按提交渠道分析流程性能,识别出的变体可为渠道策略和用户体验改进提供参考。
获取方式
请咨询 LexisNexis Risk Solutions 文档或系统管理员。此类信息通常在申请流程开始时采集。
示例
网络门户移动应用线下网点API
|
|||
|
源系统
SourceSystem
|
事件数据来源的系统或应用程序。 | ||
|
描述
该属性识别生成事件数据的源系统,例如 LexisNexis Risk Solutions 或集成的第三方工具。在复杂环境中,单个流程的数据可能来自多个系统。 了解源系统有助于进行数据验证、故障排除,以及分析可能特定于某个系统的流程变体。它有助于确保数据完整性,并提供关于活动记录方式和位置的背景信息。
为何重要
识别数据的来源,这对于数据治理、验证以及了解跨不同 IT 系统的流程执行情况至关重要。
获取方式
这些信息可能作为静态值存储,或位于数据导出或 API 响应中的特定字段。
示例
LexisNexis Risk SolutionsThreatMetrixBridger Insight XG
|
|||
|
申请类型
ApplicationType
|
客户申请的类型,如“个人”或“企业”。 | ||
|
描述
此属性根据准入实体的类型对申请进行分类。不同的申请类型通常遵循不同的流程路径,并具有不同的风险状况和 SLA 目标。 按 Application Type 分析流程可以对数据进行细分,从而比较准入不同类型客户的效率和复杂程度。这是大多数仪表板中常用的过滤器,旨在提供更精细的绩效视图。
为何重要
支持对流程进行强大的细分分析,揭示不同类型的申请是如何处理的,以及每种类型存在的具体瓶颈。
获取方式
请咨询 LexisNexis Risk Solutions 文档或系统管理员。这通常是申请或案件对象上的核心字段。
示例
个人业务高净值个人信任
|
|||
KYC 客户准入活动
| 活动 | 描述 | ||
|---|---|---|---|
|
合规审核已启动
|
案件被分配给合规官或团队进行人工审核,通常针对高风险申请。这通常可以通过状态更改为“等待合规审核”或从任务分配日志中推断出来。 | ||
|
为何重要
这标志着人工审核步骤的开始,该步骤通常耗时较长。衡量从这一时刻到完成的时间有助于量化合规相关的瓶颈。
获取方式
从任务分配日志、案件所有权变更至合规团队或案件历史中的状态更新中采集。
捕获
从“合规审核中”之类的状态更改或案件分配给合规相关的用户队列中推断得出。
事件类型
inferred
|
|||
|
合规审核已完成
|
合规官完成审核并提出建议,将 case 移交给下一阶段。当任务被标记为“完成”时可以明确捕获,或者在状态从“待合规审核”变为其他状态时推断得出。 | ||
|
为何重要
这是一个关键里程碑,标志着流程中一个核心(且通常是人工)环节的结束。它是衡量合规审核时长的终点。
获取方式
从合规任务完成时间戳或状态脱离“合规审核中”的时间中采集。
捕获
从指示审核结束的状态更改中推断得出,例如变更为“已批准”、“已拒绝”或“最终决策”。
事件类型
inferred
|
|||
|
客户入职已完成
|
该事件标志着整个准入流程的成功结束,确认客户已完全激活。它可以是一个明确的最终状态,也可以从“账户已激活”事件中推断得出。 | ||
|
为何重要
这是主要的成功状态结束事件。它对于计算所有成功准入客户的端到端周期时间必不可少。
获取方式
从“帐户已激活”时间戳推断得出,或从案件文件中诸如“入职完成”之类的最终终止状态中采集。
捕获
从最后一个重要的积极事件(如帐户激活)或最终状态更新中推断得出。
事件类型
inferred
|
|||
|
已执行风险评估
|
系统根据收集的信息和执行的检查为客户计算风险评分。这是 LexisNexis 的核心功能,通常作为明确的自动化事件记录在 case 历史中。 | ||
|
为何重要
评估结果通常决定后续的流程路径,例如是否需要加强尽职调查。这是工作流中的一个关键决策点。
获取方式
在申请的审计日志或工作流历史记录中查找记录风险评分或评估模块完成的事件。
捕获
当风险引擎完成分析并分配风险概况或分值时记录的特定事件。
事件类型
explicit
|
|||
|
已提交申请
|
标志着 KYC 准入流程的开始,即系统首次接收到客户申请。当客户通过与 LexisNexis 集成的门户网站或内部数据输入系统提交申请表时,该事件通常会被明确捕获。 | ||
|
为何重要
这是流程的主要启动事件。分析从该活动到完成所需的时间,对于衡量端到端周期时间和 SLA 达成情况至关重要。
获取方式
从记录新客户申请记录初始创建时间戳的系统日志或申请表中采集。
捕获
在创建新申请案件或在核心申请表中添加条目时记录事件。
事件类型
explicit
|
|||
|
已收到文件
|
确认客户已向系统上传或提供了所需文档。这通常是由文档提交门户生成的明确事件,或由代理商手动输入。 | ||
|
为何重要
此活动结束了一段等待时间,并触发了后续的审核活动。它是数据收集阶段的一个关键里程碑。
获取方式
当新文档附件上传时,从文档管理系统日志或申请案件文件中的带时间戳条目中采集。
捕获
当文档成功上传或在系统中被手动标记为已收到时记录事件。
事件类型
explicit
|
|||
|
申请已批准
|
系统记录下批准客户申请的最终决定。这是一个关键的业务结果,几乎总是作为明确的状态更改被捕获。 | ||
|
为何重要
这一里程碑标志着决策过程的圆满结束。分析通往批准的路径有助于识别最佳实践。
获取方式
在申请 case 记录中查找最终状态更新,通常状态被设置为“已批准”或类似的终结状态。
捕获
在主申请或 case 表中记录为最终的确定性状态更改。
事件类型
explicit
|
|||
|
申请已拒绝
|
记录下拒绝客户申请的最终决定。这是一个终结性事件,通过系统中的明确状态更改被捕获。 | ||
|
为何重要
这是主要的失败状态结束事件。分析拒绝发生的阶段及其相关原因是流程改进的关键。
获取方式
从申请记录的最终状态字段设置为“已拒绝”、“已谢绝”或类似终态时采集。
捕获
在主申请或 case 表中记录为最终的确定性状态更改。
事件类型
explicit
|
|||
|
已执行初始筛查
|
系统在提交后立即执行的自动检查,用于验证基础数据的完整性并进行初步核查。此活动通常记录为流程工作流历史中的一个明确自动化步骤。 | ||
|
为何重要
识别在最早阶段就失败的申请,有助于了解数据质量问题。它还标志着流程中第一个自动化的增值步骤。
获取方式
查找自动化规则执行日志或申请工作流历史记录中的状态更改,以确认初始筛查步骤已完成。
捕获
在 case 历史记录中记为已完成的自动化任务或特定的状态更新。
事件类型
explicit
|
|||
|
已请求文件
|
系统或用户向客户索取特定文件,如驾照或公用事业账单。该事件可从系统生成的通信日志中捕获,或通过指示 case 正在等待文件的状态更改来获悉。 | ||
|
为何重要
此活动往往会给流程带来显著的等待时间。分析其频率和时长有助于识别由客户响应时间导致的延迟。
获取方式
检查发送给客户的通讯日志中的事件或申请状态的更改,例如“等待客户文档”。
捕获
从状态更改为“等待文档”或从外发通讯日志时间戳中推断得出。
事件类型
inferred
|
|||
|
帐户已激活
|
批准后,客户帐户将在核心银行或服务平台中正式创建并激活。此活动通常记录在审计追踪中,或从帐户创建日期推断得出。 | ||
|
为何重要
这是面向客户的最终价值交付步骤。“申请已批准”与此步骤之间的延迟可能预示着系统集成存在问题。
获取方式
从帐户创建日志、向另一个系统的 API 调用或帐户记录本身的创建时间戳中采集。
捕获
记为审批后的独立事件,或通过客户记录中存在的激活 timestamp 来识别。
事件类型
explicit
|
|||
|
文档审核已执行
|
用户或自动化工具审核提交文档的真实性、有效性和完整性。此活动可以从“已收到文档”到“审核完成”的状态更改或明确的日志条目中推断出来。 | ||
|
为何重要
这是瓶颈和返工的常见源头。分析其处理时间和重复次数是提高效率和识别自动化机会的关键。
获取方式
通过追踪从“已收到文档”状态到随后的“验证通过”或“需要补充信息”状态之间的时间推断得出。
捕获
计算为从收到文档事件到标记审核完成事件之间的时间。
事件类型
inferred
|
|||
|
请求补充信息
|
合规官或审核员请求客户提供更多信息或澄清。此事件是导致返工的主要原因,通常记录为明确的状态更改或通讯日志条目。 | ||
|
为何重要
此活动会产生返工循环,从而延长准入周期。追踪其频率有助于识别不明确的要求或常见的申请缺陷。
获取方式
查找状态更改为“等待客户信息”或外部通信事件日志。这通常是用户触发的操作。
捕获
当代理人使用“请求信息”功能时记录,该操作会更改 case 状态并可能记录通信事件。
事件类型
explicit
|
|||
|
身份验证已启动
|
代表系统开始使用 LexisNexis 服务(如数据库核对)进行核心身份验证的时刻。这通常在调用验证服务时作为明确的事件日志被捕获。 | ||
|
为何重要
此活动标志着一个关键且通常耗时的子流程的开始。追踪其持续时间有助于剥离与身份核查相关的瓶颈。
获取方式
从发往身份验证模块的 API 调用日志或显示验证任务开始的审计追踪条目中采集。
捕获
当系统为申请触发身份验证模块或 API 时记录的事件。
事件类型
explicit
|
|||