角色地图：Legal / Documentation（法务）

法务是”写合同的人”——OTC 衍生品没有标准化交易所合约，每一笔交易都靠 ISDA 协议和确认书来约束。法务看不懂你的系统设计，但你的系统必须要能实现法务写的条款。

flowchart TB
    subgraph 法务工作流
        A[ISDA 谈判] --> B[Schedule 确认]
        B --> C[CSA 签署]
        C --> D[交易确认]
        D --> E[条款管理]
        E --> F[争议/违约处理]
    end
    subgraph 系统对接
        A -->|需要| D1[协议管理系统]
        D -->|需要| D2[确认书生成]
        E -->|需要| D3[条款数据库]
        F -->|需要| D4[事件管理]
    end

---

一、典型一天时间线

08:30 ─ 到公司
       │ 检查邮箱——有没有新的 ISDA 谈判反馈
       │ 有没有交易对手发来的争议通知
       │ 你需要的系统：案件/协议跟踪看板

09:00 ─ ISDA 协议谈判
       │ 和新交易对手签 ISDA Master Agreement
       │ 每一条 Schedule 条款都要磨：自动提前终止、跨违约、指定交易
       │ > "对方坚持要加 cross default，我们能不能接受？"
       │ 你需要的系统：协议模板库、条款变更追踪

10:30 ─ CSA 谈判
       │ 和对手方谈抵押品条款
       │ 最低转移金额 (Minimum Transfer Amount)、阈值 (Threshold)、
       │ 合格抵押品类型、折扣率 (Haircut)
       │ 你需要的系统：CSA 参数管理

11:30 ─ 确认书审核
       │ 新交易的确认书需要法务审核后才能发客户
       │ 检查条款是否和 ISDA 一致、交易要素是否准确
       │ 你需要的系统：确认书审核流程（电子审批）

13:00 ─ 条款咨询
       │ 业务部门来问：""这个交易结构在现有 ISDA 框架下能不能做""
       │ 你翻协议找答案
       │ > 你需要的系统：协议条款全文检索（而不是翻纸质合同）

14:00 ─ 协议归档与更新
       │ 新签的 ISDA 要归档
       │ 存量协议有变更要更新
       │ 电子版 + 关键条款提取存入系统
       │ 你需要的系统：协议信息管理系统

15:00 ─ 争议处理
       │ 交易对手声称我们违约了
       │ 你翻协议看违约条款怎么定义的、通知流程怎么走
       │ 你需要的系统：争议事件管理、条款快速检索

16:00 ─ 监管合规对齐
       │ 监管有新规（比如新《期货法》要求更新协议模板）
       │ 你需要检查存量协议是否需要修改
       │ 你需要的系统：监管变更→协议影响分析

17:00 ─ 文件整理
       │ 今天的谈判纪要、已签署协议整理归档
       │ 准备明天的谈判要点

---

二、法务的 KPI

KPI	说明	系统含义
ISDA 签署周期	从谈判到签约的天数	协议流程管理效率
确认书通过率	一次审核通过的比例	确认书自动校验
协议覆盖率	交易对手 ISDA 签约比例	协议状态跟踪
争议解决时效	争议从发生到解决的时间	争议处理工作流
条款提取准确率	关键条款能否快速从系统查到	条款数据库质量

---

三、法务使用的系统

系统	用途
协议管理系统	ISDA/CSA 电子化存储、版本管理、到期提醒
确认书生成系统	自动生成 + 审核流程
条款数据库	关键条款提取、全文检索
审批工作流	协议变更、确认书审核
DocuSign / 电子签名	线上签署协议和确认书

---

四、法务的黑话

黑话	意思	系统含义
”ISDA 签下来了吗”	ISDA Master Agreement 签署完成了吗	协议状态跟踪
”Schedule 加了几条”	谈判中额外条款的谈判进度	条款变更管理
”CSA 还没谈”	抵押品协议还没签	协议优先级管理
”AAA”	最佳评级对手方	信用评级接口
”Credit Support”	抵押品/信用支持	抵押品管理系统
”Event of Default”	违约事件	违约处理工作流
”Termination Event”	终止事件（非违约但有影响）	事件管理
”Netting”	净额结算	净额计算支持
”Close-out”	终止净额结算	平仓事件处理
”Master Agreement”	总协议框架	协议层级管理
”Credit Event”	信用事件	CDS 相关
”Force Majeure”	不可抗力	事件管理

---

五、你怎么和法务打交道

法务是 PM 容易被忽视的关键 stakeholders——他们不天天出现在交易台，但他们的条款直接影响系统的数据结构。

• 关键字段来源于协议：最低转移金额、Threshold、Haircut、合格抵押品清单——这些不是风控或交易员定的，是法务在 CSA 里谈下来的。你的系统数据结构必须跟协议走
• 协议管理系统不是”扫描件仓库”：很多公司的”协议管理”就是把 PDF 存网盘。真正的系统需要提取关键条款为结构化数据——这样才能做自动化（比如根据 Threshold 自动判断是否需要催缴抵押品）
• 法务变更 → 系统变更：ISDA Schedule 的一个条款修改，可能意味着系统的自动提前终止逻辑需要跟着改。要建立”条款变更→系统影响评估”的流程

---

---

系统支持（IT 侧锚点）

法务动作	系统 / 代码路径	关联文档
ISDA / CSA 参数	协议管理 → 结构化条款库（Threshold / Haircut）	ODTS-55 文档生成
确认书审核	DocAgent 生成 → 电子审批流	ODTS-17 确认流程
条款检索 / 违约处理	条款数据库 + 事件管理	ODTS-19 监管报告
监管变更 → 协议影响	ofareg 影响分析	ODTS-52 外部系统代码引用

下一角色：role-credit.md 授信的一天