VOL. VII · NO. 113 · OTC Derivatives · 19 JUL 2026

Master Agreement Comparison

OTC 衍生品 · 19 JUL 2026 · 10 min read · 1,571 words

· · ·

ODTS-63: 主协议体系对比——ISDA vs SAC vs NAFMII

为什么这篇文档值得读

“客户签了 ISDA 没有？” ——这是衍生品交易中第一个问的问题。没有主协议，一笔交易就没有法律框架——没有净额结算权，没有违约处理机制，没有保证金要求。对 PM/BA 来说，理解这三个协议体系的差异，就是理解为什么系统要为同一个数据生成三套不同格式的报告、为什么某些客户只能用某些协议、为什么保证金计算规则因协议而异。

三大协议全景

	ISDA	SAC	NAFMII
制定者	国际互换与衍生品协会 (纽约)	中国证券业协会 (北京)	中国银行间市场交易商协会 (北京)
覆盖市场	全球 OTC 衍生品	中国境内券商间 OTC	中国银行间市场
适用的对手方	外资银行、基金、企业	券商、期货公司、境内私募	银行、保险、财务公司
主要产品	全部 OTC 品种	TRS/期权/收益互换	IRS/债券远期/利率衍生品
法律文本	英文，全球标准	中文，SAC 模板	中文，NAFMII 模板
净额结算支持	是（主协议+附件）	是	是
CSA (信用支持附件)	ISDA CSA (标准)	SAC 补充协议	NAFMII 质押式/转让式

ISDA 主协议

谁用 ISDA

ODTS 中所有跨境交易和大部分外资客户的交易都使用 ISDA 框架。

客户画像：
  ├── 外资银行（摩根大通、汇丰、渣打）  → 必须 ISDA
  ├── 境外基金（开曼基金、香港基金）    → 通常 ISDA
  ├── 中资企业境外子公司                → 通常 ISDA
  └── QFII/RQFII 客户                  → ISDA + 中国附加条款

ISDA 的结构

ISDA 主协议由三层组成：

第一层：主协议 (Master Agreement)
  ─ 标准条款，一次签署永久有效
  ─ 包括违约事件 (Events of Default)、终止事件 (Termination Events)、
    净额结算 (Close-out Netting)
  ─ 2002 版或 1992 版（中金大部分用 2002 版）

第二层：附件 (Schedule)
  ─ 补充和修改主协议的条款
  ─ 包括：指定交易、付款净额结算、保证金规则、终止货币、
    额外违约事件、通知地址
  ─ 每个客户不同——交易台法律团队谈判的重点

第三层：信用支持附件 (CSA / Credit Support Annex)
  ─ 约定担保品（保证金）条款
  ─ 包括：初始保证金阈值、变动保证金规则、合格抵押品种类、
    估值方法、争议解决
  ─ 交易台与不同客户的 CSA 条款差异巨大

ISDA 在 ODTS 系统中的体现

系统表中：
  CtrContract.csaTemplate     ← CSA 模板 ID
  CtrContract.masterAgreement ← ISDA 主协议引用
  EDS_MARGINRULE              ← 根据 CSA 计算保证金
  CtrCounterParty.isdaSigned  ← 是否已签署 ISDA

系统中处理 ISDA 确认书：
  Doc Agent → ISDA 模板配置（30+ 个模板变量）
  → 见 55-Doc-Agent-Document-Generation.md

SAC 主协议

谁用 SAC

SAC 框架适用于中国境内券商与境内对手方的所有 OTC 衍生品交易。

客户画像：
  ├── 境内私募基金（最多的一类）        → SAC
  ├── 境内券商（同业）                  → SAC
  ├── 境内企业客户                      → SAC
  └── 境内期货公司及其子公司            → SAC

为什么需要 SAC 而不是直接用 ISDA？ 中国法律体系属于大陆法系，ISDA 的普通法概念（如 trust, equitable interest）在中国法律下不被承认。SAC 模板是以中国合同法为基础的衍生品交易框架——它和 ISDA 在法律概念上不完全对应。

SAC 与 ISDA 的关键差异

维度	ISDA	SAC
合同语言	英文	中文
法律基础	英格兰法/纽约法	中国法
完美净额结算	确定（英美法系历史判例多）	有不确定性（中国无破产净额结算专门立法）
抵押品隔离	通常需要隔离	实践中通常不隔离
终止净额结算	2002 版有定义	与破产法有潜在冲突
争议处理	伦敦/纽约仲裁	中国国际经济贸易仲裁委员会 (CIETAC)
报告要求	ISDA Trade Repository	SAC 报告系统

系统的视角： 同一个交易台、同一个交易系统，为 ISDA 客户生成的确认书是英文版的，为 SAC 客户生成的是中文版的。Doc Agent 根据合约中的 masterAgreementType 字段选择不同的渲染模板。

协议选错的真实代价

2021 年中发生过一次生产事故：一个新客户在系统中被配置为 SAC 协议，但实际签署的是 ISDA 协议。

后果链：
  配置错误：CtrCounterParty.masterAgreementType = "SAC"
  → Doc Agent 生成了中文 SAC 确认书
  → 客户（外资银行）收到中文确认书，退回
  → 运营发现协议类型错误，修改配置
  → 重新生成确认书，重新发起签署流程
  → 确认书延迟 3 个工作日才签署完毕

交易影响：
  确认书未签期间，这笔 TRS 处于"待签署"状态
  → 系统认为交易尚未生效
  → MarginCall 未生成（因为系统判断交易还没开始）
  → 3 天没有追缴保证金
  → 标的物在这 3 天内下跌 2%
  → 交易台暴露了 200 万未抵押的额外损失

这个案例说明：masterAgreementType 不是一个技术字段——它直接影响保证金、确认书、报告、争议处理四个系统模块的行为。 一个字段配错，整个生命周期都出错。

SAC 监管报送的演进

SAC 协议不只管法律框架——它也驱动了监管报送。

2018: SAC 1 号令——所有 OTC 交易必须报送
  → ODTS 增加 SacReportController
  → 1 人兼职做报告

2020: SAC 要求 CVA 数据
  → 系统需要输出每笔交易的对手方信用风险数据
  → SacAS 接口扩展

2021: SAC 初始保证金规则
  → 系统需要生成 SIMM 数据
  → MarginCalculator 增加 IM 计算

NAFMII 主协议

谁用 NAFMII

NAFMII 是中国银行间市场交易商协会管理的框架，适用于银行间市场交易。

客户画像：
  ├── 商业银行（工行、建行、招行）     → NAFMII
  ├── 保险公司                          → NAFMII
  ├── 财务公司                          → NAFMII
  └── 部分外资银行境内法人              → NAFMII (取决于产品类型)

实际影响： 中金的 OTC 衍生品业务以券商/私募/境外客户为主，NAFMII 客户的占比不高。但一笔 NAFMII 交易的规模通常远大于 SAC 交易。系统对 NAFMII 的支持主要是报告格式层面——module/nafmii/ 路径下的模板负责将交易数据转换为 NAFMII 格式的监管报告。

NAFMII vs SAC vs ISDA

维度	NAFMII	SAC	ISDA
制定机构	NAFMII (银行间)	SAC (证券)	ISDA (全球)
管辖法律	中国法	中国法	英格兰法/纽约法
主要产品	IRS/债券远期/利率产品	TRS/期权/股权互换	全品种
对手方	银行+保险+财务公司	券商+私募+企业	外资金融机构+企业
保证金	质押式或转让式	CSA 补充协议	ISDA CSA
报告报送	NAFMII 格式	SAC XML	ISDA TR
系统路径	`eds-web-app/module/nafmii/`	`ofareg/` + `eds-web-app/action/sacReport/`	`eds-web-app/module/isda/`

CSA 谈判的实际影响

CSA 中的 Threshold 和 MTA 条款直接决定了交易台的信用风险和运营工作量：

Threshold（阈值）：低于这个金额不收抵押品。Threshold = 500 万意味着客户浮亏 500 万以内不用交 VM。这降低了运营工作量（小金额不用催缴），但增加了信用风险敞口。
MTA（Minimum Transfer Amount，最低转让金额）：低于这个金额不追缴。MTA = 25 万意味着即使客户欠 30 万，如果还没到 MTA 就不去追——得等累计到 25 万以上才发起 margin call。

真实谈判： 某大型私募客户的 CSA Threshold 最初是 0（所有浮亏即时追缴），运营团队每天要处理这个客户的小额 margin call（5 万、10 万），成本高于敞口风险。后来 CSA 被重谈为 Threshold = 200 万，运营工作量下降了 80%，但风险敞口增加了 200 万——这是一个 trade-off 的典型决策。

系统影响： 每次 CSA 重谈意味着 EDS_MARGINRULE 表中该客户的规则需要更新。如果规则更新不及时（比如运营忘了改系统），系统会按旧 CSA 计算保证金——要么多追（客户不满），要么少追（风险敞口增加）。

一个客户可能同时有多个协议

实际业务中常见的情况：

一家外资银行的中国境内法人（例如摩根大通银行中国有限公司）：

  跨境交易（总行层面）    → ISDA 2002 + CSA
  境内银行间市场交易      → NAFMII (IRS 通过 SHCH 清算)
  境内券商间交易          → SAC（实际很少——外资银行境内法人
                            主要通过 NAFMII 做利率产品）

  → 系统需要为这个客户维护三套协议信息
  → CtrCounterParty 表中有多个 master agreement 记录

协议选择对系统的影响

客户入市流程中：

选择 ISDA:
  → 确认书模板：英文 ISDA
  → 保证金规则：CSA 约定的 SIMM/阈值
  → 监管报告：ISDA Trade Repository (如果需要)
  → 争议解决：伦敦/纽约仲裁

选择 SAC:
  → 确认书模板：中文 SAC
  → 保证金规则：SAC 补充协议
  → 监管报告：SAC 报告系统（自动+手动）
  → 争议解决：CIETAC

选择 NAFMII:
  → 确认书模板：中文 NAFMII
  → 保证金规则：质押式/转让式
  → 监管报告：NAFMII 格式
  → 清算：通常通过 SHCH 中央清算

一句话

一个交易台，三套协议体系。ISDA 是全球语言，SAC 是境内券商的通行证，NAFMII 是银行间的规矩。ODTS 把这三套都塞进同一个数据模型里——这就是为什么 31-Contract-Operations 中讲到的协议管理这么复杂。

关键文件

组件	路径
ISDA 确认书模板	Doc Agent → 合约配置 (`/template/isda/`)
SAC 报告生成	`eds-web-app/action/sacReport/`
NAFMII 模板	`eds-web-app/module/nafmii/`
ISDA 模板	`eds-web-app/module/isda/`
主协议关系数据读取	`sac-report/.../MasterRelaAgrmtDataReader.java`
监管报送服务	`sac-report/`
SAC XML Schema 生成	`SacReportGenerator.java`
SacAS 接口	`SacUploadService.java` (Protobuf ACP 协议)