PRA SS1/23 实务指南

作者：Jonas Mohamed Osman Abdelghafour

英国审慎监管局 (PRA) 的 SS1/23 针对模型风险管理提出了五项原则：识别与分层、治理、开发与实施、独立验证，以及从部署开始的模型风险管理。快速浏览时，它们看起来像是大多数银行已经在做的事情。但在诚实实施的过程中，它们会暴露那些仅存在于纸面上而非运营模式中的框架缺陷。

原则 1：无法管理未定义的事物

模型识别往往是实施中最容易失败的环节，因为定义的范围常被刻意收窄以保持清单的可管理性。其后果是产生了一套“影子资产”——包括设定定价覆盖的电子表格、金融犯罪中的确定性规则引擎、计算逻辑未被检查过的供应商工具，以及越来越多嵌入在工作流软件中的 AI 助手。

一种站得住脚的方法是根据模型输出的用途来定义模型，并通过分层实施比例化处理。第一层 (Tier 1) 模型需要全面的独立验证和年度审查；较低层次的模型则需进行登记、明确所有权并接受较轻程度的定期评估。定义的测试标准很简单：如果监管机构随机挑选一项对收益、资本或客户有重大影响的决策，你是否能点出其背后的模型？

原则 2：治理在于问责，而非委员会

SS1/23 期望由一名高级管理人员将模型风险作为一种独立的风险类别来负责，并向董事会层级报告。在实践中，这意味着需要一名具名的负责高管、一项针对未经批准使用行为具有约束力的政策，以及一套比“低”更有决策参考价值的模型风险偏好陈述。有效的风险偏好陈述通常结合了对未经验证的 Tier 1 敞口的限制、对逾期发现项的容忍度，以及模型必须被限制或撤销的明确条件。

原则 3：验证前的开发纪律

独立验证无法修复文档缺失的糟糕构建。开发标准应要求提供预期用途说明、数据血缘、被拒绝的备选方案、测试证据、已知局限性，以及针对每个局限性的补偿性控制措施。局限性是最被忽视但也是最有用的部分：一个边界清晰且强制执行使用限制的模型，比一个在生产环境中才被发现弱点的模型更安全。

原则 4：何为有效的挑战

验证通过测试开发者不能或不愿测试的内容来创造价值。富有成效的问题包括：基于预期用途的概念合理性、结果对重大假设的敏感性、数据的质量和代表性、在压力下及各细分市场的表现，以及监控是否能真正察觉到恶化。重复开发者的计算只能证明算术正确，而非合理性。

独立性需要是结构性的——包括汇报路线、预算以及施加条件或阻止使用的权限——否则“有效的挑战”就变成了文字编辑工作。

原则 5：上线后的生命周期

大多数模型风险在获得批准后很久才显现。一个行之有效的实施后机制会针对每个模型指定监控内容、频率、阈值，以及突破阈值后的处理措施。突破响应应预先达成一致：重新校准、人工覆盖、限制使用或撤销。模型后调整 (post-model adjustments) 值得特别关注——它们是合法的短期工具，但也是未建模判断转变为永久性且无人负责的常见方式。

实施中的常见误区

• 清单仅是列表，而非控制手段。 无人将其与生产系统进行核对。
• 发现项老化。 逾期的验证发现项是框架失效最清晰的先行指标。
• 分层通过协商确定。 如果业务线可以通过辩论进入较低层级，那么重要性评估就变成了一场预算博弈。
• 供应商模型在实务中被豁免。 对内部机制的访问受限应是进行补偿性测试的理由，而非跳过评估的借口。
• 董事会报告仅统计模型数量。 它应该报告敞口、漂移以及未决决策。

务实的顺序

建立或重建框架的机构，如果先清理资产再完善方法论，通常会走得更远：完整核对清单、指派所有者、按重要性分层、弥补 Tier 1 验证缺口，然后投资于监控自动化。在不完整的清单上应用复杂的验证方法论，起不到任何保护作用。

SS1/23 奖励证据。实施得好的机构并不是政策最长的机构，而是那些在任何特定时刻都能展示哪些模型处于活跃状态、谁拥有它们、它们表现如何以及管理层下一步将采取什么行动的机构。

主要来源： 英格兰银行 / PRA 监管声明 SS1/23，《银行模型风险管理原则》(Model risk management principles for banks)。