Slippage tolerance and protective price caps

You set a tolerance so a market order could not fill badly, and the order came back partially filled — or not filled at all — during exactly the move you were trying to get out of.

The mechanism worked. A tolerance, a maximum slippage setting, a protective cap: whatever it is called, it is a limit price attached to an order that would otherwise have had none. Adding it does not make the order safer. It converts one guarantee into the other, and the guarantee it gives up is the one people assumed they still had.

What a cap actually is

Every order type is a position on one trade-off: you can guarantee that an order executes, or guarantee the price it executes at, and not both.

A market order sits at one end. It will fill as long as there is any quantity to fill against, at whatever walking the book produces.

Attach a cap and you have moved along the axis. The order now has a worst acceptable price, which means there are book states in which it does not complete. That is not a side effect — it is the entire content of the change. A capped market order is a limit order with an aggressive limit, however the interface labels it.

The useful way to hold this: a cap does not prevent bad fills, it prevents fills. Whether that is preferable is a question about the position, not about the mechanism, and this site does not have a view on it or suggest any value for the setting.

Where caps come from

Three different sources, and they behave differently.

Venue-imposed protection. Some venues apply a cap to every market order whether you asked for one or not, converting it to something more like an aggressive limit at a tolerance they choose. This exists so that a market order into a thin book cannot print an extreme fill. It also means the “market order” you sent may not be one.

Participant-set tolerance. A field you fill in, expressed as a percentage of a reference price or as an absolute distance. The reference matters: a percentage from the touch, from the mid, or from the last trade produce different boundaries, and which is used is not always displayed.

Pool-style minimum received. When trading against a formula-priced pool, the equivalent control is a floor on the quantity you will accept out. If the computed output falls below it, the whole transaction fails rather than executing worse — frequently paired with a deadline, so a transaction that waited too long also fails rather than executing against a state it was not priced for. Note that this one is generally all-or-nothing: a pool trade does not fill part of the way and stop.

Two ways to apply the same number

Even with an agreed tolerance, there are two rules for enforcing it and they produce different outcomes.

Cap the worst fill. No individual match may occur beyond the boundary. Levels inside the cap fill, levels beyond it do not, and the order stops there with a remainder.

Cap the average. The order may consume levels beyond the boundary provided the resulting average stays inside it. Some quantity fills at prices worse than the cap; the aggregate satisfies it.

The first can leave you with a partial fill in a case where the second would have completed. The second can produce individual fills at prices you would have said were unacceptable. Both are defensible and neither is what most people picture, which is a rule that fills everything at a good price.

What happens to the unfilled remainder is a third variable: cancelled, or left resting at the boundary price as a working order you now own. The second case is the one that catches people, because an order intended as immediate has become a resting one.

The mechanism

THE MECHANISM — a cap on an order

  · Market order, no cap
                    → fills against whatever is there.
                      Execution guaranteed, price not.

  · Market order with a cap
                    → becomes an aggressive limit
                      order. Price bounded, execution
                      NO LONGER GUARANTEED.

  · Book runs out inside the cap
                    → partial fill. You hold a position
                      of a size you did not choose.

  · Cap applied to the worst fill
                    → stops at the boundary level, even
                      if the average would have been
                      acceptable.

  · Cap applied to the average
                    → individual fills may occur beyond
                      the boundary.

  · Unfilled remainder
                    → cancelled, or LEFT RESTING at the
                      boundary. An immediate order can
                      become a working one.

  · Reference price used, worst-versus-
    average enforcement, remainder handling
    and whether the venue imposes its own
                    → VENUE-SPECIFIC. Your market order
                      may already be capped.

Worked example

Illustrative figures, synthetic throughout. Suppose the ask side rests as 40,004 for 1.2 units, 40,010 for 2.5, and 40,025 for 5.0. You send a market buy for 5.0 units with a tolerance of 0.05% measured from the touch.

The boundary is 40,004 × 1.0005 ≈ 40,024. Note that the third level, at 40,025, is just outside it — by one unit of price.

Under a worst-fill rule. The order fills 1.2 at 40,004 and 2.5 at 40,010, totalling 3.7 units at an average of about 40,008. The 40,025 level cannot be matched, so 1.3 units do not fill. You hold 3.7 units and, depending on the venue, either nothing else or a resting order for 1.3 at the boundary.

Under an average rule. The order could take 1.3 from 40,025 as well, since the resulting average — about 40,013.9 — is inside the boundary. You are filled for the full 5.0, and 1.3 units of it traded at a price beyond the cap you set. With no cap at all the result is identical here, and unbounded in general: had that third level been 41,000, the uncapped order would have taken it. Two rules, one order, one book, two outcomes — and the difference between them came from a boundary sitting one unit of price below a level, which is not a thing anyone can plan around.

Now the case the setting is usually for. Suppose the same order is sent during a fast move and by the time it arrives the book is 40,004 for 0.1 and then nothing until 40,900. Under a worst-fill rule you get 0.1 units and stop. Uncapped, you get 5.0 units at an average near 40,882. The cap did what it was for, and it also left 4.9 units of the transaction not done — in a moving market, with the position you were adjusting still substantially as it was.

Both directions fail, and you choose which

Worth being explicit, because the setting is frequently presented as risk reduction. A tight tolerance fails by not executing: in fast conditions it rejects or partially fills exactly when the book is moving, and repeated rejections in a moving market are its characteristic signature. A loose tolerance fails by executing — it permits the fill it was nominally there to prevent, bounding an outcome so far away that the bound never binds. No setting avoids both, because they are the same axis, and which failure anyone would rather have is not something a description of the mechanism can answer or that this site will suggest a value for.

The failure mode

The characteristic trap is the word “protection”. A cap protects the price and exposes the fill, and the exposure is unbounded in the sense that matters: not filling leaves the position entirely as it was, for as long as the condition persists.

That combines badly with stop orders, which is where it does the most damage. A stop is a trigger that submits an order; if the order it submits carries a tolerance, then the trigger can fire, the order can be submitted, and nothing can fill — leaving a triggered stop, a fully open position, and a record that shows the mechanism activating correctly.

The second trap is the venue-imposed cap you did not know about. An order sent as a market order, converted by the venue to a bounded one, produces a partial fill for a reason that is nowhere in your own instruction. That is discoverable in advance only by reading the venue’s rules on market-order protection, and it is not visible at all in the order ticket.