Skip to main content
QuantDXB

Markets and trading · 12 min read

Execution costs

What it really costs to trade size: implementation shortfall, the square-root law of market impact, and the trade-off between trading fast and trading safely.

Before you start

  • The limit order book (this track)
  • Random walks and Brownian motion

By the end you'll be able to

  • Measure execution cost as implementation shortfall
  • Estimate market impact with the square-root law
  • Quantify the impact versus timing risk trade-off of slicing an order
  • Explain how risk aversion and signal decay change the best schedule

A strategy's backtest says buy 100,000 shares. The backtest assumed you'd get today's closing price. You won't. Crossing the spread costs something, the order itself pushes the price away, and the price moves while you trade. For many strategies these costs are the difference between a real profit and a paper one. This lesson measures them and shows the central decision of execution: how fast to trade.

TermMeaning
implementation shortfallExecution price versus the price when you decided to trade
market impactHow far your own trading moves the price against you
participation rateYour volume as a share of the market's volume over the same period
timing riskUncertainty in cost because the price moves while you trade
TWAPTime-weighted average price: equal slices at regular intervals
bpsBasis points, hundredths of a percent

Measuring cost

The standard yardstick is implementation shortfall: the difference between the average price you actually got and the price when the decision was made (the "arrival price"), in basis points of the order's value. It captures everything: the spread, the impact of your own trades, and the price drifting while you work the order.

The first part, the spread, the order book lesson covered. For small orders it is most of the cost. For large orders the second part, impact, dominates.

The square-root law

How much does an order move the price? Across many markets and decades of data, a simple rule holds up remarkably well, the square-root law:

impact≈Y σ QV,\text{impact} \approx Y\,\sigma\,\sqrt{\frac{Q}{V}},

where QQ is the order size, VV the daily volume, σ\sigma the daily volatility, and YY a constant of order 1. Two consequences matter. Impact grows with the square root of size, so doubling an order raises its cost per share by about 41%, not 100%. And it scales with volatility: the same order costs more in a jumpy stock.

Take a stock with 2% daily volatility and 1 million shares of daily volume. Selling 100,000 shares, 10% of a day's volume, in one go costs about 0.02×0.1=630.02 \times \sqrt{0.1} = 63 bps by this rule (with Y=1Y = 1).

Slicing the order

Split the order into nn equal slices, one every half hour. If each slice's impact fades before the next (a simplification; in practice part of it lingers), each slice pays the square-root cost of its own size, so the expected impact falls like 1/n1/\sqrt{n}.

But slicing takes time. While you wait, the price moves randomly, and the shares you haven't sold yet are exposed to it. That timing risk grows with the duration. For nn slices, one every Δ\Delta of a day, the spread of the average drift is

σΔ (n−1)(2n−1)6n.\sigma\sqrt{\Delta}\,\sqrt{\frac{(n-1)(2n-1)}{6n}}.

Try every schedule:

4 over 1.5 h
Expected impact (bps)
31.6
Timing risk, sd (bps)
51.9
Simulated average (bps)
–
0 runs
One slice pays the full impact of a large order but has no timing risk. More slices, half an hour apart, cut the impact like 1/√n but leave the rest of the order exposed to the price while you wait. The dashed line marks the expected cost.

Each dot on the left is a choice: trading all at once (top left: 63 bps of impact, no risk), or over a day and more (bottom right: 12 bps of expected impact, but a timing risk of 159 bps). The histogram shows what that risk means: the same schedule can cost hundreds of basis points or make money, depending on where the price goes.

Key idea. Trading fast costs impact; trading slowly costs risk. Every execution schedule is a point on this trade-off, and which one is right depends on how much risk you are willing to take.

Choosing a schedule

Which point is best depends on risk aversion. The classic framework, by Almgren and Chriss, chooses the schedule that minimises

E[cost]+λVar⁡(cost),\mathbb{E}[\text{cost}] + \lambda \operatorname{Var}(\text{cost}),

where λ\lambda says how much you dislike risk. A risk-neutral trader with no information (λ=0\lambda = 0) trades as slowly as allowed. A risk-averse one trades faster. Their optimal schedule is front-loaded: trade more at the start, when the most shares are exposed, and less later.

Other considerations push the same way or the opposite way:

  • Alpha decay. If the reason for trading (a signal) fades within hours, waiting costs expected return as well as adding risk. Fast signals need fast execution.
  • Information leakage. A long, predictable schedule can be spotted by other traders, who then trade ahead of you.
  • Volume patterns. Most markets trade more at the open and the close. A VWAP schedule slices in proportion to expected volume, which keeps participation, and impact, steady.

In code

python
import numpy as np

order, daily_volume = 100_000, 1_000_000  # selling 10% of a day's volume
daily_vol = 0.02  # 2% daily volatility
slice_days = 1 / 13  # one slice every 30 minutes of a 6.5-hour day

def expected_impact_bps(slices):
    # Square-root law per slice: cost ≈ σ · √(slice size / daily volume).
    return daily_vol * np.sqrt(order / slices / daily_volume) * 1e4

def simulate_cost_bps(slices, rng):
    # The price drifts randomly between slices; each slice pays the impact plus the drift so far.
    drift = np.concatenate([[0.0], np.cumsum(rng.normal(0, daily_vol * np.sqrt(slice_days), slices - 1))])
    return expected_impact_bps(slices) - drift.mean() * 1e4  # selling: a lower price costs more

rng = np.random.default_rng(8)
for slices in (1, 2, 4, 8, 13, 26):
    costs = np.array([simulate_cost_bps(slices, rng) for _ in range(20_000)])
    print(f"{slices:>2} slices over {(slices - 1) / 2:>4.1f} hours: impact {expected_impact_bps(slices):5.1f} bps, "
          f"total {costs.mean():5.1f} ± {costs.std():4.1f} bps")
SlicesDurationExpected impactSimulated cost (mean ± sd)
10 h63.2 bps63.2 ± 0.0 bps
20.5 h44.7 bps44.6 ± 27.6 bps
41.5 h31.6 bps31.7 ± 52.3 bps
83.5 h22.4 bps22.3 ± 82.5 bps
136 h17.5 bps17.1 ± 109.1 bps
2612.5 h12.4 bps12.7 ± 159.1 bps

The simulated averages match the expected impact, and the spreads match the timing-risk formula. Going from one slice to 26 saves 50 bps of expected cost and adds 159 bps of risk.

Where this shows up in quant work

  • Execution algorithms. Brokers and funds run TWAP, VWAP and implementation-shortfall algorithms built on exactly this trade-off, with impact models calibrated to their own trades.
  • Backtests. A realistic backtest charges the spread plus impact that grows with trade size. Strategies that trade often or in illiquid names are the most sensitive, and capacity (how much money a strategy can run before costs eat its edge) comes from this calculation.
  • Transaction cost analysis. After the fact, desks compare executions with the arrival price and with models like this one to see whether brokers and algorithms performed.

Exercises

  • Using the square-root law, how much does it cost per share to sell 1% of daily volume? 25%? How many times more does the larger order cost in total?
  • A risk-averse trader minimises expected cost + 0.005 × variance (in bps²). Using the table, which number of slices do they choose?
  • Change the code so each slice's impact decays only halfway before the next slice (half of it stays in the price). How much of the benefit of slicing survives?

Key takeaways

  • Measure execution against the arrival price: implementation shortfall includes spread, impact and drift.
  • Impact grows like the square root of size relative to volume, scaled by volatility.
  • Slicing an order reduces impact but adds timing risk; the right schedule depends on risk aversion, signal decay and information leakage.
  • Backtests that ignore impact overstate what large or frequent strategies can earn.