How to Actually Beat VWAP: Konishi's Optimal Slicing

A broker sells a client a guaranteed VWAP trade. The deal is simple: whatever the volume-weighted average price of the stock turns out to be today, that is the price the client pays, full stop. The broker now has a problem. They have promised a price they do not yet know, and they have to go into the market and try to achieve it.

Get it wrong and the broker eats the difference. So: what is the trading schedule that gets you closest to VWAP?

Hizuru Konishi's 2002 paper answers this properly, and the answer is more interesting than the obvious guess.

The problem: chasing a benchmark you cannot see yet

VWAP is a moving target computed after the fact. You do not know today's VWAP until the closing bell. To land on it, you have to trade in a way that matches how the market is going to trade, and you have to do that before you know how the market is going to trade.

The naive solution is obvious and it is what most VWAP algorithms do. Forecast the day's volume profile and trade in proportion to it. Equity volume follows a famous U-shape: heavy at the open, quiet through lunch, heavy again into the close. So trade a lot at the open, little at midday, a lot at the close. If you trade exactly in proportion to volume, and you had perfect foresight of that volume, your average price is by construction the VWAP. You cannot miss.

Konishi's paper takes this seriously and then asks the sharper question: is proportional trading really optimal, or does it only look optimal because we have been sloppy?

The key idea via analogy: matching the crowd's footsteps

Imagine you are trying to walk across a field at exactly the average pace of a large crowd, so that at every moment you are neither ahead nor behind them. The obvious strategy is to copy their pace: when the crowd surges, you surge, and when they dawdle, you dawdle. Match their footsteps and you match their average.

That works perfectly if the only thing that varies is the crowd's pace. But suppose the ground also varies: some patches are muddy, and in those patches your own footsteps sink and slow you down in a way the crowd's do not.

That is the market. Two things vary through the day, not one.

• Volume varies. This is the U-shape, and copying it is what the naive strategy does.
• Volatility varies. Prices swing around far more at the open than at lunch. And volatility is what determines your tracking error, the amount by which you can accidentally miss the benchmark.

Konishi's result is a clean statement about when these two effects cancel and when they do not.

When volume and volatility are unrelated to each other, the naive answer is right. Trade in proportion to the expected volume curve. That genuinely is optimal, and the intuition is exactly the footstep-matching one.

When volume and volatility are correlated, the optimal schedule tilts away from the volume curve. And they are correlated in real markets: the busy periods are also the wild periods. In that case, the schedule that minimises your expected miss against VWAP is not simply the volume profile, and Konishi's contribution is to quantify precisely how far it should deviate and in which direction.

There is a second ingredient the naive approach ignores completely: your own market impact. When you trade, you push the price. That moves the actual transaction prices, which means it moves the VWAP itself. Konishi's framework accounts for the fact that you are not an outside observer trying to hit a fixed target; you are one of the people setting the target. The optimal slice has to be worked out with that self-reference built in.

Why it mattered

• It gave VWAP algorithms a theoretical foundation. Before this, "trade in line with the volume curve" was a sensible heuristic. Konishi showed exactly which assumptions make it optimal and exactly which realistic features break it. That is what a good paper does: it tells you when your rule of thumb is safe.
• It separated two different objectives that get muddled. Minimising your cost and minimising your tracking error against a benchmark are genuinely different problems with different solutions. The optimal execution literature mostly attacks the first. Konishi attacks the second, which is the one that actually governs the huge business of benchmark-guaranteed trading.
• It made explicit that you move your own benchmark. This point is easy to miss and it matters enormously for large orders. A trader who is twenty percent of the day's volume is not tracking VWAP, they are substantially creating VWAP.

The honest limitations

• The whole exercise takes the benchmark as given, and the benchmark is flawed. VWAP tracking makes you a good conformist. It does not make you a good trader. If the portfolio manager needed the position on by ten in the morning, a perfect VWAP execution that finishes at four in the afternoon has served them badly. This is Perold's implementation shortfall critique, and it applies with full force here.
• It leans on volume forecasting, which is hard. The optimal schedule depends on knowing the shape of the day's volume in advance. The U-shape is reliable in aggregate but individual days wander from it badly, especially around news, index rebalances, and expiries. A schedule optimised against the wrong forecast is not optimal.
• The volume and volatility relationship is not stable. The paper's key result depends on the correlation between the two. That correlation drifts across stocks, across regimes, and across time of day.
• It largely assumes you are a passive, uninformed trader. If you have short-lived information, deliberately spreading yourself across the whole day to track a daily average is close to the worst thing you can do. Your edge decays while you conform.

The one-line takeaway

Konishi showed that trading in proportion to the day's volume curve is genuinely the optimal way to hit VWAP, but only when volume and volatility are uncorrelated, and since in real markets the busy hours are also the volatile hours, the truly optimal slice tilts away from the volume curve in a way you can actually compute.