课程 5.2 - 成交延迟调查¶
情景¶
“客户说订单花了十秒才成交”¶
一笔 XAUUSD 市价单花了十秒完成。调查不能只用最终成交时间，而要拆分：客户端到服务器、Trade Server 处理、Bridge 路由、报价源响应及结果返回。
学习目标¶
- 建立端到端执行时间线。
- 在客户端、服务器、Bridge 和报价源层定位延迟。
- 区分孤立延迟和广泛执行恶化。
执行时间线¶
客户终端请求
↓
交易服务器接收与校验
↓
执行 / 路由处理层
↓
成交或拒单结果返回
↓
客户终端显示确认
调查重点是确认延迟发生在哪一段：请求到达前、服务器处理、Bridge 队列、报价源响应，还是结果返回展示。
延迟分段¶
| 分段 | 关键问题 |
|---|---|
| 客户端到服务器 | 请求是否已经延迟到达？ |
| Trade Server 处理 | 验证、保证金或风控检查是否变慢？ |
| Bridge 路由 | 订单是否在队列中等待？ |
| 报价源响应 | 报价源响应是否变慢？ |
| 结果返回 / 展示 | 成交结果是否延迟显示？ |
调查流程¶
- 定位客户投诉对应的订单或成交记录。
- 建立完整时间线，包括下单时间、服务器接收时间、成交或拒单时间、结果返回时间。
- 对比同一时间段、同一品种或相似手数的其他订单。
- 检查 Trade Server 状态、Bridge 队列、拒单、超时和延迟趋势。
- 检查报价源状态、报价时间戳、会话状态和市场事件背景。
- 判断是单笔订单异常、某一品种异常，还是更广泛的执行质量下降。
- 带着订单编号、时间线、证据截图和初步判断升级给 Shift Leader / 当班负责人。
案例模拟¶
伦敦开盘期间出现延迟¶
实战训练¶
真实场景
客户说订单用了 10 秒才成交。
Dealer 应该看的证据
客户端时间、Trade Server 时间、Bridge 队列、报价源状态、成交时间（fill time）、市场事件。
错误示范
只看最终成交时间，不拆分延迟发生在哪一段。
正确处理
建立时间线，定位延迟段，判断是孤立订单还是广泛执行恶化。
总结¶
成交延迟调查的重点是建立完整时间线，定位延迟发生的环节，并区分单笔个案与广泛执行异常。
完成标准¶
- 能说明本课的核心风险或操作目的
- 能指出需要查看的系统、数据或证据
- 能说明正确的升级或处理方式
- 已完成 Shift Leader / 当班负责人抽查或实操确认