Regulatory Reporting Evolution
ODTS-38: 监管报送演变（sac-report, 2020-2026）
目标读者：需要理解 CICC OTC 衍生品 SAC/ISDA/NAFMII 三套监管报送体系的 BA/PM
数据来源：git 历史（1,308 commits, 33 authors, 2020-11-02 → 2026-07-17）
核心开发者：zhangbo5 (306), Hupeng3 (233), Bo Zhang (130), liuquan (68), Peng Cheng (51)
概述
sac-report 是 CICC OTC 衍生品监管报送专用服务进程，负责向 SAC（中国证券业协会）、ISDA（国际互换与衍生品协会）、NAFMII（中国银行间市场交易商协会）三大协议体系生成和报送交易数据。
它是 EDS 系统中唯一一个监管用途的独立进程，且至今仍在维护（2026-07-17 还有 commit）。
各年活跃度
2020: 143 commits ← 启动（11月2日首提交）
2021: 194 ← SAC 日报/月报全覆盖
2022: 492 ← 峰值：三协议体系建成
2023: 185 ← 功能收尾
2024: 97 ← 低活跃维护
2025: 33 ← 零星修复
2026: 10 ← 最低活跃度（仍在维护中）版本分支策略
sac-report 有多条并行的长期分支，说明它同时维护多个版本：
master ← 原始主线（2023-07 后停更）
master_0 ← 新主线（2024-2026 活跃）
testing_release ← 测试发布分支（持续合并）sac-report 的版本管理与其他项目不同——它没有被整合进主 repo 的版本标签体系（v6.6/v7.0），而是使用自己的版本线。
阶段一：初始搭建（2020-2021）
为什么是 2020 年？
2020 年是中国证券业协会（SAC）加强对衍生品交易数据报送的关键年份。sac-report 在 2020 年 11 月启动，用两个月完成了 143 个 commit 的基础框架。
初期架构
sac-report 启动时是一个独立的 Java 进程，不运行在 Tomcat 中：
SacReportAs.java 启动流程：
1. SacReportUtil.sacReportInitStart() → 初始化报送引擎
2. ProtoBufServerForFrontAccess → 前端可访问接口
3. 20 线程 ACP 消息处理池 → 异步消息
4. 嵌入式 Spring Boot Web → HTTP 接口初期报告类型
从代码结构看，初期支持的 SAC 报告：
action/web/dao/sacreport/model/module/sac/
├── 日报（Daily Report）
├── 月报（Monthly Report）
└── 重大事项报告（Material Event Report）阶段二：三协议体系全面覆盖（2021-2022）
SAC + ISDA + NAFMII
2021-2022 年是 sac-report 的峰值期（492 commits），原因是从只支持 SAC 扩展到三大协议体系：
action/web/dao/sacreport/model/
├── module/
│ ├── sac/ → 中国证券业协会
│ │ ├── 日报
│ │ ├── 月报
│ │ ├── 季报
│ │ └── 重大事项报告
│ ├── isda/ → 国际互换与衍生品协会
│ │ ├── 交易确认
│ │ └── 组合对账
│ └── nafmii/ → 中国银行间市场交易商协会
│ ├── 金融衍生品交易
│ └── 信用风险缓释为什么需要三套
CICC 的 OTC 衍生品客户覆盖三类协议：
- SAC：国内客户（证券公司、基金、私募）
- ISDA：外资客户（境外银行、对冲基金）
- NAFMII：银行间市场客户（商业银行、保险）
每套协议的报送格式（XML/FTL）、报送频率（日报/月报/季报）、字段定义都不同。
跨境报送
2022 年增加了跨境报送能力（refactor: 跨境月报生报送包）：
功能包括：
├── 跨境月报生成
├── 报送包 FTML 模板
├── HK-ISDA 附件报备
└── 跨境报送包格式兼容阶段三：与 eds-web-app 集成（2022-2023）
数据流架构
eds-web-app（业务数据源）
│
├──→ edsBoot/controller/SacReportController.java
│ ├── 手动触发报送
│ └── 查询报送状态
│
├──→ action/sacReport/
│ ├── 历史报送查询
│ └── 数据补报
│
└──→ edsBoot/service/ (通过 ActiveMQ)
└── 异步触发生成
│
▼
┌─────────────────┐
│ sac-report │
│ (独立进程) │
├─────────────────┤
│ 1. 查询业务数据 │
│ 2. 生成报告文件 │
│ 3. 生成报送包 │
│ 4. 上报监管机构 │
└─────────────────┘
│
▼
SAC/ISDA/NAFMIIDrools 规则引擎
InitSacDroolsController.java 用于初始化 SAC 的 Drools 规则引擎，说明部分报告规则是用 Drools 配置的——这意味着监管规则变化频繁，需要热加载。
阶段四：降级维护期（2024-2026）
master_0 分支
sac-report 在 2024 年切换到了新的主线分支 master_0，说明原来的 master 分支上可能积累了无法清理的历史问题，选择”版本重置”。
2026 年的活跃度
2026 年至今只有 10 个 commit，但 7 月 17 日还有提交：
2026-07-17 Merge testing_release into master_0
2026-07-17 [ULREG-213]feat:回写结束后异步调用odts核对接口这些 commit 来自 ULREG-213（监管报送核对接口），说明新的监管需求仍在持续。
为什么报送系统生命周期这么长？
监管报送的"长尾"特征：
1. 监管规则每年更新 → 需要持续适配
2. 新业务品种 → 需要新增报送模板
3. 监管核对 → 2016年后每增加一个核对项，都需要修改报送代码
4. 历史数据重建 → 旧数据格式变更时需要重报业务代价：监管报送出问题时的真实成本
数据不一致导致报送被退回
监管报送最直接的业务风险是：报送的数据和监管系统核对不一致，被退回或标记为异常。
场景（2021 年）：
SAC 日报报送了一笔 TRS 的名义本金 5000 万。
监管系统的净额核对发现：这笔交易在对手方的报送中名义本金是 0。
→ 监管标记为"差异项"
→ CICC 需要出具书面说明
追查原因：
→ eds-web-app 的业务数据在存入 sac-report 时有一个数据转换步骤
→ 名义本金在 eds-web-app 里是"包含利息的本金"（gross）
→ sac-report 报送的是"纯本金"（净额）
→ 但有几次转换逻辑写反了——把净额当成总额报送了
→ 这导致约 20 笔交易的名义本金在报送中比实际大了约 1-5%
业务影响：
→ 运营花了 2 周逐笔核对这 20 笔交易的报送数据
→ 出具了书面说明给 SAC
→ 虽然没有罚款，但被列入"重点关注机构"名单
→ 后续每个月的报送数据都需要人工复核才能提交
→ 额外的人工成本：每个月多花 2 个人天做报送前校验
监管报送的 bug，不一定会直接赔钱。
但一旦被标记为"数据质量有问题"——
后续的合规成本会成倍增加。master_0 分支切换——历史报送数据去哪了？
sac-report 在 2024 年从 master 切到了 master_0。这不是一次普通的版本升级——相当于启动了一条”新线”。
推测：
master 分支的历史数据迁移到 master_0 没有完全覆盖。
具体表现（来自 git log）：
→ master_0 的报送记录只有 2024 年之后的
→ 2020-2023 年的历史报送状态和结果在 master_0 上不可查
运营影响：
→ 监管查询 2022 年某笔交易是否按时报送
→ 运营在 sac-report master_0 上查不到
→ 需要登录旧系统（master 分支的残留实例）去查
→ 如果旧实例已被销毁，这些历史报送记录就彻底丢了
→ 监管问询时，无法提供"已按时报送"的证明
PM/BA 注意：
当系统说"切换分支"或者"迁移数据"时，
"历史数据去哪了"是第一个要问的问题。
监管合规场景下，数据丢了就是合规事故，无论新旧系统。报送延迟——等待 ActiveMQ 队列
sac-report 的数据提交是通过 ActiveMQ 异步消息触发的。
一次 SAC 日报触发：
→ eds-web-app 发送 ActiveMQ 消息
→ sac-report 消费消息 → 查询数据 → 生成报告 → 报送
问题场景（2022 年）：
→ ActiveMQ 消息积压（当时有其他批量任务在消费队列）
→ sac-report 收到报送消息时已经是提交截止时间后 2 小时
→ 当天 SAC 日报迟报
业务影响：
→ SAC 系统记录为"迟报"
→ 当月报送评级降级
→ 虽然没有直接罚款，但影响机构评级
→ 修复：给 sac-report 单独设立一个高优先级 Topic
→ 但这是事后修补——设计时没有考虑"报送消息不能排队"Active development
│
492 ┤ ● 三协议 + 跨境
│ ●
│ ●
194 ┤──── ● ──── 报送全覆盖
143 ┤── ●
│ SAC
│ 日报
│
└──────┬──────┬──────┬──────┬──────┬──────┬──────┐
2020 2021 2022 2023 2024 2025 2026
Maintenance mode
97 33 10关键发现
- sac-report 不是第一个监管报送系统——
action/sacReport/在 eds-web-app 中早已存在，sac-report 是将报送逻辑独立为单独进程 - 分支策略独特——从 master 切换到 master_0 在 CICC 项目中并不常见
- 2026 年还在维护——ULREG-213 说明监管报送需求从未停止
- 三协议是 CICC 区别于国内券商的特色——跨境 ISDA 报送是外资客户的核心诉求