Underlying And Trading Suspension
ODTS 76 — 标的与交易暂停管理：定价和生命周期的”地基”
为什么需要这篇文档
09 讲了产品生命周期状态机，08 讲了定价依赖 EOD 行情和基准价，72 讲了风控规则可以按”标的”维度拦截。但所有这些系统的共同前置依赖——“标的信息从哪来、停牌了怎么处理、基准价怎么定”——整个系列从没汇总过。
代码库里有一整套标的（underlying）管理域，散落在 eds-web-app 的 action/underlying/ 和 action/dynamic/underlying/ 里。它管着：
- 标的主数据（代码、名称、交易所、证券分类）
- A 股交易暂停（停牌）
- 基准价（base price）
- 标的的”数据质量校验”工作流
这是定价、风控、生命周期三套系统的共同地基。地基不牢，上面全歪。
1. 标的域在代码里的全貌
eds-web-app/src/com/cicc/action/underlying/ — 标的"字典"管理
├── UnderlyingDao(.java/.impl) — 标的主数据
├── AShareTradingSuspensionDao(.impl) — A 股交易暂停（停牌）
├── EdsBasePriceDao(.impl) — 基准价
├── ExchangeDao(.impl) — 交易所
├── CiccSecClsfDao(.impl) — 中金证券分类
├── StkGenInfoDao(.impl) — 股票通用信息
└── model/
eds-web-app/src/com/cicc/action/dynamic/underlying/ — 标的"运行时"操作
├── UpdateUnderlyingAction.java — 更新标的
├── UnderlyingErrorHandleUpdateOneAction.java — 标的错误修正
├── ObtainTodayErrorUnderlyingCntAction.java — 今日异常标的数量
├── ObtainTodayErrorCheckUnderlyingAction.java — 今日待校验标的
├── OptionUnderlyingSubscribeAction.java — 期权标的订阅
└── ...
eds-web-app/src/com/cicc/action/dynamic/
├── SearchBasicUnderlyingInfoAction.java — 基础标的查询
├── FetchAllWhitelistUnderlyingAction.java — 拉取白名单标的
├── CICCUnderlyingTypeGroupQueryAction.java — 中金标的类型分组
├── PortalResetUnderlyingCheckAction.java — 门户重置标的校验
└── UnderLyingBasicInfoSaveAction.java业务定位： 前面几个 DAO 是”标的字典”（静态/准静态数据），后面 dynamic/underlying/ 是”标的运行时”（每天的数据质量工作流）。
2. 标的主数据：一切的起点
UnderlyingDao / StkGenInfoDao / ExchangeDao / CiccSecClsfDao 共同构成标的主数据：
| DAO | 管什么 | 谁依赖它 |
|---|---|---|
UnderlyingDao | 标的代码、名称、类型分组 | 所有交易、风控规则（72 的 underlyingControlType） |
StkGenInfoDao | 股票通用信息 | 行情、定价 |
ExchangeDao | 交易所 | 交易时段、清算日历、SBL 的 exchId |
CiccSecClsfDao | 中金自定义证券分类 | 风控分组、报表口径 |
业务含义： 一笔衍生品交易引用的”标的”，背后是一整张主数据表。如果标的代码录错、或证券分类没维护，下游的定价、风控分组、监管报表全部算错——而且错得毫无声息（不会报红，只是分类归到了错的地方）。这是”地基不牢”最典型的体现。
3. A 股交易暂停（停牌）：和 SBL 是同一只”标的”的两个侧面
AShareTradingSuspensionDao 管的是 A 股的交易暂停——即某只股票因为什么原因、从什么时候到什么时候不能交易。
注意这和 74 文档 SBL 的”融券停牌/复牌”是同一只股票、但两个独立的系统：
AShareTradingSuspensionDao管”这只股票本身能不能买卖”（现货 + 挂钩它的衍生品）BeanSblSuspensionContract（74）管”这只股票的券源能不能借/还”
两者都要读同一份”标的停牌”事实，但各自维护、各自触发动作。一个 PM 在做”标的停牌时衍生品怎么办”的需求时，必须同时想清楚这两层。
停牌直接影响定价和风控
- 定价（08）：停牌股票没有连续行情，基准价（
EdsBasePriceDao）就成了 EOD 估值的替代锚——停牌期间市值用基准价而不是成交价。 - 风控（72）：
underlyingControlType可以按”停牌标的”加禁止交易规则。
4. 基准价（Base Price）：停牌期的”替身价格”
EdsBasePriceDao 管理基准价——当一只标的没有实时/当日行情时（停牌、新上市、流动性枯竭），定价引擎用基准价作为估值的锚。
这呼应 08 §3 “EOD 行情缺失怎么办”：系统有一整套 fallback 链，基准价是其中关键一环。基准价通常由中台定期维护（参考前收盘价、估值价、或模型价），是人工可干预的——所以”基准价准不准”直接决定停牌期间 P&L 的合理性。
5. 标的的数据质量工作流：每天都有”异常标的”要清
dynamic/underlying/ 下有一组数据质量校验动作，说明标的不是录进去就完事，而是每天要巡检：
ObtainTodayErrorUnderlyingCntAction— 今天有多少异常标的ObtainTodayErrorCheckUnderlyingAction— 今天哪些标的待校验UnderlyingErrorHandleUpdateOneAction— 单条修正PortalResetUnderlyingCheckAction— 门户重置校验
业务含义： 标的主数据会”脏”——新标的漏配分类、停牌信息没同步、证券类型映射错。系统每天扫一遍，把异常数量亮出来，中台人工逐条修。这是一个被低估的运营环节：大多数 PM/BA 以为标的信息”天然就在那”，其实它背后有一支每天清数据的隐形队伍。
期权标的订阅
OptionUnderlyingSubscribeAction 表明期权标的需要显式”订阅”——不是数据库里所有股票都能当期权标的，得先订阅、纳入期权定价/对冲的范围。
6. 内行视角：标的域是”被所有人依赖、却没人拥有”的典型的
标的管理最棘手的组织问题是所有权模糊：
- 交易台觉得”这是数据组的事”
- 数据组觉得”这是交易系统该保证的”
- 风险组觉得”标的分类不准我的分组就错”
结果就是 ObtainTodayErrorUnderlyingCntAction 每天都能扫出异常。一个成熟的 PM/BA 会在需求评审时主动问一句：“这个需求依赖的标的主数据，谁来保证它的质量和时效？“——这一个问题能挡掉一半后期扯皮。
自测
- 标的主数据由哪几个 DAO 共同构成？漏维护证券分类会连累哪些下游系统？
AShareTradingSuspensionDao（A股停牌）和 74 的 SBL 停牌，是同一件事吗？为什么不是？- 一只标的停牌期间，EOD 估值用什么价格当锚？这个价格谁维护、能不能人工改？
ObtainTodayErrorUnderlyingCntAction这类”异常标的数量”动作，说明了标的域的什么运营现实？- 为什么做”标的停牌时衍生品怎么办”的需求，必须同时想清楚现货侧和券源侧两层？
相关阅读：09-Product-and-Lifecycle-State-Machine.md（生命周期）、08-Pricing-Models-and-EOD-Valuation.md（基准价/行情 fallback）、72-Credit-and-Risk-Rules-Engine.md（按标的拦截）、74-Securities-Lending-SBL.md（券源侧停牌）