贷款发放数据模板
贷款发放数据模板
这是适用于贷款发放的通用流程挖掘数据模板。使用针对具体系统的模板,可获取更有针对性的指导。
选择具体系统- 适用于贷款发放事件日志的通用结构。
- 用于深入流程分析的建议属性和活动。
- 特定系统的数据提取说明链接。
贷款发放属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件开始时间 EventStartTime | 标记特定活动或事件正式开始时间的时间戳。 | ||
| 说明 事件开始时间是标记活动起始时刻的精确时间戳。它是事件日志的基本组成部分,对于按时间顺序排列事件、还原每个案例的流程路径至关重要。 在流程分析中,开始时间用于计算案例总时长、活动之间的间隔,以及在有结束时间时计算每个步骤的实际处理时间。它是了解流程时长、发现延误并根据服务级别协议评估绩效的主要时间属性。 重要性 该时间戳对于排列事件、计算流程周期时间以及发现活动之间的延误至关重要。 获取途径 任意系统的事件日志或交易历史表中都必须包含此字段。 示例 2023-03-15T09:00:00Z2023-04-01T14:30:15Z2023-05-20T11:22:05Z | |||
| 活动名称 ActivityName | 贷款发放流程中某个时间点发生的具体业务事件或任务名称。 | ||
| 说明 活动名称用于描述贷款发放工作流中的具体步骤或里程碑,例如“申请已提交”“信用审查已完成”或“贷款方案已生成”。每项活动都代表流程中的一个独立节点,并会占用时间和资源。 分析这些活动的顺序和频率是流程挖掘的核心。它有助于揭示实际流程、识别常见路径、发现瓶颈并衡量不同阶段的耗时。清晰且一致的活动命名对于绘制易于理解且准确的流程图至关重要。 重要性 定义流程的各个步骤,便于展示和分析流程路径、识别瓶颈并衡量各阶段耗时。 获取途径 可在记录业务流程步骤的事件日志或交易表中找到。 示例 申请已提交信用审查已完成承保决策已作出资金已发放 | |||
| 贷款申请ID LoanApplicationId | 每笔贷款申请的唯一标识符。此ID用于跟踪申请的整个生命周期。 | ||
| 说明 贷款申请ID是每笔贷款申请创建时分配的唯一键。它是主要案例标识符,可关联从初次提交到最终放款或结案的所有相关活动、文件和决策。保持标识符一致,对于还原每笔申请的端到端处理过程至关重要。 在流程挖掘中,此属性用于将所有相关事件归入同一个案例,以便按申请分析流程、周期时间和差异。如果没有一致且唯一的案例标识符,就无法准确绘制流程图或分析流程绩效。 重要性 这是流程挖掘的基础标识符,可将所有相关事件归入同一个案例,从而分析完整的贷款发放过程。 获取途径 通常可在贷款申请的表头或主交易表中找到。 示例 APP-2023-00123LN4567890178912345-A | |||
| 最近数据更新时间 LastDataUpdateTime | 标记此事件的数据最近一次从源系统刷新或提取时间的时间戳。 | ||
| 说明 此属性记录最近一次从源系统提取或刷新的数据时间戳,是数据治理和质量保障所需的元数据字段。 了解数据最近的更新时间,有助于分析人员判断数据集的新鲜度,确保分析基于当前信息。对于监控进行中的流程,这一点尤为重要,因为它能反映流程视图的时效性。该时间戳也有助于调试数据管道,并发现数据摄取计划中的潜在问题。 重要性 它能确认数据是否为最新,确保分析基于及时的信息,并有助于管理数据质量。 获取途径 通常在数据提取、转换和加载(ETL)过程中生成并保存。 示例 2023-06-01T02:00:00Z2023-06-01T04:00:00Z2023-06-01T06:00:00Z | |||
| 源系统名称 SourceSystemName | 用于标识提取事件数据的源系统或应用程序。 | ||
| 说明 源系统名称用于标明生成事件数据的应用程序或平台,例如贷款发放系统(LOS)、CRM或文档管理系统。在现代企业中,贷款发放等业务流程通常涉及多个相互关联的系统。 识别每个事件的源系统,对于数据验证、故障排查以及了解流程所涉及的技术环境至关重要。分析人员可以据此追溯数据来源,并评估不同系统对整体流程路径和潜在延误的影响。 重要性 它有助于追溯数据来源,对于验证数据以及了解跨多个IT系统的流程路径至关重要。 获取途径 通常是数据提取中的标准字段,也可以在数据工程过程中添加。 示例 BlendFinastra FusionnCinoICE Encompass | |||
| 事件结束时间 EventEndTime | 标记活动完成时间的时间戳,可用于计算事件的实际处理时间。 | ||
| 说明 事件结束时间标记活动结束的确切时刻。有些事件只是里程碑,只有开始时间;而许多活动都有明确的持续时长。结束时间可用于直接计算实际处理时间。 分析实际处理时间对于了解资源利用情况、发现特定任务中的低效环节,以及区分实际处理案例的时间与等待时间至关重要。例如,这有助于确定核保实际耗时,并将其与申请在核保人员队列中的等待时间区分开来。 重要性 它可以计算活动的实际处理时间,帮助区分创造价值的工作与等待时间。 获取途径 对于记录活动时长的系统,事件日志或交易表中通常会同时记录开始时间和结束时间。 示例 2023-03-15T11:30:00Z2023-04-02T10:00:00Z2023-05-21T15:45:20Z | |||
| 决策结果 DecisionOutcome | 贷款申请的最终结果,例如已批准、拒绝或已撤回。 | ||
| 说明 决策结果表示贷款申请处理完成后的最终状态。常见结果包括“已批准”“已拒绝”“申请人已撤回”或“已提出反要约”。 此属性对于结果分析至关重要,可帮助了解哪些流程路径会带来成功或未成功的结果。将流程差异与决策结果关联起来,组织可以识别有助于提高批准率的最佳实践,或导致申请被拒的行为。这类分析对于提升流程效率和业务成果至关重要。 重要性 它对于结果分析至关重要,有助于识别哪些流程行为和路径与贷款申请成功或未成功相关。 获取途径 通常记录在贷款申请状态字段中,或作为交易历史中的特定决策事件记录。 示例 已批准已拒绝申请人已撤回已提出反要约 | |||
| 拒绝原因 RejectionReason | 贷款申请被拒时给出的具体原因。 | ||
| 说明 贷款申请的最终结果为“已拒绝”时,拒绝原因会以代码或文字说明解释原因。常见原因包括“信用记录不足”“债务收入比过高”或“申请材料不完整”。 此属性对于分析申请失败的根本原因非常有价值。通过分析最常见的拒绝原因,组织可以发现申请人群、核保标准或申请流程本身存在的系统性问题。这些洞察可用于制定营销策略、开发产品,并改进流程以降低拒绝率。 重要性 它为根本原因分析提供重要洞察,有助于了解申请被拒的原因,并据此有针对性地改进流程。 获取途径 作为最终决策事件的一部分记录,通常与“已拒绝”这一决策结果关联。 示例 债务收入比过高信用记录不佳材料不完整房产评估价过低 | |||
| 指定用户 AssignedUser | 负责执行某项活动的用户姓名或ID,例如贷款专员或核保人员。 | ||
| 说明 指定用户用于标识执行或负责某项活动的员工或系统用户,例如贷款专员、处理人员、核保人员或结案专员。 此属性是分析团队和个人绩效、工作量分配及资源配置的基础。按用户跟踪活动,组织可以识别表现出色的员工、发现培训需求,并重新平衡工作量以提升效率。还可以分析不同用户或团队对流程结果和周期时间的影响。 重要性 它对于分析工作量分配和团队绩效,以及发现流程中的资源相关瓶颈至关重要。 获取途径 通常可在记录系统内用户操作的交易日志或事件日志中找到。 示例 John Smithj.smithunderwriting.user.123Alice Williams | |||
| 是否自动化 IsAutomated | 用于标记活动由系统自动执行还是由用户手动完成的标志。 | ||
| 说明 此布尔属性用于区分系统自动执行的活动(例如自动信用审查或初步材料验证)与人工用户执行的活动。 这一区分对于了解流程的自动化程度及其对效率的影响至关重要。分析自动化与人工步骤,有助于发现进一步自动化的机会、量化现有自动化节省的时间,并了解人力资源的工作量。它清晰呈现了贷款发放过程中人与系统的交互情况。 重要性 它有助于区分系统执行和人工执行的活动,是开展自动化分析和了解资源工作量的关键。 获取途径 它可以是事件日志中的字段,也可以根据活动名称或事件关联的用户推导得出(例如用户为“system”)。 示例 truefalse | |||
| 申请渠道 ApplicationChannel | 贷款申请最初提交的渠道,例如线上、网点或经纪人。 | ||
| 说明 申请渠道用于标识申请人最初联系机构或提交申请的方式,例如“在线门户”“移动应用”“网点”或“第三方经纪人”。 不同渠道的客户体验和内部处理工作流可能存在显著差异。按渠道分析流程,有助于组织了解各提交路径的效率和效果。分析结果可以揭示哪些渠道处理更快、客户满意度更高或数据质量更好,为技术和运营方面的战略投入提供依据。 重要性 它可以帮助分析不同提交渠道(如线上、网点或移动端)的流程绩效和客户体验。 获取途径 在申请流程开始时采集,并存储在贷款申请主表中。 示例 在线门户网点第三方经纪人移动应用 | |||
| 贷款产品类型 LoanProductType | 申请的具体贷款产品类型,例如抵押贷款、汽车贷款或个人贷款。 | ||
| 说明 贷款产品类型根据申请人所申请的金融产品对贷款申请进行分类,例如“常规抵押贷款”“FHA贷款”“汽车贷款”或“个人信用额度”。 不同贷款产品的流程、合规要求和风险特征往往各不相同。按产品类型分析流程,有助于发现差异并优化各产品线的工作流。通过这种细分,组织可以有针对性地改进流程,并了解贷款组合中周期时间、批准率和返工情况的差异。 重要性 它可以按贷款类型细分流程,以比较绩效并发现不同贷款工作流之间的差异。 获取途径 这是贷款申请表中的标准字段,存储在申请主数据表中。 示例 常规30年固定利率贷款FHA抵押贷款汽车贷款个人贷款 | |||
| 贷款金额 LoanAmount | 申请人申请的贷款总金额。 | ||
| 说明 贷款金额是申请人申请的本金总额。这项重要的财务属性通常会影响贷款申请的复杂程度和风险。 贷款金额较大时,可能需要更严格的核保流程、更多层级的审批,或采用不同的费用结构。按贷款金额分析流程,可以了解金额对处理时间、批准率和审核严格程度的影响。它也是财务分析的重要输入,例如计算贷款业务管线的总金额或每笔贷款的成本。 重要性 此属性是影响流程复杂度和风险的关键因素,可用于分析贷款金额对周期时间和批准率的影响。 获取途径 这是贷款申请数据中的核心字段,通常存储在贷款信息主表中。 示例 250000.0050000.00750000.00 | |||
| 信用评分 CreditScore | 申请人接受信用审查时的信用评分。 | ||
| 说明 信用评分是通过信用机构在申请过程中获取的数值,用于表示申请人的信用状况。它是风险评估和核保决策的主要依据之一。 信用评分较高通常意味着风险较低,可能获得更优惠的贷款条件或更快的审批。在流程挖掘中,分析信用评分对流程的影响,可以发现不同风险等级的申请人所经历的流程差异。例如,评分较低的申请可能需要更多人工审核或补充材料,从而延长周期时间。 重要性 这是风险评估的关键因素,会显著影响流程路径、决策结果和整体周期时间。 获取途径 数据来自外部信用机构,并存储在申请人的档案数据中。 示例 720650810590 | |||
| 地理位置 GeographicLocation | 与贷款申请相关的地理区域,例如州或分支机构所在地。 | ||
| 说明 地理位置用于指定与贷款相关的地点,例如房产所在州、处理申请的分支机构或申请人所在地区。 此属性有助于分析流程在不同地区的差异。例如,不同州可能有各自的合规要求,导致流程增加步骤;某些分支机构的效率也可能高于其他机构。按地理位置细分,可以发现绩效差异、资源需求和影响贷款发放流程的市场趋势。 重要性 可用于开展地理分析,发现不同地区在流程绩效、合规要求和业务成果方面的差异。 获取途径 可从申请数据中获取,例如房产地址或提交申请的分支机构。 示例 加利福尼亚州纽约州101号分支机构-市中心美国中西部地区 | |||
| 指定部门 AssignedDepartment | 在特定阶段负责处理贷款申请的部门或团队。 | ||
| 说明 此属性用于标识负责某项活动或在特定时间点持有案例的部门或职能团队,例如“贷款处理”“核保”或“结案”。 跟踪部门之间的交接,对于了解组织工作流和发现跨职能延误至关重要。按部门分析流程,有助于衡量不同团队的绩效、了解其工作量,并优化团队间的协作和交接流程。 重要性 它可以按职能团队分析流程交接和绩效,突出跨部门瓶颈和低效环节。 获取途径 可在工作流管理系统中找到,也可根据分配给任务的用户或角色推导得出。 示例 贷款发起团队A核保部门结案服务部合规审查 | |||
| 核保SLA目标 UnderwritingSlaTarget | 完成核保阶段的目标时长,以小时或天为单位。 | ||
| 说明 核保SLA目标规定了贷款申请核保阶段的预期完成时限。业务会将此目标设为关键绩效指标(KPI)基准,以确保及时处理。 将根据时间戳计算出的核保阶段实际时长与此目标进行比较,组织便可衡量SLA达成情况。这有助于发现核保环节的瓶颈、评估团队绩效,并有效管理客户预期。 重要性 它是衡量服务级别协议达成情况的基准,有助于发现延误并管理运营目标。 获取途径 通常在业务规则配置或服务级别协议文档中定义,也可能与案例数据一同存储。 示例 48小时3天7200分钟 | |||
| 申请人类型 ApplicantType | 申请人的分类,例如“新客户”或“现有客户”。 | ||
| 说明 申请人类型根据申请人与金融机构的关系进行分类,例如“新客户”或“现有客户”。 此分类很重要,因为流程可能会因该属性而有所不同。现有客户已有相关数据,流程可能更精简;新客户则可能需要更全面的身份和信息验证。按申请人类型分析流程,可以突出这些差异,并帮助组织针对不同客户群体调整和优化客户旅程。 重要性 它可以比较不同客户群体的流程,这些群体的工作流和服务级别预期可能各不相同。 获取途径 根据客户关系管理(CRM)数据推导,或在申请表中指定。 示例 新客户现有客户回头客户 | |||
贷款发放活动
| 活动 | 说明 | ||
|---|---|---|---|
| 已收到文件 | 标志着申请人提交的所有所需证明文件均已收到并上传至系统。此事件通常是申请进入承保阶段的前置条件。 | ||
| 重要性 这是一个重要里程碑,也是常见瓶颈。分析此事件发生前所耗费的时间,有助于找出因文件不完整而导致的申请处理延误。 获取途径 通常可根据贷款申请状态更新推断,例如“文件齐全”或“可进行承保”。 采集 记录申请状态变为所有所需文件均已收到时的时间戳。 事件类型 inferred | |||
| 承保决策已作出 | 标志着承保人员完成审核,并作出“已批准”“有条件批准”或“已拒绝”等决定。此事件结束贷款的核心分析阶段。 | ||
| 重要性 这是一个重要里程碑,决定申请后续的处理路径。作出此决定所需的时间是关键绩效指标。 获取途径 可根据系统中最终承保决定或贷款状态字段填写并保存时的时间戳推断。 采集 使用承保人员最后一次更新贷款申请决策状态字段时的时间戳。 事件类型 inferred | |||
| 承保已开始 | 此活动标志着正式承保流程开始,发生于承保人员将贷款申请分配给自己,或案例状态变为“承保中”时。 | ||
| 重要性 此事件标志着最关键的评估阶段开始。衡量承保所需时间是识别瓶颈、缩短决策时间的关键。 获取途径 几乎总是根据贷款申请记录中的状态变更,或工作流系统中的分配日志推断。 采集 记录贷款状态首次变为“承保中”“审核中”或类似状态时的时间戳。 事件类型 inferred | |||
| 申请已拒绝 | 此活动表示贷款申请经承保审核后被正式拒绝,是流程的一种未成功结束方式。 | ||
| 重要性 这是一个关键的结束活动。分析被拒申请的处理路径和特征,有助于发现资格标准方面的问题或流程低效之处。 获取途径 可根据贷款申请记录中的最终状态更新推断,例如状态变为“已拒绝”“已驳回”或“未通过”。 采集 记录申请最终状态设为“已拒绝”时的时间戳。 事件类型 inferred | |||
| 申请已提交 | 此活动标志着贷款发放流程正式开始,即申请人或贷款专员正式提交申请以供审核。此事件会创建案例,通常也是新贷款申请的首个记录时间戳。 | ||
| 重要性 这是流程的主要开始活动。分析从此事件到其他事件的时间,对于衡量整体周期时间和流程效率至关重要。 获取途径 通常可在贷款申请主表或记录系统中找到明确的创建事件。请查找记录创建时间戳。 采集 记录新贷款申请创建时的时间戳,且其状态为“已提交”或“新建”。 事件类型 explicit | |||
| 申请已撤回 | 表示申请人在作出最终决定或发放资金之前选择撤回申请。这是流程的另一种未成功结果。 | ||
| 重要性 这是一个关键的结束活动。较高的撤回率可能表明客户体验不佳、方案缺乏竞争力或流程耗时过长。 获取途径 通常记录为贷款申请的最终状态更新,且往往由用户手动发起。 采集 记录申请最终状态设为“已撤回”时的时间戳。 事件类型 inferred | |||
| 贷款协议已签署 | 此活动标志着申请人已签署所有结案文件,贷款协议由此具有法律约束力。这是资金发放前申请人必须完成的最后一步。 | ||
| 重要性 这是申请人最后的确认,标志着协议阶段在法律上完成,也是发放贷款资金的直接前提。 获取途径 可通过电子签名系统日志、文档管理系统更新,或结案团队手动更改状态来记录。 采集 使用电子签名平台记录的时间戳,或已签署文件上传并标记为完成时的时间戳。 事件类型 explicit | |||
| 资金已发放 | 表示贷款发放流程已成功完成,贷款金额已转给申请人或相关方。此事件标志着贷款申请成功办理完毕。 | ||
| 重要性 这是理想路径的主要结束活动。总周期时间从申请提交到此事件进行衡量,是整体绩效的关键指标。 获取途径 这是一笔核心金融交易,核心银行系统或贷款服务系统会明确记录其精确时间戳。 采集 从财务分类账或支付系统中记录资金交易的时间戳。 事件类型 explicit | |||
| 信用审查已完成 | 此活动表示已完成申请人信用报告的调取请求,且报告结果可供审核。信用评分和信用记录会附在贷款档案中。 | ||
| 重要性 完成信用审查是承保的重要前提。延迟获取相关信息可能会拖慢整个流程。 获取途径 通常记录为集成的第三方征信机构返回数据时发生的事件,也可能是手动更新的状态。 采集 使用信用报告成功收到并附加到贷款申请记录时所记录的时间戳。 事件类型 explicit | |||
| 已发送最终披露文件 | 表示已向申请人发送最终一批法律要求的结案文件,供其签署前审核。这是有时限要求的合规步骤,必须在最终结案前完成。 | ||
| 重要性 这是重要的监管里程碑。监控此活动可确保遵守结案前必须留出审核期的规定,避免造成高昂的延误和法律问题。 获取途径 可在文档管理系统日志、通信记录中找到,也可能记录为“可结案”等特定贷款状态更新。 采集 使用系统记录最终结案披露文件包已发送给申请人时的时间戳。 事件类型 explicit | |||
| 已发送初始披露文件 | 表示已向申请人发送首批法律要求披露的文件,例如贷款估算表。这是关键的合规步骤,必须在流程早期完成。 | ||
| 重要性 跟踪此活动对于监控监管合规情况、确保在规定时限内发送披露文件至关重要。此处延误可能带来合规风险和处罚。 获取途径 通常可在文档生成日志或通信模块中找到,也可能记录为贷款申请状态变更。 采集 使用文档管理系统中生成并发送初始披露文件包时的时间戳。 事件类型 explicit | |||
| 已请求文件 | 表示系统或贷款专员已正式向申请人索取所需证明文件,例如工资单或纳税申报表。此活动标志着文件收集阶段开始。 | ||
| 重要性 通过衡量申请人回复所需的时间,此活动有助于分析文件收集流程的效率。 获取途径 通常记录在文档管理模块、通信日志中,或作为“待补充文件”等状态变更记录。 采集 确定申请状态变为“等待文件”或记录文件请求时的时间戳。 事件类型 inferred | |||
| 房产估价已完成 | 表示已收到第三方估价师提供的房产估价报告,并将其添加到贷款档案中。此活动适用于抵押贷款等有担保贷款。 | ||
| 重要性 对于以房产作担保的贷款,估价是最终承保决策的重要依据。此处延误会直接影响贷款周期时间。 获取途径 可从文档管理系统中获取房产估价文件上传时的记录,也可从贷款记录中的状态字段更新获取。 采集 使用房产估价文件状态更新为“已收到”或相关任务标记为完成时的时间戳。 事件类型 inferred | |||
| 承保要求返工 | 记录流程中的返工情况,即承保人员将申请退回贷款专员或处理人员,要求补充信息或更正内容。通常表现为状态从“承保中”变回之前的状态。 | ||
| 重要性 此活动直接反映流程低效和返工循环。识别返工的频率及原因对于改进流程至关重要。 获取途径 可根据状态变更日志推断,例如申请从承保等后续阶段退回处理等较早阶段。 采集 找出贷款状态倒退的事件,例如从“承保中”变为“等待文件”。 事件类型 inferred | |||
| 贷款方案已接受 | 表示申请人正式接受贷款方案及其条款。这是一个重要里程碑,表明申请人有意继续办理贷款。 | ||
| 重要性 此事件确认申请人将继续办理贷款,并为启动最终结案手续提供明确信号。 获取途径 通常由贷款专员手动更新状态记录,也可能通过电子签名系统集成自动记录。 采集 记录贷款状态更新为“已接受方案”或类似状态时的时间戳。 事件类型 inferred | |||
| 贷款方案已生成 | 此活动发生在承保决定为“已批准”之后,表示正式贷款方案文件已创建。该文件明确了获批贷款的条款,供发送给申请人。 | ||
| 重要性 生成贷款方案是完成贷款流程的关键步骤。跟踪生成时间有助于确保申请人及时收到方案。 获取途径 通常记录在文档生成系统日志中,或作为贷款申请历史记录中的特定事件。 采集 记录贷款方案文件创建或其状态设为“已生成”时的时间戳。 事件类型 explicit | |||
数据提取指南
立即优化贷款发放流程
发现隐藏的低效环节,让整个贷款流程更加顺畅。
无需信用卡,几分钟即可完成设置。