Everything so far has treated each order in isolation. But many strategies only make sense as a set of orders executed jointly: a spread trade that must stay hedged, or a rebalance across two hundred names that must respect portfolio-level risk. This part covers the two canonical multi-order problems - pairs execution and basket (portfolio) execution - and what changes when orders stop being independent.

Pairs Execution

The Setup

A pairs strategy trades a relative-value view: two related instruments have drifted out of their historical relationship, and the trader sells the rich one and buys the cheap one, betting on convergence rather than direction (reversion to the mean). The execution algorithm’s job is to build both legs in proportion - the fill progress of one leg dictates what the other is allowed to do.

Leader and Follower

The heart of a pairs algorithm is how it “legs in.” Executing both sides simultaneously with market orders would be safe but expensive; working both sides passively risks one leg filling while the other doesn’t - leaving an unhedged directional position, known as leg risk. Standard pairs execution assigns roles:

• The leader - normally the less liquid, more expensive-to-trade instrument - is worked passively with limit orders, in small increments, to keep its impact down.

• The follower - the more liquid instrument - is executed aggressively the moment a leader increment fills, typically with marketable orders, to close the hedge gap within seconds.

Passive execution where trading is costly, aggression where it is cheap while keeping the unhedged window is kept as short as possible.

A Worked Example

Two futures, A and B, historically trade at a 3:2 value ratio. The desk sets entry triggers 1% either side of fair, with a $250,000 gross cap. When A rallies hard and the ratio breaches the upper band, the algorithm begins: it rests a small limit order in B (the thin leg, now relatively cheap). Each time a B increment fills - say 3 contracts - it instantly sends a marketable order for the proportional 2 contracts of A on the other side. Fill, hedge, repeat: the position grows in lockstep, never more than one increment unhedged, until either the cap is reached or the ratio reverts and the unwind logic takes over in mirror image.

Basket Execution

Risk Lives at the Portfolio Level

A basket algorithm executes a list - often hundreds of names, both buys and sells - as one program. The defining insight, previewed in Part 3: the risk that matters is the aggregate risk of the residual (unexecuted) portfolio, not the sum of single-name risks. Correlated buys and sells hedge each other - long one large-cap tech name against short another leaves far less net exposure than either leg alone.

What Coordination Changes

Optimizing at the portfolio level produces schedules a single-order mindset would never choose:

• Hedge-aware pacing. Two offsetting orders can both be traded slowly and cheaply, because together they carry little net risk - where in isolation each would have been rushed.

• Residual-risk sequencing. A cost-risk optimizer (the machinery of Part 10 applied to a covariance matrix) front-loads the names that dominate residual risk and lets hedged, benign names drift along cheaply.

• Constraint tracking. Real programs carry side conditions the optimizer must respect throughout execution, not just at the end: cash balance between buys and sells (self-financing), sector or beta neutrality, participation caps per name.

• Explicit hedging. When the basket itself can’t stay balanced - say the buy side is illiquid and lags - the algorithm can overlay index futures or a liquid proxy to neutralize the drift, unwinding the overlay as the real positions complete.

The Practical Payoff

The payoff is measured in the cost-risk trade-off: for the same completion risk, a portfolio-aware schedule pays less impact than trading every line item on its own clock. On large rebalances the difference is not marginal - it is often the majority of achievable savings.

Both pairs and basket engines still delegate each child order’s venue choice to the routing layer. That layer - the smart order router - is the subject of Part 9.