What is an execution algorithm trying to optimise, and how would you tell whether it did a good job?

The problem the algorithm is solving

A portfolio manager wants to buy a quantity that is large relative to what the market trades in a day. There is no price at which that quantity is simply available. If you send it all at once you will walk up the book, consume the resting offers at progressively worse prices, and reveal to everyone watching that a large buyer is present, so the price you get on the last share is worse than the price you got on the first and the next buyer to arrive is you.

The obvious remedy is to go slowly. But going slowly has its own cost, which is that the price moves for reasons unconnected to you. Over an hour the stock may drift away from you, and the unfilled remainder of your order is exposed to that drift. Trade fast and you pay market impact. Trade slowly and you take timing risk. The optimal schedule sits between them, and where exactly depends on the size of the order relative to typical volume, the stock's volatility, and how urgently the manager wants the position.

That is the whole of it, and the framing is what is being tested. An execution algorithm is not trying to find a good price. It is trying to minimise the expected cost of acquiring a position, plus some penalty for the variance of that cost, given a size it cannot hide.

Benchmarks are the trader's choice, and they change the objective

You cannot measure cost without a reference price, and the reference price you pick determines which algorithm is the right one. The common ones express genuinely different intentions.

• Arrival price, the market price at the moment the order reached the desk. Measuring against it captures the full cost of the decision to trade, including everything that happened while you worked the order. This is implementation shortfall, and it is the most honest benchmark because it is the one the fund's return actually experiences.
• Interval VWAP, the volume-weighted average price over the period the order was worked. Measuring against it asks whether you traded better than the average participant over that window. It says nothing about whether the window was the right one.
• Close, for flow that must be marked at the closing price, typically index-tracking activity.
• Previous close or open, mostly for basket flow with a specific mandate.

An algorithm is then a schedule aimed at a benchmark. A TWAP algorithm slices evenly over time, which makes it predictable and therefore easy to detect. A VWAP algorithm front-loads or back-loads according to a forecast of the day's volume curve, so it is trying to match the day's volume distribution. A percentage-of-volume algorithm consumes a fixed share of whatever actually trades, which adapts to real conditions but hands the schedule over to the market. An implementation shortfall algorithm trades more aggressively at the start, because arrival price is fixed at the beginning and every minute of delay is unhedged exposure to drift.

The link between those two lists is where candidates gain or lose ground. Judging a VWAP algorithm against arrival price penalises it for something it was never told to control. Judging an implementation shortfall algorithm against interval VWAP rewards it for nothing it was asked to do. Benchmark mismatch is the most common way a genuinely reasonable execution is reported as a bad one.

The costs that are not in the fill prices

Impact from your own trades is only part of it. Two others deserve naming.

Information leakage is the cost of other participants inferring your intention and trading ahead of the remainder of your order. It is why a predictable schedule is a liability, why child order sizes are randomised, why algorithms alternate between venues, and why a large order is not simply posted at the top of the book. The cost shows up in the prices of your later fills rather than as a separate line, which makes it easy to miss and easy to blame on the market.

Opportunity cost is the cost of the shares you did not buy. An algorithm that stops when the price runs away will show excellent slippage on what it filled and leave the manager without the position they wanted. Any cost measurement that ignores the unfilled quantity can be gamed by simply not trading when trading is expensive, which is sometimes correct and sometimes an abdication. Fees and rebates net against all of this and are small per share but not negligible in aggregate.

Transaction-cost analysis, and how to use it without fooling yourself

TCA is the measurement discipline around all of the above. Pre-trade, it estimates what an order should cost given its size, the stock's liquidity and volatility, and a proposed horizon, which is how a trader chooses the algorithm and the urgency in the first place. Post-trade, it decomposes what the order did cost.

A usable decomposition starts from the difference between the average execution price and the benchmark, expressed in basis points and signed so that positive always means worse for the client. Then it attributes: how much of the move was market-wide or sector-wide and would have happened without you, how much is attributable to your own footprint, how much came from the delay between the decision and the first fill, how much from the unfilled remainder, and how much from explicit fees. The point of the attribution is that only some components are the algorithm's fault and only some are actionable.

Two disciplines make the numbers mean something. First, compare like with like: the same algorithm on small orders in liquid names will always look better than on large orders in illiquid ones, so cost has to be normalised for order size relative to volume, spread, and volatility before two brokers or two strategies are ranked. Second, respect sample size. Execution costs have a wide distribution, so a difference in average slippage across a few dozen orders is noise, and traders routinely reallocate flow on the basis of exactly that noise.

There is also a specific trap in post-trade price reversion, which is the movement in the minutes and hours after your order finishes. If the price snaps back after you stop buying, a good part of what you paid was your own temporary impact rather than a genuine repricing, which suggests you traded too aggressively. If it keeps going, you were trading with the information rather than against it and going slower would have cost more. Reversion is the diagnostic that distinguishes those two cases, and slippage alone cannot.

The measurement that flatters everybody

The failure mode worth naming explicitly is a VWAP algorithm measured against its own interval VWAP. Because the algorithm participates in the volume that forms the benchmark, and because it is measured only over the window during which it chose to trade, it is scored against a number it partly created. Such an algorithm can report beating its benchmark on a day when the client paid substantially more than the price available when the order arrived, simply because the stock drifted for six hours while the algorithm patiently tracked the curve. The client's return does not care about the interval average. It cares about arrival price. So the sophisticated answer is that a benchmark the execution can influence is a weak benchmark, and best-execution monitoring that relies on it will systematically fail to notice the orders that cost the most.

Impact against timing risk is the trade-off, and the benchmark is what turns that trade-off into a number. Choose the benchmark before choosing the algorithm, and never let the algorithm's own trading be a large part of what it is measured against.