Define execution quality in API trading
Execution quality is how well an order submitted through an API is converted into the trades you intended, at a cost and timing that matches your expectations. In practice, it is not one number. It is a set of measurable behaviors across the order lifecycle: request submission, acknowledgement, acceptance/rejection, routing, partial fills, final fills, and post-trade reporting.
API-specific aspects matter because an integration adds technical steps—like authentication, message formatting, and asynchronous responses—that can change what you actually receive compared with what you requested.
Measure the mechanics that affect fills
To assess execution quality for an API broker in a way you can verify, focus on metrics that you can compute from your own system logs and the broker’s execution reports.
Key measurable factors include:
- Latency distribution: not just average latency, but percentiles (for example, median, 90th, 99th) for time from order submission to acknowledgement and to first fill.
- Order outcome mapping: the rate of rejections, cancellations, and “accepted but not filled” states, and how consistently your system can reconcile each request to an eventual execution.
- Fill quality relative to your reference price: define a reference such as the best available market price at the moment you measured, then compute deviation. The exact reference must be stated because results change by definition.
- Partial fill behavior: frequency and distribution of partial fills, and whether the broker returns executions in a way that lets you reconstruct the full intended position.
- Cost components: effective cost equals the executed price plus explicit fees and minus any rebates (if applicable). Even without live market data, you can measure internal consistency—what you paid vs what the broker reported.
A realistic scenario: you run the same API order template (same size, side, and order instructions) across multiple sessions and compute how the above metrics vary when liquidity is high vs low. The possible consequence is that your overall strategy cost changes even if your model is unchanged.
Evidence limits, failure modes, and what to verify
Execution quality can be difficult to prove because many drivers are variable. Stable mechanics (API handling, execution reporting consistency, deterministic mapping from requests to fills) are more assessable than market outcomes.
Common material limitations and failure modes include:
- Latency spikes: even if typical latency is low, occasional spikes can worsen price deviation.
- Rejections or delayed acknowledgements: missing or delayed confirmation can make your system send retries that increase cost.
- Partial fills and timing gaps: if executions arrive in multiple messages, your risk controls and reconciliation can drift.
- Historical mismatch: past patterns between your request timing and realized fills do not guarantee future behavior, especially after changes in infrastructure or market structure.
A practical verification checklist
To independently verify execution-related claims without relying on marketing metrics, require a repeatable evaluation plan:
- State assumptions: what you use as the fill reference, your time source, and how you handle retries and cancellations.
- Collect full traceability: store request IDs, timestamps, broker acknowledgements, and each execution message.
- Compute distributions: report percentiles for key timings and quantify rejection/partial-fill rates.
- Reconcile outcomes: confirm that your reconstructed fills match broker-reported execution details.
- Test across conditions: run the same method in different liquidity regimes and volatility periods.
Control point: if your evaluation cannot reliably map each order request to the final executions, you cannot trust any derived “execution quality” measure, because the evidence is incomplete.