Collateral Management
ODTS-61: 担保品管理 / Collateral Management——抵押品流转的生意逻辑
为什么这篇文档值得读
在 OTC 衍生品世界里,没有抵押品就没有交易。 一笔 TRS 的名义本金可能是 5 亿,交易对手如果不给保证金,交易台的敞口就是赤裸的 5 亿风险。担保品管理回答了一个朴素的问题:“如何确保交易对手不会白嫖?” 它的核心流程——初始保证金 (IM) 计算、变动保证金 (VM) 追缴、抵押品替换、争议处理——是 ODTS 系统中 PnL 之外交易量最大的处理环节。
核心概念
初始保证金 (Initial Margin / IM)
定义: 交易达成时预收的抵押品,用于覆盖未来潜在敞口。不是对当前欠款的担保——是对”将来可能欠的钱”的担保。
例子:
客户和交易台做一笔 1 年期的 TRS,标的物 1 亿
第一天:
- 盯市价值 = 0(还没开始)
- 未来 1 年,如果标的物涨 20%,交易台可能欠客户 2000 万
- IM 就是这笔"可能欠的钱"的担保
IM 计算:
PFECurve[1 年] × 名义本金 × 置信系数(通常是 99% VaR)
= 20% × 1 亿 × 1.0 = 2000 万
客户交付 2000 万现金或国债作为 IM
系统实现: MarginCalculator.java 中的 calculateIM() 方法。IM 计算基于历史模拟或 SIMM (Standard Initial Margin Model) 标准模型。中金使用 SIMM 模型计算 ISDA 清算和非清算交易的 IM。
变动保证金 (Variation Margin / VM)
定义: 交易存续期间,根据每日盯市价值变化转移的资金。
例子(续):
第 30 天:
- 标的物下跌 5%
- 盯市价值 = -500 万(客户欠交易台 500 万)
- VM 调用: 客户支付 500 万现金
第 60 天:
- 标的物反弹 3%
- 盯市价值 = -200 万(客户欠交易台 200 万)
- VM 调用: 交易台退回 300 万(之前收了 500 万,现在只需要 200 万)
关键规则: VM 用现金结算,通常 T+1 交割。IM 可以用现金或国债,通常在 T+2 交割。
担保品管理系统的生命周期
交易达成 存续期 到期
│ │ │
↓ ↓ ↓
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ IM 计算 & 收 │ │ 每日 VM 调用 │ │ 释放抵押品 │
│ 集 │ │ IM 调整 │ │ │
│ │ │ 抵押品替换 │ │ │
│ │ │ 争议处理 │ │ │
└──────────────┘ └──────────────┘ └──────────────┘
│ │ │
↓ ↓ ↓
客户交付 IM 客户补 VM 或收 VM 退回 IM + 最后 VM
系统记录: CUST 向 CICC 支付: 双向释放
EDS_CONTRACTMARGIN CICC 向 CUST 支付:
数据模型
基于代码库中的 migration 文件,担保品管理的核心表结构:
EDS_MARGIN ← 保证金账户主表(客户维度汇总)
EDS_CONTRACTMARGIN ← 逐笔交易的保证金明细(交易维度)
EDS_MARGINRULE ← 保证金计算规则(不同交易类型不同费率)
EDS_MARGINLOG ← 保证金变更历史(审计跟踪)
EDS_RISK_MARGINTABLES ← 风险维度保证金汇总
MarginCall 模型字段解析(MarginCall.java):
| 字段 | 中文 | 解释 |
|---|---|---|
clientId | 客户 ID | 交易对手 |
valuationDate | 估值日 | 计算基准确认的日期 |
mtm | 盯市价值 | 标记至市场的总盯市价值 |
im | 初始保证金 | 计算的初始保证金要求 |
mtmCreditLine | 盯市信用额度 | 不需要收 VM 的信用额度(threshold) |
imCreditLine | IM 信用额度 | 不需要收 IM 的额度 |
totalRequirement | 总保证金要求 | IM + VM 的总需求 |
heldCollateral | 已收抵押品 | 实际到账的抵押品价值 |
excess | 超额/不足 | heldCollateral - totalRequirement |
callAmount | 调用金额 | 本次需要追缴的金额 |
status | 状态 | PENDING / SENT / PAID / DISPUTED |
marginCallFile | 调用通知书 | 生成的 PDF 文件路径 |
业务流详解
第一步:IM 计算(交易达成日)
交易录入 → 系统读取 MARGINRULE → 根据交易类型和客户等级计算 IM
↓
客户是银行? → IM = 0(银行间 IM 豁免)
客户是私募/企业? → IM = SIMM 计算值
ISDA 清算交易? → IM 由 CCP 计算
IM 豁免的真实业务背景: 银行之间交易(中金对工商银行)通常不收 IM,因为双方信用评级高。但这在 2008 年后受到挑战——雷曼兄弟也是银行。2015 年巴塞尔 III 要求所有金融机构之间交易逐步强制收 IM。
第二步:每日 VM 计算
EOD 批处理 → 重新计算所有交易的盯市价值
→ 对比前一日盯市价值
→ 差值 = VM 变更金额
→ 考虑已收抵押品
→ 生成 MarginCall(如果 net VM 变动超过 threshold)
代码路径: EODServiceImpl.java → EOD 批处理回调 → MarginCalculator.java
第三步:Margin Call 生成和发送
MarginCallHandler.call():
1. 计算 totalRequirement = max(IM + netVM, 0)
2. 计算 excess = heldCollateral - totalRequirement
3. 如果 excess < 0(抵押品不足):
a. callAmount = abs(excess)
b. 生成 MarginCall 记录
c. 调用 Doc Agent 生成 Margin Call PDF
d. 调用 JUMS 发送邮件给客户
4. 如果 excess > 0(抵押品过剩):
a. 触发退回流程(客户可能要求退回多余抵押品)
第四步:抵押品替换和争议
客户收到 Margin Call 后:
场景 A:客户支付现金 → 系统确认到账 → 更新 heldCollateral
场景 B:客户替换抵押品(现金换成国债)
→ 需要先验收购入的国债是否合格(国债?评级?期限?)
→ 释放现金 → 收取国债
场景 C:客户提出争议
→ 争议标记(status = DISPUTED)
→ 双方重新计算盯市价值
→ 达成一致后更新调用的金额
IM 与 VM 的财务特性
| 特性 | IM | VM |
|---|---|---|
| 用途 | 覆盖未来潜在敞口 | 覆盖当前已实现敞口 |
| 计算频率 | 日度(或周度) | 日度 |
| 支付频率 | 首次交易 + 月/季度再计算 | 每日 |
| 可接受抵押品 | 现金、国债、高评级债券 | 现金(几乎只现金) |
| 抵押品再使用 | 不可以(需隔离) | 可以(再抵押) |
| 会计处理 | 表外资产 | 表内应收/应付 |
| 监管要求 | 巴塞尔 III / ISDA SIMM | 无专门监管 |
担保品管理的运营代价
担保品管理不是”系统自动运行”的——它消耗了运营团队的大量工时:
- 每日 Margin Call 生成和发送: 运营每天早上检查 EOD 批处理生成的 margin call 列表,确认金额合理后通过 JUMS 发送给客户。约 1 个 FTE 全职 做这件事(核对、发送、跟踪回款)。
- 争议处理: 每次 margin dispute 平均需要运营 2-4 小时跟进(电话客户、协调双方估值、更新系统)。ODTS 系统中争议率约 3-5% 的交易日,每月 1-2 次。
- 抵押品替换审批: 客户要求把现金换成国债或反过来——运营需要手工审核替换的抵押品是否合格(国债评级、剩余期限、汇率折算)。平均每次替换需要 1 小时。
- 延迟追缴的真实代价: 如果 margin call 在 16:00 前没发出去(因为系统 delay 或运营漏发),客户当天无法付款,相当于暴露了额外一天的敞口。对于高波动的标的,一天可能损失 1-2% 的头寸价值。
2022 年英国养老金危机对中国市场的教训
2022 年 9 月英国金边债券暴跌,很多 LDI 基金收到”不可交付”的 IM call——金额太大,48 小时内拿不出那么多现金。
中金内部对标后的结论:
- 系统 IM 计算的时效性可能是救命稻草——如果不能当日计算并发送 IM call,等于给了对手更多时间恶化而没有抵押品保护
- 抵押品多样性(现金 vs 国债 vs 高评级债)在危机中至关重要——只收现金的 margin call 更容易引发流动性挤兑
- ODTS 的 IM 模型(SIMM)和 CCP 的 IM 模型通常有差异,差异部分就是未被覆盖的敞口
担保品管理中常见的系统问题
争议为什么会发生?
盯市价值计算的分歧是最常见的争议来源。
真实案例:
交易台: "这笔 swap 值 -500 万(我们用了 Bloomberg 曲线)"
客户: "这笔 swap 值 -480 万(我们用了 Refinitiv 曲线)"
差额: 20 万
Margin Call 金额:交易台要求 500 万
客户愿意支付:480 万
争议:20 万 → 标记为 DISPUTED → 需要双方市场数据团队核对
系统层面的根因: ODTS 使用 Bloomberg 曲线做估值。客户可能使用不同的市场数据供应商。当双方曲线不一致时,盯市价值必然存在差异。这就是为什么 12-Market-Data-Pipeline 文档中提到的市场数据来源管理如此重要——不仅是系统内部的问题,也是客户关系的问题。
抵押品不足事件
某客户持仓:
TRS 名义本金 10 亿
IM 要求:2 亿
VM 要求:5000 万(当前浮亏)
已收抵押品:1.8 亿(客户 IM 给少了,VM 也没完全给)
→ excess = 1.8 - 2.5 = -0.7 亿
→ 需要追缴 7000 万
如果客户在 2 天内没给:
→ 触发违约事件 (Event of Default)
→ 交易台有权平仓
→ 如果标的物在此期间继续下跌,交易台承担损失
业务影响: 2022 年英国养老金危机中,金边债券利率飙升导致大量 LDI 策略的 IM 暴增(因为 SIMM 模型对利率敏感)。多家基金在 48 小时内无法交付 IM,被迫平仓——损失数百亿。担保品管理系统的自动化程度直接决定了交易台能否在市场崩盘时快速追缴保证金。
中金系统中的担保品流转
客户 (现金/国债)
│
▼
HCP (对象存储)
← 客户上传担保品凭据
← 系统确认到账
│
▼
ODTS (hedging-as)
→ MarginCalculator 计算要求
→ MarginCallHandler 生成调用
→ Doc Agent 生成 PDF 通知书
→ JUMS 发送邮件/短信
│
▼
IPMP (资金划拨平台)
← 客户回款
← VM 结算
│
▼
ODTS EOD
→ 更新 EDS_MARGINLOG
→ 更新 EDS_CONTRACTMARGIN
→ 更新下一日敞口
与 SAC 监管报表的关系
担保品数据是 SAC 监管报表的重要组成部分。SacReportServiceImpl 从 EDS_CONTRACTMARGIN 和 EDS_MARGINLOG 读取数据填入 SAC 模板中的保证金列:
SAC 报表 -> 保证金部分 -> 字段包括:
首日保证金 (First Margin)
维持保证金 (Maintenance Margin)
变动保证金 (Variation Margin)
已收保证金 (Received Margin)
保证金现金比例 (Cash Ratio of Margin)
业务洞察: 监管部门(CSRC)看保证金数据判断交易台是否在合规地管理信用风险。如果保证金覆盖率低(excess 经常为负),可能会被要求补充资本或限制交易。
一句话
担保品是 OTC 衍生品的信任基础。IM 防明天的风险,VM 付今天的账。ODTS 的担保品管理模块不是”财务功能”——它是整个交易风险控制的前线。
关键文件
| 组件 | 路径 |
|---|---|
| 保证金调用模型 | hedging-as/.../margin/neo/model/MarginCall.java |
| 保证金计算引擎 | hedging-as/.../margin/neo/MarginCalculator.java |
| 保证金调用处理 | hedging-as/.../margin/neo/MarginCallHandler.java |
| 保证金合约表 | eds-web-app/db/EDS/.../CREATE_MARGIN.sql |
| 保证金规则表 | eds-web-app/db/EDS/.../CREATE_MARGINRULE.sql |
| 保证金日志表 | eds-web-app/db/EDS/.../CREATE_MARGINLOG.sql |
| EOD 批处理入口 | edsWeb/.../EodServiceImpl.java |
| SAC 报表保证金数据 | edsWeb/.../SacReportServiceImpl.java |