第2章 评分模型构建前置条件：数据可用性、业务规则、风险偏好、监管要求

评分模型构建并非始于算法或特征工程，而是始于对四个前置条件的系统化核查。任何模型若在数据、业务、风险容忍度或合规层面存在缺口，均会导致后续工作返工甚至项目失败。本章围绕四个核心前置条件，提供可落地的检查方法与交付标准。

适用场景

• 组织首次构建或迭代更新评分模型时。
• 模型拟用于信贷审批、风险定价、客户分群、合规评估等关键决策场景。
• 监管机构或内部审计要求模型开发过程具备前置条件审计痕迹。
• 多部门协同（数据、业务、风控、合规）需统一判定模型可用性。

前置条件

在开始本章操作前，应已完成以下准备工作：

1. 已定义模型目标（如违约概率预测、信用评分范围等）。
2. 已获取数据源清单（内部系统表、外部采购数据、API接口等）。
3. 已初步确定业务规则与评分体系的对应关系（如最低准入分、拒绝线）。
4. 已明确模型适用的监管指引（如巴塞尔协议、本地信贷管理办法、GDPR/隐私法规）。

操作步骤

按顺序执行以下四个检查阶段，每个阶段均需记录输出。

输入输出物

责任边界

记录材料

1. 《前置条件检查日志》：记录每个阶段的检查日期、执行人、发现项与解决状态。
2. 《未达标问题跟踪表》：对未通过项（如数据缺失率超限、业务规则矛盾）建立问题编号、责任方、预期解决日期。
3. 《会议纪要（对齐会议）》：包含数据对齐会、规则对齐会、风险偏好对齐会、合规评审会的核心决策与签字。
4. 《版本变更历史》：若前置条件因业务调整而修改，需记录变更原因与批准人。

异常处理

• 数据不可用：若关键数据源缺失或质量不满足要求，升级为“数据风险”并启动替代方案（如调研外部数据、增加特征组合或使用统计填补），同时更新风险偏好KPI以吸收数据不确定性。
• 业务规则与模型目标冲突：组织业务方与模型方联合研讨会，量化冲突影响（如拒绝率上升3%带来的坏账下降幅度），最终由业务决策者签署修订规则。
• 风险偏好过于激进/保守：若KPI底线过高导致模型无法实现，或过低导致失去区分能力，应提请风控委员会重新审议偏好，并记录调整依据。
• 监管要求变更：一旦监管政策更新（如新增禁止变量或披露义务），立即冻结当前变量清单，启动合规复查流程，直至获得新确认函。
• 多条件交叉异常：例如数据可用性差且监管要求收紧，由项目负责人召集跨部门紧急会议，评估是否暂停项目、缩小范围或申请豁免。

验收标准

本章所有操作完成后，必须同时满足以下条件方可认为前置条件验收通过：

1. 四阶段检查清单中所有项状态均为“通过”或“已豁免（经书面批准）”。
2. 数据质量报告中关键字段完整度≥95%，缺失率≤5%，异常值占比≤3%（若未达到，须有已批准的偏差处理方案）。
3. 业务规则文档已获业务方和模型方双签确认，且规则逻辑可编码执行。
4. 风险偏好KPI标靶已量化，且与模型最小可接受性能一致。
5. 合规部门出具正式确认函，模型输入变量不包含监管禁止字段，输出具备解释性设计。
6. 所有记录材料（日志、跟踪表、会议纪要）归档至项目文档库，版本号统一。