Hedging Your Book: Passive Limit vs IOC vs Market Orders

An operator running a b-book takes the other side of client trades on their own venue. Which means the operator's book carries the net client exposure at all times. Some of that exposure is fine to hold — uncorrelated flow that offsets itself, plus whatever directional bias the risk team is happy running. The rest has to be hedged out into external destination venues.

The hedge router does that work. It watches net position per symbol, decides how much to hedge and when, and routes child orders to one or more external destinations. The single biggest lever inside that router is order type — passive limit, IOC-at-touch, or market. This piece is about what each style buys you, what it costs, and the reconciler and kill-switch scaffolding that has to sit around them.

The Three Order Styles and When Each Fires

Production hedge routers converge on three styles. Every hedge decision picks one — per child order, per destination.

• Passive limit. Post a resting order at or inside the touch on the destination venue. Wait for counter-flow to fill it. Pay the maker fee, which is often zero and sometimes a rebate. Downside: no fill until someone crosses the spread. During a fast move the market walks away from your resting price and the hedge never lands.
• IOC-at-touch. Immediate-or-cancel at the current best price on the other side. Either it fills against resting liquidity right there, or it cancels and reports nothing done. Pays the taker fee. No resting order left on the book, no cancel round-trip.
• Market. Aggressive marketable order that lifts — or slams — as much of the book as it needs to fill the requested size. Pays the taker fee plus whatever slippage the book depth serves up. Always fills. That's the whole point.

Which of these is the default is a policy call, and it shapes the entire hedge programme.

Slippage and Fill Certainty by Style

The tail matters more than the median here. A passive limit that never fills has infinite implicit slippage — you're stuck carrying the exposure. A market order that hits a thin book during a flash-crash slips an order of magnitude worse than the model said it would. Design the router for the tail, not the average.

Reconciler Design — Detect Fills, Do NOT Cancel

The reconciler is the second-order piece. It watches what happens to child hedges after they're sent and updates the operator's picture of what's landed. This is where most hedge routers go wrong.

The pattern that holds up:

• Fire the child order with an idempotency key. If the send times out, retry against the same key without double-hedging
• Poll the destination venue — or subscribe to its private WebSocket — for fill state on that key
• When a fill lands, update the operator's net-hedged position and mark the child complete
• If a passive limit is still resting and the parent's target size is already met by other fills, leave it. Cancelling and re-firing burns fees and can miss the next tick
• Never issue a bare cancel without matching re-fire logic. A reconciler that auto-cancels resting hedges because it thinks they're stale — and then doesn't re-fire — quietly eats your exposure and hands you a directional position you never chose to hold

That last rule is the one that gets skipped, and it's the one that has ended hedge programmes. If the reconciler cancels a resting hedge, either it's already booked an equivalent fill elsewhere or it's about to re-fire at a new price. There is no third option that isn't a bug.

Anyone who's watched a hedger cancel resting orders in the middle of a fast move — and then not re-fire because the state machine got confused — knows how fast an operator can go from hedged to naked long or short. Minutes. Sometimes seconds. The alarms fire, someone kills the router, and now the ops team is manually flattening a position that was never supposed to exist.

Sliced Execution — Breaking a Big Hedge Into Children

The operator's net position at any given moment can be far larger than top-of-book depth on any single destination venue. Send it as a single market order and you lift the book multiple levels, print large, and move the market against your remaining exposure.

TWAP or VWAP slicing at the router level is the pattern:

• Break the parent hedge into N children sized to sit inside typical top-of-book depth on the destination
• Space them across a window — seconds for volatile symbols, minutes for the steady share — with jitter so the pattern isn't predictable
• Use IOC-at-touch for the working children. Escalate to market only if the parent's deadline is close and size remains unfilled
• If counter-flow through the normal client book has already offset the parent exposure, cancel the remaining schedule — not resting orders, the schedule

The slicing logic has to talk to the insurance fund design, too. Slippage on a big hedge that has to fire during a stress event comes straight out of the operator's P&L, and the insurance fund's health depends on the operator not turning a survivable market move into an unnecessary loss through sloppy execution.

Kill-Switch Policy — What Triggers a Full Halt

Every hedge router needs a kill-switch. The question is what pulls it.

The triggers that pull a hedge halt on a well-designed router:

• Destination venue outage. REST or WebSocket has gone dark, or the venue is throwing rate-limit errors above threshold. Keep firing into a broken venue and you rack up cancelled orders, missing fills, and reconciler drift
• Mark-price divergence. The destination's mid has drifted from the operator's own mark by more than a configured band — typically 25-100 bps depending on symbol. Either the destination is stale, your feed is stale, or something real is dislocating. Whichever it is, keep hedging into it and the P&L bleeds
• Size limit breach. The parent hedge would blow past a per-symbol, per-venue or per-hour cap. Stop, alert, escalate to a human
• Reconciler drift. The router's picture of net hedged position disagrees with the venue's picture by more than threshold. Something is wrong. Keep firing and it gets worse
• Latency degradation. Round-trips to the destination have climbed above threshold. Late fills are worse than no fills — the price has already moved

Each of these pages the risk team. Not a log line, not a warning email — a page. And each defaults to freezing new hedging, not escalating to market orders. The flash-crash failure mode is a router that responds to "something is wrong" by dumping into a thin book with aggressive orders. Don't build that router.

Multi-Destination Routing — Weighted Split, Failover, Health Checks

A router that fires into one destination is a single point of failure. Real programmes route across two or more external venues.

The design that holds up:

• Give each destination a target weight based on typical depth, fee schedule, reliability history
• Health-check each one on a rolling basis — REST ping, WebSocket heartbeat, recent fill success rate
• Route each child to the destination with the best current combination of depth, weight and health
• Failover is automatic. A venue that fails a health check gets weight zero until it recovers
• Kill-switch policy is per-destination and global. A single-venue outage removes it from the split. A mark-price divergence across all destinations halts the whole router

The operator's risk system needs per-destination fill quality visible — realised slippage, fill rates by style, latency percentiles — so the weighting is re-tuned from data instead of intuition.

The Failure Modes That Actually Bite

Four patterns account for most hedge-router incidents in production. Every one is preventable at the design layer.

• Market orders during a flash-crash. Destination book is thin, router sends a market for the entire net position, fill prints at levels that never come back. Fix: default to IOC-at-touch, gate market orders behind a size check and a mark-price sanity gate, freeze rather than escalate when the sanity gate trips
• Reconciler that auto-cancels without re-firing. Stale-detection logic decides a resting hedge won't fill, cancels it, doesn't re-fire. Operator is left carrying exposure they thought was hedged. Fix: never issue a cancel without a paired re-fire policy, and never let the reconciler have unilateral cancel authority. Cancels are a router decision. Not a reconciler one
• Slicing with no jitter. Predictable child-order timing lets adversarial flow front-run the hedge, and every child prints worse than the last. Fix: randomise the schedule inside its window, vary child sizes within a band, no round numbers
• Kill-switch that escalates to market. A well-meaning design that responds to reconciler drift or mark-price divergence by firing market orders "to be safe" — dumping into whatever depth exists, at whatever price, to "restore" the hedge. This is exactly the wrong reflex. The safe response to "something is wrong" is to freeze new hedging. Not accelerate it

What Basis Points Ships

Every default in the Basis Points hedge router reflects the team's ~30 years of combined experience shipping matching engines, hedging stacks and venue infrastructure. Default hedge style is passive limit, with a configurable escalation to IOC-at-touch after a per-symbol timeout. Market orders are gated behind a size check and only fire from kill-switch flatten flows — never as the default. The reconciler detects fills and updates state, and has no authority to issue unilateral cancels. Slicing runs as TWAP-with-jitter, per-symbol child sizes tuned to typical destination-venue depth. Multi-destination routing is weighted with per-venue health checks and automatic failover. Kill-switch triggers cover destination outage, mark-price divergence, size-limit breach, reconciler drift and latency degradation — and every trigger freezes new hedging rather than escalating aggression.

Operators licensing the platform inherit these defaults and tune them to their own risk appetite and destination mix — escalation timeouts, slice sizes, per-destination weights, kill-switch band widths. The ops surface exposes per-child fill state, realised slippage by style, per-destination health, and reconciler drift in real time, so the risk team sees the router's behaviour rather than just its outputs. See liquidation prices on multi-asset margin for how the hedge router interacts with the engine's liquidation path during a stress event.

Book hedging isn't a feature you bolt on after launch. Reconciler discipline, kill-switch policy, multi-destination routing — these decisions live at the platform layer and get inherited by every hedge the router fires. Getting them right is the difference between a b-book that runs cleanly and one that publishes an incident report.

Frequently Asked Questions

Evaluating the platform?

Related articles