1. 拒绝原因概述
1.1 什么是拒绝原因
在信贷风控场景中，拒绝原因是指当借款申请被风控系统或人工审核判定为“拒绝”时，系统记录的具体触发拒绝决策的变量、规则或策略节点。它不仅是“申请未通过”这一结果的标签，更是解释“为什么被拒”的结构化信息。
拒绝原因通常以策略规则ID、变量阈值或模型分数区间的形式存储。例如：
- 规则级拒绝：命中“多头借贷数 > 5”规则，拒绝原因编码为 RULE_MT005。
- 模型级拒绝：信用评分低于 400 分，拒绝原因编码为 MODEL_SCORE_LOW。
- 人工级拒绝：资料真实性存疑，拒绝原因编码为 MANUAL_FRAUD_FLAG。
关键认知： 拒绝原因 ≠ 拒绝标签。拒绝标签只记录“通过/拒绝”的二元结果，而拒绝原因记录了导致拒绝的驱动因素，是后续变量衍生与分箱的核心原材料。
1.2 拒绝原因在风控中的重要性
拒绝原因在风控全链路中扮演着承上启下的关键角色，其重要性体现在以下四个维度：
| 维度 | 说明 | 业务价值 |
|---|---|---|
| 策略监控 | 实时统计各拒绝原因的出现频次与占比 | 发现策略异常偏移、规则冲突或阈值失效 |
| 变量衍生 | 将拒绝原因编码转化为可建模的特征变量 | 提升模型对拒绝客群的区分能力 |
| 拒绝推断 | 为拒绝样本提供“伪标签”或“权重”的依据 | 缓解样本偏差，改善模型泛化性能 |
| 合规解释 | 向监管或客户提供可追溯的拒绝理由 | 满足可解释性要求，降低合规风险 |
在实际生产中，拒绝原因数据往往比通过样本的标签数据更丰富、更及时。一个设计良好的拒绝原因体系，能够帮助风控团队在新策略上线后数小时内就发现潜在问题，而不必等待数月的贷后表现数据。
实践建议： 拒绝原因的编码粒度不宜过粗（如仅记录“综合评分不足”），也不宜过细（如每个阈值变化都生成新编码）。建议按策略大类 + 变量维度进行分层编码，例如：RULE_MT（多头类）、RULE_DEBT（负债类）、RULE_ID（身份类）。
1.3 拒绝原因与拒绝推断的关系
拒绝推断（Reject Inference）是风控建模中处理样本选择偏差的核心技术。拒绝原因与拒绝推断之间存在双向依赖关系：
- 拒绝原因为拒绝推断提供特征基础：拒绝原因本身可以衍生为特征变量，帮助模型学习拒绝样本的分布模式。
- 拒绝推断为拒绝原因赋予标签：通过推断模型为拒绝样本生成“假设表现”，进而验证或修正拒绝原因的有效性。
下图展示了拒绝原因在风控建模流程中的位置及其与拒绝推断的交互关系：
从流程图中可以看出，拒绝原因处于策略决策与模型开发的交汇点。具体而言，拒绝原因在拒绝推断中的三种典型应用模式如下：
| 应用模式 | 方法描述 | 对拒绝原因的依赖程度 |
|---|---|---|
| 硬截断法 | 直接丢弃拒绝样本，仅用通过样本建模 | 低（仅需拒绝标签） |
| 模糊展开法 | 根据拒绝原因对拒绝样本分层抽样或加权 | 高（需要拒绝原因分层） |
| 双模型法 | 分别训练通过模型和拒绝模型，融合评分 | 中（需要拒绝原因作为特征） |
常见误区： 很多团队在拒绝推断时只关注“拒绝/通过”二元标签，而忽略了拒绝原因中蕴含的拒绝深度信息。例如，同一个“多头借贷”规则，命中次数为 6 次与命中次数为 20 次，其拒绝原因编码虽然相同，但拒绝的“严重程度”截然不同。在变量衍生阶段，应当将拒绝原因与原始变量阈值联合编码，而非简单做 one-hot 处理。