TOPIC HOME
报送流程与监管反馈图专题主页 / 报送流程与监管反馈图
报表生成不是终点,而是正式报送流程的起点。报表从内部生成到外部提交,需要经过复核、审批、报送、回执、监管校验、反馈处理、补报重报和版本留痕。
RELATED SUBMAPS
相关专题子图
可在主图和其他专题子图之间切换,继续查看相邻业务链路。
监管报表不是从一个系统里直接导出来的,而是从交易、持仓、估值、会计、风险、托管、清算、对账、产品主数据、客户或交易对手数据、市场数据和参考数据中抽取信息,再按照监管、财务和管理口径重新组织出来的结果。
进入子图 →同一批业务数据,为什么在不同监管报表、风险报表、财务报表和管理报表里会呈现成不同样子?
进入子图 →业务系统里的字段不能直接等于报表字段。监管报表需要把源字段、标准字段、产品分类、交易对手分类、币种、期限、金额、估值和风险数据,按照特定口径加工成报表指标,最后形成报表结果。
进入子图 →报表生成以后,并不代表可以直接提交。数据校验负责确认报表数据是否完整、格式是否正确、逻辑是否成立、跨表是否一致、期初期末是否连续,并通过业务对账、会计对账、风险对账和监管校验发现差异。
进入子图 →报表生成不是终点,而是正式报送流程的起点。报表从内部生成到外部提交,需要经过复核、审批、报送、回执、监管校验、反馈处理、补报重报和版本留痕。
进入子图 →报表差异不是一个终点,而是一个追溯入口。它需要沿着字段映射、口径定义、主数据、源系统、估值数据、会计数据、风险数据、对账结果和数据血缘,一步步定位原因,再形成修正方案,必要时重跑数据、重出报表,并保留审计和历史留痕。
进入子图 →数据治理图回答的是:一张报表里的字段、指标、口径、源系统、变更、审批、版本、异常和监管问询,到底由谁定义、谁维护、谁审批、谁解释、谁负责追溯。
进入子图 →完整地图更适合横屏 / 平板 / 电脑查看
KEY RELATIONS
关键关系线
进入内部复核
报表生成后进入业务、数据和口径复核。
进入审批
内部复核通过后进入审批流程。
冻结版本
审批通过后冻结本次报送版本。
选择报送渠道
报送文件通过指定渠道发送。
更新提交状态
报送渠道返回发送、处理中或失败等提交状态。
接收回执
提交状态更新后接收外部系统回执。
进入监管校验
接收回执后进入监管端规则校验。
退回修改
监管校验不通过时形成退回修改要求。
触发补报
缺失范围或新增数据可触发补报。
触发重报
原报送版本失效或重大修正可触发重报。
沉淀历史留痕
报送结果连同文件、回执和处理记录进入历史留痕。
形成报送结果
接收回执是 Submission 最终报送结果的重要外部依据。
子节点目录
当前筛选显示 18 个节点、16 条关系线。
🔒 报表生成
module · Level 1
报表生成承接计算结果并形成报送或内部输出。
🔒 报送提交
module · Level 1
报送提交说明报表如何正式提交。
🔒 监管反馈
module · Level 1
监管反馈解释接收回执、校验、退回、补报和重报。
🔒 报表生成
process · Level 2
报表生成是指系统根据已经采集、标准化、映射、校验和计算后的数据,形成某一张或某一组报表结果。
🔒 内部复核
process · Level 2
内部复核是在报表正式审批和报送前,对报表结果进行内部检查和确认。
🔒 审批流程
process · Level 2
审批流程是报表正式报送前的责任确认环节。它把报表结果从“已复核”推进到“可以正式提交”。
🔒 报送文件
system · Level 2
报送文件是把内部报表结果按照报送渠道或接收方要求转换成可以提交的文件、数据包或格式化数据。
🔒 报送渠道
system · Level 2
报送渠道是报表文件或数据提交给接收方的路径。它可以是系统接口、平台上传、专线、文件传输、API、门户系统或其他指定方式。
🔒 提交状态
concept · Level 2
提交状态记录报表文件提交后的系统状态。它帮助机构判断报送是否已经发出、是否正在处理中、是否失败、是否被接收或是否需要重试。
🔒 接收回执
concept · Level 2
接收回执是报送文件提交后,接收方或渠道返回的接收确认或处理反馈。
🔒 监管校验
process · Level 2
监管校验是接收方或监管侧对报送数据进行格式、逻辑、勾稽、跨表、口径或业务规则检查的过程。
🔒 退回修改
process · Level 2
退回修改是指报表在复核、审批、监管校验或监管反馈后,被要求回到前序环节进行修正。
🔒 补报
process · Level 2
补报是指在原有报送之外,补充报送遗漏、缺失、新增或需要额外提交的数据。
🔒 重报
process · Level 2
重报是指对已经报送过的报表进行修正后重新提交。它通常意味着原有报送结果存在错误、口径变化、数据修正或监管要求重新提交。
🔒 历史版本与报送留痕
concept · Level 2
历史版本与报送留痕保存每次报送的数据、规则、文件、回执、修正与审批证据。
🔒 报送结果
system · Level 2
报送结果是报表报送流程在某一阶段或最终状态下的结果。它可能包括提交成功、接收成功、校验通过、退回修改、补报、重报、报送完成等状态。
🔒 版本冻结
process · Level 2
版本冻结在审批后固定本次报送的数据、规则、文件和责任边界。
🔒 Submission / 报送批次
process · Level 2
Submission / 报送批次是一次正式报送的可追踪对象,连接报表版本、渠道、回执和最终结果。
报送流程与监管反馈图
报表生成不是终点,而是正式报送流程的起点。报表从内部生成到外部提交,需要经过复核、审批、报送、回执、监管校验、反馈处理、补报重报和版本留痕。 报表生成、报送与监管反馈图
子图总说明
## 0.1 子图名称 报表生成、报送与监管反馈图 也可以在后台显示为: 报表生成图 报送流程与监管反馈图 ## 0.2 一句话定位 报表生成不是终点,而是正式报送流程的起点。报表从内部生成到外部提交,需要经过复核、审批、报送、回执、监管校验、反馈处理、补报重报和版本留痕。 ## 0.3 这张图回答什么问题 这张图主要回答: 1. 报表数据生成以后,为什么不能直接提交? 2. 内部复核和审批到底在控制什么? 3. 报送文件和报送渠道分别是什么? 4. 提交状态、接收回执、监管校验和监管反馈有什么区别? 5. 什么情况下需要退回修改? 6. 补报和重报有什么区别? 7. 为什么报表必须保留历史版本和报送留痕? 8. 为什么报表问题不仅是“生成错了”,还可能是“提交状态、监管反馈、版本管理、审批留痕”出了问题? ## 0.4 本图主链路 可以把这张图理解为以下链路: 报表结果 → 报表生成 → 内部复核 → 审批流程 → 报送文件 → 报送渠道 → 报送提交 → 提交状态 → 接收回执 → 监管校验 → 监管反馈 → 退回修改 / 补报 / 重报 → 报送留痕 → 历史版本 这条链路的核心是: 报表不是导出后就完成。 报表需要在内部被确认,在外部被接收,在监管侧被校验,在全流程中被留痕。 ---
图说明建议
## 图说明短版 报表生成图用于说明监管报表从内部结果到正式报送的完整流程。报表生成只是起点,后续还需要经过内部复核、审批、报送文件生成、渠道提交、提交状态跟踪、接收回执、监管校验、监管反馈、退回修改、补报、重报和留痕归档。 ## 图说明长版 报表不是生成出来就结束。 在金融机构中,一份报表从系统生成到正式完成,需要经历一整条流程:先由系统根据数据和口径生成报表结果,再经过内部复核和审批,转换为正式报送文件,通过报送渠道提交,并持续跟踪提交状态、接收回执和监管校验结果。如果监管反馈发现问题,报表可能需要退回修改、补报或重报。整个过程需要保留历史版本和报送留痕,以便后续审计、监管问询和问题追溯。 ---
学习引导
学习这张图时,可以按以下顺序理解: 第一步,看报表生成。 理解报表结果是如何从系统规则和数据中形成的。 第二步,看内部控制。 理解内部复核和审批流程为什么必须存在。 第三步,看正式报送。 理解报送文件、报送渠道、报送提交和提交状态之间的区别。 第四步,看外部反馈。 理解接收回执、监管校验和监管反馈分别代表什么。 第五步,看回流处理。 理解退回修改、补报、重报之间的区别。 第六步,看留痕治理。 理解历史版本和报送留痕为什么是报表治理的重要部分。 ---
常见误解合集
## 7.1 报表生成了,不代表可以提交 生成只是系统结果,仍然需要复核、审批和确认。 ## 7.2 提交成功,不代表监管通过 提交成功只说明文件发送成功,不代表监管校验通过。 ## 7.3 接收回执,不等于业务认可 回执通常偏接收和技术处理,业务规则还需要监管校验。 ## 7.4 监管反馈,不一定说明报表系统错 反馈可能来自源数据、字段映射、口径理解、估值、会计、风险或对账差异。 ## 7.5 补报和重报不是一回事 补报偏补充遗漏,重报偏修正已报结果。 ## 7.6 历史版本不是备份文件 历史版本是报表治理和审计追溯的重要依据。 ## 7.7 报送留痕不是形式要求 留痕回答谁生成、谁复核、谁审批、谁提交、为什么修改、什么时候重报等关键问题。 ---
建议配套知识库条目
1. 报表生成为什么不是终点 2. 报表结果和报送文件有什么区别 3. 内部复核到底复核什么 4. 报表审批流程为什么重要 5. 报送文件如何从报表结果生成 6. 报送渠道和接收回执有什么区别 7. 提交成功为什么不等于监管通过 8. 监管校验通常在检查什么 9. 监管反馈如何进入修改流程 10. 退回修改、补报和重报有什么区别 11. 为什么报表要保留历史版本 12. 报送留痕在监管问询中有什么作用 13. 一笔交易如何从报表生成走到监管反馈 14. 报表重报时要追踪哪些信息 15. 报表版本管理为什么重要 ---
案例
假设一笔虚构 FX Forward 在报表数据来源、口径映射和指标计算后,进入报表生成流程。 交易层面: 产品:FX Forward 交易方向:银行买入 USD,卖出 CNY 买入金额:1,000,000 USD 远期汇率:7.2000 到期日:2026-06-03 交易对手:企业客户 A 报表日:2026-03-31 估值结果:50,000 CNY 状态:未到期 进入报表生成流程后,它可能经历: 报表生成:系统根据产品、币种、期限、交易对手、估值和状态生成报表结果。 内部复核:复核币种折算、期限桶、交易对手分类、估值金额是否合理。 审批流程:报表责任人审批本期外汇相关报表。 报送文件:系统把报表结果转换为正式报送文件。 报送提交:文件通过指定渠道提交。 接收回执:渠道返回接收成功或失败。 监管校验:接收端检查字段、格式、逻辑、跨表关系。 监管反馈:若发现外汇远期余额或估值异常,返回反馈。 退回修改:机构检查是交易数据、估值数据、币种折算还是分类映射问题。 补报或重报:如果漏报,则补报;如果原报表金额错误,则重报。 报送留痕:记录原版本、新版本、修改原因、审批和提交过程。 历史版本:保留每次生成和报送的版本。 这个例子说明: 同一笔交易不仅会进入报表指标,也会进入报表生成、复核、审批、报送、反馈和版本留痕流程。 ---
内容边界
本内容只用于金融系统学习和数据口径理解,不提供投资建议、交易策略、买卖建议、收益预测、监管套利建议、规避合规方法或金融产品推荐。 本内容不包含真实监管报表模板、真实字段明细、真实客户信息、真实交易信息、真实机构内部口径、真实监管系统截图或任何敏感数据。
虚构案例:一笔业务如何穿过这张图
以下均为虚构教学案例,用于理解报表口径和系统链路,不代表任何真实交易、真实报送模板或机构内部口径。 ## 案例包 A:一笔 FX Forward 如何被报表横向切开 适合放入的节点: 数据采集、交易系统、交易数据、产品维度、币种维度、期限维度、交易对手维度、Activity、Outstanding、币种转换、期限桶、估值口径、风险指标、会计数据、清算系统、报表生成、监管反馈、字段错误、口径错误、数据血缘 案例设定: 一笔虚构的 FX Forward。 交易日:2026-03-01 报表日:2026-03-31 到期日:2026-06-03 产品:FX Forward 交易方向:银行买入 USD,卖出 CNY 交易对手:企业客户 A 买入金额:1,000,000 USD 远期汇率:7.2000 卖出金额:7,200,000 CNY 报表日估值结果:50,000 CNY 交易状态:未到期 剩余期限:约 2 个多月 期限桶:1 到 3 个月 发生额口径:本期新增交易 余额口径:报表日仍未到期余额 这笔交易在不同报表视角下会变成: 产品维度:外汇远期,也可能属于外汇衍生品 币种维度:USD / CNY,可能需要折算成本币金额 期限维度:按报表日剩余期限进入 1 到 3 个月期限桶 交易对手维度:企业客户 Activity:本期新增 1,000,000 USD Outstanding:期末仍未到期 1,000,000 USD 估值口径:MTM 50,000 CNY 风险口径:外汇风险和交易对手风险 会计口径:可能形成未实现损益 清算口径:尚未到期,未最终交割 核心教学点: 同一笔交易,不同报表看的不是同一个数字。 交易金额、折算金额、估值金额、风险敞口、会计损益、清算状态,都可能来自同一笔交易,但回答的问题不同。 --- ## 案例包 E:一个报表差异如何追溯到源系统、字段或口径 适合放入的节点: 报表差异、字段错误、口径错误、源系统错误、主数据错误、估值错误、会计错误、风险数据错误、对账差异、问题定位、Root Cause Analysis、修正方案、重跑数据、重出报表、审计留痕、数据血缘、责任追踪、Data Owner、System Owner、Report Owner、口径 Owner 案例设定: 某张监管报表中,外汇远期未到期余额比预期多出 1,000,000 USD。 初步现象:报表 Outstanding 金额偏高 涉及业务:一笔 FX Forward 交易状态:交易系统显示未到期 实际情况:该交易已被提前取消,但状态没有同步到报表数据链路 问题来源:源系统状态更新延迟或接口未同步 影响字段:交易状态、Outstanding 标识 影响报表:未到期余额口径 修正方式:修正交易状态,重跑数据,重出报表 留痕:记录问题定位、修正方案、审批和版本 核心教学点: 报表差异不是只看报表结果,而要沿着数据血缘追溯到源系统、字段、口径、接口和责任人。 ---
Branch 访问说明
所有 Branch 都由后台权限控制。未授权访客只能看到锁定预览,开通授权后可查看完整节点文章和关系解释。