R3. 重大数据与市场事件控制手册¶

内部控制参考

本手册定义重大数据公布、市场事件、异常波动窗口及其他高影响交易时段的系统无关控制原则。

R3 不应包含旧平台路径、Profile 名称、Temporary Plan 名称、固定参数、截图、内部 URL 或固定分钟级事件时间表。

1. 目的¶

R3 用于确保重大市场事件按照已批准的准备、监控、控制验证、恢复确认、事件记录和交班流程处理。目标是降低运营不确定性，而不是把临时事件控制变成没有记录的日常习惯。

2. 事件识别与范围¶

控制窗口开始前，确认：

事件名称和市场相关性；
当前已批准的 Event Calendar / Event & Product Control Sheet 来源；
预计受影响产品和交易时段；
已知假期、流动性条件或平台限制；
当前客户敞口和集中度；
过往事件或重复问题；
需要的值班、复核和升级覆盖。

应使用当前批准的事件日历和内部风险记录，不依赖记忆或非正式市场聊天。

3. 事件时间与时区核对¶

事件时间必须依据当前批准的事件日历及当前平台 Server Time 参考表核对。不得仅凭历史表格、记忆时间或过去时区规则确认事件时间。

每次重大事件前，必须核对：

官方公布时间；
MT Server Time；
Jakarta Time；
Hong Kong Time；
各相关平台当前 Server Time 是否一致；
夏令 / 冬令时间是否已正确转换。

本手册不得写死 GMT+2、GMT+3 或任何平台的永久时间规则。

统一使用以下原则：

按当前平台 Server Time 表和当期时区规则核对；
如平台时间、公告时间或班表提醒存在不一致，暂停后续控制确认，并立即升级；
不得凭记忆、旧表格或上一期事件时间直接判断。

应明确记录：

核对人；
核对时间；
使用的事件来源；
最终确认的控制窗口；
是否存在时区或平台时间差异。

4. 提醒与公告核对¶

事件前必须确认以下事项已准备：

当前 Event Calendar 已更新；
班表或交班提醒已安排；
相关人员已获得必要提醒；
内部公告内容、事件时间和控制窗口一致；
如适用，外部网站或平台公告已由指定负责人核对；
当前事件的待办、负责人和复核时间已明确。

不得记录具体群组名称、人员姓名、内部 URL、旧系统提醒路径或具体 Alarm 按钮。

使用角色名称：

Event Owner；
Shift Leader；
Designated Operator；
Client Communication Owner；
Dealer；
IT On-call。

责任分工：

角色	责任
Event Owner	确认事件日历、时间核对和提醒准备完成
Shift Leader	确认班次覆盖、交班信息和执行责任人
Designated Operator	按批准方案确认相关控制状态
Client Communication Owner	确认公告口径与发布时间
Dealer	确认已收到提醒、监控异常、保存证据、升级及交班
IT On-call	支持技术异常调查，不负责决定风险控制方案

如发现提醒缺失、责任人不明确或公告时间不一致，应视为运营控制缺口，并立即升级处理。

如发现缺口：

Dealer 不得自行假设流程已完成；
必须立即通知 Shift Leader；
由 Shift Leader 指定补救负责人并记录补救动作；
如临近控制窗口仍无法确认，升级至 Manager / Risk Owner。

5. 已批准的事件控制方案¶

已批准方案应定义：

控制窗口；
受影响产品或账户组；
监控重点；
如有，已授权的临时控制；
审批负责人；
复核人和交班负责人；
恢复条件。

Dealer 负责核对已批准状态、监控异常、保存证据、升级及交班。

仅限经授权的 Operator 通过当前授权系统执行或解除已批准的临时控制。Dealer 不得自行启用、调整、扩大或解除任何事件控制措施。

6. 班表、通知与复核¶

重大事件前，由 Shift Leader / Manager 确认：

谁负责报价和执行监控；
谁负责敞口和集中交易流监控；
谁负责客户投诉或争议信号；
谁负责验证临时控制；
控制窗口中由谁批准变更；
事件后交班由谁负责。

可复用培训资料中应使用角色名称，不写个人姓名。

7. 控制窗口监控¶

事件控制窗口中，监控：

报价质量和点差变化；
订单流、拒单、超时、部分成交和快平信号；
敞口集中和客户同向交易；
客户投诉或争议信号；
平台和执行链路状态；
与已批准控制方案不一致的情况。

不得仅凭单一观察扩大控制范围。观察结果与批准方案或预期基线不一致时，应带证据升级。

8. 临时控制验证¶

如已批准临时控制并处于生效状态：

确认其在批准范围内生效；
确认未影响无关产品、账户或时段；
确认监控证据已保存；
如系统执行结果与批准内容不一致，立即升级。

每次批准变更后，都应重新验证。

9. 事件后恢复¶

控制窗口结束后：

验证已批准的临时控制是否按指示解除、恢复或保留；
确认报价、执行和平台状态已回到约定运营状态；
复核受影响订单、争议和未关闭客户影响信号；
记录需要延续到下一班的事项。

恢复完成不是事件结束，而是完成验证并完成交班。

10. 事件与交班记录¶

事件记录必须包括：

事件和控制窗口摘要；
已批准方案和审批状态；
控制验证结果；
报价、执行、敞口和投诉观察；
事件或异常订单；
未关闭事项和负责人；
下一次复核触发条件。

11. 需要 Manager 确认的事项¶

以下项目在成为永久规则前，需要 Manager 最终确认：

事件控制窗口；
事件时间与时区核对标准；
提醒与公告责任分工；
临时控制权限；
恢复标准；
客户争议处理阈值；
敞口集中升级阈值；
事件后复盘负责人。