Skip to content

Liquidity-Seeking Algorithms: When to Use a Sniper, a Guerrilla, or a March

Liquidity-seeking algos trade fill certainty for better prices. Sniper, guerrilla, and aggressive POV each push that trade to a different point — picking one means picking how much variance you can live with.

7 of 12 ~14 min

Most execution algos fall into two camps. The first camp is schedule algos: VWAP, TWAP, POV. They have a target participation curve and they stick to it, more or less. They don’t try to be clever; they spend time to reduce impact. The second camp is liquidity-seeking algos: guerrilla, sniper, liquidity seeker, iceberg-plus. They actively hunt for hidden liquidity in dark pools and at passive fills on lit exchanges.

The difference compresses into one sentence: schedule algos sell you certainty of completion, liquidity-seeking algos sell you a probability of a better price. This article is about the second camp, and that sentence is the through-line — every strength, every weakness, and every failure mode of a liquidity-seeking algo is a different face of the same certainty-for-probability trade. If you’ve ever wondered why your “liquidity-seeking” algo left 30% of the order unfilled and walked away, or why it filled everything in two seconds at the offer, the answer is in the terms of that trade, and the terms were optimized for a situation that may not be yours.

Harris (2003, Ch. 22) distinguishes between active and passive execution strategies in a way that’s still useful: passive algos wait for the market to come to them; active algos go to the market. Liquidity-seeking lives in between. It actively hunts, but it hunts by resting passive orders to attract fills and then jumping on attractive targets when they appear. The classification isn’t about aggression; it’s about whether you’re taking or making at any given moment.

What Problem Are These Algos Solving?

Schedule algos solve the time-versus-impact problem: given an hour to buy 100,000 shares, a VWAP algo paces your fills against volume and accepts impact as the cost of patience. Liquidity-seeking algos solve a different problem — finding liquidity that isn’t on the lit book. A large-cap US stock might show 5,000 shares at the best bid on the NYSE, while the broker’s smart order router knows there are 200,000 shares resting in dark pools and behind iceberg orders on ECNs. A schedule algo won’t see those. A liquidity-seeking algo will.

The premise is that hidden liquidity is cheaper to access than displayed liquidity, and the premise is mostly true: you don’t pay the spread when you cross against a resting dark order, and you don’t pay impact if no one sees you take it. But the cheap liquidity comes with two riders — it isn’t always there when you want it, and searching for it leaks information. Those two riders map onto the two big families of liquidity-seeking failures, which we’ll get to.

Sniper: The Far End of the Trade

The three main strategies can be ordered by how much certainty they’re willing to give up for price. At the far end sits the sniper.

A sniper algo rests a single passive order deep in the book — well below the current bid — and waits. It might be working a buy order at $49.90 while the offer sits at $50.01, waiting for someone to come down and hit its bid. When it gets filled, it replaces the order and waits again. A pure sniper is essentially a limit-order strategy with execution-algorithm plumbing around it: it pushes the certainty-for-price trade to its limit, with the best potential price and the least guaranteed fill.

Its habitat follows directly from that position. Wide spread, stable midpoint, hours rather than minutes, no urgency — under those conditions the deep bid eventually gets hit and you pocket the whole spread. Flip any condition and it turns on you: if the mid drifts while you wait, you pay timing cost; if the spread is tight, your deep bid never gets touched; if the stock gaps through your level, you simply miss. Most execution desks offer a sniper, but few traders run it as a primary strategy. For most institutional orders it’s too slow.

Guerrilla: Rest, Watch, Pounce

The guerrilla combines the sniper’s patient resting with an opportunistic taking engine, moving the trade one notch back toward certainty. The classic behavior: post passive orders at the touch or just inside it, monitor dark pools continuously, and “pounce” — cross the spread immediately — when an attractive hidden order shows up.

The pounce is the key. The guerrilla maintains a “want list” of hidden orders it has seen in dark pools, and when a target is large enough and priced well enough, the algo lifts it instantly, before it gets pulled — which demands sub-millisecond reaction times. So the guerrilla wants a specific environment: good dark-pool liquidity (large-caps, ADTV > $1B), a spread wide enough that passive posting earns something, and a tolerance for some adverse selection. When the spread is under a cent, passive posting earns nothing; when the dark pools are empty (small-caps, recent IPOs, halted names), the pounce loop has nothing to pounce on — and in either case the guerrilla degenerates into an expensive wait.

Adverse selection deserves its own paragraph, because it’s the guerrilla’s hidden cost. You post a passive bid at $49.99 and someone hits it — a reasonable inference is that they knew something you didn't. The mid drifts to $50.05 right after your fill. You did “save the spread,” but you got longer at a price that was already stale. Cheap liquidity is sometimes cheap for a reason.

Aggressive POV: The Middle Ground

POV (percentage of volume) is technically a schedule algo, but its aggressive variant — sometimes called “aggressive POV” or “liquidity-seeking POV” — is a hybrid that moves the trade another notch toward certainty. The algo sets a target participation rate (say, 10% of volume), but instead of slicing child orders uniformly, it concentrates them at moments when displayed liquidity is thick.

The math is simple. If volume in the last 5 minutes was 50,000 shares and you want 10% participation, you owe the market 5,000 shares. Rather than sending 1,000 shares a minute for five minutes, the algo watches the book and sweeps the full 5,000 when a large displayed order appears. It inherits the schedule algo’s roughly predictable completion and the liquidity-seeker’s opportunism. The price is that it touches both sets of tails: when volume spikes, its participation cap trips too fast; when volume dries up, it can’t fill at all; and it makes no promises against a hard deadline.

The aggressive POV variant is what most desks actually mean by “liquidity-seeking.” If you don’t know what else to use, it’s a reasonable default.

What the Algos Are Actually Doing Under the Hood

Most liquidity-seeking algos maintain three internal loops. The display loop posts and refreshes passive orders on lit venues — deciding price, size, and venue, possibly randomizing order size to avoid detection. The detection loop monitors dark-pool indications of interest (IOIs), retail wholesaler flow, and displayed iceberg refreshes, building a “liquidity map” of where size is likely hiding. The pounce loop fires a take order within microseconds when the detection loop flags a target — rate-limited, so it doesn’t blow through multiple levels.

def pounce_check(target_size, target_venue, mid, spread, max_spread=0.10):
    """Decide whether to cross the spread for hidden liquidity."""
    if target_size < 1000:
        return False                # not worth the trip
    if spread > max_spread:
        return False                # spread is too wide, market is unstable
    if target_venue in blocked_venues:
        return False                # anti-gaming rules
    return True

That’s a toy. Real implementations also check the NBBO, the time of day, recent volatility, and the fraction of ADV already worked.

One Order, Four Paths

Suppose you have 200,000 shares to buy in a US large-cap with ADV of 8 million shares, spread $0.01, mid $50.00.

The schedule algo (VWAP over 60 minutes) is the baseline: predictable, completes on time, roughly 4-6 bps of impact plus 0.5 bps of spread. The sniper posts a $49.95 bid for 90 minutes: if the mid holds, you fill passively and save the spread; if it moves to $50.10, you’ve missed and paid 10 bps of timing cost. The guerrilla posts at 49.99/49.99 / 50.00 and watches the dark pools: when a 50,000-share block appears at $49.99, it pounces — a quarter of the order fills at the bid with zero spread cost, and the algo keeps working. Total cost might land at 1-2 bps, or you might fill nothing and end up paying full VWAP anyway. Aggressive POV at 12% participation sweeps as size appears, fills in 30-45 minutes, costs 3-5 bps.

Four expected values, four variances. This is exactly the tradeoff the academic literature formalized: Bertsimas and Lo (1998) framed optimal execution as impact cost against timing risk, with the optimal path being a tradeoff curve rather than a single answer; Almgren and Chriss (2000) added a quadratic penalty on the variance of execution cost and derived closed-form trajectories — front-loaded if you’re urgent, linear if risk-neutral, back-loaded if you have time. Note, though, that this theory assumes a fixed volume schedule. Liquidity-seeking algos are a different animal: they react to latent liquidity (dark pools, hidden orders), so there is no closed-form trajectory to derive. The academic work mostly doesn’t model this. Practitioners do, and what they find lines up with the through-line: in liquid names with deep dark pools, liquidity-seeking beats schedule algos on average impact but carries higher variance — outperforming in the middle of the distribution and underperforming in the tails. If your PM can live with variance, it’s a win. If not, stick with VWAP.

So the “best” choice depends on what you’re optimizing. If the PM cares about beating VWAP, aggressive POV is safest. If the PM wants minimum impact at any cost, guerrilla with a long horizon. If the fear is missing a fast-moving name — and the risk of not filling is acceptable — then, and only then, the sniper.

The Hunter Gets Hunted

We said searching leaks information. A liquidity-seeking algo that posts the same size at the same price at the same venue every day is publishing its own schedule. Other participants figure out the pattern and trade ahead of it. Harris (2003, Ch. 21) discusses this “information leakage” in the context of large orders: if your algo tips its hand by repeatedly posting at one venue, sophisticated counterparties recognize the pattern, position ahead of you, and extract rent.

Modern algos therefore randomize — child order size, posting venue, refresh timing, price level. The randomization is bounded, since too much of it destroys the benefits of consistent execution, but a moderate dose lowers the odds of being fingerprinted. The cost lands elsewhere: randomization makes TCA harder. If child order sizes bounce between 100 and 500 shares, you can’t compare one day’s execution directly to another’s. Most TCA systems smooth this out by averaging across many orders; at the single-order level, it’s noise.

The Yardstick Is Often Wrong Too

The high variance creates a subtler problem: liquidity-seeking algos are routinely judged against the wrong benchmark.

Put a guerrilla against a VWAP benchmark and it will sometimes look terrible. The reason is mechanical: the VWAP benchmark assumes you trade with volume, and the guerrilla trades opportunistically — filling fast when it finds a block, waiting when it doesn’t. The two simply don’t match. The professional approach is to benchmark liquidity-seeking against arrival price or implementation shortfall; if you must use a VWAP benchmark, expect stretches where the guerrilla looks bad while doing exactly what it was designed to do. The algo isn’t broken. The yardstick is.

This is also why generic “our algos beat the benchmark by X bps” reports are usually meaningless. The right comparison is algo-specific: VWAP algo against VWAP benchmark, IS algo against arrival price, liquidity-seeker against an IS benchmark. Otherwise you’re comparing apples to screwdrivers.

Four Classic Complaints

The failure modes come with fixed scripts on every desk, and each script traces back to the same thing: the terms of the trade weren’t understood.

“It didn’t fill.” The trader set a sniper on a stock with a tight spread. The mid drifted up, the bid never got hit, and the algo returned 30% filled at the end of the horizon. The algo did what it was designed to do — the mistake was running a sniper on a tight-spread, trending stock.

“It filled everything in two seconds.” The trader set a guerrilla on a low-volume name. The algo posted at the touch, a large block came in, the pounce loop fired, and the entire parent order filled at the offer. The trader crossed a 1-cent spread on 200,000 shares — $2,000 of cost the PM never budgeted. The fix is a participation cap.

“It paid more than VWAP.” The trader ran aggressive POV on a day when volume spiked. The algo hit its participation cap and stopped, leaving 40% unfilled; the stock ripped, and by the close the unfilled portion was up 1.5%. The effective cost came out far worse than a plain schedule algo would have. The fix is a higher cap, or a hybrid algo with a hard deadline.

“The dark pool fills were toxic.” The trader’s guerrilla found “great” liquidity in dark pool X — mostly sub-penny fills, spread saved — and then the stock moved against them. The great liquidity was informed traders. The fix is monitoring adverse selection by venue: if one pool’s fills are systematically followed by adverse price moves, drop it.

When to Turn It Off Entirely

Some situations call for switching liquidity-seeking off and falling back to a schedule algo. Earnings days: volume is heavy enough that VWAP works fine, and liquidity-seeking adds complexity for no benefit. Index rebalance days: liquidity is concentrated and prices are well-defined; VWAP handles it. Crisis markets: spreads blow out, dark pools withdraw, and there is nothing left to seek. And stale-signal days — when the market is moving on information your model doesn’t capture, a liquidity-seeker fills you at bad prices, while a schedule algo absorbs the move less painfully.

The general rule: normal market and large order, use liquidity-seeking; unusual market or small order, use a schedule algo. In operational terms, a decision sequence that covers most cases:

  1. Is the order > 5% of ADV? Yes → liquidity-seeking with a low participation rate (1-3%). No → schedule algo; the impact will be minimal anyway.
  2. Is the spread > 5 cents? Yes → guerrilla makes sense; passive posting earns. No → sniper is too risky.
  3. Is there a hard deadline? Yes → aggressive POV with a rising participation rate. No → guerrilla with a long horizon.
  4. Is the PM risk-averse? Yes → VWAP with a slight POV tilt. No → guerrilla or sniper.

Most shops default to one of three algos — VWAP, POV, liquidity-seeker — and reach for the third only when the order is large relative to ADV and the PM can stomach variance.

A note on baskets: with correlated names, liquidity-seeking gets harder. You can’t run an independent sniper on each leg — legs fill at different times and the basket goes off-balance. Basket-aware algos monitor fill progress across all legs and adjust per-leg aggression to keep the whole on schedule; Harris (2003, Ch. 24) discusses this “portfolio execution” problem and notes that coordinated execution can meaningfully reduce overall cost for highly correlated baskets versus working the legs independently. That’s its own article: multi-asset execution.

The Honest Ending

Liquidity-seeking algos are not magic. They’re a bet that hidden liquidity exists at reasonable prices and that you’ll find it before someone else does. Sometimes the bet pays; sometimes it doesn’t; the variance is real. If your shop’s culture is beating VWAP by 2-3 bps consistently, well-calibrated liquidity-seeking gets you there. If the culture is never missing a benchmark and never carrying variance, stick to schedule algos and pay the impact as a known quantity. The people who do this well run liquidity-seeking as the default with conservative parameters — participation caps, max impact budgets, a hard deadline that falls back to a schedule algo. They use the algo’s intelligence without letting it make decisions their PM wouldn’t.

And one thing that appears in no model: trader intuition. A skilled execution trader looks at the book, the news, the recent prints, and decides “this stock is about to gap,” or “there’s a hidden seller here,” or “I should just cross now.” No algorithm captures that. The best liquidity-seeking algos augment a trader’s intuition rather than replace it — the trader who treats the algo as a black box and walks away gives up the advantage of being human, while the one who treats it as a tool (set the parameters, watch the fills, intervene when something looks off) gets the best results. The buy-side desk that wins on execution combines smart algorithms with experienced traders. Neither alone is sufficient.

References

  • Harris, L. (2003). Trading and Exchanges: Market Microstructure for Practitioners. Oxford University Press. Ch. 21-22, 24. ISBN: 978-0-19-514470-3.
  • Almgren, R., & Chriss, N. (2000). “Optimal Execution of Portfolio Transactions.” Journal of Risk, 3(2), 5-39.
  • Bertsimas, D., & Lo, A. W. (1998). “Optimal Control of Execution Costs.” Journal of Financial Markets, 1(1), 1-50.