如何验证执行问题的相关信息？
以可验证的方式定义执行问题
执行问题是指您的订单意图与实际订单处理结果之间的差异。一个“可验证”的定义应聚焦于可观测的事实，例如：
- 订单意图：方向（买入/卖出）、订单类型（市价单/限价单）、申报数量和提交时间。
- 报告结果：订单是否被接受、部分成交、完全成交、取消或拒绝。
- 执行记录：成交时间戳、成交价格以及任何记录的错误。
这一点很重要，因为后续分析不应将稳定的机制（订单如何处理）与可变条件（市场流动性、波动性以及各参与方收取的费用）混为一谈。
建立用于验证主张的信息来源层级
在评估有关执行问题的信息时，应将主张的来源分层。一个实用的层级结构是：
-
您可观察到的原始记录
- 您的订单单据详情和确认信息。
- 订单生命周期历史（已接受、挂单中、已成交、已取消、已拒绝）。
- 包含时间戳和价格的交易或成交报告。
-
系统级文档
- 交易所或交易平台规则（如适用）。
- 平台文档，定义订单状态、有效时间（time-in-force）以及成交记录方式。
-
中介机构的法律/运营文件
- 经纪商文档，描述订单执行的处理方式，包括常见失败模式。
-
解释性报告
- 分析、博客文章或摘要。这些应视为次要信息，因为它们可能省略假设或仅选择有利的观察结果。
使用此层级结构来判断哪些内容可以独立验证，哪些属于解释性内容。
使用可复现的验证步骤（无需实时数据）
您可以通过“纸质记录”流程来验证执行问题信息。
-
固定场景和假设
- 明确：订单类型、订单数量以及您正在分析的时间窗口。
- 对于任何涉及成本的示例，明确列出假设的成本组成部分（例如：佣金和您能观察到的其他费用），并在比较中保持这些成本恒定。
-
将意图与订单状态历史进行比较
- 确认订单在任何声称的执行前已被接受。
- 记录确切的状态转换（例如：已提交 → 挂单中 → 已成交/部分成交 → 已取消）。
- 如果主张称“执行延迟”，请通过从提交时间戳到首次成交时间戳之间的时间差来验证延迟。
-
比较声明的与实际的成交行为
- 如果主张提到滑点，请从成交价格与预期参考价格（例如：限价/市价决策的预期执行价格）之间的差异来验证，并始终使用相同的参考标准。
- 如果主张提到不完全成交，请验证总成交数量是否低于预期订单数量。
-
谨慎归因失败模式
- 延迟：接受与首次成交之间存在较长时间间隔。
- 部分成交：多次成交事件，总数量在“问题”发生时低于预期。
- 拒绝或取消：明确的状态和（如提供）记录的原因代码。
-
使用多个独立实例重复验证
- 当同一失败模式在多个独立订单中被观察到时，验证效果更佳，而不仅限于单一事件。
验证过程中的实质性限制与风险
即使进行了仔细检查，结果仍可能不确定：
- 市场条件变化：流动性和波动性会影响“良好”执行的表现，因此历史关系不能保证未来结果。
- 混合原因：延迟可能来自市场活动和操作处理两方面；时间线可能显示症状，但无法揭示确切的内部原因。
- 成本与报价模糊性：不同系统可能使用不同的参考点记录价格，费用在报告中的表示方式也可能不同。
- 一次性事件：单个异常订单可能反映的是短暂状况，而非持续存在的“问题”。
验证中的一个关键失败模式是，将您订单记录中的真实差异与无法从原始记录中确认的更广泛叙述相混淆。
当验证不明确时应进一步询问什么
如果您无法将主张与您的记录对齐，请专注于澄清那些针对可验证项目的提问：
- 哪些确切的时间戳和订单状态支持该主张？
- 用于衡量滑点的参考价格是什么？它记录在哪里？
- 该主张是关于部分成交、延迟、拒绝还是价格不匹配——而记录中实际存在的是哪一种？
独立验证执行问题，主要在于证据质量、清晰的假设，以及在变化条件下进行一致的比较。