VOL. VII · NO. 40 · OTC Derivatives · 01 JAN 1970

追保与结算：钱实际怎么流动

OTC 衍生品 · 01 JAN 1970 · 8 min read · 1,567 words

· · ·

簿记了、定价了，但钱还没有动——追保与结算是业务运营的日常痛点，也是 0004/0007/0008 没有展开的纵深。

必须记住

追保 = VM（每日盯市） + IM（初始保证金）；结算 = 每笔现金流（权利金/融资款/分红/到期）的实际划转。追保靠 MarginCallProcessor 发通知，结算靠 CashTransferService 驱动划转指令——两者都是人工介入比例最高的环节，系统只完成了 30%，剩下 70% 靠运营手工。

一、VM vs IM：两把不同的锁

业务：保证金是对手方违约时的护城河，分两层：

类型	目的	频率	计算基础
VM 变动保证金	覆盖已实现盯市盈亏	每日	当日 MTM − 上日 MTM
IM 初始保证金	覆盖处置期潜在未来敞口	每日/每周	SIMM 或简化公式

系统锚点（IT 侧）
hedging-as/src/com/cicc/pricing/margin/
  VariationMarginService.java — VM 计算
  InitialMarginService.java — IM 计算
  MarginCalculator.java — 汇总引擎
EOD 第 7 步 MarginStep → MarginCallProcessor → IPMP MoneyTransferClient

二、VM 是怎么滚动的

第 1 天：MTM = 100，簿记
第 2 天：MTM = 105 → 客户欠台里 5 → 台里追 VM 5
第 3 天：MTM = 98  → 台里欠客户 2 → 台里付 VM 2
第 4 天：MTM = 102 → 客户欠台里 4 → 台里追 VM 4

累计：客户已付 VM = 5 − 2 + 4 = 7
MTM 变化：+2（100→102）
差额 5 = 已锁住的保证金（防备未来波动）

但追保金额不是直接用 MTM 差值：

marginCall = netVM − alreadyPostedMargin

MTA（最低追保额）兜底：
  marginCall > MTA → 发起追保
  marginCall ≤ MTA → 累积到第二天

内行才知道

追保争议不是偶发——每月占 5–15% 的追保次数，典型原因：估值模型差异（台里用隐含波动率、客户用历史波动率）、公司行为应用时点不一致、外汇汇率口径不同。运营每次处理争议平均耗时 1–3 小时。每月 60 次争议 ≈ 每年 1–2 人月。

三、IM：处置期内的”最坏情景”

IM 比 VM 复杂得多——它问的是”如果对手现在破产、台里需要处置头寸，最坏亏多少？“

方法	公式	适用
简化法	名义本金 × 风险系数	小型对手（期权 20%、TRS 10%）
SIMM	ISDA 标准（Delta/Vega/曲率/基差）	2021 年大对手新规
Excel 手算	风险团队独立计算	前 10 大客户

双线串联

0007 的 PFE（潜在未来敞口）→ 决定 IM 上限 → SAC 2021 规则要求报 SIMM → 0008 的监管报送链路在这里汇合。一条链：PFE 算 IM → MarginCalculator → SacReportController 报监管。

四、追保瀑布流：每天的 6 小时

追保不是自动化的——EOD 计算完，运营要从 9 点忙到下午 4 点：

时段	任务	自动化程度
08:30–09:30	审查 EOD 保证金数据，检查异常	10%（系统生成，人工审查）
09:30–10:30	双边估值比对，确认追保金额	0%（纯手工）
10:30–11:00	生成追保通知（邮件/平台）	50%（模板生成，内容仍需人工核对）
11:00–12:00	处理客户付款指令，核对银行到账	30%（部分自动对账）
14:00–15:00	跟进未付追保，发提醒，升级紧急联系人	0%（纯手工打电话）
随机	争议处理（平均 1–3 小时/次）	0%

血的教训

2022 年 3 月：中概股暴跌，TRS 客户 MTM 急剧恶化，台里同时向 15 个客户发出 4 亿元追保。部分客户被多家券商同时追，选择"谁催得紧就先付谁"。追保专员从上午 9 点打到晚上 8 点，最终 2 个客户违约（共 5000 万），强平损失 800 万。系统没有追保仪表盘——运营靠手工查银行到账记录，付款状态不透明。

五、资金流转：结算不只是到期

结算不是只在”到期日”发生——每一笔现金流都在特定日期划转：

现金流类型	时间	触发组件
权利金（期权）	T+1 或 T+2	`ContractSaveService`
融资付款（TRS）	每月/每季定盘日	`ContractHelper`
分红划转（TRS）	标的除息日	`ContractDividendHelper`
VM 追保	每日 EOD 后	`MarginCallProcessor`
到期结算	到期日	`ContractSettleHelper`

系统锚点（IT 侧）
eds-web-app/src/com/cicc/edsBoot/cash/
  CashTransferController.java — REST API
  CashTransferService.java — 业务逻辑
  CashTransferGenerator.java — 划转指令生成
  odyssey-cash-manager-service/ — 实际资金划转（IPMP 集成）

六、违约处理：从追不到到强平

第 1 天：发出追保
第 2 天：客户未付款 → 发送提醒
第 3 天：仍未付款 → 上报高级管理层
第 4 天：仍未付款 → 发出违约通知
第 5 天：违约 → 台里平掉所有头寸
          → 平仓亏损 → 用已付保证金弥补
          → 平仓盈利 → 退还保证金 + 盈余

违约工作流不自动化——由信用风险和法务部门处理。ContractSettleHelper.finalSettle() 处理正常到期终止，违约走单独的 DefaultHandler。

七、测验（Recall 练习）

VM（变动保证金）的计算基准是？

IM（初始保证金）的目的是覆盖什么？

"追保瀑布流"中，双边估值比对发生在哪个时段？

ISDA SIMM 考虑的四大风险因子是？

分红划转（TRS）触发的日期是？

追保争议最常见的两个原因是？

客户已付保证金不足以覆盖 marginCall 时，系统才会发起追保——判断对吗？

"系统没有追保仪表盘"导致的直接后果是？

八、错题本与复习

查看全部错题

本课错题记录

九、延伸阅读

内部：ODTS-16 追保 IM/VM —— 追保瀑布流、争议处理、2022 年中概股暴跌完整复盘。
内部：ODTS-14 结算与资金流转 —— 5 类现金流划转路径与代码落点。
内部：ODTS-15 对冲工作流 —— Delta 汇总、对冲建议、交易员决策空间。
串联：0004 TRS 保证金 · 0007 PFE/IM · 0008 监管报送

收口

追保与结算是整个 OTC 业务运营的"出纳台"——几乎所有前面的知识（TRS/雪球/期权 + 风险估值 + 监管报送）最终都会在这里汇合、以现金流的形式落地。下一步可以回顾综合测验，或去错题本复习薄弱环节。

Lesson 0012 · 追保与结算 · 上游 0004 TRS · 错题追踪 0011 错题本 · MISSION: 产品 + IT 双线精通 · 样式 base.css