AI Regulatory Reporting / Risk Data Aggregation / Attestation Architecture 解读

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

核心导读

金融机构的监管报送不是报表生产线，而是把监管义务、业务事实、风险数据、转换规则、对账控制、签署责任、提交证据和更正闭环组合成一套可证明的事实系统。AI 可以提升说明书解析、异常聚类、证据检索和叙事起草效率，但不能替代口径定义、例外处置、签署、提交和更正判断。

重要说明：本文是学习、作品集和内部架构训练材料，不构成法律意见、监管解释、合规结论、审计意见、财务报告结论、资本充足性结论、模型验证结论或监管报送建议。具体适用范围、报送义务、口径解释、重要性判断、提交时限、更正或重报判断，应由 Legal / Compliance / Regulatory Affairs / Finance / Risk / Internal Audit / Management 授权角色结合机构类型、牌照、监管关系、报告说明和内部政策确认。访问日期按 2026-06-30 记录。

---

Source Anchors

---

1. 核心问题：报送事实为什么难以证明

监管报送的表面工作是把数据填进 Call Report、FR Y-14A/Q/M、内部风险报告或监管问询模板。真正的难点是证明每个数字在特定报告期、说明书版本、合并范围和冻结时间下是可解释、可复算、可对账、可签署的事实。

低成熟度流程通常是：

源系统抽数
  -> 数据团队拼表
  -> 报表团队调 Excel
  -> Finance / Risk 人工检查
  -> 管理层邮件签字
  -> 提交后靠共享盘、聊天记录和个人记忆解释差异

AI 会放大这个模式的风险。LLM 能让说明书解析更快、差异解释更流畅、叙事更像正式材料；但如果底层事实链没有工程化，AI 只会把不可靠数据包装成更有说服力的文本。

成熟 reporting architecture 必须回答：

---

2. 方法：从 Source-to-Report 到 Evidence-to-Action

BCBS 239 的启发不应停留在原则清单。它应被翻译成产品和架构能力：统一口径、稳定数据架构、准确完整及时的数据、适应监管问询的重切能力、可审查的报告和可追踪的整改。

成熟主线是：

obligation / instruction
  -> report metric contract
  -> source-of-record and as-of snapshot
  -> controlled transformation
  -> reconciled reporting data product
  -> schedule / cell / narrative output
  -> layered attestation
  -> submission package
  -> post-submit issue and correction loop
  -> audit-ready evidence graph

这套架构的贡献有三点。

第一，把监管说明书变成 versioned obligation inventory，而不是 PDF 附件。每个 schedule、line item、cell 和内部解释都能追踪 instruction version、owner、适用范围、解释记录和变更影响。

第二，把报表指标变成 report metric contract，而不是复用 BI 指标。报送指标必须说明业务含义、粒度、来源优先级、冻结时间、转换规则、对账规则、质量阈值和签署责任。

第三，把签署和提交变成 evidence graph，而不是审批邮件。签署绑定数据版本、控制结果、例外披露和提交包；提交绑定 exact artifact、hash、校验结果和确认编号。

---

3. Reference Architecture 与核心实体

Regulatory instructions / reporting obligations
  Call Report | FR Y-14A/Q/M | internal risk reports | supervisory requests
        |
        v
Obligation and metric contract registry
  schedule item | cell | definition | materiality | scope | owner | effective date
        |
        v
Source-of-record and as-of data layer
  GL | subledger | deposits | loans | cards | treasury | risk engines | model outputs
  legal entity | product | customer | account | collateral | scenario | calendar
        |
        v
Transformation and control plane
  extraction | mapping | classification | aggregation | allocation | adjustment
  DQ rules | edit checks | reconciliations | variance analytics | lineage events
        |
        v
Reporting data products
  Call Report mart | FR Y-14 mart | risk aggregation mart | management reporting mart
        |
        v
Attestation and evidence layer
  owner sign-off | exception disclosure | issue linkage | evidence manifest | audit log
        |
        v
Submission and post-submit lifecycle
  final package | checksum | validation result | submission confirmation | regulator Q&A
  correction / restatement | remediation | control improvement
        |
        v
AI assist layer with hard boundaries
  mapping suggestions | anomaly explanations | narrative drafts | evidence retrieval | QA triage

不可压缩的原则：

No reported number without metric contract.
No metric contract without owner and lineage.
No lineage without transformation version.
No transformation without control evidence.
No attestation without exceptions and issue disclosure.
No AI-generated narrative without grounded source facts and human approval.
No submission without immutable package manifest.

核心实体包括 reporting obligation、report metric contract、reporting period、source dataset、transformation rule、reconciliation rule、manual adjustment、report cell、attestation、submission package、issue/correction 和 AI assist event。每个实体都应有 owner、version、scope、evidence reference 和 retention/access 属性，避免报送事实散落在 SQL、Excel、邮件和个人记忆中。

---

4. Report Metric Contract：报送口径的产品契约

报表指标不是普通 dashboard metric。它直接连接监管说明、财务/风险事实、提交证据和签署责任。

示例：

metric_id: RPT-CREDITCARD-UTILIZED-BALANCE
report_mapping: FR Y-14M credit card portfolio schedule
grain: account x legal_entity x product x reporting_period
time_basis: month-end as-of, source freeze at T+2 18:00 CST
source_priority: card servicing ledger, reconciled to GL control account
transformation: exclude charged-off accounts after charge-off effective date; include posted purchases, fees and interest per approved mapping
reconciliation: subledger-to-GL tolerance 0.05% or USD 50k, lower of absolute/materiality rule
attestation: card data owner, finance reporting owner, regulatory reporting owner
AI_boundary: AI may draft variance explanation using approved recon facts; AI cannot change mapping or approve break

Contract 的价值不在文档漂亮，而在于驱动 lineage、DQ、对账、签署、变更影响分析和 AI 边界。

---

5. Lineage、Transformation Controls 与 Reconciliation

Lineage 应按风险和重要性分层，而不是用一个泛化图谱覆盖所有场景。

Lineage 必须能回答 cell 为什么是这个值、来源数据何时冻结、哪些记录贡献了值、哪些控制通过或失败、谁批准了例外、提交的是哪个版本、提交后问题如何处理。

Transformation controls 让每条转换规则都可理解、可测试、可变更、可签署。

Reconciliation 是 reporting data product 的核心能力，而不是最后一道人工检查。

Break record 至少包含 break_id、impacted metric/schedule/period、amount/count、tolerance、root cause、owner、decision、approver 和 evidence_ref。Severity 应区分 critical、high、medium、low，防止所有差异都被压成 immaterial。

---

6. Attestation 与 Submission Evidence

签署不是“我看过这个报表”。签署应明确：

I attest to this scope,
for this reporting period,
based on this data version,
with these controls passed,
with these disclosed exceptions,
within this responsibility boundary.

分层签署可以避免一个角色签下自己无法证明的内容。

Attestation packet 应包括 scope、instruction/data/transformation/semantic versions、control results、exceptions、material changes、AI usage disclosure、signer/authority/time 和 evidence links。

提交证据要证明四件事：提交过、提交的是什么、基于什么版本、提交之后如何处理反馈和缺陷。

Evidence vault 要有 immutable versioning、access segregation、searchability、retention alignment 和 hash/timestamp/owner/approval chain integrity。

---

7. Issue, Correction and Restatement Loop

提交后发现问题时，架构必须支持事实快速定位，但是否更正、重报或沟通监管属于授权治理流程。

detection
  -> issue classification
  -> impacted reports / periods / metrics / entities
  -> quantitative and qualitative impact
  -> Legal / Compliance / Regulatory Reporting / Finance / Risk decision
  -> correction or no-correction rationale
  -> resubmission package if required
  -> root cause remediation
  -> control enhancement
  -> closure attestation

Issue taxonomy 应区分 source data defect、mapping defect、transformation defect、manual adjustment error、instruction interpretation change、model/estimate issue、AI narrative issue 和 submission artifact issue。每类 issue 都应能通过 lineage 找到 impacted reports、periods、metrics、data versions 和 submission packages。

Correction decision record 至少包含 issue_id、discovered_by、impacted_scope、materiality facts、decision、approval、evidence 和 preventive action。Preventive action 不应只写“加强复核”，而应落实到 DQ rule、mapping test、parameter approval、EUC control、AI narrative guardrail 或 training update。

---

8. AI Assist Boundaries

AI 在 regulatory reporting 中有价值，但必须定位为 assistant, not accountable reporter。

禁止边界必须写入流程和工具权限：AI 不做法规适用性最终判断，不改变 report metric definition，不直接写入 final report cells，不关闭 reconciliation break，不签署 attestation，不提交监管报表，不生成无来源 narrative，不掩盖 issue 或重写审计痕迹。

Generated narrative controls 应包括 grounding、citation、fact/analysis/judgment separation、human review、prompt/model/retrieval/output versioning、prohibited language 和 sampling QA。关键点是让 AI 解释已经被批准的事实，而不是让 AI 自行发现事实、编排判断和生成监管结论。

---

9. 为什么有效、哪里容易误用

这套架构有效，不是因为它增加了文档，而是因为它把报送不确定性变成可管理对象。

第一，metric contract 让口径不再依赖个人经验。第二，source extraction、record count、checksum、DQ、population reconciliation 和 variance analytics 让数据问题更早暴露。第三，break severity、owner、decision、approver 和 evidence_ref 让例外可治理。第四，分层 attestation 防止高层签署人被迫证明超出职责边界的内容。第五，AI 可以提高检索、聚类、起草和影响分析效率，但不削弱 deterministic controls 和授权责任链。

常见 anti-pattern：

这套架构也有建设边界。不是所有报表都需要 L5 record/evidence lineage；应按报告重要性、监管关注、管理决策影响和历史缺陷分层。否则 evidence architecture 会变成新型行政负担。

---

10. 架构和产品价值

对有金融零售软件经验的人来说，核心价值不是学习报表字段，而是把报送能力看成长期 data product。

Senior management MI 应报告 reporting readiness，而不是泛化项目状态：filing readiness、critical DQ pass rate、late feeds、unreconciled amount、break aging、adjustment count/value、critical metrics lineage coverage、open issues by severity、corrections/resubmissions、AI assist events 和 narrative QA defects。

---

11. 金融零售系统案例：信用卡组合 FR Y-14M 报送

设想一家大型零售银行要改造信用卡月度 loan-level 报送能力。旧流程依赖 card servicing extract、GL 对账表、风险模型输出、Excel 映射和人工 variance commentary。

目标不是“把 Excel 搬到平台”，而是建立信用卡报送 data product。

Card servicing ledger
  -> month-end as-of snapshot with checksum
  -> card reporting semantic layer
  -> metric contracts for utilized balance, credit line, delinquency, charge-off
  -> transformation controls and mapping tests
  -> GL / subledger / population reconciliation
  -> FR Y-14M reporting mart
  -> attestation packet
  -> submission package and issue loop

关键对象包括信用卡账户、客户、产品、额度、余额、delinquency、charge-off、fee、interest、payment、line increase、fraud flag、hardship program、month-end as-of、T+2 data freeze、late arrival policy、FR Y-14M schedule item 和内部风险聚合口径。

AI 可以参与三类工作：从说明书变更中提示受影响 metric contracts；对 reconciliation breaks 聚类，提示 charge-off effective date mapping、late fee reversal timing、closed account inclusion 等根因候选；基于已批准 variance table 和 issue ledger 起草解释。

AI 不能改变信用卡余额、charge-off 或 delinquency 的报送口径，不能直接修正 final report cells 或关闭 break，不能生成未引用 evidence 的监管问询回复。

上线成功的证明不是报表能生成，而是团队能抽取任意 material cell，追到 contributing population、源记录版本、转换规则、对账结果、签署记录、提交包和后续 issue 处理。

---

12. 学习验证

完成本文后，应能用架构对象解释以下问题。

最低可运行能力可以从 top material metric contracts、as-of source snapshots、structured reconciliation breaks、attestation/submission evidence packet 开始。规模化阶段再扩展到 cell/record/evidence lineage、AI-assisted impact analysis、correction workflow 和 readiness MI。

最终判断标准：

Can the team reconstruct a submitted number, its source records, transformation logic,
control results, exceptions, signer, submission artifact and later corrections without
asking the original preparer to remember what happened?

如果答案是否定的，问题不是 AI 不够强，而是 reporting architecture 还没有成为可证明的系统。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。