OTC Derivatives
Options, swaps, and the risks hedged and unhedged.
场外衍生品（OTC Derivatives） 是指在非公开市场、由交易双方直接协商达成的衍生品合约。与交易所交易的衍生品（如股指期货、商品期货）不同，OTC 衍生品具有以下核心特征：
收益互换是指交易双方约定在未来一定期限内，一方支付挂钩标的资产的收益，另一方支付固定或浮动利率的合约。
PE[私募基金] -->|雪球/杠杆/对冲| D[衍生品业务]
A[Pre-Trade 交易前] --> B[Execution 交易执行]
ISDA（International Swaps and Derivatives Association） 是全球衍生品行业标准制定组织。ISDA 主协议是国际 OTC 衍生品的"宪法"。
MR[市场风险] -->|Greeks/VaR| MP[市值计量]
抵押品（Collateral）是 OTC 衍生品信用风险管理的第一道防线：
如果一个衍生品的价格偏离了其复制组合的成本，套利者就会进入市场，推动价格回归。
CSRC --> B[交易所 SSE/SZSE/CFFEX]
A[结构化产品] --> B[固定收益部分<br/>零息债券 / 贴现债券]
Impact --> Sys[系统处理<br/>估值调整/合约修改/清算]
DH[交易台主管 Desk Head] --> Sales[销售 Sales]
Biz[业务部门<br/>Sales/Trading/Risk/Ops] -->|需求| PM[产品经理 / BA]
解决什么问题：Sales 做产品方案时，以前靠手工拼 PPT/Word——慢、容易错、格式不统一、合规风险高。系统自动生成后：快、一致、审计可查。
KYC 调查（身份识别、受益所有人、资金来源、政治人物筛查）
角色：法务合规部（Compliance）、风险管理部（Risk Management）
A[阶段一<br/>客户需求] --> B[阶段二<br/>客户准入]
xVA 是衍生品估值的价格调整，本质是对"交易对手可能不付钱"、"融资要花钱"、"资本占用有成本"这些现实问题的量化修正。
Black-Scholes 假设波动率是常数，但现实不是。波动率曲面描述了不同行权价（Strike）和不同期限（Tenor）对应的隐含波动率。
A: Total Return Swap — 总收益互换（也称收益互换）
E1[环节1: 需求发现<br/>Sales→客户] --> E2[环节2: Term Sheet<br/>系统生成]
<a id="section-risk-greeks"></a>
最后一步：回头看 README.md 检查是否有遗漏
A learning-record captures a non-obvious lesson or key insight — equivalent to an
用户要的不是"IT → 业务"的单线转型，而是产品（业务）与 IT（代码/系统）双线同时精通。
在 ~/odts1（hedging-as / eds-web-app / eds-price-server）全量检索 CS01|Cs01|CreditSpread|creditSpread（Java，大小写不敏感）结果为 0 命中。
风险（0007）、监管（0008）、架构（0009）三条支线看似独立，实则共享同一个根因：ODTS 是围绕一个共享 Oracle schema 的集中式单体，服务间靠文件轮询/异步集成，且有两套定价引擎。
为后续每一节课打地基：先建立"地图"，产品与系统各给一个锚点。
把 0001 的语汇串成一条主线——一笔交易在端到端路径上，哪一步发生、哪段代码跑了、什么顺序。
一类最"干净"的 OTC——只有利率因子。学完你就懂了上一问的 DV01 是怎么从一笔交易里长出来的。
券商 OTC 业务量最大的产品。如果你只能深懂一个，就是它。它把"杠杆配资 + 标的收益 + 融资利率 + 信用利差"压进一笔交易。
近 3 年中国最火、也最复杂的 OTC。本质是"卖出看跌期权 + 自动赎回"。理解它，就理解了路径依赖型产品的全部难点。
期权是结构化产品的"乐高积木"——雪球的看跌、TRS 的凸性，拆开都是期权。这课把 Greeks 全家族一次讲清，并落到真实代码。
一笔交易"盯市（MTM）"后，风险怎么度量、资本怎么占用、敞口怎么限额——这是 0002 阶段 4/6 的纵深展开。
同一笔交易，为什么系统要生成三套不同格式的报告？——因为对手方签的"主协议"决定了法律框架与报送通道。
把前面所有支线（产品/风险/监管）放进同一张系统地图——并看清"为什么迁移这么慢"。
这 10 题不考孤立记忆，而是考"一个概念跨两节课怎么接"——PM/BA 真正的功力在此。
记录每节课的错题，随时回来重做。答对 2 次自动从错题本移除——真正掌握的题不再反复出现。
簿记了、定价了，但钱还没有动——追保与结算是业务运营的日常痛点，也是 0004/0007/0008 没有展开的纵深。
簿记了头寸、生成了对冲建议，但交易员说"等等"——理解对冲工作流的本质，是成为合格交易台成员的第一步。
0005 教"雪球是什么"，这节教"雪球为什么是这样定价的"——以及它如何反过来影响市场。
CSA（信用支持附件）是 OTC 主协议的"安全协议"，定义了抵押品如何交付、估值、替换——没有它，0004 和 0012 里讨论的追保就是无根之木。
一个台一年盈亏几千万，靠的不是"猜对市场"——而是三块收入来源的系统化管理。
日终批处理是 OTC 交易系统的"心跳"——它把 5000+ 活跃交易从 T 日状态推进到 T+1 状态，每一步失败都可能引发连锁反应。本课拆解 10 个步骤、幂等性设计原则与真实故障案例。
券商 OTC 衍生品部门的 IT 专家 / 准 PM-BA。
A MISSION.md captures _why_ the user is learning this topic. It grounds every lesson.
结论： 不存在"2010 启动"。所有仓库中没有任何一个在 2015 年之前有提交。原"2010 / 早 6 年"的叙事是错误记忆，已删除（含"contract-first 在 2010 年超前"的论断改为 2015 年前后）。
中金公司 (CICC) 的权益衍生品交易台 (equity derivatives desk) 在 2014 年时规模很小：约 10 人——3 个交易员 (trader)、2 个结构化产品设计师/量化 (structurer/quant)、3 个销售 (sales)、2 个运营 (operations)。
2016–2017 年是 雪球 (Snowball) 结构化产品的"淘金热"(gold rush)。
2018 到 2021 这三年，交易台从一个小众结构化产品精品店 (boutique) 变成了中国 top-3 的 OTC 衍生品做市商 (dealer)。
到 2021 年，中金 OTC 衍生品交易台不再是创业团队了。它是一个中国 OTC 衍生品 top-3 做市商，和中信、广发及其他主要券商直接竞争。
业务型实习生加入交易台后，知道 Java、Spring Boot、Vue，读过 01–04 了解了系统演进，但还是答不出最重要的问题：
这篇文档是 ~35 个项目（~/odts1/ 下）的导航索引。每个项目回答三个问题：这个项目做什么？→ 关键包是什么？→ 什么时候会动它？
你知道 Java、Spring Boot，但不知道 TRS 是什么，雪球为什么敲出 (knock out)，NDF 怎么结算。这篇文档填补这个空白。
定价引擎 (hedging-as) 是整个 ODTS 中智力密度最高的部分，也是所有开发者觉得最难 debug 的——不是代码逻辑复杂，而是数学不熟悉。这篇文档从业务直觉讲到代码结构。
作为一个新开发，你会发现 ODTS 的架构是……分层的。有些部分是 2022 年的 Spring Boot，有些是 2016 年的 JFinal，有一个模块至今在用 2015 年的 raw JDBC。这篇文档解释为什么——更重要的是，我们怎么迁移的和还剩什么没干。
前面 9 篇文档告诉你了系统是什么。这篇告诉你怎么改它。
你已经读了 TRS、Snowball、NDF、Barrier Option 是什么。但交易台不是为了好玩才做这些——它们是为了赚钱。
系统产生的每一个价格——每一个 MTM、每一笔保证金、每一份风险报告——都始于外部世界的一个数字：
客户在交易之前必须经过上线 (onboarding) 流程：
交易簿记了。定价引擎估值了。但这两件事一分钱也没有动。结算是钱实际易手的地方。
交易台做的每一笔交易都会产生风险。卖出一张看涨期权 → short gamma。一个 TRS → long delta。一张 NDF → 外汇敞口。
每一笔 OTC 交易都有交易对手风险。如果对手违约，交易台持有的头寸可能已经亏了钱。保证金 (Margin) 就是防范这个的担保金。
电话里的交易不是交易。Bloomberg chat 里的交易不是交易。只有双方签署确认书说"是的，我们按这些条款做了这笔交易"，交易才是真的。
5. 计算所有 Greeks (delta, gamma, vega, theta, rho)
在中国境内，每一笔场外衍生品交易必须在 T+1 内向中国证券业协会 (SAC) 报送。报送内容包括交易要素（对手方、产品类型、名义本金、期限）、风险要素（Delta、Gamma、Vega、对手方敞口）和抵押品要素（IM、VM 金额）。
对于业务人员来说，数据库是不可见的——它是"系统背后的系统"。但数据库出问题时，症状总是很显眼：下午 3 点交易簿记失败、午夜 EOD 批处理崩溃、监管报告数据对不上、新产品上线延迟两周……这些都是由数据库技术债 (technical debt) 引发的业务问题，不是技术问题。
一个衍生品交易台不是 9 点到 5 点的作息。交易日有明确的阶段，每个阶段涉及不同的人、系统和风险。对做这个系统的开发者来说，理解这个时间线至关重要——一个在早上保证金催缴 (margin call) 期间出现的 bug，业务影响是同一 bug 在下午 3 点出现的 100 倍。
背景： 2022 年一个周一早上。保证金团队运行每日变动保证金 (VM) 计算。一个客户的催缴显示为 5000 万人民币。上次催缴是 500 万。"他们的持仓变了？""没有，和周五一样。""标的物价格有变动？""略微波动，但不会有 10 倍。"
每笔场外衍生品交易都需要一个价格。但"价格"在不同语境下含义不同：交易簿记 (trade booking) 时是客户支付/收到的权利金 (premium)，计算于交易时 T+0；每日 P&L 时是盯市价值 (mark-to-market)，计算于 EOD 批处理；保证金 (margin) 时是需要多少抵押品，计算于 EOD 批处理和次日早上；风险 (risk) 时是持仓对市场波动的敏感度，计算于 EOD 批处理；提前了结 (unwind
场外衍生品交易台承担风险。每笔交易都有风险。问题不是"我们有没有风险？"而是"我们知道自己的风险是什么吗？"风险管理是以下实践的循环：衡量风险（我们可能损失多少？）、设定限额（允许我们损失多少？）、监控风险（我们在限额内吗？）、缓释风险（对冲、保证金、提前终止）。
投资银行的场外衍生品系统不是一个单一应用。它是一个由 45 个以上项目组成的生态系统，通过 Protobuf TCP、HTTP REST、文件和数据库进行通信。每个项目有特定的职责。这不是过度设计——每个服务对应一个独立的业务领域，比如结算、确认、保证金、抵押品管理、报告、会计等——它们各自有不同的发布节奏和团队。
两方各自计算同一笔交易的盯市价值 (MTM)，算出不同的数字，然后催缴 (margin call) 和抵押品支付就对不上了。
Novation（交易对手变更） 是指一笔存续期交易的一方将其权利和义务全部转让给第三方，原对手方退出，新对手方加入。
雪球本质上是一个带敲入敲出障碍的奇异期权，挂钩一只股票或指数，只要标的不大跌，持有者定期获得高票息。名字由来：雪球越滚越大——只要不触发敲出，持有期越长，累计票息越高。
每个估值日（通常是每个营业日），基金管理人或托管人对衍生品组合进行集中度检查 (concentration check)：所有衍生品合约的名义本金 (notional) 加总后，除以基金的净资产 (NAV)，不能超过监管或基金合同约定的阈值。
普通（香草）期权的特点是：只要到期时是价内 (ITM)，持有者就获得收益。障碍期权在此基础上加了一个条件——标的在存续期内触碰到某个价格水平时，期权会"消失"（敲出）或者"出现"（敲入）。
场外衍生品的每一笔交易背后都有一份或多份法律文件。这些文件在很多公司至今仍然以 PDF 附件 + 邮件的方式流转。"合同在邮件里"不是一句笑话。
ODTS 系列目前 32 篇（含本文），覆盖了 OTC 衍生品业务和系统的核心框架——交易生命周期、产品类型、风险、估值、合规、角色地图。但如果按"一个 PM/BA 入职后应该知道的全部东西"算，还有大量空白。
CICC（中金公司）的 OTC 衍生品系统是一个 10+ 年演进的庞然大物。两个世代并存：
eds-web-app 是 CICC OTC 衍生品系统的单一主后端。它从 2016 年底一个简单的 Struts2 项目起步，经过 10 年演变为一个包含 Struts2 + Spring Boot + MyBatis + ActiveMQ + Kafka 的大型混合架构系统。
eds-price-server 是一个独立于 eds-web-app 运行的定价服务。注意它的 commit 分布和 eds-web-app 一样从 2016 年开始，说明定价引擎从一开始就被设计为独立服务——这是一个早期的架构决策。
hedging-as（Hedging Application Server）是 CICC OTC 衍生品系统的实时对冲与风险引擎，负责 delta/vega 等 Greeks 的对冲计算、保证金管理、合约状态机流转和复杂产品的 Python 估值桥接。
CICC 的 OTC 衍生品前端经历了三个世代的技术栈变迁：
sac-report 是 CICC OTC 衍生品监管报送专用服务进程，负责向 SAC（中国证券业协会）、ISDA（国际互换与衍生品协会）、NAFMII（中国银行间市场交易商协会）三大协议体系生成和报送交易数据。
├── 前端 ───────────────────────────────────────────
eds-utility 是 CICC OTC 衍生品系统的共享类库，被 eds-web-app、hedging-as、sac-report、eds-price-server 等几乎所有 EDS 系统引用。它不是独立的进程，而是一个 JAR 包。
odts-option-web 是 CICC OTC 衍生品系统的期权交易前端，基于 Vue.js 技术栈，独立于 eds-web-app 的 JSP 页面运行。
new-edsweb 是一个运营后台前端项目，面向以下用户群体：
CICC 的 OTC 衍生品系统有 15+ 个独立服务进程。它们之间的通信不是通过统一的 API 网关或 Service Mesh，而是通过 7 种不同的协议，每种协议服务于特定的通信场景。
CICC OTC 衍生品系统的 CI/CD 不是一个统一的平台，而是三种模式的混合：
衍生品系统本质上是一个数据加工厂：交易从对手方来，经过定价、风控、结算、报告四个环节，每个环节产生新的数据。理解了数据在哪、怎么走，就理解了系统的一半。
在衍生品系统里，一个 bug 的代价不是"改一行代码"——一笔错误的保证金计算、一个被遗漏的敲出事件，可能意味着几十万甚至上百万的损失。
edsWeb (odts1) ofareg (odyssey) unilink (新前端)
用户层 听云 (Tingyun APM)
35+ 个子系统如何知道彼此的存在？当一个系统要查找一笔交易的信息时，它怎么知道该调用什么接口、传入什么参数、得到什么格式的响应？
CATS（Commodity Auto Trading System）位于 /odts1/CATS 目录中。从目录名看它和 ODTS 在同一级，但从深处看它是商品部自用的交易系统。Git log 显示只有 79 次提交，活跃期约一年（2019-2020），之后再无人问津。
CATS（Commodity Auto Trading System）是中金公司 Commodity 部门的商品交易管理系统，覆盖从交易录入到最终结算的全生命周期。它和 ODTS（Options Derivatives Trading System）在同一个技术平台（BaseWeb/Spring+Hibernate）上构建，但 CATS 只处理商品类交易，而 ODTS 处理更广泛的权益类/指数类场外衍生品。
ODTS（Options & Derivatives Trading System）作为中金公司的 OTC 衍生品核心交易管理系统，自 2013 年（Struts2 时代）至今，已经发展成一个由数十个业务模块和微服务组成的庞大生态。ODTS 本身并不孤立运作——它与交易员手中的 Excel 文件、清算所的接口、监管机构的报送系统、行情数据源、内部风控平台、数字认证平台等数十个外部系统保持实时或准实时的数据交换。
subgraph Business["业务系统 Business Systems"]
场外衍生品交易中，所有 P&L 最终要变成资金流动：票息支付、margin call 催缴、到期结算、敲出结算。这些资金通过 IPMP 从交易台的银行账户转到客户账户（或反过来）。IPMP 出问题 = 交易台无法支付 = 违约。
数字证书是衍生品合同签署的"最后一公里"——它把系统里的交易数据变成具有法律效力的文件。这个环节出故障，前面的所有流程都白费。
Doc Agent 是"交易数据变成法律文件"的关键环节。这个环节出错没有中间状态——要么生成了正确的 PDF，要么没生成。没有"差不多能用"的确认书。
Dipper 是 ODTS 的数据同步平台,与其底层消息系统 Pulsar (Apache Pulsar) 配合,负责将生产环境 (Oracle EDS) 的交易数据实时或准实时同步到决策分析数据库。
通知服务是交易台与客户/运营之间的"最后一句话"——所有系统处理的结果，最终要通过通知告知人类行动。通知失败 = 业务流程无声断裂。
HCP (Hitachi Content Platform) 是 ODTS 使用的对象存储系统,用于存储所有二进制文件——合同 PDF、报表输出、上传附件、证书文件等。
场外衍生品交易中，银行和托管行代表了"最后一个信任环节"——它们持有交易台的真实资金。如果文件交换出了问题，资金不会自动移动到正确的位置。这在 2022 年之前是最常见的故障模式之一。
如果你问一个交易员"这笔 TRS 赚了多少？"，他会给你一个数字。但这个数字不是最终利润——它是未经过 XVA 调整的。XVA 是"把合同上的利润转化为真正的利润"的一系列调整。 对 PM/BA 来说，理解 XVA = 理解你的系统输出的 PnL 和财务入账的 PnL 之间的差距。
在 OTC 衍生品世界里，没有抵押品就没有交易。 一笔 TRS 的名义本金可能是 5 亿，交易对手如果不给保证金，交易台的敞口就是赤裸的 5 亿风险。担保品管理回答了一个朴素的问题："如何确保交易对手不会白嫖？" 它的核心流程——初始保证金 (IM) 计算、变动保证金 (VM) 追缴、抵押品替换、争议处理——是 ODTS 系统中 PnL 之外交易量最大的处理环节。
在 ODTS 的交易量中，利率衍生品占不到股权衍生品的份额——但它的业务复杂度、风险规模和对系统架构的冲击力远超股权类产品。一笔 10 年期 IRS 的名义本金可能高达 50 亿，它涉及的现金流计算（逐日计息、reset、摊销）跨越十年。对 PM/BA 来说，利率衍生品是理解"为什么 OTC 系统的数据模型如此复杂"的关键入口。
"客户签了 ISDA 没有？" ——这是衍生品交易中第一个问的问题。没有主协议，一笔交易就没有法律框架——没有净额结算权，没有违约处理机制，没有保证金要求。对 PM/BA 来说，理解这三个协议体系的差异，就是理解为什么系统要为同一个数据生成三套不同格式的报告、为什么某些客户只能用某些协议、为什么保证金计算规则因协议而异。
ODTS 的大部分交易是双边清算的——交易台直接对客户承担信用风险。但中国市场正在推动 OTC 衍生品进入中央对手方清算 (CCP) 的时代。上海清算所 (SHCH) 已经要求标准 IRS 集中清算。SAC 的保证金规则也倾向于推动更多产品走 CCP。对 PM/BA 来说，CCP 清算不是系统功能——它是整个 OTC 市场基础设施的底层变化，影响协议的每一行。
ODTS 不交易信用衍生品。 这是一个重要的事实——中金的 OTC 衍生品业务以股权类（TRS、期权、雪球）为主，信用衍生品（如 CDS）的交易量极小，中国版的 CDS（即 CRM/信用风险缓释工具）更是尚未推广开来。但信用衍生品概念渗透在 ODTS 的多个领域中——尤其是 CVA/DVA 的输入参数（CDS 价差）、监管报告中的信用风险数据、以及 NAFMII 框架下的银行间市场业务。这篇文档解释 CDS 和 CRM 是什么，以及它们
CSA 是 ISDA 主协议 (Master Agreement) 的附件，规定了双边衍生品交易里一方如何向另一方提供抵押品（担保品）来覆盖信用风险。一句话：没有 CSA，就没有保证金；没有保证金，OTC 交易在监管口径下不能做。
在 2016 年前，交易商之间的 OTC 衍生品大多不收初始保证金（只有 VM 变动保证金）。2008 年危机后，G20 在匹兹堡峰会定调：所有标准化的 OTC 衍生品要集中清算 + 收双边保证金。
产品设计 (term sheet) → 交易录入 (trade capture) → 风控校验 → 估值 (pricing)
定价引擎 (Pricing Engine) 不能嵌在 Web 应用里，原因（基于 51 文档单体天花板教训）：
① 交易录入 (trade capture) eds-web-app / 终端
8:30 小李打开录入界面（见 16/25 文档），客户要买一笔雪球。他要填十几个字段（见 68 文档）：敲入价、敲出价、观察频率、票息……
前面 16-Margin-Calls、24-Risk-Management-Framework 讲的是事后的风险——保证金催缴、VaR、压力测试。但 OTC 衍生品最重要的风险防线其实在交易发生之前：一笔交易能不能做、做多大、用哪个账户做，是由一套风控规则引擎在簿记瞬间实时裁决的。
24-Risk-Management-Framework 讲了风险管理的概念和后台模型，16/61/64 讲了保证金、担保品、中央清算。但有一个真实存在、且风险官每天在用的系统，整个系列从没写过：
整个 ODTS 系列写满了期权、远期、互换、收益凭证、雪球这些"主角"产品，但代码库里有一类独立、真实存在、却从未被文档提及的簿记业务：
31-Contract-Operations 里提过一句关键的踩坑："额度预占失败导致交易被拒"。但"额度"本身——客户/账户到底有多少可交易额度、怎么查、怎么占用、怎么在日终重置——整个系列从没专篇写过。
09 讲了产品生命周期状态机，08 讲了定价依赖 EOD 行情和基准价，72 讲了风控规则可以按"标的"维度拦截。但所有这些系统的共同前置依赖——"标的信息从哪来、停牌了怎么处理、基准价怎么定"——整个系列从没汇总过。
61-Collateral-Management 写了"担保品"（现金/债券质押覆盖保证金），72 写了"风控规则引擎"，76 写了"标的"。但有一类真实存在、且直连监管报送的业务域，三篇都没覆盖：
72 写了 eds-web-app 里的 RiskRule 规则引擎（规则怎么配置、怎么通过 ActiveMQ 广播）。73 写了风险官用的 rm-web 前端。但中间缺了最关键的一环：
08-Pricing-Models-and-EOD-Valuation 讲了定价的机制（EOD 估值、行情依赖、基准价 fallback、Payoff 函数），但没回答一个 PM/BA 最该先知道的问题：
08-Pricing-Models-and-EOD-Valuation 讲了"理论公允价值"怎么算（Payoff + 行情 + 模型）。但真实世界里，一笔场外衍生品在账上以公允价值入账时，还要再叠一层估值调整（XVA, X-Valuation Adjustment）——因为对手方可能违约（CVA）、自己也可能违约（DVA）、资金占用有成本（FVA）、抵押品有成本（ColVA）……
80-XVA 提到 KVA（资本估值调整）是 XVA 的一项，资本占用要折算成经济成本。但"监管资本"本身是一个独立的大主题，32-Coverage-and-Gaps 把它列为没覆盖的重要领域。本文用业务语言讲清楚：一笔场外衍生品，为什么不仅要占用额度（75）、要押保证金（16/73）、还要消耗一层"监管资本"。
08-Pricing-Models-and-EOD-Valuation 讲了衍生品怎么估值，31-Contract-Operations 讲了合同怎么运营，但没讲一个财务视角的致命问题：一笔衍生品，经济上是赚钱的，会计报表上可能完全不体现，甚至体现为亏损。 这就是对冲会计（Hedge Accounting）要解决的事。
从零开始写/重写 ODTS 文档系列，每一篇从业务领域出发（"一个懂点 Java 但对衍生品不了解的业务型实习生，能通过文章了解业务，然后立即上手看代码"）。计数器从 100000 开始，每写一篇或优化（重写）一篇，减 1。直到 0。
不是"学知识"，而是获得角色地图——每个同事每天几点在做什么、需要系统做什么、你该何时找他们谈什么。
系统里需要维护的定价参数（PM需知道每个参数的来源）：
Monitor -->|价格 ≤ 敲入价| KI[敲入状态]
结构化票据收益 = 保本本金 + 固定票息（保本型雪球票据）
A[支付 LPR+利差<br/>年化] -->|融资成本| B{收益互换}
核心区别：结算解决的是"到期了钱怎么划"，抵押品解决的是"还没到期但风险变了，先交点东西垫着"。它们跑在不同的时间节奏上，用不同的系统。
学习分 4 个阶段，按顺序推进。每个阶段标注了（了解 / 理解 / 掌握 / 熟练）四级要求。
学习完成！回顾 README.md 查看学习路径
官网地址：https://www.csrc.gov.cn
RESOURCES.md tracks high-trust sources used to ground lessons. Lessons should link out to these.
A[风险事件<br/>行情波动 / 操作失误] --> B[检测]
A[私募基金] -->|雪球/杠杆/指数| D[OTC 衍生品]
合规系统不是独立系统——它的规则必须嵌入到所有其他系统中：
│ > "这个交易要占用 5000 万，对方只剩 3000 万了"
PM 看到的是"功能"，开发看到的是"结构"。理解他们的视角才能沟通：
│ 和新交易对手签 ISDA Master Agreement
下一角色：role-risk.md 风控的一天
│ Delta 贡献了多少？Gamma？Vega？Theta？
│ 交易员/structurer 报过来一个定价结果"看起来不对"
│ > "隔夜美股跌了2%，我们的Delta敞口扩大了多少？"
│ 你需要的系统：晨会看板（市场数据+产品推荐+客户持仓摘要）
│ 销售带着客户需求来了："客户要挂钩中证500，保本80%，上限15%"
│ 查看隔夜 Greeks 变化——昨晚市场波动对持仓的影响
没有对冲头寸就卖出期权、收取权利金。交易台一般不会裸卖——监管也不让——但客户问"你们能不能做"的时候，意思是"你们是不是自己扛风险"。
Risk_SYS[风险管理系统<br/>限额/Greeks/VaR]
┌──────────────────────────────────────────────────────────────────┐