2. 模型风险管理框架：国际监管要求、三道防线与全生命周期管理
模型风险管理（MRM）并非凭空产生的技术实践，而是由一系列国际监管标准驱动、经过多年演进形成的体系化框架。理解这一框架，是构建有效监控方案的前提。本节将梳理三大核心支柱：国际监管要求（SR 11-7、巴塞尔协议）、三道防线模型以及全生命周期管理流程。
2.1 国际监管要求：SR 11-7 与巴塞尔协议
全球模型风险管理实践主要受两大监管文件影响：美联储的 SR 11-7 以及巴塞尔银行监管委员会（BCBS）发布的《巴塞尔协议》相关准则。
| 监管标准 | 发布机构 | 核心关注点 | 对MRM的影响 |
|---|---|---|---|
| SR 11-7 | 美联储（FRB） | 模型定义、风险分级、验证独立性、文档与治理 | 定义了“模型”的广义范围（包含评分卡、估值、风控等），要求建立模型清单、实施独立验证，并强调持续监控 |
| 巴塞尔协议III | 巴塞尔银行监管委员会（BCBS） | 资本充足率、信用风险、市场风险、操作风险计量 | 对内部评级法（IRB）、高级计量法（AMA）等模型提出严格的验证与回测要求，驱动了模型风险资本计提 |
| BCBS 239 | 巴塞尔银行监管委员会 | 风险数据聚合与风险报告 | 要求模型输入数据与输出报告具备高精度、完整性与及时性，间接强化了模型监控的数据基础设施 |
关键概念： SR 11-7 将模型定义为“一种定量方法、系统或方法，它应用统计、经济、金融或数学理论、技术和假设，将输入数据转换为定量估计”。这一定义覆盖了从简单的线性回归到复杂的机器学习模型。
2.2 三道防线模型：组织架构与职责分离
为了确保模型风险管理的独立性与有效性，行业普遍采用“三道防线”组织架构。每一道防线承担不同的角色，形成层层递进的制衡机制。
实践提示： 在Spark监控平台中，第一道防线通常通过自动化调度脚本（如Shell/Python）将模型性能指标写入Hive或Kafka；第二道防线则通过Spark SQL或流式作业读取这些指标，生成监控仪表盘与预警；第三道防线审计时，可直接查询Spark作业日志与血缘关系，验证监控覆盖率。
2.3 全生命周期管理：从开发到退出的闭环
模型风险管理不是一次性的验证活动，而是贯穿模型整个生命周期的持续过程。全生命周期管理通常包含以下六个阶段：
- 模型识别与分级：建立模型清单，根据风险影响、复杂度、使用范围对模型进行分级（如高、中、低风险）。
- 模型开发与文档：记录模型目的、方法论、假设、数据来源、开发过程及局限性。
- 模型独立验证：由第二道防线对模型进行概念合理性、数据质量、输出稳定性、回测与基准测试。
- 模型实施与监控：模型上线后，持续监控输入数据质量、输出分布、性能衰减与业务环境变化。
- 模型评审与更新：定期（如年度）或事件驱动（如市场突变）对模型进行再评审，决定是否调整、重新开发或退出。
- 模型退出与归档：当模型不再适用时，执行有序退出计划，并归档所有相关文档与监控历史。
监控盲区警示： 许多机构在模型上线后便放松了监控，导致模型性能衰减数月后才被发现。全生命周期管理要求“实施与监控”阶段持续输出指标，并作为“评审与更新”的输入。在Spark平台上，建议为每个模型建立监控作业DAG，自动计算PSI、KS、Gini等稳定性指标，并写入时序数据库供评审调用。
2.4 框架整合：监管、防线与生命周期的协同
将上述三个维度整合，可以形成完整的模型风险管理框架：
- 监管要求（SR 11-7、巴塞尔协议）定义了“做什么”与“做到什么程度”。
- 三道防线定义了“谁来做”与“如何制衡”。
- 全生命周期管理定义了“何时做”与“流程顺序”。