如何评估API接入的执行质量（外汇背景，教育用途）
API接入中“执行质量”的含义
执行质量是指通过API下达的订单在实际成交结果与你下单时刻所预期结果之间的匹配程度。实际上，你通过可观察的系统行为来判断执行质量：时间延迟、订单处理方式、请求成交与实际成交之间的对应关系，以及错误或意外事件发生的频率。
API接入改变了执行问题可能出现的位置。你不再仅关注市场和策略行为，还需考虑订单提交和订单生命周期相关的“连接机制”：API如何接收你的请求、如何确认接受、如何更新订单状态，以及如何将交易结果回传至你的系统。
核心机制：可衡量的内容
为评估执行质量，首先需定义几个术语：
- 请求时间：你的应用程序发送订单消息的时间。
- 确认/接受时间：API确认订单已被接受并进入处理流程的时间。
- 执行事件时间：成交或取消发生的时间（由API报告）。
- 预期与实际结果对比：实际成交价格、数量或时间是否与你的系统假设一致。
一个可衡量的评估通常包括：
- 延迟分布（不仅仅是平均值）。跟踪从请求到确认的时间，以及从确认到首次成交的时间。考虑百分位数（例如，多频繁达到“足够快”）。
- 可靠性。测量被拒订单、超时、重复请求和状态更新缺失的发生率。
- 订单结果准确性。将请求的价格/数量/限制条件与最终执行或确认的结果进行比较（包括部分成交）。
- 事件完整性。检查你收到的订单状态序列（已接受 → 部分成交 → 完全成交/取消）是否一致且完整。
- 成本透明度。执行质量无法与总交易成本（点差、佣金、费用以及由成交差异隐含的滑点）分开。你只能根据实际应用的价格和费用来评估。
一个关键理念是将你观察到的执行结果与你可控的基准进行比较。你的基准可以是在一致条件下使用小额订单进行的受控测试，并明确记录时间戳和输入。
证据与示例：一种验证式测试
假设你进行一项测试，通过API提交相同的限价单并记录：
- 应用程序的精确请求时间戳，
- API确认接受的时间戳，
- 首次成交和完全成交的时间戳，
- 成交价格和成交数量，
- 任何错误代码或缺失的更新。
然后在多次试验中计算几个汇总数据：
- 确认延迟 = 接受时间 − 请求时间。
- 首次成交时间 = 首次成交时间 − 请求时间（或 − 接受时间，只要定义一致）。
- 成交偏差 = 你的限价与实际成交价格之间的差异（方向性和绝对值）。
- 成交完整性 = 每笔订单的（已成交数量 ÷ 请求数量），以及最终部分成交的订单占比。
由于市场条件可能快速变化，你需要将证据分为两层：
- 系统行为证据：在类似条件下，延迟、拒绝和缺失更新是否以可预测或稳定的发生率出现。
- 市场与成本证据：成交差异是否可由流动性变化和交易成本变化解释，而非API处理问题。
你也应明确记录假设。例如，若测试使用相同的订单有效期设置或订单类型，请注明；否则对接受和部分成交的解释将变得模糊。
需考虑的局限性与失败模式
即使测量结果良好，执行质量仍无法完全预测。常见的实质性局限包括：
- 失败模式：被拒或超时的订单。系统在正常运行时可能很快，但在负载或连接变化时仍可能出现不可接受的拒绝率。
- 失败模式：过期或不一致的市场数据。若你的应用程序基于滞后于下单时刻的数据做决策，你可能会看到更差的成交结果，这不仅仅是“延迟”问题。
- 失败模式：部分成交与成交后更新。部分成交可能是准确的，但若你的应用程序错误跟踪剩余数量或错误处理状态序列，你所测量的执行“质量”可能反映的是软件逻辑错误。
- 测量局限：时间戳对齐。若你在不了解时钟同步的情况下将本地时间戳与API报告的时间戳进行比较，你的延迟结论可能存在偏差。
- 证据局限：历史表现不保证未来表现。