3、数据准备:违约样本定义、数据来源、数据清洗、生存时间与截尾数据处理

违约概率模型与迁徙矩阵估计的成败,往往在数据准备阶段就已注定。模型算法再精巧,若样本定义含糊、数据源混杂、清洗规则失当、生存时间与截尾处理错误,最终输出的违约概率(PD)与迁徙率(Migration Rate)都会失真,甚至误导信贷审批与资本计量决策。本章围绕数据准备的四大核心任务展开:违约样本的严谨定义、数据来源的甄别与整合、数据清洗的标准化流程,以及生存分析框架下时间与截尾变量的处理逻辑。以下内容将结合巴塞尔协议(Basel II/III)监管定义、实际建模项目经验与常见陷阱,给出可落地的操作指引。

数据准备核心链路:从原始数据到建模样本 数据来源 内部信贷系统 征信/外部数据 违约样本定义 逾期90天/监管定义 展期/重组/破产标记 数据清洗 去重/缺失/异常值 逻辑校验/口径统一 生存时间 观察期/表现期 截尾标记 时间轴设计 观察点(特征截取) → 表现期(12/24个月) → 结果判定(违约/未违约/截尾) t₀观察点 t₀+12M t₀+24M 右截尾(最常见) 表现期结束仍未违约 左截尾 进入观察时已处于风险状态 区间截尾 仅知违约发生在某区间内 输出:清洗后样本 + 生存时间 + 截尾指示变量

上图展示了数据准备的整体链路:从多源数据接入,到违约口径锁定,再到清洗与生存时间构造,最终形成可供模型直接使用的宽表(Wide Table)或生存分析格式数据。下面逐一拆解每个环节的关键技术要点。

3.1 违约样本定义:监管口径与业务口径的博弈

核心原理:违约(Default)是二分类模型中“坏客户”的标签来源,也是迁徙矩阵中“吸收态”的判定标准。巴塞尔委员会将违约定义为“债务人实质性无力偿还债务”,具体可操作标准包括:逾期超过90天、债务人被宣告破产/进入清算程序、发生债务重组且预计造成损失等。国内商业银行在监管报送中通常遵循《商业银行资本管理办法》的细化要求,但业务部门(如零售信贷、信用卡)可能采用更敏感的30天或60天逾期作为预警口径。

判断方法:在建模实践中,建议采用“主标尺+辅助标记”的双层定义法:

  • 主标尺(监管硬性):逾期≥90天或进入法定破产程序,作为违约的充分条件。
  • 辅助标记(业务增强):包括展期超过30天、借新还旧、司法追偿、核销等,需结合业务逻辑判断是否纳入违约。
  • 排除项:技术性逾期(如银行系统故障导致的延迟扣款)应通过人工复核剔除。
口径类型定义标准适用场景优缺点
监管口径逾期90天+破产+重组损失资本计量、监管报送标准统一,但反应滞后
业务预警口径逾期30/60天贷中监控、催收策略敏感度高,但误报率大
内部评级口径监管口径+自定义事件PD模型开发灵活,需充分文档化
风险提示:若建模样本中违约定义与监管报送口径不一致,会导致模型PD校准失败。务必在数据字典中记录每个违约标记的生成规则、生效日期和修订版本。

3.2 数据来源:内部系统与外部数据的整合策略

核心原理:违约概率模型需要覆盖借款人的还款行为、财务状态、宏观经济环境等多维信息。数据来源通常分为三类:内部核心系统(信贷管理系统、核心银行系统、催收系统)、外部征信数据(人行征信、百行征信、税务、工商)、以及宏观数据(GDP、失业率、行业景气指数)。

操作流程:

  1. 数据盘点:列出所有可用数据表,标注粒度(借据级/客户级/产品级)、时间跨度、更新频率。
  2. 主键设计:确定唯一标识(如借据号+客户号),保证同一借款人在不同系统中的记录可关联。
  3. 时间对齐:外部征信数据通常有T+1或T+3延迟,需与内部数据在“观察时点”上对齐,避免未来信息泄露。
  4. 数据质量探查:统计各字段缺失率、唯一值数量、逻辑矛盾(如放款日期晚于逾期日期)。
实战经验:某股份制银行在开发小微企业PD模型时,发现内部信贷系统与征信系统的客户名称匹配率仅78%。通过引入统一社会信用代码作为关联键,并采用模糊匹配算法(编辑距离≤2),将匹配率提升至96%,但额外增加了约3%的误匹配风险。最终通过人工抽检500条样本,确认误匹配率低于0.5%后才投入使用。

3.3 数据清洗:从原始数据到建模宽表

核心原理:数据清洗的目标是消除噪声、填补缺失、统一量纲,使数据满足模型输入要求。对于信贷数据,清洗重点包括:重复记录处理、异常值识别(如年龄>120岁、贷款金额为负数)、缺失值插补(均值/中位数/回归插补/多重插补)、以及口径统一(如利率的年化/月化转换)。

清洗流程清单:

  • 去重:按借据号+还款计划编号去重,保留最新状态记录。
  • 异常值:采用IQR(四分位距)法或业务规则(如收入>0且<1亿)识别并处理。
  • 缺失值:区分随机缺失与非随机缺失。对于“收入”这类强预测变量,若缺失率>30%,建议单独设置“缺失标志”作为特征。
  • 逻辑校验:例如“贷款余额>0但状态为已结清”属于矛盾数据,需回溯原始系统确认。
-- 示例:清洗规则SQL片段
UPDATE loan_table
SET is_default = 1
WHERE overdue_days >= 90
  AND loan_status IN ('正常','关注')
  AND data_source = 'core_system';
-- 剔除技术性逾期
DELETE FROM loan_table
WHERE overdue_reason = 'system_error'
  AND overdue_days < 5;
经验提醒:清洗规则必须形成可审计的文档,记录每条规则的业务依据、影响行数、执行时间。在模型验证阶段,监管机构常要求提供清洗前后的数据对比报告。

3.4 生存时间与截尾数据处理:构建时间维度

核心原理:违约概率模型本质上是一个时间事件模型(Time-to-Event),需要定义每个样本的“风险起始时间”和“风险结束时间”。生存时间(Survival Time)指从观察起点到违约事件发生或截尾的时间长度。截尾(Censoring)是指未观察到违约事件发生,但样本退出观察的情况,包括右截尾(最常见,表现期结束时仍未违约)、左截尾(进入观察时已处于风险状态)和区间截尾(仅知违约发生在某时间段内)。

判断方法:

  1. 确定观察点(t₀):通常选择贷款发放日、额度生效日或固定日历日期(如每年6月30日)。
  2. 设定表现期(Performance Window):监管要求至少12个月,建议24个月以捕捉更多违约事件。
  3. 生成生存时间变量:若在表现期内违约,生存时间=违约日期-t₀;若未违约,生存时间=表现期长度(右截尾)。
  4. 构造截尾指示变量:1表示违约事件发生,0表示截尾。
样本类型生存时间计算截尾标记模型处理方式
表现期内违约违约日 - t₀0(未截尾)直接纳入事件
表现期结束未违约表现期长度1(右截尾)Cox/离散时间模型
提前还款/核销退出日 - t₀1(右截尾)视为竞争风险
常见误区:将提前还款(Prepayment)直接视为“未违约”处理,会低估生存概率。建议采用竞争风险模型(如Fine-Gray模型)或将其单独建模,避免参数估计偏误。

3.5 案例拆解:某消费金融公司12个月PD模型数据准备

背景与约束:某持牌消费金融公司需开发12个月期限的PD模型,用于贷前审批。数据源包括内部核心系统(2018-2023年)、人行征信报告(月度更新)、以及第三方反欺诈数据。初始样本为320万笔贷款,违约率约2.8%。

初始现象与目标:初步建模时发现模型区分度(AUC)仅0.68,低于预期0.75。经排查,问题出在数据准备环节:违约定义不统一(部分业务线采用60天逾期,部分采用90天),且生存时间未考虑提前还款的截尾影响。

关键输入数据与参数:

  • 贷款发放日期:2018-01-01至2022-06-30
  • 表现期:12个月(固定窗口)
  • 违约定义:逾期≥90天或核销
  • 截尾规则:表现期内提前还款或结清记为右截尾

分析判断过程:通过数据探查发现,约15%的样本在表现期内提前还款,若将其简单视为“未违约”,则生存时间被高估,违约概率被低估。同时,不同业务线的逾期口径差异导致约2.3万笔样本的违约标记冲突。

实际操作步骤:

  1. 统一违约口径:全量样本按“逾期≥90天或核销”重新标记,冲突样本以核心系统状态为准。
  2. 重构生存时间:对提前还款样本,生存时间=提前还款日-t₀,截尾标记=1。
  3. 增加时间切片特征:将观察期内的还款行为(如最近3个月逾期次数)作为动态特征。
  4. 重新训练模型:采用离散时间生存模型(Logistic回归+时间变量)。

结果对比:调整后模型AUC提升至0.74,校准度(Hosmer-Lemeshow检验p值)从0.02改善至0.15,表明模型拟合优度显著提升。更重要的是,审批通过率在保持相同坏账率的前提下提升了6个百分点。

风险与代价:重新定义违约口径导致部分历史样本的标签发生变化,需与财务部门确认拨备计提的联动影响。此外,生存时间重构增加了数据处理的复杂度,建模周期延长约2周。

复盘经验:数据准备阶段的时间投入应占整个建模项目的40%以上。建议建立“数据质量报告”模板,每次建模前自动生成字段缺失率、逻辑矛盾数、口径冲突数等指标,作为数据准入的门槛条件。

总结复盘:数据准备不是简单的“清洗+拼接”,而是对业务定义、时间语义、数据质量的系统性工程。违约样本定义需兼顾监管合规与业务敏感性;数据来源整合需解决主键匹配与时间对齐;清洗规则需可追溯、可审计;生存时间与截尾处理则直接决定模型的时间维度正确性。建议团队在项目启动时即建立数据字典、口径文档和清洗日志,为后续模型验证与监管审计奠定基础。