您的KYC客户入职数据模板
您的KYC客户入职数据模板
- 事件日志建议包含的属性
- 流程中需要跟踪的关键活动
- 实用的数据提取指南
KYC客户入职属性
| 名称 | 说明 | ||
|---|---|---|---|
|
客户申请
CustomerApplication
|
每个客户入职申请案例的唯一标识符。 | ||
|
说明
客户申请是主要案例标识符,用于汇总单个客户入职流程中的所有相关活动和事件。每份申请都从提交开始,最终获批并激活账户,或被拒绝。 在流程挖掘中,此属性对于还原每份申请的端到端流程至关重要。分析人员可以查看完整的事件序列、跟踪每份申请的状态并比较不同路径。按此ID分析案例,有助于发现常见的流程变体、瓶颈以及偏离标准过程的情况。
重要性
此ID是流程挖掘的基础,可将各个事件关联起来,形成连贯的端到端流程实例以供分析。
获取途径
在Pega中,这通常是主要案例ID,常见字段为pzInsKey,或主案例类型工作对象中便于业务人员识别的对应字段。
示例
APP-2023-00123APP-2023-00124APP-2023-00125
|
|||
|
开始时间
EventTime
|
表示活动或事件开始时间的时间戳。 | ||
|
说明
此属性记录活动开始的准确日期和时间,确定单个客户申请案例中所有事件的先后顺序。 时间戳是分析流程绩效的基础,可用于计算活动持续时间、步骤间等待时间以及入职流程的端到端周期时间。这些数据对于识别瓶颈、衡量SLA达成情况和了解流程效率至关重要。
重要性
时间戳提供了计算时长、分析流程绩效和识别延误所需的时间顺序信息。
获取途径
这是Pega审计轨迹中的标准信息,通常以pxTimeCreated的形式记录在每个事件的历史表中。
示例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:05:00Z
|
|||
|
活动
ActivityName
|
入职流程中发生的具体事件或任务名称。 | ||
|
说明
此属性记录业务活动或系统事件的名称,例如“申请已提交”“合规审核已启动”或“申请已拒绝”。它代表客户入职流程中的一个步骤。 活动分析是流程挖掘的核心。此属性用于构建流程图,展示不同步骤之间的顺序流,帮助识别事件顺序、衡量各项活动的发生频率,并找出最常见或最耗时的任务。
重要性
此属性定义流程图中的步骤,便于您直观呈现、分析并了解流程的流转情况。
获取途径
此信息通常记录在Pega的审计轨迹(历史表)中,也可以根据案例状态变化推导得出。
示例
已完成初步筛查已完成合规审核申请已批准
|
|||
|
SLA目标日期
SlaTargetDate
|
预计完成客户入职案例的日期。 | ||
|
说明
此属性存储申请的目标完成日期,该日期由服务级别协议(SLA)规定。SLA可能因客户类型、风险等级或产品而异。 此日期对于“SLA达成情况跟踪”仪表板及相关KPI至关重要,可作为实际完成日期的对照基准。分析未能达到SLA目标的案例,有助于发现系统性延误并优先呈现流程改进事项,确保履行服务承诺。
重要性
此属性为衡量按时完成情况提供基准,对客户满意度和运营管理至关重要。
获取途径
Pega内置了SLA管理框架。此日期通常存储在pySLAGoal等属性中,也可能存储在案例的自定义SLA属性中。
示例
2023-11-10T17:00:00Z2023-11-15T17:00:00Z
|
|||
|
拒绝原因
RejectionReason
|
说明申请被拒绝的原因。 | ||
|
说明
当申请的最终状态为“已拒绝”时,此属性会提供具体原因,例如“背景调查未通过”“文档不完整”或“风险等级高”。 此属性是“申请拒绝分析”仪表板的主要分析依据。按原因对被拒案例分类,企业可以找出入职流程中最常见的失败环节。这些洞察有助于有针对性地改进流程、降低拒绝率、改善客户体验并提高运营效率。
重要性
此属性有助于了解申请未通过的原因,从而有针对性地改进流程并提高成功率。
获取途径
案例状态变为“已拒绝”时,可能会在案例上设置相应属性。请查阅Pega KYC文档,了解标准拒绝原因字段。
示例
命中制裁名单文档信息不一致识别出政治公众人物(PEP)信息不足
|
|||
|
用户
OperatorId
|
执行活动的用户唯一标识符。 | ||
|
说明
此属性记录负责完成KYC流程中特定任务的员工或系统用户ID,例如合规专员或自动筛查机器人。对于自动化步骤,该值可能是系统或服务账户ID。 按用户分析有助于了解工作量分配、个人绩效和培训需求。通过识别参与非标准流程的用户或团队,也可以调查流程偏差。
重要性
此属性将流程活动关联到具体人员或团队,以便分析工作量、评估绩效并进行一致性检查。
获取途径
这是Pega审计轨迹中的标准字段,通常以pxUpdateOperator或类似属性存储在历史表中。
示例
j.doe@acmebank.comkyc_analyst_04system_auto_agent
|
|||
|
申请状态
ApplicationStatus
|
客户申请的最终结果或当前状态。 | ||
|
说明
此属性表示流程结束时申请的整体状态,例如“已批准”“已拒绝”或“已撤回”。对于尚未完成的案例,也可以反映最近一次已知状态。 这是结果分析中的关键维度。“申请拒绝分析”仪表板会直接使用此属性对案例分类,帮助了解不同结果的成因。分析导致不同状态的流程,有助于发现获批案例的最佳实践,以及被拒案例的根本原因。
重要性
此属性定义案例的业务结果,便于对比成功与未成功的流程路径。
获取途径
通常是Pega案例工作对象的最终状态(pyStatusWork)。
示例
已批准已拒绝等待合规审核客户已撤回
|
|||
|
结束时间
EndTime
|
表示活动或事件完成时间的时间戳。 | ||
|
说明
此属性记录活动结束的准确日期和时间,并与开始时间配合计算各项活动的处理时间。 单独记录结束时间可以提高绩效分析的准确性。通过开始时间和结束时间之间的时长,可以计算实际处理时间;通过一项活动的结束时间与下一项活动的开始时间之间的时长,则可以计算等待时间。这对于定位真正的瓶颈、区分瓶颈与排队等待至关重要。
重要性
此属性可精确计算活动处理时间,是深入分析绩效和识别瓶颈的关键。
获取途径
Pega审计轨迹中可能包含此信息;如果没有,也可以将后续事件的开始时间作为当前事件的结束时间来推导。
示例
2023-10-26T10:15:00Z2023-10-26T18:05:20Z2023-10-27T11:00:00Z
|
|||
|
部门
WorkGroup
|
负责该活动的部门或职能团队。 | ||
|
说明
此属性用于标识执行用户所属的组织单位或团队,例如“筛查团队”“合规部门”或“入职运营团队”。 按部门分析流程对于“部门工作量分布”仪表板至关重要。管理者可以借此了解工作如何在不同团队间流转、识别跨职能瓶颈,并评估整个入职流程中的资源分配情况。此分析有助于优化交接并平衡工作量。
重要性
此属性支持分析不同业务单元之间的流程和瓶颈,为资源管理和组织优化提供依据。
获取途径
此信息通常与Pega中的用户档案(Operator ID记录)关联,可与事件数据联接。对应属性可能是pyWorkGroup。
示例
初步筛查合规审查账户激活
|
|||
|
风险等级
RiskLevel
|
客户申请的风险评估等级。 | ||
|
说明
此属性表示评估得出的客户风险等级,通常分为“低”“中”或“高”。风险等级通常由自动评分引擎根据客户数据和筛查结果确定。 风险等级会显著影响流程变体。高风险申请通常需要额外的尽职调查步骤,例如加强合规审核,因此周期时间更长。按风险等级分析流程,有助于解释这些差异,并确保风险控制有效运行,同时避免造成不必要的延误。
重要性
此属性有助于解释流程路径和时长的差异,因为风险等级通常决定所需的尽职调查程度。
获取途径
这可能是案例上的计算属性,由Pega决策规则或评分模型填充。请查阅Pega KYC文档。
示例
低中高
|
|||
|
SLA状态
SlaStatus
|
表示案例是否在SLA目标时间内完成。 | ||
|
说明
此属性根据实际完成时间戳与“SLA目标日期”的比较结果,将每个已完成案例归类为“按时”或“逾期”。 这是“SLA达成情况跟踪”仪表板和“SLA达成率”KPI的核心指标,可直观呈现服务承诺的达成情况。分析逾期案例的特征,有助于找出延误的根本原因,并降低未来未达到SLA目标的风险。
重要性
此属性直接衡量服务承诺的达成情况,对运营管理、合规和客户满意度至关重要。
获取途径
将最后一项案例活动的时间戳与SlaTargetDate字段进行比较即可得出此值。如果完成时间晚于目标时间,则状态为“逾期”。
示例
按时逾期有风险
|
|||
|
上次数据更新
LastDataUpdate
|
上次数据刷新或提取的时间戳。 | ||
|
说明
此属性表示最近一次从源系统提取数据的时间。单次数据加载中的所有记录通常具有相同的时间戳。 该时间戳有助于了解所分析数据的新鲜度,让用户知道流程分析反映的是当前情况还是较早时期的数据,以及预计何时更新数据。这对于运营监控仪表板至关重要。
重要性
此属性告知用户数据的时效性,帮助他们判断分析反映的是当前状态还是过去某个时期。
获取途径
此值在数据提取、转换和加载(ETL)过程中生成并写入数据集。
示例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
周期时间
CycleTime
|
从提交申请到最终处理完成所经过的总时间。 | ||
|
说明
此计算指标衡量每份客户申请的端到端时长,即从第一个事件到最后一个事件所经过的时间。通常通过计算指定案例中最后一项活动与第一项活动的时间戳之差得出。 周期时间是衡量流程效率和客户体验的核心关键绩效指标(KPI)。“整体入职周期时间分析”仪表板使用此指标监控平均处理时长、识别处理时间过长的案例,并跟踪流程改进举措的长期效果。
重要性
这是关键KPI,可直接衡量客户视角下入职流程的整体速度和效率。
获取途径
流程挖掘工具会按案例ID计算时间戳的最大值与最小值之差,得出此指标。
示例
5天4小时12天1小时2天8小时
|
|||
|
客户ID
CustomerId
|
正在办理入职的客户唯一标识符。 | ||
|
说明
此属性是唯一ID,用于将申请关联到主数据系统中的客户记录。它代表KYC流程所针对的实体,可以是个人,也可以是组织。 申请ID用于跟踪流程,而客户ID则支持分析同一客户的多份申请,或使用客户细分、历史记录等属性丰富流程数据,从而以客户为中心分析入职流程。
重要性
此属性将流程数据与客户主数据关联,支持基于客户属性和历史记录开展更深入的分析。
获取途径
这通常是KYC案例中的核心属性,用于将案例关联到Pega内部或外部CRM中的客户数据模型。
示例
CUST-98765CUST-98766CUST-98767
|
|||
|
客户所在国家/地区
CustomerCountry
|
客户的居住国或注册地所在国家/地区。 | ||
|
说明
此属性存储正在办理入职的客户所属国家/地区,是评估风险和确定所需尽职调查程度的重要依据。 分析客户所在国家/地区有助于发现重要规律。某些司法管辖区可能风险较高,导致入职流程更长、更复杂。此维度支持按地理区域分析绩效,并帮助确保高效满足当地合规要求。
重要性
此属性支持按地理区域分析流程,而地理区域通常与监管复杂程度和风险等级相关。
获取途径
此属性位于与案例关联的客户数据对象中。
示例
USADEUSGPGBR
|
|||
|
文档状态
DocumentStatus
|
客户提供文档的当前状态。 | ||
|
说明
此属性跟踪KYC流程所需文件的状态,取值包括“等待客户提交”“已收到”“已验证”或“已拒绝”。在单个案例中,此状态可能多次变化。 此属性是“入职流程吞吐量与状态”仪表板和“文件验证速度”分析的关键数据,可细致呈现常见瓶颈环节。通过跟踪文件在各状态下停留的时间,企业可以发现客户提交延迟或内部审核延迟。
重要性
此属性有助于了解文件处理子流程,发现并解决文件验证中的常见延误。
获取途径
此属性可能位于与主案例关联的数据对象或页面列表中,用于跟踪每份所需文件。请查阅Pega KYC文档。
示例
等待上传已收到,等待审核已批准已拒绝,需补充信息
|
|||
|
是否自动化
IsAutomated
|
用于标识活动由系统还是人员执行的标记。 | ||
|
说明
如果活动由筛查引擎或系统规则等自动化代理执行,此布尔属性为true;如果由人工用户执行,则为false。 区分自动化活动和人工活动对于自动化分析至关重要。此属性有助于衡量现有自动化的效果、找出适合未来自动化的人工任务,并了解流程中人员与系统的协作情况。
重要性
此属性区分人工执行的活动和系统执行的活动,是开展自动化计划或分析的基础。
获取途径
此属性可根据事件关联的用户ID推导得出。如果OperatorId对应已知的系统或代理账户,则此标记设为true。
示例
truefalse
|
|||
|
是否返工
IsRework
|
用于标识活动是否属于返工循环的标记。 | ||
|
说明
如果同一案例中的某项活动(例如“文件审核”)发生多次,此布尔属性为true。触发返工的事件通常包括“已请求补充信息”。 识别返工对于发现流程低效和客户体验中的阻碍至关重要。“流程返工与循环”仪表板使用此属性量化返工的频率和影响。减少返工通常是重要目标,因为这有助于加快处理速度、降低运营成本并改善客户体验。
重要性
此属性可突出显示流程低效、重复任务和循环,这些都是流程改进的重点。
获取途径
分析数据时,可检查同一案例ID下是否出现重复的活动名称来推导此标记。例如,“文件审核已完成”再次出现时,即可识别出重复活动。
示例
truefalse
|
|||
|
案例类型
CaseType
|
KYC入职案例的具体类型。 | ||
|
说明
此属性用于对入职申请分类,例如“个人客户”“企业客户”或“高净值个人”。不同案例类型通常对应不同的流程变体、步骤、SLA和风险特征。 按案例类型分析流程,可以更有针对性地比较绩效,了解某些类型的入职流程是否更容易出现延误或拒绝。此类细分对于根据不同客户流程的具体需求制定改进措施至关重要。
重要性
此属性可将流程数据划分为不同类别,从而开展更准确、更有针对性的绩效分析。
获取途径
通常是Pega中案例实例的类名称,或用于定义案例类型的专用属性。
示例
个人客户入职企业客户入职简化尽职调查
|
|||
|
源系统
SourceSystem
|
标识数据的来源系统。 | ||
|
说明
此属性指定记录事件的源应用程序。在此流程中,该值通常为“Pega KYC”。 如果所有数据都来自同一系统,此属性看似多余;但它对于数据治理至关重要,在整合多个系统的数据时更是不可或缺。它能明确数据来源,并帮助排查数据集成问题。
重要性
此属性提供数据来源的关键信息,有助于落实数据治理并分析来自多个源系统的数据。
获取途径
通常在数据提取和转换过程中添加一个固定值,用于标记数据集的来源。
示例
Pega KYCPega CLM
|
|||
|
申请办理的产品
OnboardedProduct
|
客户申请办理的金融产品。 | ||
|
说明
此属性指定客户申请办理的产品或服务,例如“零售银行账户”“企业贷款”或“投资服务”。不同产品可能有不同的监管要求和复杂程度,因此会影响入职流程。 按产品分析流程,有助于发现特定产品线是否周期时间更长或拒绝率更高,为针对产品改进流程提供依据。
重要性
此属性支持按产品线细分流程分析,揭示绩效差异和优化机会。
获取途径
这通常是案例上的一个属性,在申请流程开始时选定。
示例
支票账户财富管理企业信用额度
|
|||
KYC客户入职活动
| 活动 | 说明 | ||
|---|---|---|---|
|
入职流程已完成
|
此活动标志着整个KYC客户入职流程成功结束。当Pega案例达到表示成功完成的最终解决状态,且所有下游操作均已完成时,系统会记录此活动。 | ||
|
重要性
这是流程的主要成功结束事件,对于计算所有成功入职客户的端到端周期时间至关重要。
获取途径
可根据案例解决状态(pyStatusWork)设置为最终成功值时的时间戳推断,例如“已完成并解决”。
采集
在History-Work表中识别最终“已完成并解决”状态的时间戳。
事件类型
inferred
|
|||
|
已启动合规审核
|
此活动表示合规团队正式开始审核。这是流程中的关键环节,通常耗时较长。当案例被分配至合规工作队列或状态相应更新时,系统会记录此活动。 | ||
|
重要性
这是合规审核周期时间指标的开始事件,有助于衡量并发现这一关键且通常由人工执行的审核阶段中的瓶颈。
获取途径
可根据案例状态(pyStatusWork)变为“待合规审核”,或合规工作篮中创建任务分配事件推断。
采集
识别案例被分配至合规工作篮,或状态变更为表示审核开始时的时间戳。
事件类型
inferred
|
|||
|
已完成合规审核
|
此活动表示合规团队已完成审核并提出建议。可通过案例状态变化记录,表明案例已离开合规阶段。 | ||
|
重要性
这是合规审核周期时间指标的结束事件。分析截至此时的耗时,对于提升合规审核效率至关重要。
获取途径
可根据案例状态(pyStatusWork)从“待合规审核”变为“待最终决定”或“已批准并解决”等状态推断。
采集
识别案例历史记录中合规审核阶段或任务分配完成时的时间戳。
事件类型
inferred
|
|||
|
已完成风险评估
|
此活动表示已根据申请和核验数据完成客户风险评估与评分。这是一个关键里程碑,通常在Pega案例中的风险评估阶段或步骤完成时记录。 | ||
|
重要性
这是合规方面的关键里程碑。分析此活动的耗时和结果,有助于了解风险管理效率及其对流程路径的影响。
获取途径
可根据Pega案例模型中特定阶段或流程的完成情况推断,该完成情况会导致审计跟踪中记录的状态变化。
采集
可根据风险评估阶段之后pyStatusWork的变化推断,例如变为“待合规审核”。
事件类型
inferred
|
|||
|
已提交申请
|
此活动表示在Pega系统中创建了新的客户入职案例。当客户申请的新案例实例通过客户门户、内部用户或自动数据馈送正式启动时,系统会记录此活动。 | ||
|
重要性
这是整个入职流程的主要开始事件,对于衡量端到端周期时间以及分析申请提交量和规律至关重要。
获取途径
当创建新的工作对象(案例)时,Pega审计跟踪中会记录此明确事件。请在pc_history_work表中查找该案例ID的初始记录。
采集
从pc_work表中的案例创建时间戳或审计跟踪中的首条记录获取。
事件类型
explicit
|
|||
|
已收到文档
|
表示客户已将所有所需文档上传或提交至系统。通常在新附件关联到Pega案例时,系统会记录此明确事件。 | ||
|
重要性
这是一个关键里程碑,标志着文档审核和核验SLA计时开始。此时间点之前的延误取决于客户,之后的延误则属于内部因素。
获取途径
当新文档关联到案例时,Pega附件表(pc_link_attachment或pc_data_workattach)会明确记录此事件。
采集
事件时间为关联到案例的相关附件对象的创建时间戳。
事件类型
explicit
|
|||
|
申请已批准
|
表示最终决定已批准客户的入职申请。这是一个关键业务里程碑,可根据案例状态更新为最终成功解决状态推断。 | ||
|
重要性
这是区分成功案例和未成功案例的关键里程碑,也是最终账户激活步骤的前置环节,常用于衡量决策耗时。
获取途径
可根据案例解决状态(pyStatusWork)设置为最终成功值时的时间戳推断,例如“已完成并解决”或“已批准并解决”。
采集
在案例审计跟踪中识别反映成功解决的pyStatusWork最终更新记录。
事件类型
inferred
|
|||
|
申请已拒绝
|
表示最终决定拒绝客户的申请,并终止入职流程。可根据案例进入最终未成功解决状态推断此事件。 | ||
|
重要性
这是主要的失败结束事件。分析申请拒绝率并了解失败原因至关重要,可通过“拒绝原因”等属性进行分析。
获取途径
可根据案例解决状态(pyStatusWork)设置为最终失败值时的时间戳推断,例如“已拒绝并解决”。
采集
在案例审计轨迹中,找出反映拒绝状态的pyStatusWork最终更新记录。
事件类型
inferred
|
|||
|
已启动背景调查
|
表示已开始对客户进行外部或内部背景调查,可能涉及第三方服务集成。通常可根据案例状态变化推断此事件,表明案例正在等待调查结果。 | ||
|
重要性
此活动有助于单独分析等待外部依赖项所花费的时间,评估第三方服务的表现及其对整体入职时间的影响。
获取途径
可根据Pega的History-Work表中记录的案例状态(pyStatusWork)变为“待背景调查”或类似状态推断。
采集
识别pyStatusWork更新为表示背景调查已启动的时间戳。
事件类型
inferred
|
|||
|
已完成初步筛查
|
表示已完成对申请数据的初步审核,通常由自动化执行,用于检查信息完整性和基本资格。通常可根据案例状态变化推断此事件,例如状态从“新建”变为“待补充文档”。 | ||
|
重要性
分析这一初始阶段的耗时,有助于发现数据验证或自动规则执行中的早期瓶颈,避免拖延整个流程。
获取途径
根据Pega审计跟踪(History-Work表)中记录的案例状态属性(pyStatusWork)变化推断。
采集
识别pyStatusWork从“新建”或“已提交”状态变为“筛查完成”或类似状态的时间戳。
事件类型
inferred
|
|||
|
已完成文档审核
|
此活动表示合规专员或自动化流程已完成对客户提交文档的审核。可根据案例或文档状态变化推断此事件,表明审核步骤已完成。 | ||
|
重要性
此活动标志着文档核验时长指标的结束。分析完成此步骤所需的时间,有助于发现人工或自动审核流程中的低效环节。
获取途径
可根据审计跟踪中案例状态(pyStatusWork)从“待审核”变为“审核完成”或“待检查”推断。
采集
识别案例状态(pyStatusWork)发生变化的时间戳,以确定文档核验子流程已完成。
事件类型
inferred
|
|||
|
已请求提供文档
|
当系统或工作人员确定客户需要提供特定文档才能继续办理时,会发生此活动。可通过识别通信记录的创建,或案例状态变为“待客户提供文档”等状态来记录。 | ||
|
重要性
跟踪此活动有助于衡量客户的响应时间,并发现流程是否经常因等待文档而停滞。它也是文档核验时长指标的前置活动。
获取途径
可以通过明确的通信事件(pc_link_attachment)记录,也可以根据审计跟踪中记录的案例状态(pyStatusWork)变化推断。
采集
可根据pyStatusWork变为“待提供文档”或类似状态推断,也可以关联明确的“发送通信”事件。
事件类型
inferred
|
|||
|
已请求补充信息
|
当审核人员(通常是合规人员)需要客户提供更多信息或作出说明时,会发生此活动。通常会明确记录此事件,例如用户从案例中发送特定通信时。 | ||
|
重要性
此活动是流程返工和循环的主要指标。跟踪其发生频率,对于衡量一次处理成功率和发现要求不明确的问题至关重要。
获取途径
可以是审计跟踪中记录的明确“发送通信”事件,也可以根据状态变为“待客户提供信息”推断。
采集
根据特定通信对象的创建记录,或案例工作人员发起的流程操作记录获取。
事件类型
explicit
|
|||
|
账户已激活
|
此活动表示客户账户已在核心银行系统或相关下游系统中成功创建并激活。通常可根据成功批准后Pega案例中的最终状态更新推断。 | ||
|
重要性
这标志着客户和企业实现价值的时刻。从“申请已批准”到此事件之间的时间,可用于衡量系统交接效率。
获取途径
可根据特定案例状态(pyStatusWork),例如“账户已激活并解决”,或审计跟踪中记录的集成设置标志推断。
采集
识别表示下游账户已激活的案例属性更新时间戳。
事件类型
inferred
|
|||
数据提取指南
立即优化KYC入职流程,减少延误
让KYC流程更顺畅,将入职时间缩短至24小时,并加强合规管理。
无需信用卡,几分钟即可完成设置