Execution Algorithms
Prerequisite: Order Book Mechanics
Your desk needs to sell 50,000 shares of a mid-cap stock. The average daily volume is 200,000 shares. A single market order would consume the entire visible bid side, walk the price down 2–3%, and broadcast your intent to every participant watching the tape. By the time the last fill arrives, you have moved the market against yourself by $400,000. The execution algorithm exists to prevent this — to slice, schedule, and route the parent order so that the market does not notice you are there.
The cost of a bad execution is not the commission. It is the market impact: the price movement caused by your own order. For institutional-size orders, impact routinely exceeds all other transaction costs combined.
Market Impact and the Square-Root Law
Market impact grows with order size, but not linearly. Empirical research across equity, futures, and crypto markets consistently finds that impact follows a square-root relationship:
\[\text{Impact} \approx \sigma \cdot \sqrt{\frac{Q}{V}}\]
where \(\sigma\) is daily volatility, \(Q\) is order quantity, and \(V\) is average daily volume. An order representing 1% of daily volume incurs roughly 10% of the impact of an order representing 100% of daily volume — not 1%.
| Order size (% of ADV) | Expected impact (at 2% daily vol) |
|---|---|
| 1% | ~20 bps |
| 5% | ~45 bps |
| 10% | ~63 bps |
| 25% | ~100 bps |
The implication: splitting a large order into smaller pieces and spreading them over time reduces total impact. Every execution algorithm is a strategy for when and how to split.
TWAP: Time-Weighted Average Price
TWAP divides the parent order into equal-sized child orders and spaces them evenly across the execution window. A 50,000-share sell over 4 hours becomes roughly 208 shares every minute (or 12,500 per hour, sliced further into smaller intervals).
def twap_schedule(total_qty, duration_minutes, interval_minutes):
num_slices = duration_minutes // interval_minutes
slice_qty = total_qty // num_slices
remainder = total_qty % num_slices
schedule = [slice_qty] * num_slices
schedule[-1] += remainder
return scheduleTWAP ignores volume. It sends the same quantity at 9:35 AM — when the market is liquid and spreads are tight — as it does at 12:15 PM — when volume has dropped by 60% and spreads have widened. The 12:15 slice moves the price more per share than the 9:35 slice.
TWAP is appropriate when the goal is a benchmark price that is independent of market microstructure — when you want a fair time-average and do not want the algorithm making volume-dependent decisions. It is the simplest algo to implement, the simplest to explain to compliance, and the simplest to audit.
See Executing Money Flows. The idempotency requirements for child orders are identical to those for payment operations — each slice must be idempotent and independently retryable without double-execution.
VWAP: Volume-Weighted Average Price
VWAP weights child order sizes by the market’s historical volume profile. The U-shaped intraday volume curve — heavy at open, light at midday, heavy into close — means more shares should execute during high-volume periods, where the algo’s flow is a smaller fraction of total activity.
The volume profile is computed from the trailing 20–30 days of intraday volume data, bucketed into intervals (typically 5 or 10 minutes). Each bucket’s share of daily volume determines the fraction of the parent order assigned to that interval.
| Time bucket | Historical volume share | VWAP allocation (50K shares) | TWAP allocation |
|---|---|---|---|
| 9:30–10:00 | 12% | 6,000 | 3,205 |
| 10:00–10:30 | 8% | 4,000 | 3,205 |
| 12:00–12:30 | 3% | 1,500 | 3,205 |
| 15:30–16:00 | 14% | 7,000 | 3,205 |
VWAP’s objective is to match the market’s volume-weighted average price for the day. If you execute at VWAP, you have done no worse and no better than the average dollar transacted that day. This makes VWAP a common benchmark for institutional trading — the question is not “did you get a good price” but “did you get the market’s average price.”
The failure mode: if your order is a significant fraction of daily volume, your own execution distorts the VWAP benchmark. You are simultaneously trying to match the average and contributing disproportionately to it. For orders above 5–10% of ADV, VWAP tracking becomes self-referential.
Participation Rate (POV)
A participation rate algorithm targets a fixed fraction of real-time market volume. Set participation to 10%, and the algorithm monitors the consolidated tape, executing 1 share for every 10 that trade in the market.
Unlike TWAP and VWAP — which follow a predetermined schedule — participation rate is adaptive. If volume surges, the algorithm accelerates. If volume drops, it slows. The completion time is unknown at the start; it depends on how much volume the market generates.
def pov_next_qty(target_rate, market_volume_since_last, executed_since_last):
target_executed = target_rate * market_volume_since_last
deficit = target_executed - executed_since_last
return max(0, int(deficit))| Participation rate | Expected completion (25% ADV order) | Impact profile |
|---|---|---|
| 5% | 5 days | Minimal — you are 5% of the noise |
| 10% | 2.5 days | Low — detectable by sophisticated participants |
| 20% | 1.25 days | Moderate — your flow is a visible signal |
| 50% | 0.5 days | High — you are half the market |
The tension: higher participation rates finish faster but generate more impact. Lower rates are stealthier but tie up capital and extend exposure to overnight risk. The participation rate is a direct tradeoff between urgency and cost.
Iceberg Orders
An iceberg order exposes only a small visible quantity to the order book while holding the remainder in reserve. When the visible portion fills, the algorithm automatically replenishes it from the reserve. The market sees a steady stream of 200-share orders; it does not see the 50,000 shares behind them.
Visible: 200 shares @ $45.10
Reserve: 49,800 sharesThe displayed quantity must be small enough to avoid detection but large enough to attract fills. Too small (10 shares on a stock trading 5,000 per level) looks suspicious — other participants recognize iceberg signatures by the speed and consistency of replenishment. Modern detection algorithms identify icebergs by tracking refill patterns: if a 200-share bid at $45.10 refills within 50ms of every fill, the pattern is obvious.
Countermeasures include randomizing the displayed quantity (180–220 shares), randomizing the refill delay (50–500ms), and periodically stepping away from the price level before re-entering. These add implementation complexity but reduce detection probability.
Iceberg orders on most regulated exchanges are legitimate order types with exchange-level support. On venues where they are not natively supported, implementing iceberg behavior programmatically may raise regulatory questions about market manipulation depending on the jurisdiction and the intent.
Smart Order Routing
When a security trades on multiple venues — the primary exchange, alternative trading systems (ATS), dark pools, and in some markets 15+ venues simultaneously — the router must decide where to send each child order.
The routing decision evaluates:
| Factor | What to optimize |
|---|---|
| Displayed liquidity | Volume at the best bid/offer on each venue |
| Hidden liquidity | Estimated dark pool fill probability |
| Fees/rebates | Maker rebates ($0.002/share) vs taker fees ($0.003/share) on US equities |
| Latency | Round-trip time to the venue’s matching engine |
| Fill rate | Historical fill probability for this venue/symbol/size combination |
A naive router sends to the venue with the best displayed price. A production router considers that the displayed quantity at that price may be a 100-share order on a dark pool with 2ms additional latency, while a lit exchange shows 5,000 shares at the same price with 200μs latency. The lit exchange fills your 1,000-share slice immediately; the dark pool fills 100 and forces you to route the remaining 900 elsewhere at a now-worse price.
SEC Rule 606 (in the US) requires brokers to disclose order routing practices, including payment for order flow arrangements. Regulation NMS requires that orders be routed to the venue displaying the best price (National Best Bid and Offer). Your router must comply with both — it cannot route to a higher-fee venue with a better rebate if another venue displays a better price.
Crypto vs Traditional Markets
Algorithmic execution in crypto markets faces structural differences that change the implementation.
| Dimension | Traditional equities | Crypto |
|---|---|---|
| Venues | 15+ exchanges and ATS (US equities) | 5–10 major CEXs + DEXs |
| Trading hours | 6.5 hours/day (US equities), extended hours limited | 24/7/365 |
| Settlement | T+1 (US equities) | On-chain: 1 block to finality. CEX: instant internal |
| Pre-funding | Margin or credit from prime broker | Must pre-fund each venue independently |
| Market data | Consolidated tape (SIP) | No consolidated feed — poll each exchange |
| Regulation | SEC/FINRA, Reg NMS, best execution | Fragmented — DORA (EU), MiCA, no US equivalent to Reg NMS for crypto |
The pre-funding constraint is the most operationally significant. In equities, a prime broker extends credit and nets settlement across venues. In crypto, you must deposit assets on each exchange before trading. An algorithm routing across 5 exchanges needs capital deployed on all 5 — capital that sits idle on venues that happen to have worse prices at execution time.
Cross-venue arbitrage is harder because moving assets between exchanges requires on-chain transfers with confirmation times measured in seconds (Solana) to minutes (Ethereum). By the time an arbitrage transfer confirms, the price difference has closed.
DEX execution adds gas cost as a variable. A Uniswap trade on Ethereum costs $5–50 in gas depending on network congestion. For a $500 trade, gas is 1–10% of the notional — larger than any market impact the algorithm could reduce. On Solana, the same swap costs $0.01, making algorithmic execution on DEXs viable for smaller sizes.
Implementation Concerns
Execution algorithms in production require:
State management. Each parent order spawns hundreds or thousands of child orders across multiple venues. The algorithm must track fills, partial fills, cancellations, and rejections for every child — and reconcile them against the parent order in real time. A parent order that is 99.8% filled but has 0.2% in a rejected state on a venue that went down requires manual intervention protocols.
Clock discipline. TWAP and VWAP depend on accurate time intervals. A 5-minute VWAP bucket that drifts by 30 seconds because of system clock skew will misallocate volume and underperform the benchmark. NTP synchronization to microsecond precision is the baseline; PTP (Precision Time Protocol) is standard at low-latency firms.
Monitoring. Every child order is a point of failure. The production dashboard tracks: slippage against benchmark (VWAP, TWAP, arrival price), fill rate per venue, rejection rate per venue, participation rate vs target, and estimated remaining completion time. Alerts fire on deviations — a venue’s fill rate drops below 50% of historical, the algorithm pauses routing to that venue and redistributes.
Fallback behavior. When a venue goes offline, the algorithm must redistribute remaining quantity across surviving venues without spiking participation on any one of them. When the parent order approaches its deadline with significant unfilled quantity, the algorithm faces the urgency decision: switch from a passive VWAP to an aggressive crossing strategy, accepting higher impact to ensure completion. The switch threshold — how much unfilled quantity at what remaining time triggers aggressive behavior — is the most consequential parameter in the system.