ODTS 17 — 交易确认：每笔交易的法律记录

业务问题

电话里的交易不是交易。Bloomberg chat 里的交易不是交易。只有双方签署确认书说”是的，我们按这些条款做了这笔交易”，交易才是真的。

这份确认书是具有法律约束力的文件。如果系统簿记错了，确认书就错了，交易台就有法律问题。

电话 → "成交，600519.SH 做 TRS，1000 万 RMB" → 不是交易
簿记 → 系统录入完整条款 → 算半个交易
确认书 → 签署的法律文件 → 这才是交易

确认工作流

T+0：交易在系统内完成簿记
  → 尚未生成确认书

T+1：生成确认书
  → 系统用模板 + 交易数据生成 .docx
  → 运营检查准确性
  → 运营发给客户（邮件）

T+2：客户确认
  → 客户签署（或发回他们的 ISDA 确认书）
  → 运营核对并归档

如果条款不一致：
  → 差异解决（电话/邮件）
  → 生成修订 (amendment)
  → 双方签署修订

系统如何生成确认书

模板系统

~/odts1/eds-web-app/src/com/cicc/edsBoot/confirm/
├── ConfirmGenerator.java            — 主编排
├── ConfirmDataProvider.java          — 从交易数据库填充数据
├── confirm.docx/                     — Apache POI 模板处理
├── template/                         — .docx 模板
│   ├── trs_template.docx
│   ├── option_template.docx
│   ├── snowball_template.docx
│   ├── ndf_template.docx
│   └── swap_template.docx
└── ConfirmReportService.java         — 报告

每个模板是一个带占位符的 Word 文档：

{{counterpartyLegalName}}
{{tradeDate}}
{{effectiveDate}}
{{maturityDate}}
{{underlying}}
{{notional}}
{{currency}}
...

数据填充器

ConfirmDataProvider.java 从交易数据库读取数据并填充占位符。这些占位符总计 50 多个字段，覆盖从对手方法定名称、交易日、起息日、到期日、标的物、名义本金到各种产品特有条款。

确认书长什么样

一份简化的 TRS 确认书：

总收益互换交易确认书

日期：[2025 年 7 月 16 日]

致：[交易对手法定名称]
自：中国国际金融（香港）有限公司

事由：总收益互换参考号 TRS20250716001

交易条款如下：

通用条款：
  交易日：        2025 年 7 月 16 日
  起息日：        2025 年 7 月 18 日
  终止日：        2026 年 1 月 18 日
  币种：          RMB
  名义本金：      10,000,000

甲方（总收益支付方）：  CICC
乙方（总收益接收方）：  [交易对手]

股票信息：
  股数：          100,000
  参考价格：      100.00
  初始价格：      100.00
  发行人：        贵州茅台酒股份有限公司
  代码：          600519.SH

总收益条款：
  分红处理：      乙方有权获得所有分红
  ...

融资条款：
  浮动利率支付方： 乙方
  浮动利率：      SHIBOR 3M
  利差：          +100 bps
  天数计算规则：   ACT/365

[签署页]

中文确认书问题

监管要求：中国境内对手方需要中文版确认书，并带有特定的 SAC 措辞。

系统生成两个版本：

1. 英文确认书 — 用于 ISDA 框架
2. 中文确认书 — 用于 SAC 合规

中文确认书包含必须逐字录入的监管文本：

中国国际金融股份有限公司与[对手方全称]之间的总收益互换交易确认书

...

依据《证券法》、《证券公司监督管理条例》、《证券公司金融衍生品交易风险管理指引》...

这些监管文本块作为常量存储在：

eds-web-app/src/com/cicc/edsBoot/confirm/ChineseRegulatoryText.java

什么会出错

1. 模板不匹配

交易产品：TRS
使用的模板：TRS 模板
  → 但这个 TRS 带有雪球式的障碍特征（混合产品）
  → 标准 TRS 模板不覆盖障碍条款
  → 确认书不完整

修复：手动生成确认书（律师起草）

2. 数据不一致

系统显示：名义本金 = 10,000,000
客户显示：名义本金 = 10,100,000

为什么？手续费的处理方式不同（含或不含）
修复：电话确认，修改确认书

3. 确认书滞后

问题：T+0 簿记交易，T+10 才发确认书
  → ISDA 要求 T+5 内确认（某些产品 T+2）
  → 延迟确认会面临监管罚款

修复：系统在 T+1 自动生成确认书
  → 但如果运营积压，它仍然在队列里等着

确认状态

系统追踪确认状态：

Contract.confirmationStatus:
  PENDING_GENERATION   — 交易已簿记，尚未确认
  GENERATED            — .docx 已生成，待审核
  SENT                 — 已发给客户
  CONFIRMED            — 客户已确认
  AMENDED              — 交易条款变更，需要新确认书
  DISPUTED             — 客户不同意条款
  DEFAULT              — 交易违约，无需出具确认书

确认队列

运营每天处理一个队列：

今日队列（new-edsweb → 确认页面）：
  ┌────────┬──────────┬──────────┬────────────┬──────────┐
  │ 交易   │ 客户     │ 产品     │ 生成日期   │ 状态     │
  ├────────┼──────────┼──────────┼────────────┼──────────┤
  │ TRS001 │ UBP_HK   │ TRS      │ 2025-07-16 │ GENERATED│
  │ OPT002 │ CITADEL  │ 香草     │ 2025-07-16 │ GENERATED│
  │ SNB003 │ PINGAN   │ 雪球     │ 2025-07-15 │ SENT     │
  │ ...    │          │          │            │          │
  └────────┴──────────┴──────────┴────────────┴──────────┘

日常量： 每天 30–50 份确认书（2024 年）。每份花运营 5–10 分钟。也就是确认书一项每天就要 3–8 小时。

2022 年确认书积压危机

2022 年，交易台经历了创纪录的雪球发行月：一个月 400 个雪球。运营只有 3 个人。每个雪球都有复杂的确认书，含多页障碍条款。

积压到了 150 笔未确认交易。平均确认时间达到 T+15。合规部门提出了警告。交易台不得不：

1. 临时雇佣 2 名运营人员
2. 连续加班 3 周
3. 与客户协商接受延迟确认

此后的系统改进： 自动生成逻辑被优化。模板被简化。最常见的雪球变体获得了预审批模板，不再需要法律审核。

确认书延迟的商业代价： ISDA 要求 T+5 内完成确认（部分产品 T+2）。延迟确认不会直接产生罚款，但会影响：

1. 对手方信用风险管理：在确认书签回之前，这笔交易的条款在法律上是”未定”的。信用风险团队不能把未确认交易计入净额结算。如果客户在 T+3 违约且确认书未签回，这笔交易只能按无担保敞口计算——这直接影响交易台的信用额度。一个 2000 万的雪球延迟确认 = 2000 万的无担保敞口，等于交易台的信用额度被占用且无法再利用。
2. 会计确认：财务团队不能将未确认交易记为衍生品合约。这意味着每日估值、P&L 确认都受到合规质疑。
3. 客户关系：延迟确认在客户心里打了一个结——客户会怀疑”是不是交易台内部出了什么问题”。

确认书出错的代价： 如果确认书上的条款和系统簿记不一致且没有被发现，客户和法律上都认定确认书为准。例如：确认书上写的名义本金是 1000 万，但系统里是 1100 万。如果客户违约，法律程序将按确认书的 1000 万计算欠款——交易台损失 100 万的索偿权。2020 年，一个 NDF 交易由于确认书上缺少了一个”重置条款”，导致该笔交易无法按 NDF 方式交割，最后按普通远期结算，交易台损失了约 150 万。事后修复：所有 NDF 模板加上了自动审计检查——重置条款缺失 = 确认书生成失败。

实际系统：Doc Agent 文档生成

2022 年积压危机后，ODTS 引入了 Doc Agent（文档生成服务），作为独立的 HTTP REST 服务，专门负责合同/确认书的 PDF 渲染：

eds-web-app → Doc Agent (HTTP REST, JSON)
  POST /doc-agent/generate
  {
    "templateId": "snowball_2022_v3",
    "templateType": "CONFIRMATION",
    "dataSource": {
      "contractId": "SNB202507001",
      "counterpartyId": "CLT0001",
      "tradeDate": "2025-07-16",
      ...
    },
    "outputFormat": "PDF"
  }
  ← 返回: { "docId": "DOC20250716001", "status": "SUCCESS", "url": "/hcp/confirm/SNB202507001.pdf" }

Doc Agent 接管了原来 Apache POI 模板系统的 PDF 生成工作。生成的 PDF 直接存入 HCP 对象存储，URL 返回给 eds-web-app 记录到数据库。

Doc Agent 与传统模板系统的关系：

• 旧系统 (.docx Apache POI) 仍用于生成可编辑的 Word 确认书（运营需要修改的场景）
• Doc Agent 用于直出不可改的 PDF（标准确认书、批量生成）

实际系统：Cert App 数字签章

确认书签署通过 Cert App 完成数字签名和电子签章（详见 ODTS-47）：

运营在页面打开确认书 PDF
  → 点击"发送签章"
  → Cert App 发送短信验证码到操作人手机
  → 运营输入验证码
  → Cert App 返回待签名数据 (DataToSign)
  → 前端调用系统证书私钥签名
  → 签名后的确认书存档至 HCP
  → 状态更新为 SENT

签署的法律效力： Cert App 的数字签名满足《中华人民共和国电子签名法》的要求，使电子确认书与纸质签署具有同等法律效力。

数据目录补充

Doc Agent 调用:
  eds-web-app/src/.../confirm/DocAgentClient.java  ← HTTP 客户端调用 Doc Agent
  odyssey/cash-manager/.../DocAgentService.java     ← Odyssey 侧调用

Cert App 调用:
  eds-web-app/src/.../cert/CertAppClient.java       ← 证书/签章 HTTP 客户端
  odyssey/.../cert/CertService.java                  ← Odyssey 侧封装

教训： 确认流程是瓶颈。当交易台业务量创纪录时，运营总是最先崩溃的环节。系统可以一天处理 1000 笔簿记，但法务加运营一天只能处理 30–50 份确认书。

运营数据： 一个 3 人运营团队负责确认书的生命周期成本：每人 60 万/年（含福利），团队每年 180 万。加上一个兼职审核的法务（50% 时间，40 万），确认流程年化成本约 220 万 RMB。以每日 40 份确认书、每份 5–10 分钟计算，每份确认书的”人本成本”约 50–100 元。这个数字看起来不大，但乘以年化 10,000+ 份确认书，就是每年 50–100 万的直接运营支出。

还有一个隐藏成本——Amendment： 每笔交易的条款变更（如延期、增加名义本金、替换标的）都需要一份新的确认书——Amendment。一个 Amendment 的工作量和新交易几乎没有区别：运营同样要生成确认书、发给客户、等客户签回。2023 年，交易台的 10,000 份确认书里有 30% 是 Amendment。如果一个新确认书成本 100 元，一个 Amendment 的成本也是 100 元——但 Amendment 是”免费”的业务（客户不付费，交易台只从额外利息中获益）。这就是为什么运营团队有增无减：业务量加倍，确认书三倍（新交易 + 存续交易的变更）。