AI Collections / Hardship：逾期与困难客户处理架构
AI collections architecture 不是让系统“更会催”。它是一套 customer-treatment control system：在管理信用损失、现金流和运营容量的同时，证明客户被相称联系、获得可负担和可访问的方案、没有被高压或误导，困难情境没有被当成收入提取机会。
AI Collections / Hardship / Delinquency Treatment Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_COLLECTIONS_HARDSHIP_DELINQUENCY_TREATMENT_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
重要说明: 本文只讨论 early delinquency、collections contact、hardship treatment、repayment options、agent assist、complaints 和 evidence controls 中的 AI 产品与架构设计，不构成法律、监管、FDCPA/Reg F 适用性、消费者保护、信贷建议、债务咨询、催收话术审批、模型验证或客户通知结论。Debt collection、servicing、hardship 和 delinquency treatment 的具体要求必须由 Legal、Compliance、Conduct Risk、Credit Risk、Collections/Hardship Operations、Complaint Operations、Privacy、Model Risk、Operational Risk、Vendor Management、Internal Audit 等共同确认。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| CFPB Debt Collection Rule / Regulation F | https://www.consumerfinance.gov/rules-policy/regulations/1006/ | 用作 debt collection communications、disclosures、call/contact controls、recordkeeping 和 consumer treatment 的 official regulatory anchor；具体适用性由 Legal/Compliance 判断 |
| CFPB consumer complaint database | https://www.consumerfinance.gov/data-research/consumer-complaints/ | 用 complaint themes、consumer harm signals、servicing/collections feedback 训练 complaint linkage、RCA、CAPA 和 evidence loops |
| CFPB compliance circulars landing page | https://www.consumerfinance.gov/compliance/circulars/ | 用 consumer financial protection、servicing、fees、misleading communications、complaints 和 conduct-risk lens 组织控制语言；具体 circular 适用性需逐项判断 |
| FTC Fair Debt Collection Practices Act text | https://www.ftc.gov/legal-library/browse/rules/fair-debt-collection-practices-act-text | 用作 FDCPA statutory text anchor, 训练 collections communication、harassment/abuse、false/misleading representation、unfair practices 等风险意识；不在本文判断适用性 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 AI risk taxonomy、impact assessment、model evaluation、monitoring 和 continuous improvement |
| ISO/IEC 42001 overview | https://www.iso.org/standard/42001 | 用 AI management system、policy、roles、operation planning、performance evaluation、internal audit 和 improvement 建立 operating model |
| WCAG 2.2 | https://www.w3.org/TR/WCAG22/ | 用 Perceivable / Operable / Understandable / Robust 约束 digital hardship、payment、chat、document upload、notification 和 complaint channels |
核心导读
AI collections architecture 不是让系统“更会催”。它是一套 customer-treatment control system：在管理信用损失、现金流和运营容量的同时，证明客户被相称联系、获得可负担和可访问的方案、没有被高压或误导，困难情境没有被当成收入提取机会。
AI 改变的是从 delinquency event 到 treatment 的决策链。传统 collections 容易把 DPD、接通率、promise-to-pay 和回收金额当作主目标；AI 可以把账户状态、付款行为、hardship context、投诉/争议、渠道偏好、无障碍需求、vendor contact 和 prior treatment history 组合起来，判断什么时候 soft support、什么时候暂停压力、什么时候进入 specialist review、什么时候提供可持续 repayment option。但预测客户会付款，不等于应该怎样联系客户；预测客户会接电话，也不等于联系是相称和合规的。
本篇应重点理解“treatment orchestration”的证据和控制边界。企业级 contact ledger、frequency cap、complaint/dispute/hardship hold、approved content、affordability guardrail、vendor export、final-channel capture 和 complaint RCA 必须连成闭环。AI 不能自由生成催收话术，不能用 hardship/vulnerability signal 做更高压力或更差条款，不能把不可承受计划包装成成功；高影响方案、争议余额、困难援助和投诉场景都需要人工判断、理由记录和可审计证据。
问题定义
传统 collections optimization 常被压缩为 right customer、right channel、right time、right amount。金融零售 AI 需要把问题升级为 right treatment、right guardrail、right evidence、right human judgment、right customer outcome。
高风险场景包括：
- 客户首次 missed payment，但尚未进入正式 hardship route。
- 多产品线和第三方 vendor 对同一客户重复触达，形成 over-contact。
- 客户表达失业、医疗支出、丧亲、诈骗损失、domestic abuse、语言或无障碍困难。
- chatbot 推荐了客户无法承受的 payment plan。
- agent-assist 自动生成 collections script，员工误以为已合规审批。
- 客户投诉被骚扰、承诺减免后仍被收费、无法通过无障碍渠道申请困难援助。
成熟目标不是“AI 催回更多钱”，而是：
Can the institution reduce credit loss while proving that customers in difficulty
were treated with dignity, accessibility, proportionality, consistency and evidence?
核心原理/方法
第一条原则：DPD 是账户状态，不是客户处境。Treatment taxonomy 必须同时看 account status、payment behavior、hardship context、support need、contact constraints、complaint/dispute status、prior treatment history 和 product policy。
第二条原则：risk prediction 不等于 treatment decision。delinquency score、contact propensity、payment likelihood 可以提示 early support，但不能直接触发高压联系、不利处理或不可解释方案。
第三条原则：contact strategy 必须 enterprise-level。单个产品线优化接通率会造成全企业 over-contact；需要跨账户、渠道、vendor、household/customer 的 contact ledger、frequency cap、preference、consent、complaint/dispute/hardship hold。
第四条原则：repayment option 必须受 affordability 和 durability 约束。promise-to-pay、short-term plan、forbearance-like path、fee review、hardship treatment 和 human specialist 都应由 policy-bound option engine 管理。
系统/架构模型
参考架构：
account delinquency events
-> customer contact profile and preferences
-> complaint / dispute / fraud / hardship status
-> accessibility and language preference
-> AI signal and treatment layer
-> treatment policy and option engine
-> contact orchestration
-> agent-assist and customer self-service
-> hardship / bereavement / fraud / complaint specialist handoff
-> evidence ledger
-> QA / model risk / conduct monitoring
-> complaint RCA / remediation / CAPA
核心组件：
| Component | 职责 |
|---|---|
| Delinquency event hub | 汇聚账户状态、payment events、fees、plan status、charge-off path |
| Contact control service | 管理 consent、preference、frequency、channel、complaint holds、vendor logs |
| Treatment policy engine | 生成 approved option set、restrictions、customer explanations |
| Hardship orchestration | 处理困难原因、文件、审批、计划、review、extension |
| Affordability guardrail | 检查 plan sustainability、payment failure risk、customer impact |
| Support detector | 识别 hardship、accessibility、language、bereavement、fraud/scam、complaint distress |
| Agent-assist guardrail | 控制话术、summary、uncertainty、prohibited actions、human reason |
| Accessibility layer | 确保 payment/hardship/complaint channels 可访问 |
| Evidence ledger | 保存模型、政策、人工、最终沟通、投诉链路 |
| Governance cockpit | 监控 roll rate、durable resolution、complaints、conduct defects、CAPA |
关键机制与取舍
Treatment taxonomy：
| Dimension | Examples | 架构用途 |
|---|---|---|
| Account status | current but at-risk、1-29 DPD、30-59 DPD、late-stage | 决定 policy universe，但不能单独决定 treatment |
| Payment behavior | partial pay、broken promise、autopay failure、overdraft dependency | 识别现金流压力和 plan sustainability |
| Hardship context | job loss、medical、bereavement、disaster、caregiving、divorce | route hardship options and specialist review |
| Support signal | accessibility request、language barrier、scam loss、distress、cognitive load | pressure suppression and dignified support |
| Contact constraints | preferred channel、time、representative、contact limitation | outreach control |
| Complaint/dispute status | fee dispute、fraud claim、active complaint | suppress/modify collections path |
| Treatment history | prior forbearance、plan performance、waiver history | 防止重复不合适方案 |
| Product risk | credit card、personal loan、auto、overdraft、BNPL | 影响 options、notices、routing |
Contact strategy 取舍：
| Design element | 弱设计 | 强设计 |
|---|---|---|
| Timing | 只预测接通率 | 同时检查 permitted window、preference、timezone、distress、complaint hold |
| Channel | 按 conversion 排序 | 按 preference、accessibility、consent、documentation need、sensitivity |
| Frequency | 各产品线独立优化 | enterprise contact ledger 去重、限频、合并 |
| Message | “立即付款避免后果” | amount/date/options/consequence/human help 清晰可解释 |
| Segmentation | 高风险客户更多触达 | 高风险客户更多 support and review，不是更多 pressure |
| Vendor | vendor 自行拨号/话术 | 统一 contact controls、content library、evidence export、complaint loop |
Hardship option engine：
customer situation
+ product/account policy
+ hardship status
+ affordability estimate
+ support need and accessibility preference
+ complaint/dispute holds
+ prior treatment history
-> eligible option set
-> customer explanation
-> human review if high-impact
-> final-channel capture
证据与控制
Evidence ledger 最少字段：
case_id
account_id / product_type
customer_contact_profile_id
delinquency_bucket
support_need_type
signal_source
ai_run_id
treatment_policy_version
option_set_presented
recommendation
human_decision and reason
final_channel_event_id
contact_attempt_id
vendor_contact_reference
complaint_id
remediation_id
QA_result
CAPA_id
控制矩阵：
| Control objective | Control activity | Evidence |
|---|---|---|
| 防止 over-contact | enterprise contact ledger、frequency caps、preference、complaint/dispute/hardship holds | contact attempts report、suppression log、vendor reconciliation |
| 保留客户尊严 | no-shame content、prohibited language scan、agent QA | script library、transcript QA、LLM eval |
| 提供适当 treatment | policy-bound option engine + affordability guardrails | option eligibility log、plan sustainability review |
| 安全识别 hardship | support signals route to specialist without permanent labeling | signal card、handoff packet、access rules |
| 控制 AI 生成沟通 | approved content、source grounding、final-channel capture | prompt bundle、RAG manifest、channel event |
| 保护 vulnerable situations | pressure suppression、specialist handoff | routing record、sales suppression、QA sample |
| 确保 accessibility | WCAG/manual QA for payment、hardship、upload、chat、documents、complaints | test report、assistive tech transcript |
| 链接 complaints | complaint record includes AI/contact/treatment/evidence ids | complaint file、RCA、remediation、CAPA |
| 控制 vendors | evidence export、content controls、audit rights、issue escalation | vendor QA、SLA、export test |
指标应包含 roll/cure/loss，也要看 plan completion、re-default、complaints per contact、preference adherence、over-contact、hardship approval timeliness、false negative hardship signal、unsupported script defects、accessibility completion、final-channel capture、CAPA recurrence。
金融零售/AI产品场景
- Early delinquency support：autopay failure 和 overdraft cycle 触发 soft support，不触发高压催收；客户陈述 job loss 后进入 hardship route。
- Multi-product customer：信用卡、贷款和 overdraft 都 delinquent，contact control service 合并触达，避免三天七次联系。
- Digital hardship form：screen reader、keyboard-only、upload recovery 和 large text 作为 release gate；客户不能完成表单时自动提供 assisted channel。
- Agent-assist call：屏幕展示 customer-stated facts、contact constraints、eligible options、prohibited actions 和 uncertainty，而不是让模型自由写催收话术。
- Complaint hold：客户投诉 fee 或 dispute balance 后，系统同步到 all product/vendor contact paths，直到 review 决定是否继续。
- Vendor collections：第三方 vendor 必须使用同一 content library、contact cap、evidence export 和 complaint feedback loop。
反模式
| 反模式 | 风险 | 更好的控制 |
|---|---|---|
| 只优化 promise-to-pay | 客户承诺不可承受计划，随后 re-default and complaint | affordability guardrail and durable resolution metrics |
| DPD-only treatment | 忽略 hardship、dispute、preference、complaint | multi-dimensional treatment taxonomy |
| contact propensity 无 conduct control | 接通率提升但骚扰感增加 | contact control service and content guardrails |
| LLM 自由写 collections script | 误导、威胁、unsupported promise | approved content blocks and final-channel capture |
| hardship signal 变 stigma | 未来服务或销售受到不当影响 | purpose-bound support_need_type |
| complaint hold 不同步 | 投诉期间继续收到自动催收 | complaint-to-contact suppression integration |
| vendor evidence gap | 无法证明第三方如何联系客户 | export and reconciliation |
| accessibility 只做 UI QA | 客户无法申请 hardship | journey-level accessibility gate |
| 模型分数驱动限制动作 | 缺少解释和复核 | human review and reason code |
最终心智模型
Collections AI 的本质不是 pressure optimization，而是 treatment orchestration。成熟系统应能证明：客户落后还款时，机构能早期识别风险和支持需求，按偏好和约束相称联系，提供可负担和可访问的方案，保护困难情境不被销售或高压利用，指导员工安全沟通，链接投诉和补救，并用证据证明 fair treatment。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。