ODTS 21 — 交易日时间线：从晨会到午夜批处理

一个衍生品交易台不是 9 点到 5 点的作息。交易日有明确的阶段，每个阶段涉及不同的人、系统和风险。对做这个系统的开发者来说，理解这个时间线至关重要——一个在早上保证金催缴 (margin call) 期间出现的 bug，业务影响是同一 bug 在下午 3 点出现的 100 倍。

全景

07:30  — Market data refresh (prices, rates, vol surface)
08:00  — Morning meeting (risk review, P&L explanation)
08:30  — Market opens
09:00  — Margin call preparation (VM calls sent)
09:30  — Trading begins (new trades, amendments)
11:30  — Morning session ends
13:00  — Afternoon session begins
15:00  — Market closes
15:00  ├─ Post-market (corrections, late bookings)
        └─ Settlement batch starts
16:00  — Confirmation matching, chasing
17:00  — Regulatory report preparation
18:00  — EOD batch starts (10-step process)
20:00  — EOD batch completes (if nothing breaks)
20:30  — Operations final review

每半小时详解

07:30 — 市场数据刷新

系统醒来，加载隔夜市场数据：从上交所/深交所获取股票价格、利率数据 (SHIBOR、LPR、CNY IRS 曲线)、汇率 (USD/CNY、HKD/CNY)、流动性标的的波动率曲面 (vol surface) 和股息预测 (dividend forecast)。

可能出错的地方：数据源延迟（交易所延迟）会使风险数据过时；数据损坏（错误价格）会导致 P&L 错误；数据缺失（停牌股票）则系统必须妥善处理。系统必须在 08:00 前完成，否则早间风险报告就是错的。

08:00 — 早间风险晨会

首席交易员 (head trader) 审阅：前一天的 P&L（按簿记本分盈亏）、当前敞口（每个标的的 Delta、Gamma、Vega）、今天到期的保证金催缴（哪些客户欠钱）、隔夜市场波动（是否有跳空 gap）。

系统职责： 08:00 前生成早间风险报告。如果迟到了，交易员不高兴。如果报告错了，他们盲目交易。

08:30 — 市场开盘

上证和深交所在 09:30 开盘，但交易台从 08:30 开始准备。

09:00 — 保证金催缴

这是每天操作风险最高的时间段。保证金流程计算初始保证金 (IM) 和变动保证金 (VM)，通知客户（邮件/Bloomberg chat），并对逾期催缴升级到信用风险部门。

为什么 09:00 很重要： 客户期望 09:30 前收到保证金催缴。催缴晚了意味着客户付款时间少，容易引发争议和信用风险升级。错误的催缴（多收）损害客户关系。遗漏的催缴（少收）增加对手方风险。

09:30—11:30 — 上午交易时段

最繁忙的时间。新交易的流程是：在 Bloomberg 聊天或电话中达成一致 → 交易助理 (trade assistant) 在系统中簿记 → 风险检查（是否超过任何限额）→ 交易详情发送给客户进行确认。

此期间系统负载：高写入量（新交易、修改）、高读取量（交易员查看持仓和风险）、保证金催缴发出、确认模板发送。

11:30—13:00 — 午休

中国市场中午休市，交易暂停。系统得到喘息，但结算继续处理，确认继续匹配，批处理可以开始准备。

13:00—15:00 — 下午交易时段

与上午类似，但多了一项活动：关前冲刺——交易员争分夺秒完成午间谈判的交易。收盘前最后 30 分钟（14:30–15:00）最紧张。

如果一笔交易在 14:30 簿记，需要进入今天的批处理，只有 3.5 小时用于簿记 → 结算 → 确认 → 批处理。任何延迟都会级联：迟簿记 → 迟确认 → 迟批处理。

15:00 — 市场收盘

市场收盘，但交易台的工作还没完。两个并行流程启动：

盘后 (15:00–17:00)：修正簿记错误的交易、迟到的簿记（今天已达成协议但尚未簿记的交易）、修改（客户要求变更）。

结算批处理 (15:00–15:30)：计算净资金变动，结算指令发送至托管行，证券过户指令发送至 CSD。这是当晚第一个自动化批处理，输入包括今天到期的所有交易、今天有票息/分红事件的交易、今天到期的保证金催缴。输出包括结算文件 (CSV/XML) 和异常报告（结算失败的交易）。

为什么 15:00 必须立即运行？上海清算所 (Shanghai Clearing House) 有截止时间。托管行 16:00 后停止接收指令。任何延迟意味着结算失败，进而导致现金罚款。

16:00 — 确认匹配

到 16:00，今天的所有交易应该已簿记完毕。确认团队从系统导出所有新交易，生成确认书 (DTCC CTM / 邮件 / 传真)，发送给对手方进行匹配，追踪未匹配交易并跟进。

痛点： 如果一笔交易在 14:55 簿记且有错误，确认书就是错的，16:00 匹配失败。运营必须纠正并重新发送。这会将结算推迟一天。

17:00 — 监管报告准备

系统生成 SAC XML 报告（今天簿记的所有境内 OTC 交易）、SFC 报告（香港交易）、CSRC 报告（零售结构化产品）。这些要经过审核检查表，次日早上提交。

18:00 — EOD 批处理启动

主事件：10 步批处理流程。

Step 1:  Market data archival (snapshot closing prices)
Step 2:  Position reconciliation
Step 3:  Trade enrichment (attach market data to all trades)
Step 4:  Risk computation (Greeks for all LIVE trades)
Step 5:  Margin computation (IM/VM per CSA)
Step 6:  P&L computation (mark-to-market)
Step 7:  Settlement generation (for next day)
Step 8:  Accounting entries (GL posting)
Step 9:  Regulatory report generation
Step 10: Data archival (cleanup, partition maintenance)

20:00 — EOD 批处理完成（目标）

如果一切顺利，批处理 20:00 前完成。运营审核 P&L 解释（为什么赚钱/亏钱）、风险报告（明天的敞口是什么）、异常报告（什么失败了）。

20:30 — 运营终审

一天中最后一次人工检查：所有保证金催缴都发出去了吗？所有确认书都匹配了吗？所有报告都生成了吗？系统准备好迎接明天了吗？

什么让这个时间线变得困难

问题 1：批处理窗口太短

EOD 批处理只有约 2 小时（18:00–20:00）来处理所有事情。如果批处理运行超过 20:00，运营加班，明天的市场数据可能冲突（数据源竞争），疲劳时更容易犯错。

问题 2：实时与批处理的冲突

交易员有时希望在 15:00 后簿记交易。但结算批处理 15:00 就开始了。如果交易员簿记的同时结算批处理在运行，会出现竞态条件 (race condition)：新的资金流转是否包含在结算中？

临时方案： 资金划拨表上有个 IS_FROM_TRANSFER 标志。结算批处理查询 WHERE isFromTransfer = '0'，交易员簿记时手动将 isFromTransfer = '1'。这是创可贴，不是解决方案。

问题 3：09:00 截止时间的悖论

保证金催缴基于昨天的 EOD 数据计算。但如果昨天的 EOD 批处理有错误（常有的事），早上的保证金催缴就用了错误数据。保证金团队必须决定：用昨天的数据（快，但可能不对）还是重算今天的风险（正确，但需要 2 小时）。现实中，他们用昨天数据，必要时手动调整。

日历异常

时间线在以下情况会有变化：中国市场提前收盘（节假日前夕）批处理 13:00 就开始；半天交易（如春节前夕）所有事情压缩到 4 小时内；年末批处理可能运行 6+ 小时（交易更多、检查更多）；市场波动剧烈时保证金催缴激增，运营加班；系统升级日批处理必须在维护窗口前完成。

开发者须知

如果你的代码在 15:00–18:00 之间运行，你正处于一天中最关键的窗口。一个 bug 意味着：结算失败（真金白银的损失）、确认失败（监管风险）、批处理延迟（运营加班）、保证金催缴错误（对手方风险）。

经验法则： 周三上午 10:00 部署到生产。绝对不要在周五下午 15:30 部署。

大厨私房话

一位交易台老手告诉我，判断”新人”最显著的标志是问”市场几点收盘？“好像那是一天的结束。正确的问题是”批处理几点结束？“——因为那才是你真正能回家的时间。

每个时间窗口的商业价值： 交易台一天的固定成本（人员 + 系统 + 办公室）约 40–60 万/天。上午 09:30–11:30 的高峰期每小时产生约 10–15 万利润（新交易簿记、对冲执行）。如果一个 bug 在 10:00 阻塞交易簿记 30 分钟，机会成本约 5–7.5 万。而在下午 15:00–16:00 的结算窗口，延迟 30 分钟不会直接损失 P&L，但可能导致结算失败罚金（几百到几千元）和运营加班（500–1000 元）。系统研发在评估 bug 优先级时，需要知道上午 10 点的 30 分钟阻塞比下午 3 点的 30 分钟阻塞贵了 100 倍——但开发者常常不在代码里标注”这段代码在上午 10 点运行”。