Collateral Management
07 抵押品管理（Collateral Management）
抵押品管理是风险管理与资金运营的核心交汇点。对于 PM 来说，这是最需要精细设计工作流的领域之一。
一、为什么需要抵押品
抵押品（Collateral）是 OTC 衍生品信用风险管理的第一道防线：
| 风险 | 没有抵押品 | 有抵押品 |
|---|---|---|
| 对手方违约损失 | 全额敞口 | 敞口 - 抵押品价值 |
| 授信额度需求 | 大额授信 | 基于净敞口 |
| 监管资本占用 | 高 | 低 |
| 交易门槛 | 仅高信用对手方 | 可扩展至更多对手方 |
二、保证金类型
2.1 初始保证金（Initial Margin, IM）
IM 用于覆盖未来潜在未来敞口（PFE）：
- 什么时候需要：交易开始时
- 计算方式：
- SIMM（Standard Initial Margin Model，ISDA 标准模型）
- 监管时间表（分阶段实施）
- 简单比例法（非中央清算交易）
- 典型金额：名义本金的 5%-30%（取决于产品和对手方）
ISDA SIMM 简介：
- 覆盖 5 大类风险因子（IR、FX、EQ、CR、CO）
- 标准化的风险敏感性计算
- 被全球监管机构认可
2.2 变动保证金（Variation Margin, VM）
VM 用于覆盖当前敞口的每日变化：
- 什么时候需要：每日（基于日终估值）
- 计算方式：当日 MtM - 前一日 MtM
- 特点：全额传递（Pass-through），每日结算
VM 流程：
每日估值 → 计算 VM 金额 → 发出 Margin Call → 对方支付 → 确认到账2.3 独立保证金（Independent Amount）
在 CSA 未约定的情况下，双方可能协商一个独立保证金（类似 IM 但更灵活）。
三、核心参数
| 参数 | 含义 | 典型值 | 系统设计影响 |
|---|---|---|---|
| Threshold（免追保额度） | 低于此敞口不需要抵押品 | 0 ~ 5000万 | 影响 Margin Call 触发频率 |
| MTA（最低转移金额） | 应支付/收取的最低金额 | 25万 ~ 100万 | 金额小于 MTA 不触发 |
| Haircut（折扣率） | 抵押品估值折价 | 现金 0%、国债 2%、股票 15-30% | 需维护折扣率表 |
| Eligible Collateral（合格抵押品） | 可接受的抵押品类型 | 现金、国债、AAA 信用债 | 需在系统中配置 |
| Notification Time | 通知截止时间 | 每天 14:00 | 影响批处理时间窗口 |
四、Margin Call 流程
这是抵押品管理的核心业务流程：
graph TD
A[每日估值] --> B[计算当前敞口]
B --> C[扣除已缴抵押品]
C --> D[计算应缴抵押品]
D --> E{超过 Threshold + MTA?}
E -->|是| F[发出 Margin Call]
E -->|否| G[不触发]
F --> H[对手方支付]
H --> I[收到并确认]
I --> J[更新抵押品记录]
H --> K{逾期未收到?}
K -->|是| L[催收流程]
L --> M{再次逾期?}
M -->|是| N[违约处理]Margin Call 通知方式
| 方式 | 时效性 | 适用场景 |
|---|---|---|
| 邮件 | 中 | 日常 |
| 即时通讯 | 高 | 紧急追保 |
| 门户系统 | 中 | 自助查询 |
| 电话 | 最高 | 严重逾期 |
五、抵押品种类与折扣率
| 抵押品类型 | 折扣率（Haircut） | 特点 | 系统处理 |
|---|---|---|---|
| 人民币现金 | 0% | 最优质抵押品 | 简单 |
| 美元/港币现金 | 0% | 需汇率折算 | 汇率管理 |
| 国债 | 1%-3% | 高流动性 | 需接入债券估值 |
| 政策性银行债 | 2%-5% | 准国债 | 同上 |
| AAA 信用债 | 5%-10% | 收益率较高 | 需评级数据 |
| A 股股票 | 15%-30% | 波动大 | 需盯市、集中度限制 |
| 公募基金 | 10%-20% | 依赖底层资产 | 需基金估值 |
六、抵押品优化（Collateral Optimization）
当客户有多种抵押品时，系统需要帮助选择最优的抵押品组合：
优化目标：
- 最低成本的抵押品（机会成本最低）
- 不触发短缺
- 符合对手方的合格抵押品要求
优化策略：
- 使用成本最低的抵押品（如现金优于股票）
- 保留优质抵押品（国债往往留作其他用途）
- 避免集中度超标（同一发行人不超限）
- 最小化转换成本（减少买卖频次）
七、争议处理（Dispute Resolution）
估值争议是抵押品管理中最容易引发业务与系统冲突的场景之一。两方各自计算同一笔交易的盯市价值 (MTM)，算出不同的数字，催缴和支付就对不上了。
7.1 差异从哪来
- 估值源不同：你用了 Wind 收盘价，对方用了 Bloomberg；你的波动率曲面更新频率是 T+1，对方是实时
- 估值模型不同：你用 Black-76 算期权，对方用 SABR；利率曲线构建方法不一致
- 算息日惯例不同：ACT/365 vs ACT/360，营业日规则不一致
- 公司行动处理不同：分红/配送调整的时间和方式不一致
- CSA 条款解读不同：Threshold、MTA、Haircut 的应用方式不一致
- 数据时间点不同：你看 16:00 的快照，对方看 18:00 的
7.2 争议生命周期
阶段 1：估值差异出现。 券商向客户发送 VM 催缴：请支付 500 万。客户回复：“我们算出来是 200 万。“差异 300 万——这就是争议 (dispute)。
阶段 2：争议标记与追踪。 运营将这笔催缴标记为 Disputed，记录：争议金额、客户声称金额、差异原因、开始时间。客户按 200 万支付（无争议部分），300 万进入争议处理。
PM 笔记： 保证金系统必须支持部分支付 (partial payment)，不能把催缴标记为”未付”或”已付”二选一。多数系统最初只做全额标记，后续才打补丁——在需求评审中应提前发现。
阶段 3：调查。 检查输入数据（双方市场数据源是否一致？）、计算方法（是否相同模型？）、时间点（EOD 快照几点的？）、CSA 条款（Threshold 是否正确应用？）。手段包括导出估值分解明细、电话会议逐项比对、提交第三方估值。
阶段 4：解决。 三种结果：一方认错修正催缴 → 系统需支持修正并保留历史版本；双方妥协取中间值 → 系统需支持手动调整并记录原因；升级到 CSA 约定的第三方估值代理 (valuation agent) → 通常需要数天。
阶段 5：关闭。 记录争议原因代码（数据源/模型/公司行动）、解决方式、处理时长。这些数据最终成为运营 KPI——争议率、平均解决时间——也会反馈到系统优化优先级。
7.3 CSA 中与争议直接相关的条款
| CSA 条款 | 对系统的含义 |
|---|---|
| Valuation Agent（估值方） | 谁提供”官方”估值？通常是券商。争议期间以估值方为准 |
| Valuation Time（估值时间） | 16:00 和 18:00 差异很大——晚间数据可能包含公司行动调整 |
| Notification Time（通知时间） | 催缴必须在几点前发出。系统如果 16:00 才发，可能已超时 |
| Dispute Resolution（争议处理） | 争议升级到第三方的时间线，通常 2 个营业日内 |
| Alternative Valuation（替代估值） | 争议僵持时使用的第三方估值来源（如 Bloomberg 估价） |
7.4 争议处理的系统功能要求
- 催缴拆分：支持部分支付，争议部分单独标记
- 争议录入：记录对方声称金额、差异原因、对方联系人
- 估值分解导出：从输入数据到计算结果的完整链路导出
- 催缴修正与重新发送：修正金额后重新发出催缴，保留历史版本和历史催缴记录
- 争议超时告警：根据 CSA 争议解决时间线自动告警
- 审计日志：谁在什么时候做了什么修改、为什么
- 争议统计报表：争议率、平均解决时间、主要原因分布
7.5 真实案例：估值时间点差异
某券商用 EOD 16:00 收盘价计算 VM，客户用 15:30 的价格（认为 15:00 收盘后到 15:30 是盘后交易，价格不可靠）。差异 0.5%——在 10 亿名义本金上就是 500 万。
系统设计时没有考虑”估值时间点不一致”这个场景，假设”所有参与者都用同一个收盘价”。现实是客户可以在 CSA 中约定自己的估值时间。
教训： 设计保证金系统时，不要认为”我们怎么算”是唯一的。需要支持参数化的估值时间、数据源、模型选择——因为每个客户的 CSA 条款都可能不同。
7.6 争议数据流转
定价引擎 → 计算 MTM
↓
保证金引擎 → 应用 CSA 参数 → 生成催缴
↓
催缴通知 → 发送客户
↓
客户争议 ← 运营录入系统
↓
调查 → 数据比对 → 修正或确认正确
↓
争议关闭 → 审计日志存档八、对账
抵押品对账是每日运营的重要环节：
| 对账类型 | 频率 | 内容 |
|---|---|---|
| 持仓对账 | 每日 | 双方登记的抵押品是否一致 |
| 估值对账 | 每日 | 双方计算的抵押品价值是否一致 |
| 变动对账 | 每日 | 当日抵押品增减是否一致 |
| 现金对账 | 每日 | 资金到账情况 |
九、PM 视角：抵押品管理系统设计
核心模块
抵押品管理系统
├── 静态数据管理（门槛、折扣率、合格品）
├── 保证金计算引擎
├── Margin Call 工作流
├── 抵押品优化引擎
├── 对账模块
├── 争议管理
└── 报表与监管报送与外部系统的集成
交易系统（敞口） → 抵押品系统
估值系统（MtM） → 抵押品系统
↓
Margin Call → 邮件/门户
↓
收到支付 → 结算系统
↓
更新记录 → 会计系统关键设计考量
| 考量 | 说明 |
|---|---|
| 实时性 | 日内 Margin Call 需要实时或近实时计算 |
| 灵活性 | 不同对手方的 CSA 条款不同，系统需支持参数化配置 |
| 自动化 | 全自动 Margin Call 可大幅降低运营负担 |
| 审计追踪 | 所有操作记录完整、不可篡改 |
| 多币种 | 多币种抵押品需要实时汇率 |
| 时间窗口 | 日终流程需要在限定时间内完成 |
下一步：08-Valuation-Pricing.md 理解估值与定价基础