Definition: what execution algorithms do
Execution algorithms are rule-based methods that manage how an order is carried out over time. Instead of sending one large order immediately, the system submits multiple smaller “child orders” and decides when and how much to trade. The core idea is to map a desired total quantity (the order intent) into a sequence of actions (the execution plan) while responding to real trading conditions.
Mechanism: how a worked example is set up
To make a worked example understandable, separate stable mechanics from variable conditions.
- Stable mechanics (assumptions you control in the example):
- Target: buy 100,000 units.
- Time horizon: 3 equal time slices.
- Split rule: 1/3 of the remaining quantity in each slice.
- Pricing rule: each child order fills at the “effective price” you assume for that slice.
- Variable conditions (what can change in real life):
- Available liquidity and spreads.
- Partial fills and cancellations.
- Transaction costs and slippage.
- Differences in execution venue and market microstructure.
Worked scenario (no real-time data)
Assume the following effective prices per time slice for your child orders (these are hypothetical inputs for the example):
- Slice 1: effective buy price = 1.1000
- Slice 2: effective buy price = 1.1010
- Slice 3: effective buy price = 1.0995
Assume also a simple fill limitation:
- In slice 1, 100% of the intended child quantity fills.
- In slice 2, only 80% of that slice’s child quantity fills.
- In slice 3, whatever remains is fully filled.
Step-by-step calculations
- Target quantity = 100,000.
- Child quantities intended per slice using the split rule:
- Slice 1 intent: 33,333.33 units
- Slice 2 intent: 33,333.33 units
- Slice 3 intent: 33,333.34 units (rounding to total 100,000)
- Apply the fill limitation:
- Slice 1 filled: 33,333.33 at 1.1000
- Slice 2 filled: 0.80 × 33,333.33 = 26,666.67 at 1.1010
- Slice 3 filled: remaining = 100,000 − (33,333.33 + 26,666.67) = 40,000.00 at 1.0995
- Compute total cost and volume-weighted average price (VWAP):
- Cost = (33,333.33 × 1.1000) + (26,666.67 × 1.1010) + (40,000.00 × 1.0995)
- Cost ≈ 36,666.66 + 29,346.67 + 43,980.00 = 109,993.33 (in price×units terms)
- VWAP ≈ Cost / 100,000 ≈ 1.0999333
- Interpret slippage versus a baseline (optional metric, still hypothetical):
- If a baseline was 1.1000, then effective VWAP is slightly higher by about 0.0000667.
This example illustrates how results depend on (a) the split rule, (b) fill availability/partial fills, and (c) the effective prices you assume for each slice.
Limitations and risks: what can break the example in real execution
At least one material limitation is inherent: you cannot assume full, deterministic fills. Even with fixed split rules, the market can force outcomes to differ via partial fills, changing spreads, or delayed execution.
Common failure modes to look for in practice include:
- Partial-fill risk: the algorithm may end up trading a smaller or delayed portion than planned.
- Timing risk: if child orders execute later than expected, effective prices can differ.
- Cost/venue mismatch: fees and different liquidity sources can change “effective price.”
- Rounding and minimum order sizes: they can prevent exact quantity targets.
Because the scenario uses hypothetical effective prices, the numeric result is not predictive. Historical patterns do not guarantee future execution behavior, and results can vary with market conditions, costs, and jurisdiction.
Verification and next question to ask
To independently verify claims about an execution algorithm, focus on recordable facts:
- What rule produced each child order (quantity, time slice logic, and any adjustments)?
- What were the actual timestamps for submissions and fills?
- What were the effective fill prices and filled quantities?
- Do computed metrics (like VWAP) match the filled orders’ records under your stated assumptions?
If you want the next step, ask for a worked example that includes explicit transaction costs (fees or commissions) and shows how they change VWAP and any slippage metric—again, using hypothetical but fully stated inputs.