Algorithms and Placement: How Each Slice Reaches the Market

A large order is never sent to the market as one instruction. It is a parent order, broken into child orders that reach venues over time.

That split creates two distinct decision layers, and confusing them causes most of the muddle in this area.

The scheduling layer decides how much to trade in each interval, which is the optimisation from the previous lesson. The placement layer decides how a given slice reaches the market: as one order or several, resting or crossing, displayed or hidden, on which venue.

An execution algorithm is a policy covering both, and algorithms are usually named after their scheduling logic even though the placement half often matters more. Two implementations of the same nominal algorithm can differ substantially in realised cost purely through placement.

The useful question about any algorithm is therefore not what it is called but what benchmark it is optimising, because that determines the behaviour when the two layers conflict.

Almost every algorithm on an execution menu is a variation on four scheduling rules.

TWAP spreads the order evenly across clock time: equal quantity per interval. It is the simplest possible schedule and it ignores that volume is not evenly distributed through the day.

VWAP distributes the order in proportion to expected volume, trading more when the market is busy. It targets the volume-weighted average price over the window.

POV, percentage of volume, sets a participation rate and trades that fraction of whatever prints. Unlike the first two it does not commit to finishing, since if volume never arrives the order does not complete.

IS, implementation shortfall, optimises against the arrival price using the mean-variance framework of the previous lesson, front-loading according to a chosen urgency.

The first three are relative benchmarks, defined against what the market did. Only the last is absolute, defined against a price fixed before trading began. That distinction is the whole of the next step.

A relative benchmark makes the algorithm's job tracking rather than minimising. If the price falls all day while it buys, a VWAP algorithm can report a perfect result while the portfolio lost money on every share.

That is not a defect if tracking is what you wanted. An index fund replicating a benchmark has genuinely delegated the price decision elsewhere, and matching the market average is exactly the mandate.

It is a serious defect if the trade was made because of a view. Then price drift is precisely the cost that matters, and the benchmark that ignores it will report success on the days it hurt you most.

So the algorithm choice is downstream of the same question as the urgency parameter: why is this trade being made? A view-driven order belongs on an absolute benchmark. A mandate-driven order belongs on a relative one.

Underneath the schedule, every child order faces the choice from the first microstructure lesson: rest, or cross.

Crossing the spread guarantees the fill and pays the spread. Resting may earn the spread instead of paying it, and may not fill at all.

The naive arithmetic favours resting, and it is wrong for two reasons established earlier. Resting orders suffer adverse selection, filling disproportionately just before the price moves against you. And an unfilled child order does not remove the requirement to trade; it defers it, so the quantity reappears later, often when conditions are worse.

The practical policy is conditional rather than fixed. Rest when the schedule has slack and the spread is wide relative to expected drift. Cross when the schedule is behind, the spread is narrow, or the queue ahead is long enough that a fill is unlikely.

That last consideration is why queue position is tracked as an explicit input. A resting order behind substantial size at the same price has a low probability of filling before the level moves, and waiting there has an option cost.

The logic is small, and writing it out makes the inputs explicit.

def place(slice_qty, behind_schedule, spread_bps, queue_ahead, resting_size,
          urgency_bps, max_display=500):
    """Return (action, displayed_qty). urgency_bps is the drift cost of
    waiting one interval, estimated from volatility and signal decay."""
    if behind_schedule > 0.15:
        return "cross", slice_qty            # falling behind dominates
    fill_odds = resting_size / (queue_ahead + resting_size + 1e-9)
    expected_saving = spread_bps / 2 * fill_odds
    if expected_saving < urgency_bps:
        return "cross", slice_qty            # waiting costs more than it saves
    return "rest", min(slice_qty, max_display)   # show only part of the size

place(20_000, 0.02, spread_bps=4, queue_ahead=80_000,
      resting_size=20_000, urgency_bps=0.3)
# ('rest', 500)   fill odds 0.20, saving 0.40bps > 0.30bps of drift

place(20_000, 0.02, spread_bps=4, queue_ahead=400_000,
      resting_size=20_000, urgency_bps=0.3)
# ('cross', 20000)  fill odds 0.05, saving 0.10bps < 0.30bps of drift

Same spread, same slice, opposite decisions. The only thing that changed was the queue ahead, which turned a likely fill into an unlikely one.

The max_display parameter in that code is the second placement lever, and it exists because of the inference problem.

A displayed order of 20,000 tells everyone that a buyer of at least 20,000 is present. That is information, and the price moves on it before the order fills. Showing 500 at a time reveals far less.

Iceberg orders formalise this: display a small quantity, and when it fills, automatically replenish from a hidden reserve. The displayed portion keeps price priority; the hidden portion usually loses priority to displayed orders at the same price, which is the deliberate subsidy to visibility discussed in the market design lesson.

So concealment has a direct cost: you queue behind anyone willing to show their size. You are trading a worse fill probability for less information leakage, which is the same trade-off as everywhere else in this cursus, arriving one level lower.

The rule of thumb is to size the display to what the venue would consider unremarkable. An order small enough to look like ordinary flow reveals nothing, and revealing nothing is worth more than filling slightly faster when the parent order is large.

The third placement decision is where to send the child order, and in a fragmented market this is a real choice rather than a formality.

Venues differ on more than the price showing. Fee structure matters: many venues rebate liquidity providers and charge takers, others invert it, and the difference can exceed the spread on a tight instrument. Participant mix matters more: a venue whose flow is largely uninformed is a better place to rest an order than one dominated by fast participants, for exactly the reasons the spread lesson set out.

Non-displayed venues offer a different bargain. Nothing shows before the trade, so a large order can meet a counterparty without either side broadcasting. The cost is uncertainty: you cannot see whether anyone is there, so an order may sit unfilled while displayed markets trade.

The standard approach is to work several venues at once, resting non-displayed while participating on lit venues, and to route based on realised fill quality rather than on the quoted price alone.

That last phrase is the important one. A venue that fills you quickly and is followed by an adverse move is worse than one that fills you slowly and is not, even though the first looks better on price.

The pattern in the last column is that every algorithm fails by doing exactly what it was told, in circumstances where that instruction was wrong.

That is worth stating because it locates the responsibility. Algorithm selection is not a technical choice delegated downward; it is the encoding of why the trade exists. The trader can execute a chosen policy well, and cannot repair a policy chosen against the wrong benchmark.

Which makes measurement the final piece: without it, a wrongly chosen algorithm reports success indefinitely.