2. 金融模型基础

在金融风险管理与信贷决策中，模型不是一次性的分析产物，而是一项持续运营的资产。理解模型从需求到退役的完整生命周期，掌握标准化的开发流程，并熟悉评分卡、PD、LGD、EAD 等核心模型类型，是构建模型基线、开展 Challenger 对比与增量评估的前提。本节将围绕这三个基础维度展开。

一、核心原理：模型生命周期是一条闭环

金融模型的生命周期并非线性终点，而是一个持续迭代的闭环。典型阶段包括：业务需求与目标定义、数据准备与探索、模型开发与验证、部署上线、监控与回检、重开发或退役。每个阶段都有明确的交付物与准入准出条件。

其中，监控与回检是模型生命力的关键。模型上线后，宏观经济、客群结构、政策环境都会变化，导致模型区分能力下降或排序偏移。若缺乏监控，模型会悄然失效，形成“模型风险”。因此，生命周期管理的本质是：让模型始终与业务现实保持校准。

核心观点：模型生命周期不是“开发完就结束”，而是“上线后才真正开始”。基线模型、Challenger 模型与增量评估，都是生命周期中监控与迭代环节的标准化动作。

二、方法流程：标准化开发流程的六个步骤

无论构建评分卡还是 PD 模型，开发流程通常遵循以下步骤：

  1. 业务理解与目标定义：明确模型用途（审批、定价、限额、资本计量）、目标变量（违约、逾期、流失）与时间窗口。
  2. 数据准备与清洗：整合内外部数据，处理缺失值、异常值、重复值与时间穿越问题。
  3. 特征工程与变量筛选：构建衍生变量，通过 IV、WOE、相关性、VIF 等指标筛选入模变量。
  4. 模型训练与调优：选择算法（逻辑回归、决策树、XGBoost 等），进行分箱、正则化与超参数调整。
  5. 模型验证与评估：使用 KS、AUC、Gini、PSI、Lift 等指标，结合样本外与时间外验证。
  6. 部署、监控与文档：上线后持续监控稳定性与区分度，并保留完整模型文档以备审计。

在代码层面，一个典型的模型训练与评估流程可以用如下伪代码表示：

# 示例：评分卡模型训练与评估核心步骤
data = load_data("credit_data.csv")
train, oot = time_split(data, split_date="2023-01-01")

# 分箱与WOE转换
binner = WOEBinner(max_bins=5, min_bin_pct=0.05)
binner.fit(train, target="default")
train_woe = binner.transform(train)
oot_woe = binner.transform(oot)

# 逻辑回归训练
model = LogisticRegression(C=0.1, class_weight="balanced")
model.fit(train_woe[features], train["default"])

# 评估
ks = ks_statistic(oot["default"], model.predict_proba(oot_woe[features])[:,1])
auc = roc_auc_score(oot["default"], model.predict_proba(oot_woe[features])[:,1])
print(f"OOT KS={ks:.4f}, AUC={auc:.4f}")

三、常见模型类型：从评分卡到 PD、LGD、EAD

金融领域常见模型可按用途分为以下几类，它们共同构成信用风险计量的核心工具链：

模型类型核心目标常用算法关键指标
申请评分卡（A卡）预测新客户违约概率逻辑回归、WOE分箱KS、AUC、PSI
行为评分卡（B卡）预测存量客户未来风险逻辑回归、GBDTKS、Lift、稳定性
催收评分卡（C卡）预测逾期客户回款概率逻辑回归、决策树KS、回收率
PD 模型估计违约概率逻辑回归、XGBoostAUC、CAP、校准度
LGD 模型估计违约损失率Beta回归、线性回归MAE、R²、分布对比
EAD 模型估计违约风险暴露线性回归、时间序列CCF、预测误差

其中，PD、LGD、EAD 三者共同决定预期信用损失（ECL）：ECL = PD × LGD × EAD。这一公式是 IFRS 9 与巴塞尔协议的核心计量逻辑，也是模型基线对比与增量评估的重要落脚点。

提示：评分卡通常以 WOE 分箱加逻辑回归为主，强调可解释性；而 PD/LGD/EAD 在监管资本计量中更强调校准度与保守性。开发时需根据用途选择算法与验证标准。

四、案例与场景：一个消费信贷评分卡的生命周期

假设某银行消费信贷部门要开发一款申请评分卡。业务目标是提升审批通过率同时控制坏账。开发团队首先定义“违约”为“首次逾期超过 90 天”，选取过去 24 个月数据，预留最近 6 个月作为时间外样本。

在特征工程阶段，团队构建了收入负债比、历史查询次数、设备指纹稳定性等变量。经过 WOE 分箱与 IV 筛选，最终入模 12 个变量。模型上线后，每月监控 PSI 与 KS：若 PSI 超过 0.25 或 KS 下降超过 20%，则触发回检与重开发。

半年后，由于客群下沉，模型 KS 从 0.42 降至 0.31。团队随即启动 Challenger 模型开发，引入更多行为数据与机器学习算法，并与基线模型进行增量评估，最终决定是否切换。这正是模型生命周期闭环的典型体现。

金融模型生命周期闭环与ECL构成 需求定义 数据准备 模型开发 验证评估 部署上线 监控回检 预期信用损失 ECL PD 违约概率 LGD 违约损失率 EAD 违约风险暴露 ECL = PD × LGD × EAD

五、误区与复盘：常见开发陷阱

  • 时间穿越：使用未来信息构建特征，导致模型在样本内表现优异但上线后失效。必须严格按时间切分训练与验证样本。
  • 过度依赖样本内指标：只看训练集 KS/AUC，忽视时间外验证与稳定性 PSI，容易高估模型能力。
  • 忽视业务可解释性：在监管场景中，黑箱模型可能无法通过验证。评分卡通常优先选择逻辑回归与 WOE 分箱。
  • 缺少监控机制：模型上线后无人跟踪，导致风险累积。应建立 PSI、KS、Lift 的定期监控报表。
  • 混淆 PD、LGD、EAD 的用途：三者计量目标不同，不能简单用同一套特征与算法处理，需分别设计与验证。
复盘要点：模型开发不是追求最高 AUC，而是在可解释性、稳定性、区分度与业务约束之间取得平衡。基线模型与 Challenger 模型的对比，正是为了在可控风险下寻找更优解。

掌握模型生命周期、开发流程与常见模型类型，是后续开展基线设定、Challenger 对比与增量评估的基石。只有把基础打牢，才能在模型迭代中做出稳健、可审计、可落地的决策。

← 上一章 📖 返回目录 下一章 →