目录
AI Regulatory Reporting / Risk Data Aggregation / Attestation Playbook
定位: 面向 AI PM / Senior BA / Regulatory Reporting Product Lead / Risk Data Architect / Enterprise Architect / Data Governance / Finance-Risk Tech / AI Governance 的高级落地手册。
目标: 把 regulatory reporting、risk data aggregation、BCBS 239、Call Report / FR Y-14 style reporting、report lineage、transformation controls、metric definitions、reconciliations、attestation、submission evidence、issue management、correction/restatement、data quality、AI assist boundaries 和 generated narrative controls 连接成可上线、可审计、可运营的 reporting data product。
核心观点: 报送系统的产品不是"报表", 而是被定义、被控制、被签署、被提交、被追溯、可纠错的 reportable fact。
边界说明: 本手册不是法律意见、合规结论、审计结论、财务确认、监管报送建议或模型验证报告。exact applicability、报告义务、解释口径、提交时限、更正/重报判断和对外沟通由 Legal / Compliance / Regulatory Affairs / Finance / Risk / Internal Audit / authorized management 负责。本文只把官方锚点和架构实践转成产品、BA 和架构可执行 artifact。访问日期: 2026-06-30。
1. Source Anchors
2. Capability Map
Regulatory instructions and obligations
-> reporting product catalog
-> metric contracts and semantic layer
-> source-of-record and as-of snapshots
-> transformation and data quality controls
-> reconciliation and variance management
-> report build and generated narrative controls
-> layered attestation
-> immutable submission evidence
-> issue / correction / restatement loop
-> management readiness MI
Capability Why it matters Core artifacts Obligation management 报表说明、schedule、line item、适用范围和版本必须可管理 obligation register、instruction impact memo Metric definition 同一术语在风险、财务、运营和监管报送中可能不同 report metric contract、semantic layer Source and as-of control 报送关心报告期事实, 不是当前数据库状态 source-of-record register、freeze snapshot Transformation control 抽取、映射、分类、聚合、分摊、调整都要可测试 transformation spec、rule registry、test suite Data quality 报送数据质量要覆盖准确、完整、及时、一致、有效 DQ SLO matrix、exception workflow Reconciliation 对账证明数字可依赖, 不是事后解释 recon rule card、break register Attestation 签署必须绑定 scope、版本、控制结果和例外 attestation packet、sign-off ledger Submission evidence 提交物必须 immutable、可查、可复盘 package manifest、checksum、portal confirmation Issue and correction 提交前后问题必须进入同一闭环 issue ledger、impact assessment、CAPA AI assist governance AI 提效但不能接管责任链 AI use register、prompt/output log、human approval
3. Operating Model
3.1 Reporting Product Line
把 regulatory reporting 当成产品线管理, 而不是每季度临时项目。
Product layer Owner Backlog examples Reporting obligation product Regulatory Reporting / Compliance new instruction intake, schedule change, applicability workflow Metric and semantic product Finance/Risk Data Product Owner metric contract, taxonomy, hierarchy, line item mapping Source data product Business Data Owner / Data Governance source certification, DQ SLO, late data policy Transformation product Data Engineering / Reporting Technology pipeline control, code release, parameter governance Reconciliation product Finance/Risk Control Owner recon rules, tolerance, break workflow, variance analytics Attestation product Regulatory Reporting Owner sign-off scopes, packet templates, escalation Evidence product Architecture / Records / Audit Liaison evidence vault, retention, access, audit extract AI assist product AI Governance / Product / Model Risk approved AI use cases, prompt registry, narrative QA
3.2 RACI
Activity PM Senior BA Architect Data Owner Reg Reporting Finance/Risk Legal/Compliance Internal Audit Obligation intake C R C C A/R C A/R I Metric contract A/R R C C A/R A/R C I Source certification C C C A/R C C I I Transformation design C R A/R C C C I I Control design C R A/R C A/R A/R C C Reconciliation disposition I C C C A/R A/R C I AI assist approval A/R R C C C C C I Attestation I C C A/R by scope A/R A/R C I Submission I C C I A/R C C I Issue / correction decision C R C C A/R A/R A/R C Control effectiveness review I C C C C C I A/R
Legend: A = accountable, R = responsible, C = consulted, I = informed.
4. Reference Architecture
Instruction and obligation registry
- forms, schedules, line items, instructions, Q&A, internal interpretations
|
v
Reporting semantic layer
- metric contracts, data dictionary, legal entity/product/customer/account taxonomy
|
v
As-of reporting data platform
- source extracts, freeze snapshots, record counts, checksums, late-arrival handling
|
v
Transformation and control plane
- mapping, classification, aggregation, allocation, model/estimate feeds, manual adjustments
- DQ, edit checks, reconciliations, variance, lineage, EUC controls
|
v
Report build workbench
- schedule population, validation, narrative draft, exception disclosure, reviewer workflow
|
v
Attestation workflow
- source owner, transformation owner, control owner, business/finance/risk owner, executive signer
|
v
Submission evidence vault
- final files, hashes, validation results, approvals, portal confirmation, regulator Q&A
|
v
Issue and remediation system
- breaks, defects, correction assessment, resubmission evidence, CAPA, control enhancement
4.1 Non-Functional Requirements
NFR Reporting-specific requirement Traceability material report items trace to metric contract, source dataset, transformation, controls, attestation and submission package Reproducibility selected report period can be rebuilt from frozen inputs and versioned logic Integrity final package cannot be overwritten; evidence has hash/timestamp/owner Timeliness close calendar, data freshness and escalation aligned to filing deadline Resilience critical reporting process supports contingency, rerun and manual fallback with controls Access control source data, report drafts, evidence, AI prompts and submission packages have role-based access Segregation of duties preparer, reviewer, approver, submitter and evidence admin responsibilities separated where required by policy Observability pipeline status, DQ, recon, attestation, issue aging and AI assist events visible Retention report evidence retained according to records policy and legal hold requirements
5. Artifact Templates
5.1 Obligation Register
Field Description obligation_id Stable ID, e.g. OBL-CALL-031-RC-C-001 regulator / agency FFIEC, Federal Reserve, OCC-related supervisory request, internal committee report_family Call Report, FR Y-14A/Q/M, internal risk report form / schedule / item Exact form, schedule, line item or cell reference instruction_version Official instruction version and effective date applicability owner Legal/Compliance/Reg Reporting owner for applicability confirmation reporting frequency monthly, quarterly, annual, event-driven legal entity / consolidation scope entities and consolidation basis under confirmed scope data owner owner of source facts metric_id linked report metric contract control_ids linked DQ, transformation, reconciliation, attestation controls change history instruction change, interpretation change, implementation impact
5.2 Report Metric Contract
Field Required content metric_id and name Stable name used across reports report mapping form, schedule, line item, cell, internal MI mapping definition approved business and reporting definition numerator / denominator exact inclusion and exclusion rules grain and dimensions account, loan, customer, legal entity, product, scenario, period time basis as-of date, event time, posting time, available time, freeze time source of record authoritative source and fallback hierarchy transformation logic mappings, classifications, aggregations, allocations, rounding data quality rules completeness, validity, freshness, consistency, uniqueness reconciliation source-to-source, source-to-report, cross-schedule, period variance materiality and tolerance threshold, rationale, approval owner attestation owner source, report, finance/risk and executive roles AI usage allowed assist use, prohibited use, review requirement versioning effective date, approver, prior version, change impact
Field Required content rule_id Stable transformation ID linked metric affected metric IDs and schedule items input datasets dataset IDs, source versions, freeze times output datasets reporting mart table or file logic description business-readable rule code / parameter version repository, release, mapping table, calendar, threshold test cases normal, edge, missing data, late data, negative/zero, currency, consolidation validation owner preparer, reviewer, approver change trigger instruction change, source change, defect, optimization rollback / rerun how to rebuild and restore prior version
5.4 Reconciliation Rule Card
Field Required content recon_id Stable ID recon type source-to-source, source-to-report, cross-schedule, cross-report, period-over-period compared objects datasets, metrics, schedules, periods tolerance absolute, percentage, materiality, zero tolerance frequency daily during close, monthly, quarterly, pre-submit break categories timing, mapping, source defect, transformation, manual adjustment, instruction interpretation owner and reviewer accountable roles escalation threshold, SLA, forum evidence report, screenshot-free data extract, ticket, approval
5.5 Attestation Packet
Section Minimum content Scope report, period, legal entity, schedules, metrics Data version source snapshots, record counts, checksums, freeze time Controls DQ, edit checks, recon, variance, manual adjustment status Open exceptions breaks, issues, late data, EUC dependency, AI narrative defects Changes instruction, mapping, model/estimate, source, transformation, threshold AI assist use cases, prompts/models, outputs, reviewers, approvals Signer statement signer role, responsibility boundary, data version, exception acknowledgement Evidence references immutable links to logs, reports, tickets, package manifest
5.6 Submission Manifest
Field Required content package_id Stable package ID report / period form, schedules, period, legal entity scope final files filenames, formats, row counts, cell counts checksums hash for each final artifact validation results internal validation and portal validation outputs approvals attestation IDs and submission authorization submitter authorized submitter and timestamp confirmation portal confirmation ID, receipt, warnings/errors post-submit notes regulator questions, corrections, issue links
6. End-to-End Workflow
6.1 Obligation Intake and Impact Analysis
official instruction / form update / regulator Q&A
-> obligation register update
-> applicability and interpretation routed to Legal/Compliance/Reg Reporting
-> impacted metrics, sources, transformations, controls identified
-> implementation stories created
-> approval and effective date recorded
Control questions:
Which reports, schedules and periods are affected?
Which metric contracts require definition changes?
Which source systems and mappings are impacted?
Is historical restatement or comparative period adjustment in scope?
Which attestations and evidence templates need to change?
Does AI assist prompt/retrieval corpus need updating?
6.2 Data Sourcing and Freeze
Step Control Extract source data record count, checksum, cutoff, source owner confirmation Freeze as-of snapshot immutable version, reporting period, available time Validate source quality completeness, validity, uniqueness, freshness, source reconciliation Handle late data late-arrival policy, impact assessment, owner approval Certify source source data attestation packet
Step Control Apply mappings mapping table version, unmapped item report Classify products/entities taxonomy version, exception queue Aggregate and allocate rule version, sample replay, rounding validation Apply model/estimate output model version, parameter version, model-risk evidence where applicable Apply manual adjustments reason code, evidence, dual approval, roll-forward/reversal Populate report schedules schedule/cell validation, precision, edit checks
6.4 Validation and Reconciliation
Validation Examples DQ validation missing critical field, invalid code, stale feed, duplicate account Edit checks allowed values, mathematical relationships, row/column totals Source reconciliation subledger to GL, servicing to GL, risk engine to source exposure Cross-schedule reconciliation schedule totals and shared line items Variance analysis period-over-period, budget/stress/scenario, expected trend Narrative-to-fact check explanation cites approved facts and issue references
6.5 Attestation and Submission
control results complete
-> exceptions disclosed
-> source / transformation / control / business attestations captured
-> final package generated
-> package manifest and checksum created
-> authorized submission
-> confirmation archived
Stop rules:
critical reconciliation break open.
required source attestation missing.
material metric lacks approved definition.
final package checksum missing.
AI-generated narrative not reviewed.
issue impact not dispositioned.
6.6 Post-Submit Monitoring
Trigger Action Regulator validation error issue ticket, scope assessment, corrected package if authorized Regulator question evidence retrieval, source fact package, approved response workflow Internal defect discovery issue classification, impact analysis, correction decision Audit finding control remediation plan, owner, due date, closure evidence Repeat break root cause review, platform backlog, management MI
7. Control Library
Control ID Control objective Control activity Evidence RPT-001 报送义务版本受控 official forms/instructions 进入 obligation register, 记录版本和 effective date obligation change log RPT-002 适用性判断权责清晰 applicability 由 Legal/Compliance/Reg Reporting 确认, PM/BA 只提供事实底稿 applicability memo RPT-003 指标定义唯一 material line items 有 approved metric contract metric contract approval RPT-004 来源数据权威 source-of-record register 说明系统优先级和 owner source register RPT-005 as-of 版本冻结 每期 source snapshots 有 freeze time、record count、checksum snapshot manifest RPT-006 数据质量可度量 critical fields 有 DQ SLO 和 failure workflow DQ report RPT-007 转换逻辑可测试 mappings、classifications、aggregations 有 rule version and tests test result, rule registry RPT-008 参数变更受控 thresholds、mapping tables、calendars、scenarios 走审批 parameter change log RPT-009 模型/估计输出受控 report-used model outputs 连接 model version、input、validation/monitoring evidence where applicable model output evidence RPT-010 EUC 风险受控 reporting spreadsheets/databases inventory, access, version, review EUC register RPT-011 对账覆盖关键风险 material metrics 有 source-to-report and cross-check rules reconciliation report RPT-012 break disposition 可追溯 every break has category, owner, decision, approver, evidence break ticket RPT-013 manual adjustment 双控 adjustment requires reason, evidence, preparer, approver adjustment register RPT-014 narrative 有事实支撑 generated or manual narrative references approved facts narrative QA log RPT-015 AI assist 受限 AI usage registered, outputs reviewed, no direct write to report cells AI assist log RPT-016 attestation 绑定版本 sign-off references data version, controls, exceptions attestation packet RPT-017 final package 不可覆盖 final files stored with checksum and manifest submission manifest RPT-018 regulator Q&A 有证据链 responses cite source facts and approval workflow Q&A package RPT-019 correction decision 可审计 issue impact and correction/restatement decision recorded by authorized owners correction decision record RPT-020 CAPA 关闭有证明 root cause remediation tested and closure approved CAPA closure evidence
8. Decision Tables
8.1 Lineage Depth by Materiality
Materiality / risk Minimum lineage Additional requirement Low internal report dataset-level owner and definition required Standard regulatory line item metric-to-source dataset DQ and reconciliation evidence Material regulatory line item column-level and transformation-level attestation and sample replay Loan/account-level schedule record-level for sample and population freeze snapshot and source record version Regulator question / correction evidence lineage submission package, issue, approval, response history
8.2 AI Assist Approval
AI activity Default decision Required controls Search approved instructions and evidence Allow access control, retrieval log Suggest line item mapping Allow with review source citation, mapping owner approval Generate DQ rule candidates Allow with review engineer/control owner approval before deployment Cluster reconciliation breaks Allow with review no auto-close, precision monitoring Draft variance narrative Allow with strict controls grounded facts, citation, human approval Rewrite regulatory response Restrict Legal/Compliance/Reg Reporting workflow Change metric definition Not allowed owner/governance only Write final report cell Not allowed controlled reporting data product only Sign attestation Not allowed human authorized signer only Submit report Not allowed authorized submission workflow only
8.3 Correction / Restatement Severity
Severity Signal Governance action Critical material submitted error, key schedule impacted, regulator validation failure, executive attestation affected immediate escalation, evidence freeze, authorized correction decision High tolerance breach or repeated defect with potential filing impact issue committee review, remediation plan, possible correction assessment Medium contained data/control defect below tolerance but recurring RCA, backlog, management MI Low documentation, taxonomy, minor control improvement normal change cycle
8.4 Manual Adjustment Approval
Adjustment type Approval mechanical timing adjustment below tolerance preparer + reviewer business classification adjustment business owner + reporting owner material amount adjustment finance/risk owner + regulatory reporting owner post-freeze adjustment reporting owner + control owner + documented exception adjustment affecting submitted period correction governance workflow
9. Data Quality and Reconciliation Checklist
9.1 Critical DQ Rules
Dimension Example checks Completeness required accounts/loans/transactions present; no missing legal entity/product/risk code Accuracy source balance matches control account; numeric precision and sign convention correct Validity allowed code values, date ranges, currency, product taxonomy Consistency customer/account/legal entity IDs consistent across systems Freshness feed arrives before freeze; stale data flagged Uniqueness no duplicate contributing records unless explicitly allowed Population included/excluded population has reason codes Referential integrity foreign keys to customer, product, legal entity, scenario and source records valid Distribution material shifts in balances/counts/rates flagged Access correctness restricted fields not exposed to unauthorized report users or AI retrieval
9.2 Reconciliation Pack
Pack element Required content Recon summary pass/fail, total breaks, amount/count, severity Break detail break_id, metric, source, amount, tolerance, owner Root cause timing, source defect, mapping, transformation, manual adjustment, instruction interpretation Disposition corrected, accepted with rationale, monitored, escalated Approval approver role, date, evidence Trend repeat breaks, aging, concentration by source/system/metric MI impact whether management/readiness report should show amber/red
10. AI-Generated Narrative Control
Generated narrative appears in variance explanation, management commentary, regulator Q&A draft, issue summary and attestation exception summary. It must be controlled like any other report artifact.
10.1 Narrative Contract
narrative_contract:
purpose: variance_explanation | issue_summary | evidence_summary | q_and_a_draft
allowed_sources:
- approved_metric_contract
- reconciliation_result
- variance_table
- issue_ledger
- owner_comment
required_output:
- factual_summary
- source_references
- uncertainty_or_exception
- reviewer_action
prohibited_output:
- legal_conclusion
- regulatory_commitment
- unsupported_root_cause
- blame_assignment
- invented_amount_or_trend
10.2 Narrative QA
QA test Pass condition Fact grounding all material claims trace to approved facts Number consistency values and direction agree with report data Source precision references point to metric/period/break/evidence ID Scope discipline narrative does not explain outside approved period/report Legal boundary no applicability or compliance conclusion unless approved owner inserted it Human edit record AI output, edits and approval retained Repeat defect monitoring factual defects, unsupported claims and tone issues tracked
11. Issue Management and CAPA
11.1 Issue Workflow
detection
-> triage severity
-> freeze relevant evidence
-> identify impacted reports / periods / metrics / entities
-> quantify impact
-> classify root cause
-> decide disposition through authorized governance
-> implement correction or remediation
-> retest controls
-> close with evidence
11.2 Root Cause Taxonomy
Root cause Example Preventive control Source data late booking, source defect, missing field source DQ SLO, feed certification Mapping product/legal entity/counterparty category wrong mapping approval and unmapped report Transformation SQL/rule/allocation bug code review, regression test, sample replay Metric definition ambiguous inclusion/exclusion metric contract governance Reconciliation tolerance too loose or break not escalated tolerance review, break aging MI Manual process spreadsheet overwrite, undocumented adjustment EUC controls, dual approval Model/estimate model output stale, parameter not approved model output evidence, parameter governance AI assist generated narrative unsupported or wrong source narrative contract, QA sampling Governance owner unclear, attestation missing RACI, mandatory sign-off gate
11.3 CAPA Closure Criteria
Criterion Required evidence Root cause verified RCA record and supporting facts Impact assessed impacted reports, periods, metrics, amounts/counts Fix implemented code/mapping/contract/control change Regression passed rerun result and comparison Control strengthened new or changed control ID Owner attested accountable owner closure sign-off Management informed MI update for high/critical issues
12. Senior Management Reporting Readiness MI
This MI is about reporting data architecture health, not generic board AI oversight.
Dashboard tile RAG signal Filing calendar status due dates, build status, submission readiness Required attestation coverage completed, pending, overdue by role Critical DQ status pass rate, failed critical rules, late feeds Reconciliation status open breaks, material breaks, aging Manual adjustment profile count/value, late adjustments, approval exceptions Lineage coverage critical metrics with required lineage depth Issue and correction status open critical/high issues, post-submit defects, CAPA aging AI assist usage approved use events, narrative QA defects, unauthorized attempts Repeat root causes top systems, mappings, controls causing breaks
Senior management question set:
Which filings are blocked by data, control, attestation or submission evidence?
Which material metrics rely on manual workarounds or EUCs?
Which unresolved breaks are being accepted, by whom, and why?
Which source systems repeatedly produce reporting defects?
Which AI-generated narratives failed fact grounding?
Which remediation items require funding or architecture change?
13. Implementation Guardrails
Guardrail Practical rule Contract before automation Do not automate a report item until metric contract and owner are defined Semantic layer before AI AI reads approved metric definitions and facts, not random tables As-of before analytics Reporting period snapshots must be frozen and reproducible Controls in pipeline DQ, edit checks and reconciliations run before report build Evidence by design Logs, versions, approvals and checksums are generated during workflow No silent override Manual adjustments, threshold changes and mapping changes require reason and approval Dual use separation BI dashboards, management MI and regulatory filings can share data products but not uncontrolled definitions AI low privilege AI cannot write report cells, close breaks, approve exceptions, attest or submit Human accountability every material output has named owner and signer Correction-ready lineage and evidence must support post-submit impact analysis
14. 30-60-90 Day Roadmap
Days 1-30: Stabilize Facts
Workstream Outcome Inventory top reports Call Report / FR Y-14 / internal risk reports scoped by materiality Identify top material metrics top schedules/line items and owner map Build metric contract template definition, source, transformation, recon, attestation fields Map source-of-record GL, subledger, servicing, risk engines, model outputs Create issue register breaks, defects, manual adjustments, recurring root causes
Days 31-60: Engineer Controls
Workstream Outcome Build as-of snapshot process freeze, checksum, record count, late data policy Implement critical DQ rules completeness, validity, freshness, consistency Implement reconciliation pack source-to-report and period variance for material metrics Structure attestation packet scope, version, controls, exceptions, sign-off Define AI assist policy approved use cases, prohibited actions, narrative QA
Days 61-90: Prove and Scale
Workstream Outcome Add lineage coverage dataset/column lineage for material metrics Create submission evidence vault manifest, checksum, validation, confirmation Run mock regulator question reconstruct number and evidence within SLA Launch readiness MI filing status, DQ, recon, attestation, issue, AI usage Close repeat root causes CAPA with control enhancement and management owner
15. Interview-Ready Answers
Q1: 你如何把 BCBS 239 落到 AI regulatory reporting architecture?
30 秒版本 :
我会把 BCBS 239 转成可执行架构能力: governance 变成 RACI 和 attestation, data architecture 变成 source-of-record、taxonomy、lineage 和 as-of snapshots, accuracy/completeness/timeliness/adaptability 变成 DQ、reconciliation、close calendar 和 ad hoc query capability。AI 只能在这些控制之上辅助。
2 分钟版本 :
BCBS 239 不是文档清单, 它要求银行能可靠、完整、及时、灵活地聚合和报告风险数据。产品上我会先建立 obligation inventory 和 report metric contracts, 确保每个 line item 有定义、source、owner、transformation、control 和 attestation。架构上建立 as-of reporting data layer, 支持报告期冻结、record count、checksum 和复算。控制上把 DQ、edit check、source-to-report reconciliation、cross-schedule reconciliation 和 variance analysis 前置到 pipeline。AI 放在 assist layer, 例如 mapping suggestion、break clustering 和 narrative draft, 但不能改变定义或签署事实。
Q2: Call Report / FR Y-14 style reporting 与普通管理报表最大的区别是什么?
30 秒版本 :
监管报送不是 dashboard, 它需要说明书版本、口径解释、法律实体/合并范围、as-of 事实、严格对账、签署、提交证据和更正路径。普通管理报表可以容忍探索性分析, regulatory reporting 必须可证明。
2 分钟版本 :
普通管理报表常常以决策速度和趋势洞察为中心, 但 Call Report / FR Y-14 style reporting 以 reportable facts 和 submission evidence 为中心。每个 schedule item 都要映射到官方说明书版本和内部 metric contract。数据要区分 event time、posting time、available time 和 freeze time。模型或估计输出如果进入报送, 要连接模型版本、参数、输入和控制证据。提交后还要能回答监管问题, 所以 final files、checksums、validation、attestations、portal confirmation 和 Q&A 都要进 evidence vault。
Q3: 如何控制 AI 生成 variance narrative?
30 秒版本 :
把 narrative 当成受控派生产物。AI 只能基于 approved metrics、reconciliation results、variance tables、issue ledger 和 owner comments 起草, 每个关键解释要有 source reference, 人审后才能进入报表或问询材料。
2 分钟版本 :
我会建立 narrative contract, 明确 allowed sources、required output 和 prohibited output。禁止 AI 写法律结论、监管承诺、责任归因或没有来源的原因。系统记录 prompt、model、retrieved sources、draft、human edits 和 approval。QA 会检查 fact grounding、number consistency、source precision、scope discipline 和 legal boundary。高风险 narrative 必须由 Reg Reporting、Finance/Risk 或 Legal/Compliance 授权角色审核。
Q4: 发现报送后错误, 产品和架构应该怎样响应?
30 秒版本 :
先冻结证据, 通过 lineage 做 impact assessment, 找到受影响报告、期间、指标、源数据和提交包。是否更正或重报由授权治理决定, 系统负责复算、证据、审批、重新提交和 CAPA。
2 分钟版本 :
我会创建 issue_id, 用 evidence lineage 连接 source snapshot、transformation version、report cell、attestation 和 submission manifest。然后量化影响金额、数量、期间和 legal entity, 识别 root cause: source、mapping、transformation、manual adjustment、model output、AI narrative 或 governance。Reg Reporting、Finance/Risk、Legal/Compliance 判断 correction path。架构侧生成 revised data、recon result、attestation update、submission package 和 closure evidence。最后把根因转成 control enhancement, 防止同类问题重复。
Q5: 为什么 attestation architecture 是产品问题?
30 秒版本 :
因为签署不是最后一步签名, 而是对数据版本、控制结果、例外和责任范围的产品化承诺。如果没有结构化 attestation packet, 签署人无法知道自己确认了什么。
2 分钟版本 :
我会把 attestation 分层: source owner 确认源数据和冻结版本, transformation owner 确认规则和运行, control owner 确认 DQ/recon/edit checks, business/finance/risk owner 确认业务解释和例外, regulatory reporting owner 确认 package readiness, executive signer 做授权批准。每个签署都引用同一个 data version、control results、exceptions 和 evidence links。这样审计或监管问询时, 不需要靠口头回忆解释当时为什么可以提交。
16. Quality Bar
一个 reporting data architecture 达标的最低标准:
For any material submitted number,
the team can reconstruct:
obligation and instruction version,
metric definition,
source records or source population,
transformation logic and version,
data quality and reconciliation results,
manual adjustments and exceptions,
attestation trail,
submitted package and confirmation,
post-submit issues and correction decisions.
如果这个链条断了, AI 不应被用来"补解释"。正确的产品动作是修复 metric contract、lineage、control、attestation 或 evidence architecture。