ODTS 29 — 估值日合规检查：Valuation Day Sentinel

对 PM/BA 来说，估值日合规检查是运营和风控的交集——它回答一个核心问题：这个基金的衍生品持仓规模和它的净资产匹配吗？

一、什么是估值日合规检查

每个估值日（通常是每个营业日），基金管理人或托管人对衍生品组合进行集中度检查 (concentration check)：所有衍生品合约的名义本金 (notional) 加总后，除以基金的净资产 (NAV)，不能超过监管或基金合同约定的阈值。

为什么需要这个检查？

场外衍生品的高杠杆意味着：一个 10 亿净资产的基金，可能持有 100 亿名义本金的雪球。如果市场剧烈波动，这 100 亿名义本金的亏损可能远超基金的实际承受能力。合规检查确保杠杆率可控。

三个结果等级：

状态	含义	行动
OK	集中度 ≤ 阈值	无操作
WARN	集中度接近阈值（如 ≥ 阈值的 80%）	通知风控部门关注
BREACH	集中度 > 阈值	触发违规处理流程—减仓、停止新交易、向监管报告

---

二、检查流程的每一步

步骤 1：获取 NAV

估值日的第一件事：获取基金的净资产。

NAV 的来源通常是：

• 托管行估值数据（最权威）
• 基金管理人自估值（用于日间监控）
• 第三方估值机构（如中证估值、中债估值）

如果多个来源都有数据，系统需要比较它们，差异过大则告警。

NAV 数据错误的真实成本：

2021 年，某托管行在一次系统升级后，连续 5 个交易日向 ODTS 推送了错误的 NAV 数据——基金净资产被少报了约 15%。原因是托管行的接口字段映射错了，把”基金总资产”当成了”基金净资产”推送。系统照单全收。

期间，5 只基金的集中度看起来"正常范围内"。
但实际上因为 NAV 被低估，集中度被高估了约 15%。
如果当时有一只基金的真实集中度是 480%（阈值 500%），
系统报告的是"OK"——但其实实际只有 480 ÷ 1.15 ≈ 417%。

真正的问题不是数据错了——而是没有人发现数据错了。因为：没有人手工核验托管行推送的 NAV 是否合理。运营默认”系统对的就是对的”。直到一个月后，另一家托管行的数据与这家对不上，才回溯发现。5 天的错误数据已经进了合规存档——无法撤回。

业务教训： 自动化最大的风险不是技术故障，而是”错误的自动化”——系统自动相信了错误的数据源，放大了而不是减少了手工流程的核验成本。好的需求应该包含”NAV 合理性校验”功能：环比前一日变化超过 5% 自动标记审查、多来源交叉验证差异自动告警。

步骤 2：统计存续合约名义本金

系统从交易系统中拉取所有存续（未到期、未终止）场外衍生品合约的名义本金。

需要区分的维度：

维度	为什么重要
产品类型	不同产品的风险不同，可能需要分类型检查（如雪球单独算集中度）
标的资产	同一个标的的集中度（如所有挂钩中证 500 的合约加总）
交易对手	单个交易对手的集中度（防止单一对手违约产生的连锁风险）
名义本金 vs 市值	名义本金衡量杠杆敞口，市值衡量实际风险敞口

步骤 3：计算集中度

集中度 = 总名义本金 / NAV × 100%

例：NAV = 5 亿，所有衍生品名义本金 = 20 亿
集中度 = 20亿 / 5亿 = 400%

阈值的典型值：

投资者类型	集中度阈值	说明
专业投资者（私募）	500%-2000%	取决于基金合同约定
公募基金专户	100%-500%	更严格
保险资金	50%-200%	非常保守
券商自营	按风控指标	流动性覆盖率等

步骤 4：形成检查报告

检查报告需要包含：

估值日：2024-07-17
NAV 来源：托管行
NAV 金额：500,000,000 元

合约统计：
  - 存续合约数：47
  - 总名义本金：20,000,000,000 元
  - 集中度：400%
  - 阈值：500%

分产品类型：
  - Snowball: 12,000,000,000 (240%)
  - Swap: 5,000,000,000 (100%)
  - Vanilla Option: 3,000,000,000 (60%)

分标的（Top 5）：
  - 中证 500: 8,000,000,000 (160%)
  - 沪深 300: 4,000,000,000 (80%)
  - 创业板指: 3,000,000,000 (60%)

状态：OK

步骤 5：存档与报送

检查报告需要：

• 存档备查（监管要求保存至少 5 年）
• 发送给风控部门
• 如 BREACH，需在指定时间内向监管报告并制定整改计划

---

三、系统的核心需求

3.1 数据源管理

需求	说明
NAV 多来源	支持托管行、自估值、第三方三种 NAV 来源，可切换或比较
NAV 版本控制	如果托管行在 T+1 更正了 T 日的 NAV，系统需标记版本并重新计算
合约数据同步	每日从交易系统同步存续合约清单，确保一致性
手工补充	对系统未覆盖的产品（如通过邮件确收的交易），支持手工录入名义本金

3.2 检查规则引擎

需求	说明
多阈值配置	不同产品类型、不同标的、不同交易对手可以设置不同阈值
阈值变更历史	监管规则变化或基金合同修改时，阈值变更需留痕
批量处理	如管理 50 只基金，系统需支持一次运行所有基金的检查
定时运行	每个估值日自动触发，也支持手动重新运行

3.3 告警与通知

需求	说明
分级告警	WARN 邮件通知风控，BREACH 短信/电话通知风控负责人
告警升级	BREACH 持续未处理则自动升级通知层级
附上下文	告警消息中附带详细数据摘要，而非只有一句”集中度超限”

---

四、PM/BA 的视角

4.1 这个系统解决什么问题

业务痛点： 运营人员每个估值日手工从多个系统拉数据，放入 Excel 计算集中度，然后邮件发送合规报告。手工流程的典型问题：

• 数据来源不一致（交易系统 A 和交易系统 B 的合约清单有差异）
• 计算错误（Excel 公式被误删、引用范围不对）
• 漏检查（某只基金这个月没人做估值日检查）
• 发现违规时已经是 T+3，错过了最佳减仓时机

手工流程的代价案例——被错过的 BREACH：

2020 年，某私募基金管理的 ODTS 账户中，一只专户产品因为一波行情上涨导致衍生品名义本金被动上升（部分雪球敲出后重新滚动，新合约以更高名义本金入场）。集中度在 3 周内从 300% 缓慢爬升到了 650%（阈值 500%）。运营人员每周做一次检查（因为”太忙了”），第 3 周才发现。

真实事件链：
  第 1 周结束时：集中度 420%（还在 OK 范围）
  第 2 周中：集中度突破了 500%（但没人检查）
  第 2 周结束时：集中度 580%（仍没人发现）
  第 3 周结束时：运营检查发现 650%
  开始减仓：T+2 才完成减仓
  市场在此期间下跌了 5%，基金损失约 3%
  
  **后果：** 合规部门报监管，基金被暂停新开衍生品仓位 1 个月。

业务成本： 1 个月不能开新仓，意味着基金错过了当月几个最好的建仓机会；合规事件记录进了基金档案，未来机构客户尽调 (DD) 时会问”为什么你们有过合规问题”——影响募资。

这个案例说明为什么”每日自动检查”不仅仅是一个效率提升——它是合规风险控制的基础设施。人工每周检查在大部分时间够用，但一旦出问题就是合规事件。

系统化后带来的价值：

角色	之前	之后
运营	每天 2 小时手工做检查	10 分钟审核系统结果
风控	被动收 Excel 邮件	主动看实时仪表盘
合规	季度抽查	每日自动检查+存档
管理层	不知道有没有问题	每日风险视图

4.2 需求评审中容易遗漏的点

遗漏 1：NAV 的维度和货币

如果你只存一个 NAV 数字，你会在实际运营中发现问题：基金可能有多种份额类别（A 类、C 类），每个类别的 NAV 不同。集中度检查应该用哪个？答案是”基金层面的总净资产”——但系统需要支持从多份额 NAV 汇总。

另外，如果基金投资了境外标的，NAV 是人民币还是折算后的美元？不同货币的集中度是否需要分开算？

遗漏 2：合约的时点问题

估值日检查用的是”当日收盘后”的数据。这看起来简单，但实际场景很复杂：

• 某合约在估值日下午 2:00 到期终止了，它算不算今日的存续合约？
• 某合约在估值日下午 4:00 确认书才签回来，但交易是昨天做的，它算不算？
• 监管报送和内部风险管理的口径是否一致？

这些都需要项目启动时就定义清楚，而不是开发中才发现。

遗漏 3：BREACH 之后的自动化操作

一个合规系统如果只能”展示问题”而不能”解决问题”，它的价值就打了折扣。更高阶的功能：

• 风控一键生成减仓建议（哪个合约持仓比例最高、优先平）
• 减仓指令自动下发到交易系统
• 新交易硬阻断（集中度超过阈值时，交易系统直接阻止新增）

但这些功能涉及复杂的责任边界——系统”建议” vs 系统”执行”，需要在需求中明确。

BREACH 后响应速度的真实成本：

监管要求是 BREACH 发生后 5 个工作日内向监管报告并提交整改计划。但比监管成本更大的，是市场成本。

真实案例：
  某基金 BREACH 发生在周五收盘。
  运营周一才发现（系统只有 T+1 检查）。
  风控周二开会讨论减仓方案。
  周三下达减仓指令。
  周四执行完成。
  
  BREACH 到减仓完成：6 天。
  在此期间中证 500 下跌了 8%。
  基金因为高集中度多亏了额外 2%（相比正常仓位）。
  
  名义亏损：约 1000 万——不是来自合规问题，而是来自响应延迟。

这里的核心洞察是：BREACH 不是风险事件本身——BREACH 之后的响应速度才是真正的风险变量。 系统自动化程度越高（从”发现→开会→下指令→执行”的链条上每减少一个环节），业务亏损就越小。

4.3 与监管报送系统的关系

估值日合规检查的原始数据（集中度报告、BREACH 记录）也是监管报送的重要输入。

监管要求	数据来源
场外衍生品月报	月末集中度报告
风险指标日报	每日估值检查记录
重大事项报告	BREACH 记录
SAC/NAFMII 主协议下的信息披露	集中度数据 + 交易对手维度统计

如果系统设计时就把合规检查和监管报送的数据模型对齐，后续做报送功能时就少了很多数据搬运的工作。

---

五、系统架构示意

┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│  交易系统     │    │  NAV 数据源   │    │ 产品主数据   │
│  (合约清单)   │    │  (托管行/自估)│    │  (基金/投管) │
└──────┬───────┘    └──────┬───────┘    └──────┬───────┘
       │                   │                   │
       ▼                   ▼                   ▼
┌─────────────────────────────────────────────────────┐
│         估值日合规引擎 (Valuation Day Sentinel)        │
│                                                      │
│  1. 拉取 NAV                                          │
│  2. 拉取存续合约清单                                    │
│  3. 按产品/标的/对手方汇总名义本金                        │
│  4. 计算集中度 → 匹配阈值 → 判定 OK/WARN/BREACH         │
│  5. 生成报告 + 触发告警                                  │
└──────────────┬──────────────────────────────────────┘
               │
       ┌───────┴──────────┬──────────┐
       ▼                  ▼          ▼
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ 风控仪表盘    │  │ 告警通知      │  │ 存档/监管报送 │
│ (实时视图)    │  │ (邮件/短信)   │  │ (历史备查)   │
└──────────────┘  └──────────────┘  └──────────────┘

---

六、常见问题

问：NAV 应该在什么时候取？

答：交易日结束后（通常是 15:00-17:00 之间的快照）。如果托管行数据在 T+1 才出，系统和流程需要约定是否先用自估值数据做日检，等托管行数据出来后再回刷校验。

问：集中度检查需要实时还是 T+1？

答：监管要求是”至少每日一次”，所以日终批量检查是基线。但如果系统能支持盘中实时监控（如盘中 NAV 下跌 5% 就重新算一遍），在极端行情中有巨大价值。

问：不同监管机构要求的差异怎么处理？

答：基金合同 + 监管要求共同决定阈值。系统中应该支持基金级别的检查规则配置，而非全局统一阈值。一只券商资管产品和一只私募基金的阈值完全不同。

---

下一阶段：ODTS 30 — 障碍期权