AI Credit Lifecycle / Underwriting / Line Management Governance Architecture 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_CREDIT_LIFECYCLE_UNDERWRITING_LINE_MANAGEMENT_GOVERNANCE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

核心导读

信贷 AI 不是一个审批分数模型，而是一套会改变客户准入、客户成本、信用敞口、机构损失、投诉风险和证据责任的生命周期决策系统。成熟架构要把预筛、审批、定价交接、额度管理、原因码、公平借贷、人工覆盖、champion/challenger、组合监控和客户救济连成可治理的信用决策工厂。

AI 能改变的不是“是否批准”这一个节点，而是从 prequal exposure、申请受理、收入与身份材料解释、风险排序、额度与定价交接、CLI/CLD、adverse reason、appeal 到投诉反馈的整条决策链。每个节点都要说明它是在执行政策、估计风险、生成解释、路由人工、触发客户沟通，还是改变客户可获得的信用条件；这些动作对应不同的权限、证据、监管关注和客户伤害路径。

系统价值来自把信用决策拆成可重放的 contract：as-of data snapshot、permissible purpose、feature lineage、policy version、model version、score band、line basis、pricing handoff、reason source、override note、communication template 和 monitoring trigger。这样做不是为了增加文档，而是为了在模型升级、组合恶化、投诉上升或公平借贷挑战出现时，能追溯到底是数据、政策、模型、额度网格、价格策略、人工覆盖还是客户沟通造成了变化。

评估证据不能停在 AUC、KS 或 approval rate。高成熟度信贷 AI 要同时看 segment outcome、reason accuracy、line/pricing drift、manual overturn、complaint/appeal/reversal、prequal-to-decline gap、rejected-population uncertainty、champion/challenger 和 post-action customer harm。控制边界也必须清楚：模型可以帮助排序、估计、解释和监控，但不能静默改写授信政策、把行为急迫度伪装成风险变量、生成无法证明的 adverse action reason，或让客户失去纠错和救济路径。

---

0. 适用边界

本文是学习和架构训练材料, 不构成法律意见、监管意见、合规结论、信用审批结论、定价建议、adverse action notice 建议、fair lending 结论、模型验证报告、消费者报告使用结论、投诉处理意见或供应商推荐。

正式项目必须由 Legal、Compliance、Fair Lending、Credit Risk、Pricing Strategy、Model Risk、Data Governance、Privacy、Information Security、Customer Experience、Operations、Complaint Management、Portfolio Risk、Internal Audit、Vendor Management、Product Owner、Architecture 和 senior management 共同确认。不同产品、渠道、客户群、州法、数据来源、consumer reporting 使用方式、notice workflow 和供应商角色会改变控制要求。

本文讨论的是架构和治理设计: 如何让事实、规则、模型、人工判断、客户沟通、投诉和组合表现形成可重放证据链。它不替代机构政策、法律解释或模型验证。

---

Source Anchors

Source-to-architecture pattern:

official anchor
  -> internal policy interpretation
  -> decision-control objective
  -> product requirement
  -> runtime evidence
  -> monitoring and issue workflow
  -> governance review

---

1. 核心问题: 信贷 AI 是生命周期控制系统

信贷 AI 最常见的错误起点是把问题缩成:

features -> score -> approve / decline

这个视角遗漏了信用产品真正改变客户和机构的位置。AI 可能决定谁看到 offer、谁进入申请、谁被要求补件、谁被批、谁被给低额度、谁拿到不同 APR、谁被降额、谁收到什么原因、谁能申诉、谁的投诉被升级, 以及哪些组合风险被管理层看到。

信用生命周期的关键 surface 如下:

成熟问题定义不是“模型是否更准”, 而是:

Can we prove which policy, data, model, override, line rule and pricing handoff
produced this customer's outcome,
why the reason codes were specific and accurate,
whether similarly situated customers were treated consistently,
whether proxies and overrides changed outcomes,
whether portfolio performance remains within risk appetite,
and whether complaints and customer harm flow back into governance?

---

2. 方法和架构贡献

本文的架构贡献是把信用 AI 拆成一套 layered decision factory。核心不是让模型更复杂, 而是把每个 customer-impacting decision 变成可登记、可解释、可复核、可监控、可挑战的对象。

customer and product context
  -> legal/compliance/policy interpretation
  -> eligibility and application controls
  -> feature boundary and lineage
  -> risk / fraud / capacity / behavior models
  -> policy decision orchestration
  -> line and pricing handoff
  -> reason attribution and customer communication
  -> human review, override and appeal
  -> portfolio, complaint and model-risk monitoring
  -> challenger, remediation and change control

2.1 Decision Taxonomy

先建立 decision taxonomy, 否则所有治理都会被“模型分数”吞掉。

2.2 Reference Architecture

customer / application / bureau / transaction / account / servicing data
  -> data classification, consent / permissible-use / purpose controls
  -> feature store with lineage, effective date and exclusion flags
  -> policy rules and product eligibility engine
  -> fraud / identity / capacity / affordability / credit risk models
  -> underwriting decision orchestration
  -> line assignment and exposure management service
  -> risk-based pricing handoff service
  -> reason attribution service
  -> adverse-action / customer communication / servicing packet
  -> manual review, override, appeal and complaint case workflow
  -> portfolio monitoring, fair lending / proxy monitoring, MRM monitoring
  -> challenger sandbox, policy change control and evidence ledger

---

3. 机制原理: 从审批到决策契约

Underwriting 至少包含五个 planes:

eligibility plane
fraud / identity plane
credit risk plane
capacity / affordability plane
policy exception and manual review plane

每次 underwriting decision 应输出结构化 contract, 供 line、pricing、reason、servicing 和 monitoring 使用。

设计要点:

• decision_outcome 保存路径, 不能只保存最终状态: policy decline, model decline, counteroffer, manual review, incomplete, customer withdrawn。
• reason_codes 来自 reason attribution service, 不能由 LLM、客服或 analyst 事后手写。
• line_basis 和 pricing_basis 显式分开, 便于解释同一风险等级下的额度或价格差异。
• human_actions 进入 override monitoring, 否则人工复核会变成不可见的 second model。

---

4. Prequalification、Pricing 和 Line Management

Prequalification / preapproval-like journeys 的风险在于客户体验语言、营销排序和信贷资格之间存在缝隙。AI 很容易用 conversion 或 propensity 去优化“谁最可能点”, 但信用治理关心的是 qualified access 和 expectation alignment。

Pricing handoff 是另一条高风险边界。必须区分三类差异化:

Pricing handoff contract 应包含:

Line management 要单独治理, 因为额度同时影响 customer access、spending capacity、loss exposure、utilization ratio、trust 和投诉。

初始额度可以按四层思考:

minimum usable line
  + risk-adjusted exposure
  + capacity / affordability cap
  + product and portfolio constraint
  + manual / relationship exception

CLD 是特别敏感的动作。它可能让交易失败、推高 utilization、破坏客户信任, 并在压力周期集中影响某些群体。降额不能只由 batch model 输出触发, 应形成:

trigger reason -> exposure impact -> customer impact -> notification / servicing path
  -> appeal / correction -> monitoring -> portfolio review

---

5. Reason、Fairness、Override 和 Challenger

Reason architecture 是信用 AI 的核心控制面。复杂模型不能成为“无法说明主要原因”的借口, 但 notice 适用性和最终口径由 Legal / Compliance / Fair Lending owner 判断。

decision facts
  -> policy hit and model contribution capture
  -> reason candidate generation
  -> principal reason ranking
  -> reason catalog mapping
  -> evidence reference binding
  -> template / notice / servicing packet
  -> complaint and appeal reuse

Reason catalog 需要版本化:

Fair lending / proxy risk 不是 underwriting model 的一次性测试。它是 lifecycle control plane:

Overrides 和 challengers 要产生学习, 不是只满足形式记录。

Override monitoring 应覆盖 reviewer、channel、product、segment、branch/partner、model band、vintage performance、complaints、appeal outcomes、reason changes、queue SLA 和 evidence completeness。

---

6. 为什么有效: 把治理嵌入运行时

这套架构有效, 因为它把治理从上线审批表移动到 runtime evidence。

第一, decision taxonomy 防止“一个 score”掩盖多种客户影响。Prequal、approval、line、price、CLI、CLD、reason、appeal 都有不同 owner、证据和监控口径。

第二, policy-first orchestration 让模型在已批准的产品、资格、exposure 和 prohibited-use 边界内工作。模型可以提升排序和识别能力, 但不能静默改写政策。

第三, structured decision contract 让每次客户结果可重放。信贷系统最怕的是六个月后只能说“模型当时这么判”。成熟系统能拿出 data snapshot、feature version、policy version、model score、line basis、pricing handoff、reason code、human action 和 communication template。

第四, reason-ready design 降低事后解释和投诉处理风险。Reason 在模型、政策、模板、客服和投诉之间共享同一 source of truth, 而不是让每个团队重新解释一次。

第五, line/pricing separation 让风险、价格和行为经济学边界清楚。Risk tier、line amount、APR、promotion、retention concession 都可能合理, 但必须能说明不同 levers 的批准依据和监控结果。

第六, complaint-learnable feedback loop 把客户伤害转成治理信号。投诉、appeal、reversal、wrong reason、CLD dissatisfaction 和 prequal mismatch 不只是客服成本, 而是模型、政策、产品文案、流程和控制的早期预警。

---

7. 局限和误用

局限也包括数据不可观测性。Rejected population、withdrawn application、abandoned onboarding、thin-file customer、non-traditional income 和 suppressed offer audience 的真实表现通常不可完全观察。架构上需要 reject inference、challenger、second-look、manual sample review 和 complaint signals, 但不能把这些替代为确定事实。

---

8. 架构和产品价值

对有金融零售经验的人, 这篇的关键价值不是学一个新模型, 而是把信贷产品、风险、合规、运营和数据平台翻译成共同的 operating system。

---

9. 金融零售系统案例: AI-Governed Credit Card Lifecycle

场景: 一家银行准备升级信用卡生命周期平台, 覆盖线上 prequal、移动端申请、收入文档抽取、underwriting、初始额度、APR tier、主动 CLI、批量 CLD、adverse reason、appeal 和投诉。

目标不是“上线一个 ML approval model”, 而是形成下面的运行闭环:

prequal exposure
  -> application decision
  -> line and price
  -> reason and communication
  -> activation and utilization
  -> CLI / CLD
  -> complaints and appeals
  -> portfolio and fairness monitoring
  -> policy / model / line / reason change

核心设计:

一个典型问题: 模型升级后 approval rate 基本稳定, vintage loss 下降, 但平均初始额度下降 28%, prequal-to-decline gap 上升, CLD 投诉和 wrong-reason appeal 上升。低成熟度团队会说“风险更好”; 成熟架构会同时检查 access 是否被低 line 隐性限制、哪些 segment 承担更多 friction、reason catalog 是否仍反映真实 principal factors、pricing handoff 或 line cap 是否被间接改变、complaints/appeals 是否说明客户无法纠错, 以及是否需要 challenger、second-look band、line grid adjustment、reason mapping update 或 release rollback。

---

10. 学习验证

完成本文后, 应能用一套连续架构讲清楚 prequal、application、line、pricing、CLI/CLD、reason、override、complaint 等 customer-impacting decisions, 并画出 data -> policy -> model -> orchestration -> line/pricing -> reason -> review -> monitoring -> complaint 的证据链。还应能定义 underwriting decision contract, 解释 reason、line、pricing、fairness、monitoring 和 runtime evidence 的控制目的。最小可交付架构包应包括: lifecycle decision inventory、reference architecture、underwriting decision contract、reason catalog sample、line management policy map、pricing handoff contract、monitoring metric contract、complaint-to-control loop 和 governance evidence pack。真正掌握这篇的标志是: 能把“AI 信贷审批”重新定义为信用生命周期治理平台, 并能说明每个客户结果如何被政策、数据、模型、人工、沟通和反馈共同控制。

---

SOTA 检查 (2026-07-01)

• MRM 指导已完成换代 (2026-04)：Fed / OCC / FDIC 于 2026-04-17 联合发布修订版 MRM 指导（Fed 侧为 SR 26-2，OCC 侧为 Bulletin 2026-13），正式取代 SR 11-7 (2011) 和 SR 21-8 (2021)，转向 risk-based / tailored 控制。本篇把 SR 11-7 标为“历史锚点”、SR 26-2 / OCC 2026-13 标为“更新锚点”的处理与现役监管状态一致，仍成立。
• GenAI/agentic AI 在 SR 26-2 中被置于正式 scope 之外，但不豁免治理：传统 ML（分类器、gradient-boosted、神经网络）用于 credit/fraud 仍完全在 scope 内；生成式与 agentic AI 因“新颖且快速演化”未纳入正文，机构须用更广义的风险治理框架覆盖。这印证本篇的分层设计：reason attribution、evidence ledger、override monitoring 等控制面不能只挂在 MRM 审批表上，必须内嵌在运行时。
• Adverse action 具体原因义务未被削弱：CFPB Circular 2022-03（发布 2022-05，“复杂算法不是无法给出 specific principal reasons 的借口”）截至 2026-07 仍是现役口径。2026-04 CFPB 最终规则收窄了 ECOA 下的 disparate-impact 责任、聚焦故意歧视，但 adverse-action 具体原因义务不受影响；同时州检察长层面的算法歧视执法在 2025 年末起明显加强（前 CFPB 局长 Chopra 加入 Democratic AGs Association 协调消费者保护执法）。含义：本篇第 5 节的 fair lending lifecycle control plane 不能因联邦执法收缩而裁剪，state-level 与私人诉讼风险仍然要求 segment/proxy monitoring 全量保留。
• 治理框架层未出现替代者：NIST AI RMF 1.0 (2023-01) 的 Govern/Map/Measure/Manage 与 ISO/IEC 42001:2023 (2023-12) 的 AIMS 到 2026-07 仍是 AI 治理 operating model 的主流骨架，本篇用它们组织 credit lifecycle 的方式无需替换。
• 不随版本过时的框架性结论：decision taxonomy、structured decision contract（as-of snapshot / policy version / model version / line_basis / pricing_basis 分离）、reason 必须来自决策事实而非 LLM 叙述、override 进入监控避免成为隐形 second model、complaint-to-control 反馈环——这些是架构不变量；2026 年监管方向（更强 explainability 要求、AI 治理进入常规检查）只是提高了它们的强制性。
• 库内配套：操作手册版见 docs/AI_CREDIT_LIFECYCLE_UNDERWRITING_LINE_MANAGEMENT_GOVERNANCE_PLAYBOOK.md（模板/RACI/门禁/runbook，与本篇配对阅读）。