支持 NIN — 迭代需求

对应需求：REQ-ITER-013。目标是在现有 BVN/KYC 口径外，补充尼日利亚 NIN 采集、校验和归档能力。
已拍板：NIN 与 BVN 二选一，客户提供其中任一有效身份核验结果即可继续流程。

1. 第一性原理

KYC 的目的不是收集证件号，而是确认“这个手机号背后的客户是真实、唯一、可追责的自然人”。BVN 与 NIN 都是身份信号，系统应抽象为身份核验能力，而不是把某个证件写死在业务流程里。

2. 交互设计图

BVN 与 NIN 二选一交互设计

3. 产品口径

已拍板口径：

NIN 与 BVN 二选一。
客户已完成有效 BVN 核验时，不强制再采集 NIN。
客户已完成有效 NIN 核验时，不强制再采集 BVN。
现金贷和手机分期共用同一套身份核验结果，不重复采集。

如果客户同时提交 BVN 和 NIN，系统应保存两类核验结果；两者核心身份信息明显冲突时，进入风控/人工复核，不自动覆盖已有通过结果。

4. 范围

包含

前端采集 NIN。
crs 调用供应商做 NIN 核验。
结果归档到客户身份档案。
风控可读取 NIN 核验结果。
进件流程支持 BVN / NIN 二选一。
运营/日志可追溯核验状态。

不包含

NIN 图片 OCR。
人工 KYC 审核台。
多供应商自动切换。
复杂身份冲突仲裁。

5. 数据口径

字段	说明
`nin_hash`	NIN 哈希，业务展示不存明文
`nin_masked`	脱敏展示，如末四位
`nin_verify_status`	pending / passed / failed / error
`nin_provider`	供应商
`nin_verified_at`	核验时间
`nin_name_match`	姓名是否匹配
`nin_birthdate_match`	出生日期是否匹配
`nin_raw_ref`	原始响应归档引用，不直接暴露

6. 流程

客户输入 NIN
  -> 前端基础格式校验
  -> bns 提交身份资料
  -> crs 调供应商核验
  -> crs 返回标准化结果
  -> bns / 客户档案归档
  -> 风控读取核验结果

7. 异常处理

异常	处理
格式错误	前端直接提示
供应商超时	标记 error，可重试
信息不匹配	标记 failed，是否阻断待策略决定
供应商余额不足	触发 02-监控告警
重复提交同一 NIN	复用已有有效结果
已有有效 BVN	不强制采集 NIN
已有有效 NIN	不强制采集 BVN
BVN 与 NIN 信息冲突	进入风控/人工复核

8. 验收标准

前端能采集并校验 NIN 基础格式。
crs 能返回统一的 NIN 核验结果。
NIN 明文不在普通业务表和日志中暴露。
同一客户已通过的 NIN 结果可被现金贷和手机分期复用。
客户完成 BVN 或 NIN 任一有效核验后，可继续进入后续流程。
已有有效 BVN 的客户不被强制要求补 NIN；已有有效 NIN 的客户不被强制要求补 BVN。
风控能读取 NIN 状态并用于决策。
供应商失败、余额不足、超时能被记录和告警。