ODTS 16 — 追保：IM、VM 和交易台最紧张的一小时

业务问题

每一笔 OTC 交易都有交易对手风险。如果对手违约，交易台持有的头寸可能已经亏了钱。保证金 (Margin) 就是防范这个的担保金。

两种保证金：

变动保证金 (Variation Margin, VM)：
  → 覆盖逐日 P&L 变动
  → 如果交易让客户亏钱 → 交易台向客户追 VM
  → 如果交易让客户赚钱 → 客户向交易台追 VM
  → 每日计算

初始保证金 (Initial Margin, IM)：
  → 覆盖潜在未来损失（如果客户违约）
  → 基于头寸在处置期内的风险
  → 每日或每周计算

变动保证金详解

VM 怎么运作

第 1 天：交易以 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
      差额 5 = 初始保证金（押着防备未来波动）

VM 确保当前风险敞口始终有抵押品覆盖。每天，亏钱的一方付现金给赚钱的一方。

VM 计算

hedging-as/src/com/cicc/pricing/margin/
├── MarginCalculator.java            — 保证金引擎
├── VariationMarginService.java      — VM 逻辑
├── InitialMarginService.java        — IM 逻辑
└── MarginReportService.java         — 保证金报告

VM 计算：

对于每笔合约：
  vmAmount = currentMTM - previousMTM (+ 分红、融资等)
   
按交易对手汇总：
  netVM = 与该对手所有合约的 vmAmount 之和

如果 netVM > 0：客户付给交易台
如果 netVM < 0：交易台付给客户

但实际追保金额不是 netVM。它是：

marginCall = netVM - alreadyPostedMargin

如果 marginCall > MTA (Minimum Transfer Amount) → 发起追保
如果 marginCall < MTA → 累积到第二天

追保工作流

08:00 — EOD 批处理计算保证金
09:00 — new-edsweb 中生成保证金报告
09:30 — 运营审查追保
10:00 — 追保通知发给客户（邮件）
10:00–16:00 — 客户回应（付款或争议）
16:00 — 未付追保 → 升级处理

保证金计算的代码路径：

EOD 批处理 → 第 7 步：保证金
  → MarginCalculator.run()
    → 对每个对手、每笔合约：
      → computeVM(contract, counterparty)
      → computeIM(contract, counterparty)
    → aggregateByCounterparty()
    → applyCSATerms(threshold, MTA, rounding)
    → generateMarginCalls()

初始保证金详解

IM 更难算。它是如果对手违约且交易台在 N 天内（通常 10 天）无法平仓时的潜在未来敞口。

计算方式：

对每个头寸：
  → 模拟未来价格路径 (Monte Carlo)
  → 计算处置期内第 99 百分位损失
  → 这就是 IM 要求

这是计算密集型的。EOD 批处理的 IM 步骤在 3 小时总数中占了 20 分钟。

简化的 IM（用于小型对手）：

IM = 名义本金 × 风险系数

风险系数取决于：
  - 产品类型（期权 20%、TRS 10%、NDF 5%）
  - 标的波动率（高波动股票 = 更高系数）
  - 剩余期限（期限越长 = 系数越高）

完整 IM（用于大型对手）：

IM = SIMM (Standard Initial Margin Model)
  — 行业标准 (ISDA SIMM)
  — 考虑：delta 风险、vega 风险、曲率风险、基差风险
  — 按交易对手计算，不是按合约

ODTS 没有完全实现 SIMM。对于大多数对手，它使用简化方法。对于前 10 大客户，IM 是单独计算的（通常由风险团队在 Excel 里算）。

什么会出错

1. 追保争议

交易台说：VM = 500 万 RMB
客户说：VM = 420 万 RMB（差了 80 万）

为什么有差异？
  — 不同估值模型（交易台用隐含波动率，客户用历史波动率）
  — 不同市场数据（交易台的价格 vs 客户的价格）
  — 不同的外汇兑换率
  — 公司行为已应用 vs 尚未应用

解决方法：
  — 双方核对各自数据
  — 就中间价达成一致（或最接近市场价格）
  — 错了的一方补差额

2. 追保迟到

交易台在上午 10:00 追保
客户在下午 4:30 才付款
资金在结算截止时间之后才到账

问题：如果客户在 10:00 到 4:30 之间违约，
      交易台当天没有保证金覆盖风险

3. 抵押品 haircut 争议

客户用政府债券作为保证金
系统应用 5% 的 haircut（面值 100 的债券算 95）
客户说："政府债券无风险，不应该打折扣"
ISDA 说：5% 的 haircut 是市场惯例
解决方法：取决于 CSA 条款

4. 集中度 haircut

客户质押 5 亿 RMB 的腾讯股票作为保证金
交易台应用集中度 haircut（任何单只股票不超过组合的 20%）
系统拒绝超额部分
客户必须提供不同的抵押品

5. 追保争议的频率和成本

追保争议不是偶发事件——它是这个业务的日常。

每月追保争议约占总追保次数的 5–15%。对于一个有 30 个活跃对手、每个对手每月 20 次追保的交易台，每月有 30–90 次争议。每次争议的处理流程：

• 运营发现争议 → 记录到争议跟踪表
• 联系客户获取对端估值 → 等待客户回复（平均 1–2 天）
• 双方数据比对 → 找出差异原因（0.5–2 小时）
• 协商一个中间金额 → 如果无法达成一致，升到管理层（可能再拖 3–5 天）

争议的累积成本： 每次争议平均消耗运营 1–3 小时、交易员 0.5 小时。以月均 60 次争议计算，每月就是 60–180 运营工时 + 30 交易员工时。折合每年 1–2 人月。更重要的是，正在争议中的金额在争议期间是不需要支付的——客户可以利用争议机制延缓资金支出。有些客户会系统性地对每笔追保提出质疑，这不是因为他们真的认为系统算错了，而是因为争议期间他们不需要付费。交易台需要分辨”真争议”和”策略性争议”，但这个判断依赖运营的经验——系统不提供任何帮助。

追保瀑布流 (Margin Waterfall)

系统中每日追保流程的实际人力投入——这远不是自动化的：

时段	任务	谁做	工时可观吗
08:30–09:30	审查 EOD 生成的保证金数据，检查有无异常	运营 (1人)	1小时/天 — 快速检查
09:30–10:30	比对双边估值差异，确认追保金额正确	运营 (1人)	1小时/天 — 最耗时的一步
10:30–11:00	生成追保通知（邮件/Pdf/平台上传），至少检查一遍再发	运营 (1人)	0.5小时/天
11:00–12:00	处理客户的付款指令，核对银行到账	运营 (1人)	1小时/天 — 高峰期更长
14:00–15:00	跟进未付追保，发提醒，升级到紧急联系人	运营 (1人)	1小时/天
随机	回答客户的争议电话和邮件	运营 + 交易员	0.5–2小时/天 — 取决于客户数量

运营团队每年花在追保流程上的人力成本约为 1.5–2 FTE × 80 万 RMB/年 = 120–160 万。这不是 IT 成本——这是做生意的运营开销。系统自动化的部分（EOD 计算）只完成了 30%，剩下的 70% 靠手工审查、比对、发通知、追款。

当追保未获满足时：

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

系统追踪追保状态。但违约工作流是不自动化的——由信用风险和法务部门处理。

保证金报告

每天，运营生成一份保证金报告：

交易对手：CLT0001 (UBP_HK)
日期：2025-07-16

活跃头寸：
  合约 ID           | 产品     | MTM     | VM     | IM
  SNOWBALL001       | 雪球    | 15,000K | +200K  | 3,000K
  TRS002            | TRS     | 50,000K | -100K  | 5,000K
  OPT003            | 期权    | 5,000K  | +50K   | 1,000K

汇总：
  总 MTM：             70,000K
  净 VM（交易台应收）： 150K
  IM 要求：             9,000K
  应付总保证金：        9,150K
  已付保证金：          8,500K
  追保金额：            650K
  MTA：                 500K
  状态：                CALL_ISSUED

数据来源：

• CtrContract — 活跃合约列表
• TodayContractRaInfo — 估值结果
• MarginResult 表 — 保证金计算结果
• CashTransfer — 已付抵押品记录

弄错的代价

失败	成本
少收保证金	如果客户违约，交易台损失无抵押部分
多收保证金	客户投诉 → 关系损伤 → 业务流失
追保迟到	客户利用延迟 → 交易台有无担保敞口
IM 算错	监管处罚（SAC 要求准确的 IM）
抵押品未追踪	交易台以为有抵押但实际上没有现金

真实故事： 2021 年，发给一家香港私银的追保通知发错了邮件地址。客户 5 天没付款。交易台的敞口是 2000 万 RMB。当客户最终付款后（错误被发现时），交易台已经有 5 天无担保敞口。发错邮件的运营人员被重新培训。系统也更新为根据 CSA 记录自动填入正确的客户联系方式。

2022 年 3 月的保证金螺旋： 2022 年 3 月，中概股暴跌（拼多多跌 30%、阿里跌 20%），TRS 客户的 MTM 急剧恶化。交易台同时向 15 个客户发出了 4 亿元的追保。问题是——客户也在同一时间被其他券商追保。部分客户无法同时支付所有追保，选择了”谁追得紧就先付谁”。交易台的追保专员从上午 9 点一直打电话到晚上 8 点。最终有 2 个客户违约（共 5000 万），交易台强制平仓损失了 800 万（流动性差，卖不到好价格）。事后复盘发现：系统没有在追保发出后自动追踪付款状态，运营需要手工查银行到账记录。交易台紧急加了一个”追保仪表盘”，每天下午 3 点自动显示未付追保清单。