Third Party Guarantee And Principal Protected
ODTS 77 — 第三方担保与本金保障型产品：担保品之外的”信用增强”
为什么需要这篇文档
61-Collateral-Management 写了”担保品”（现金/债券质押覆盖保证金），72 写了”风控规则引擎”，76 写了”标的”。但有一类真实存在、且直连监管报送的业务域，三篇都没覆盖：
第三方担保 / 本金保障型（principal-protected）结构化产品。
代码库里，担保（guarantee）不是 61 文档里”质押券”那种担保品，而是一整套**“本金保障型收益凭证”的产品族**——它们在数据库里以 GUARANTEE_VAN / _DSF / _CPS / _DIG / _SF 五种审核视图存在，每一种都对应一类结构化产品，并且每一种都强制要求 SAC 监管报送。同时，CounterpartyAgreement（对手方协议）模型把”主协议 + 产品签署 + 是否报送”绑在一起。
一个 PM/BA 如果不知道”本金保障型”是 ODTS 里一个独立且强监管的产品族，在做收益凭证、监管报送、对手方协议相关需求时会严重误判范围。
1. 本金保障型产品族（VAN / DSF / CPS / DIG / SF）
数据库里的审核视图直接暴露了产品族的划分（eds-web-app/db/EDS/code/views/）：
v_report_audit_guarantee_van.sql — 本金保障型（VAN）
v_report_audit_guarantee_dsf.sql — DSF 型
v_report_audit_guarantee_cps.sql — CPS 型
v_report_audit_guarantee_dig.sql — DIG 型
v_report_audit_guarantee_sf.sql — SF 型
（每种都有对应的 _auditlogguarantee_xxx 变更日志视图）每张视图都挂在一张审核模板上（见 T051_GUARANTEEVAN 的 R033/L033 模板记录：本金保障型(VAN)审核模板）。
业务含义： “本金保障型”不是单一产品，而是一个有 5 个变体的产品族，每个变体（VAN/DSF/CPS/DIG/SF）是收益凭证的一种结构（不同挂钩标的、不同保本比例、不同收益结构）。它们在系统里被当成需要独立审核、独立报送的品类对待——这就是为什么数据库里不是一张表，而是五套审核视图 + 五套日志视图。
这和 07-Business-Concepts 里”簿记口径 vs 定价口径双枚举”是同一类现象：一个业务概念（本金保障型）在系统里被拆成多个技术变体，PM/BA 必须知道全部分支，否则需求只覆盖一种变体会漏掉另外四种。
2. 对手方协议（CounterpartyAgreement）：主协议 + 产品签署 + 报送开关
CounterpartyAgreement 模型（action/dynamic/model/CounterpartyAgreement.java）是把”法律协议”和”系统行为”绑定的关键对象：
| 字段 | 含义 |
|---|---|
masterAgrmtno / mMasterAgrmtVer | 主协议编号 / 版本（如 ISDA/SAC/NAFMII，见 63） |
mSigningDate | 主协议签署时间 |
mNeedReport | 主协议是否报送 |
mfillParty | 协议申报角色（发起方/对手方） |
pProductMode | 产品签署模式 |
pTheDateTable | 产品签署时间表 |
pNeedReport | 产品是否报送 |
pSuchProducts | 签署的产品列表 |
quotaApplyId / counterpartyApplyId | 关联的额度/对手方申请 |
type | 协议类型 |
counterpartyAgreementDoc | 协议文档（附件） |
业务含义： 一份对手方协议 = “我们和这个客户签了哪份主协议（m 开头字段）+ 在这份主协议下允许做哪些产品（p 开头字段）+ 每一层要不要报监管”。mNeedReport / pNeedReport 两个开关直接驱动 38-Regulatory-Reporting 的报送范围——协议里没打报送标记的，监管报告里就不会出现。
履约担保协议（PerformanceGuaranteeAgrmt）
叠加在对手方协议之上的，是 PerformanceGuaranteeAgrmt（履约担保协议）：
| 字段 | 含义 |
|---|---|
counterpartyAgreementId | 关联的对手方协议 |
gSupagrmtno | 担保协议编号 |
gPerformanceGuaranteeAgrmt | 履约担保协议内容 |
gNeedReport | 履约担保是否报送 |
注意又是第三个报送开关（gNeedReport）。一个产品从”签主协议 → 签产品 → 签履约担保”三层，每层都有独立报送标记——这就是 38 文档里”为什么同一笔业务在监管报告里有时出现、有时不出现”的底层原因之一。
3. 本金保障型的确认书生成（Risky / RHEG）
RiskyConfContractParamGenerator（utils/contract/）专门生成本金保障型（代码里叫 RHEG，即 RISKY 头）的确认书（confirmation），它实现了 ContractParamGenerator 接口，为每种确认书生成对应参数：
RHEG_I_CONTRACT — RISKY 头初始确认书
RHEG_S_CONTRACT — RISKY 头追加/修改确认书
RHEG_P_CONTRACT — RISKY 头个人客户确认书
RHEG_C_CONTRACT — RISKY 头机构客户确认书业务含义： 本金保障型产品的确认书不是通用模板，而是按”初始/追加 × 个人/机构”拆成四种。这呼应 06-Code-Map 里”确认书字段填充在 generator 不在业务项目”的架构事实——确认书是模板 + 参数生成器模式，每个产品族有自己的 generator。PM/BA 做确认书需求时，要找的是对应的 XxxConfContractParamGenerator，不是去改业务项目。
相关动作 TrsRiskyConfExecutePrintAction（执行打印）、TrsRiskyConfRevokeAction（撤销）表明本金保障型确认书还有执行打印和撤销的完整生命周期。
4. 它和担保品系统（61）的区别（别搞混）
| 概念 | 本文（第三方担保/本金保障型） | 61-Collateral-Management |
|---|---|---|
| 本质 | 一类产品族（本金保障型收益凭证） | 覆盖保证金的质押物机制 |
| 作用 | 产品本身的信用增强 / 本金保障结构 | 交易后的风险覆盖 |
| 监管 | 强制 SAC 报送（5 种变体各报各的） | 不直接报送，影响保证金计算 |
| 代码 | CounterpartyAgreement / GUARANTEE_* 视图 / RHEG generator | eds-web-app/.../collateral/ |
一句话： 61 是”借钱要押东西”，本文是”这个产品本身就带保本结构、且每卖一笔都要报监管”。两者都叫”担保/保障”，但完全是两回事。
5. 内行才知道的：三道报送开关是监管漏报的高发区
mNeedReport（主协议）/ pNeedReport（产品）/ gNeedReport（履约担保）三个开关，任意一个被漏勾，对应的业务就不会进 SAC 报告。而这三个开关分散在 CounterpartyAgreement 和 PerformanceGuaranteeAgrmt 两个对象里，且默认不是自动全开——依赖业务人员在签约时手动勾选。
这解释了 38-Regulatory-Reporting 里”报送范围对齐”为什么是个长期痛点：报送的源头不是”监管要什么”，而是”签约时有人勾了什么”。一个成熟的 PM/BA 在做报送相关需求时，会先问”报送标记从哪来、谁负责勾、默认值是什么”，而不是只盯着报告生成那段代码。
自测
- “本金保障型”在 ODTS 里是单一产品还是产品族？证据是什么（哪类数据库对象）？
CounterpartyAgreement里哪两个字段分别控制”主协议报送”和”产品报送”？- 履约担保协议（PerformanceGuaranteeAgrmt）带来第几个报送开关？三者任一漏勾会怎样？
- 本金保障型确认书有几种？它们按什么维度拆分？
- 本文的”第三方担保/本金保障型”和 61 的”担保品”本质区别是什么？
相关阅读：61-Collateral-Management.md（质押担保品）、38-Regulatory-Reporting-Evolution.md（SAC 报送）、63-Master-Agreement-Comparison.md（主协议）、06-Code-Map.md（确认书 generator 模式）