Execution algorithms: what you measure
Execution algorithms are methods that decide how orders are broken into smaller actions and how those actions are timed and routed. To measure them in a way that others can verify, focus on measurable execution fields (what happened) and measurable timing fields (when it happened). Then compare results only under clearly stated assumptions, because market conditions and execution costs can dominate outcomes.
Mechanism and measurable fields
A practical way to define measurement is to start from an “order event log” for one parent order.
1) Timing fields
- Request time: when the parent order was submitted.
- Start of execution: when the first child execution attempt occurs.
- Completion time: when the parent order is fully filled or terminated.
- Queue/latency windows: the elapsed time between sending a child order and receiving an acknowledgement or fill (if your data captures it).
2) Fill-quality fields
- Fill ratio: filled quantity divided by intended quantity.
- Remaining quantity: what is not filled by completion.
- Fill distribution: how much was filled in each time bucket.
3) Cost and price-impact fields To avoid ambiguity, compute costs using a chosen reference price and a clearly defined formula. Common reference choices include:
- Mid-price at start (a midpoint between best bid and ask, if you can observe it)
- Decision price at the time the algorithm began
- Arrival price at the first executable moment
Then measure:
- Slippage: difference between average execution price and the reference price (directional).
- Implementation shortfall (conceptually): cost relative to a reference that includes both price movement and execution incompleteness.
4) Constraints and control fields If the algorithm has parameters (for example, participation targets or timing limits), treat them as measurable inputs and verify how often the algorithm met those constraints under each scenario.
Evidence and example calculation (with explicit assumptions)
Assume you have a parent order for 100 units.
- Parent order submitted at 10:00:00.
- First child execution attempt at 10:00:05.
- Full completion at 10:00:35.
- Average execution price across fills is 1.2000.
- Your reference price (mid-price at execution start) is 1.1980.
A simple, verifiable slippage calculation is:
- Slippage = Average execution price − Reference price
- = 1.2000 − 1.1980 = 0.0020 (per unit, in price terms)
To make this independent and reproducible, you also state:
- the reference definition (mid-price at 10:00:05)
- the data granularity (fill prices and timestamps)
- whether you used quantity-weighted averages
If you also observe that only 90 of 100 units were filled, you report fill ratio = 0.90 and treat the incompleteness as a separate, material component rather than folding it into price alone.
Limitations and failure modes (what breaks comparisons)
Even with careful metrics, comparisons can be misleading if they ignore variability.
Material limitations
- Market conditions dominate: liquidity, spread width, and volatility can change during execution and affect costs.
- Costs differ across scenarios: fees, commissions, and any execution-related charges can alter cost metrics.
- Benchmark dependence: slippage numbers change when you change the reference price definition.
- Historical relationships do not establish future results: past performance under one regime may not apply to another.
Failure modes to measure or watch for
- Partial fills: the algorithm completes with leftover quantity.
- Queue delays and latency sensitivity: execution timing may worsen during periods of higher congestion.
- Over-trading or under-trading against intended pacing: the actual child order rate can deviate from targets.
- Stop/termination behavior: repeated cancellations or early exits can bias cost and completion-time comparisons.
Verification and the next question
To verify claims about an execution algorithm, you need three things that can be independently checked: (1) the measured fields and formulas, (2) the timestamps and time windows used, and (3) the assumptions about reference prices and data availability. If two parties compute the “same” metric but choose different reference prices or sampling windows, their results can legitimately disagree.
A useful next question is: what data do you actually have for the reference price (mid-price, arrival price, or another proxy) and for latency/acknowledgements? With that answered, you can align measurement definitions before comparing algorithms or providers.