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

面向对象: CBAP+ Financial Retail PM / Senior BA / Regulatory Reporting Product Lead / Risk Data Architect / Enterprise Architect / Data Governance Lead / Finance-Risk Technology Partner。 核心问题: 金融机构如何把 Call Report、FR Y-14、内部风险报告、BCBS 239 风险数据聚合、报表血缘、转换控制、指标定义、对账、签署、提交证据、问题整改和更正重报做成可追溯、可复算、可审计、可被 AI 辅助但不被 AI 接管的 reporting data architecture? 学习目标: 建立 source-to-report lineage、metric contract、attestation evidence graph、reporting control plane、AI assist boundary、restatement loop 和 senior management reporting readiness 的高级架构心智模型。

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

---

Source Anchors

一句话:

Regulatory reporting architecture is not a report factory. It is a governed source-to-report evidence system where every reported fact has definition, lineage, control, reconciliation, owner, attestation and correction path.

---

1. Thesis: 报送不是填表, 是事实产品化

低成熟度 regulatory reporting 通常长这样:

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

这种模式在 AI 时代会更危险。LLM 可以让 narrative 更快、mapping 更像样、异常解释更流畅, 但如果底层事实链没有工程化, AI 只会把不可靠数据包装成更有说服力的文本。

成熟 reporting data architecture 的目标是:

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

PM / BA / Architect 的高级价值不在于解释每个报表字段, 而在于把监管说明书、业务事实、数据结构、口径控制、责任签署、问题管理和 AI 辅助边界连成一个可运行系统。

---

2. Reporting Data Architecture 心智模型

2.1 从 Source-to-Report 到 Evidence-to-Action

2.2 三个不能混淆的对象

2.3 BCBS 239 到架构语言

---

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.

---

4. Canonical Data Entities

---

5. Report Metric Contract: 报送口径的产品契约

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

示例:

metric_id: RPT-CREDITCARD-UTILIZED-BALANCE
report_mapping: FR Y-14M credit card portfolio schedule, internal regulatory reporting mart
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

---

6. Source-to-Report Lineage

6.1 Lineage 深度分层

6.2 Report Lineage 应能回答的问题

---

7. Transformation Controls

报表转换控制的目标不是让每条规则都复杂, 而是让每条规则都能被理解、测试、变更和签署。

AI 可以帮助发现映射异常、生成测试候选、解释差异模式, 但不能绕过 transformation control。

---

8. Reconciliation Architecture

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

8.1 对账类型

8.2 Break Management

每个 break 必须有:

break_id
impacted_metric / schedule / period
amount / count / percentage
tolerance
root_cause
owner
decision: correct now / disclose exception / monitor / remediate after filing
approver
evidence_ref

---

9. Attestation Architecture

签署不是"我看过这个报表"。签署应明确:

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.

9.1 Layered Attestation

9.2 Attestation Packet

---

10. Submission Evidence

提交证据要能证明"提交过"、"提交的是什么"、"基于什么版本"、"验证结果如何"、"之后发生了什么"。

Submission evidence vault 的设计要求:

• immutable versioning: final package 不被覆盖。
• access segregation: preparer、approver、auditor、viewer 权限分离。
• searchability: 可按 report、period、metric、issue、signer、source system 查找。
• retention alignment: 按内部 records retention 和 legal hold 执行。
• evidence integrity: hash、timestamp、owner、approval chain 可验证。

---

11. 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

11.1 Issue Taxonomy

11.2 Correction Decision Record

---

12. AI Assist Boundaries

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

12.1 Allowed with Controls

12.2 Not Allowed

12.3 Generated Narrative Controls

---

13. Senior Management MI: 只报告 Reporting Readiness

本文不展开通用 board MI。这里的 senior management MI 只服务 regulatory reporting data architecture readiness。

好的 MI 不是"本期已完成报送", 而是:

Which report items are materially reliant on manual workarounds?
Which reconciliations are open and who accepted them?
Which metrics lack required lineage depth?
Which AI-assisted narratives had factual defects?
Which repeat defects need platform investment?

---

14. PM / Architect Implications

高级面试表达:

我不会把 AI regulatory reporting 做成"LLM 帮忙填表"。我会先做 source-to-report data product: obligation inventory、metric contract、as-of snapshot、lineage、DQ、reconciliation、attestation 和 submission evidence。AI 只在 mapping suggestion、anomaly detection、evidence retrieval 和 grounded narrative draft 中辅助, 所有定义、例外、签署、提交和更正判断仍由授权 owner 负责。

---

15. Anti-Patterns

---

16. 面试题准备

Q1: 如何设计一个 AI-assisted regulatory reporting architecture?

30 秒版本: 我会先建设 source-to-report evidence system, 再加 AI assist。核心是 obligation inventory、metric contract、as-of source data、controlled transformation、reconciliation、attestation、submission evidence 和 issue/restatement loop。AI 只能做建议、检测、检索和有来源的 narrative draft, 不能定义口径、改数、关闭差异、签署或提交。

2 分钟版本: 金融监管报送的风险不在于表格生成慢, 而在于数字能否被证明。架构上我会把每个 report item 当成一个数据产品: 有说明书版本、业务定义、粒度、source-of-record、转换规则、对账规则、质量 SLO、owner 和签署范围。数据层要有 as-of snapshot, 因为报送关心某个报告期和冻结点的事实。控制层要包括 source-to-source、source-to-report、cross-schedule、period-over-period 和 narrative-to-fact reconciliation。签署层要分 source、transformation、control、business、reg reporting 和 executive。AI 放在辅助层, 例如异常聚类、证据检索、说明书影响分析、variance narrative 草稿, 但每个输出必须有来源、版本、reviewer 和审批记录。

Q2: BCBS 239 对产品和架构最重要的启发是什么?

30 秒版本: BCBS 239 的本质是让风险数据聚合和风险报告具备 governance、architecture、accuracy、completeness、timeliness 和 adaptability。对 PM/Architect 来说, 它要求我们把报表从人工汇总升级为可追溯的数据产品和控制系统。

2 分钟版本: 我会把 BCBS 239 翻译成工程要求: 数据架构要有统一 identifier、taxonomy 和 metadata; 关键指标要有 owner 和 contract; 数据要能自动化聚合并与源系统和会计数据对账; 报告要在正常和压力情境下按时生成; 对监管临时问询要能按 legal entity、产品、行业、地区和风险维度快速重切。最容易被低估的是 adaptability: 它不是临时 SQL 能跑出来, 而是语义层、血缘、质量和权限已经产品化。

Q3: AI 生成 regulatory reporting narrative 的边界是什么?

30 秒版本: AI 可以基于 approved facts 起草 variance explanation, 但不能生成没有来源的解释、法律/合规结论、责任归因、提交承诺或更正判断。所有 narrative 都要有 fact grounding、citation、人审、版本和 QA。

2 分钟版本: 我会把 narrative 当成派生控制对象。输入只允许来自 approved variance table、reconciliation result、issue ledger 和 owner comment, 不让模型自由读取原始大表后发挥。输出要区分事实、分析、判断和需 Legal/Compliance 确认的问题。关键句子必须引用 metric、period、source 或 issue reference。高影响报表和监管问询材料必须人工审批, 并保留 prompt、model、retrieval corpus、AI output、human edit 和 approval log。

Q4: 发现提交后数据错误, 架构应该如何支持更正或重报?

30 秒版本: 系统应快速做 impact assessment: 哪些报告、期间、line item、legal entity、records 和 attestations 受影响。是否更正或重报由授权 governance 判断, 架构负责提供复算、证据、版本、审批和整改闭环。

2 分钟版本: 我会先冻结 evidence, 创建 issue_id, 通过 lineage 找到 impacted reports、periods、metrics、data versions 和 submission packages。然后量化影响, 区分 source defect、mapping defect、transformation defect、manual adjustment error、instruction interpretation 或 model estimate issue。Reg Reporting、Finance、Risk、Legal/Compliance 根据事实决定是否 correction、resubmission、disclosure 或 monitor。技术侧生成 revised dataset、reconciliation、validation、attestation 和 package manifest。最后把根因转成 preventive action, 例如新增 DQ rule、mapping test、parameter approval 或 AI narrative guardrail。

Q5: 如何避免 AI 让报送流程看起来更快但实际更不可靠?

30 秒版本: 先把 deterministic controls 建好, 再接 AI。AI 输出必须低权限、可追溯、可拒绝、可抽检。所有关键动作仍由系统控制和人类 owner 完成。

2 分钟版本: 我会设置四类 guardrail。第一, data guardrail: AI 只能访问 approved catalog、metric contracts 和 evidence vault, 不直接改 reporting mart。第二, workflow guardrail: AI 只能生成 suggestion 或 draft, final action 需要 owner review。第三, evidence guardrail: 每次 AI assist 都有 model、prompt、retrieved source、output、reviewer 和 decision。第四, quality guardrail: 抽检 AI narrative factuality、reconciliation break clustering accuracy 和 unauthorized use detection。这样 AI 提升分析效率, 但不削弱报送责任链。

---

17. 最小可落地能力集

最终判断标准:

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 还没有成为可证明的系统。