Your algorithm is a third of the way through a large sell order and the liquidity on the other side disappears. What should it do?
6 min readUpdated 2026-08-15Target archetype: Enterprise Captive
0
Answer
Short answer
Establish first whether the book is genuinely empty or your market data has gone stale, then stop making the problem worse: your own prints are feeding the volume measure you throttle against.
Was this answer helpful?
Likely follow-ups
→The instruction says complete by the close. Does that override the price constraint, and who is entitled to decide?
→How would you set a price collar that does not simply follow the market down?
→The venue halts the stock. What happens to your resting orders, and what do you do at the reopening auction?
→Your primary market data feed goes stale for two seconds. What is the algorithm's posture, and how does it know it has gone stale?
First decide whether the market is empty or your view of it is
The observation "there is no liquidity" is an inference from data, and the two situations that produce it need opposite responses. A genuinely thin book means you should slow down and stop pushing. A stale or gapped feed means you are trading blind, and slowing down is not enough: you should stop entirely, because every decision you make is now based on a book that may not exist.
Telling them apart is a liveness question rather than a content question. A feed that has stopped delivering looks identical to a market in which nothing is happening, so the algorithm needs heartbeats, sequence continuity and a per-venue staleness clock, and it needs to treat "no update for longer than expected" as an event rather than as quiet. This is why the consolidated view feeding an algorithm needs an explicit degraded state: an algorithm that cannot distinguish a quiet market from a broken feed will eventually cross a spread that was never there.
Your own trading is inside the measurement
The second thing to establish is a feedback loop most candidates miss. A participation-rate algorithm targets a share of traded volume, and traded volume includes its own prints. In a normally liquid market that self-reference is a rounding error. In a thin market it is the dominant term: if you are most of the volume, then trading more raises measured volume, which raises your permitted rate, which causes you to trade more.
The same trap sits in benchmark-following logic. An algorithm tracking a moving reference price will follow a price that its own executions are moving, so a schedule that says "keep up with the market" turns into "keep selling into the hole you are digging". The defence is that the participation measure should exclude your own executions, and the price constraint should be anchored to something your trading cannot move, which in practice means a reference struck before you began or a limit derived from an interval far longer than your own trading horizon.
Behaviour has to be specified, because the default is bad
An algorithm has three possible responses and only one of them is acceptable as a silent default.
It can complete the order anyway, which is what a schedule-driven instruction with no price constraint will do, and it is how a large order turns into a price event. It can stop, which is safe for the market and leaves a client with an unfilled residual they do not know about, exposed to whatever happens next. Or it can pause against a stated condition and tell somebody, which is the only response that keeps the decision with the person entitled to make it.
So the design work is in making the pause a real, defined state rather than an absence of activity. It needs a trigger expressed in terms the desk can reason about: displayed depth within a band of the reference price falling below a threshold, spread widening beyond a multiple of its recent typical value, price moving more than a stated amount from the arrival price, or the algorithm's own share of volume exceeding its cap. It needs a defined posture while paused, meaning whether resting orders are pulled or left.
It needs a resumption condition, so it does not require a human to restart it for a two-second event. And it needs to escalate, visibly, to a trader who can decide whether to widen the constraint, work the residual by hand, or leave it.
Loading diagram…
The branch that costs money is the middle one: an algorithm without it has no way to express "the market is telling me something" and will resolve every ambiguity in favour of finishing the order.
The residual belongs to somebody
Pausing is not free, and a good answer says so rather than treating caution as costless. An order that stops halfway leaves the client with unhedged exposure and with the timing risk they were paying you to manage. If the market is falling, stopping a sell order is a decision to hold, and that decision has an owner. This is the honest reason "just stop trading" is not a complete answer: the algorithm can protect the market from your order and cannot protect your client from the market.
What resolves it is that the constraint and the escalation are agreed with the client in advance as part of the instruction, so that a pause is the behaviour they asked for rather than a failure you have to explain afterwards. Limit prices, participation caps and completion obligations conflict with one another, and the instruction has to say which one wins. An algorithm that silently prioritises completion over price has answered that question on the client's behalf.
Halts and auctions are a different regime
Venues in many markets suspend continuous trading when a price moves too far too fast, and reopen through an auction. That changes the problem in ways continuous-market logic gets wrong. Resting orders may be cancelled or may be carried into the auction depending on the venue's rules, an auction price is formed from an order book with entirely different dynamics, and a large residual submitted into a thin reopening auction is capable of setting the price rather than trading at it.
An algorithm therefore needs to know, from reference data rather than from code, whether an instrument is halted, whether its venue's rules carry orders into the auction, and what its own posture is on resumption. The simplest defensible position is to treat a halt as a hard pause requiring a positive decision to resume, precisely because the resumption is the moment the algorithm's assumptions are least valid.
What May 2010 established about instructions with no price in them
In May 2010, an automated selling programme working a very large order without regard to price or time interacted with liquidity that was already thin, and helped produce a violent intraday collapse and recovery in US equity markets, with some securities trading at absurd prices before those trades were broken. The programme was not malfunctioning; it did what it had been told. What was missing was any representation inside the instruction of the market it was executing into.
That is why the interviewer is asking this question rather than a question about scheduling. The behaviours being scored are a price constraint that does not chase the market, a participation cap measured on volume other than your own, a defined pause with a defined escalation, and a posture for the case where the venue itself stops. An algorithm that has all four will complete fewer orders on time, and it will not be the reason a security traded at a price nobody believes.
An execution algorithm's most important instruction is the one that tells it to stop. Absence of liquidity, absence of data and a venue halt all look the same from the inside, and all three have to reach the same conclusion faster than the algorithm can finish the order.