Microstructure and Execution · Execution

2Order Types and Their Uses

In January 2015 two US stock exchanges agreed to pay a USD 14 million penalty, without admitting or denying the findings, to settle SEC charges about their order types. Their rules described one way of re-pricing an order that would lock or cross another venue’s quote; the exchanges accepted three, with different priority against each other, and had described one of them completely to some members but not to all. Nothing was hidden in the matching engine’s code. It was hidden in the difference between what the engine did with an order and what the rulebook said it would do. An order type is exactly that: a contract about what the engine will do with an order, and its fine print decides who trades first.

2.1 Price conditions: limit, market, marketable limit, stop

A limit order and a market order (Definition 1.1) differ in what they guarantee: the limit order its price, the market order its execution, as long as there is anything to execute against. Between them sits the order most traders actually send.

Definition 2.1 (Marketable limit order)

A marketable limit order is a limit order whose price reaches the best opposite quote when it arrives: a buy at or above the best ask, a sell at or below the best bid. It executes at once against the book, up to its limit price, and any remainder rests at that price.

A marketable limit order is a market order with a guard rail: a buyer who sends 200 shares at the ask plus five cents trades everything available up to that price and no further. The guard matters when the book is thin, and it matters most when orders arrive that were not sent by a person reacting to the market but by a price the market reached.

Definition 2.2 (Stop order, stop-limit order)

A stop order rests unseen until a trade occurs at or through its stop price (at or above it for a buy stop, at or below it for a sell stop); it then becomes a market order. A stop-limit order becomes a limit order at its stated limit price instead.

Stops are the order of traders who want out when a price is reached: the stop-loss. Their triggers are prices, their execution is immediate, and a book full of them is a book that sells harder the more it falls. Figure 2.1 measures this on firm.exchsim, the book’s exchange simulator (built in chapter 26): a bid ladder of 500 shares at every cent below 100.00, sell stops of 800 shares at every cent from 99.95 down, and one market sell of 3 000 shares. Without stops the sale walks the ladder down five cents. With twenty stops beneath it, each triggered sale takes out more bids, reaches the next trigger, and the price falls 37 cents; 19 000 shares trade for an initial sale of 3 000. Stop-limit orders priced one cent below their triggers stop the cascade sooner (25 cents), because an order that cannot sell at its limit rests instead of walking down: the guard rail again, bought at the price of not getting out.

Figure 2.1. A stop cascade on firm.exchsim: the fall caused by one market sell of 3 000 shares into a ladder of 500 shares a cent, against the number of 800-share sell stops placed a cent apart from 99.95 down. Data: mx_ordertypes.stop_cascade.

2.2 Time conditions

Definition 2.3 (Time in force; immediate-or-cancel, fill-or-kill and good-till-cancelled orders)

An order’s time in force says how long its unexecuted part may rest. A day order rests until the end of the session. An immediate-or-cancel order (IOC) executes what it can on arrival and cancels the rest. A fill-or-kill order (FOK) executes in full on arrival or not at all. A good-till-cancelled order (GTC) survives the session’s end and rests until it is executed or cancelled.

IOC and FOK orders never rest, so they never show anything to the market before they trade: they are how algorithms take liquidity, sweep several venues at once (the intermarket sweep order of One Quant Book 1, chapter 9, is an IOC with a legal flag), and ping dark pools (chapter 9). The at-the-open and at-the-close times in force, which rest only for an auction, belong to chapter 10. The simulator’s order-entry protocol carries all six (D, G, I, F, O, C).

The table shows what one book does with eight orders of different kinds. Firm 1 rests 300 shares bid at 99.99 and 500 offered at 100.01; firm 2 then sends, in order:

order	reports	filled	what happened
limit buy 100 at 100.00	accepted	0	rests; becomes the best bid, 100 displayed
marketable limit buy 200 at 100.01	accepted, executed	200	takes 200 of the 500 offered
post-only buy 100 at 100.01	rejected (would cross)	0	never enters the book
fill-or-kill buy 400 at 100.01	accepted, cancelled	0	only 300 remain at 100.01: nothing trades
immediate-or-cancel buy 400 at 100.01	accepted, executed, cancelled	300	takes the 300, cancels 100
iceberg sell 1 000 at 100.02, 100 shown	accepted	0	rests; the feed shows 100
midpoint peg sell 200	accepted	0	rests hidden at the mid, 100.01
sell stop 300 at 99.99	accepted (waiting)	0	invisible until a trade at 99.99 or lower

2.3 Display conditions: hidden, iceberg, pegged

Definition 2.4 (Hidden order, iceberg order)

A hidden order rests in the book and can execute against incoming orders but appears in no market-data feed. An iceberg order (reserve order) displays only a slice of its size; when the slice is executed, the venue displays the next slice from the reserve, at the back of the queue.

A hidden order gives up two things for its secrecy. At its price it ranks behind every displayed order, whatever their arrival times (the priority firm.lob implements), and, being invisible, it attracts no one: a displayed bid tells sellers where to sell, a hidden one waits to be found. An iceberg’s refreshed slice is a new arrival and joins the back of the queue with a new reference on the feed (chapter 1), so a large iceberg trades one slice per pass of the queue.

Definition 2.5 (Pegged order, midpoint peg)

A pegged order has no fixed price: the venue sets it from a reference quote and resets it whenever the reference moves, within an optional limit. A primary peg follows the best quote on its own side; a midpoint peg rests hidden at the midpoint of the best bid and best ask.

A midpoint peg trades at half the spread: a buyer and a seller who both peg to the midpoint meet there, each saving half a spread against crossing it. That is the business of dark pools (chapter 9), and the reason exchanges offer midpoint pegs too. The rule text of one exchange shows how much fine print the order type carries.

As of June 2026 — Pegging and minimum quantity on Nasdaq

Nasdaq’s Rule 4703, as reproduced in a rule filing of June 2026: an order with Pegging receives a new timestamp whenever its price is updated (it is evaluated as a newly entered order); an order with Midpoint Pegging is removed when the inside bid and offer become crossed or missing, re-entered at the new midpoint, and cancelled if no valid price returns within one second; midpoint-pegged orders are cancelled when a trading halt is declared; pegging orders are subject to a collar and are cancelled where they would execute more than USD 0.25 or 5% (whichever is greater) worse than the national best bid and offer; an order with a Minimum Quantity attribute must be at least a round lot and may not be displayed.

**Figure 2.2.** Two display conditions. Top: an iceberg shows one slice; when it is consumed, the venue shows the next slice at the back of the queue. Bottom: a midpoint peg rests, invisible, halfway between the best bid and ask.

An iceberg hides its size but not its behaviour. On firm.exchsim, with Book 7’s simulated flow as background, an agent sells 30 000 shares at the best ask showing 300 at a time, first as a venue iceberg, then as an algorithm that sends a new 300-share order itself after each slice fills. A detector reads only the public feed: after an execution removes a displayed order entirely, it looks for an add at the same side and price within 50 milliseconds and of exactly the removed order’s size. Figure 2.3 shows the arms race. The venue’s refresh arrives in the same event as the execution and is caught every time (99 of 99), with 20 false alarms in the half hour from other orders that happened to match. An algorithm that refills at once is caught 62% of the time (its refills that met a market that had moved executed on arrival and rested smaller); refilling after a random delay averaging 200 milliseconds drops that to 18%, and randomising the size by up to 30% to 6%. Loosening the detector (one second, sizes within 35%) brings detection back to 47% but with 378 false alarms for 34 detections. Randomised delays and sizes are why execution algorithms that refill their own orders are harder to see than venue icebergs.

Figure 2.3. Detecting icebergs from the public feed: the share of true refills a strict and a loose detector flag (left) and their false alarms (right), for a venue iceberg and for an algorithm refilling immediately, after a random delay (mean 200 ms), and with a random size (up to 30% either way); 30 000 shares shown 300 at a time in a simulated half hour. Data: mx_ordertypes.iceberg_study.

2.4 Who uses which, and why

participant	typical orders	why
retail investor	market, limit, stop	simple; the broker routes (One Quant Book 1, chapter 10)
execution algorithm	limit orders at the best, pegs, hidden, iceberg, IOC to dark pools	work a large order without showing it; take liquidity only when needed
market maker	post-only limits, mass quotes, IOC to hedge	earn the spread and the rebate; never take by accident
latency-sensitive trader	IOC and intermarket sweep orders	take a stale price before it moves, touch nothing else
position-protecting trader	stop and stop-limit	get out at a price without watching the screen

Order types multiply because each solves one participant’s problem inside the priority rules, and each can change who trades first. The 2015 case of the hook is the extreme: order types that re-priced an order to avoid locking another venue’s quote, with a priority behind the scenes that only some members fully knew. The lesson for anyone who trades is to read the rulebook and the technical specification together and test the engine’s behaviour against both; for anyone who builds an engine (chapter 26), to write the rule in one place and derive the documentation from it.

2.5 A limit order is a free option

Definition 2.6 (Free option of a limit order)

The free option of a limit order is the right a resting limit order grants the rest of the market: to buy at its price (a resting sell is a call written at that strike) or to sell at its price (a resting buy is a put), exercisable by anyone, at any time, until the order is cancelled.

Copeland and Galai (1983) described the cost of supplying quotes this way: a dealer’s bid and ask are a put and a call written to traders who know more. The option is exercised when the value moves through the price before the owner can cancel. A European version gives a lower bound on its value.

Proposition 2.7 (The value given away by a resting order)

A sell order rests at distance $d\ge0$ above the efficient price $P^\ast_0$ , which moves as a Brownian motion with volatility $\sigma$ per square-root second. If a trader who knows $P^\ast_T$ buys from it at time $T$ whenever $P^\ast_T$ exceeds its price, the order loses on average

C(d)=\sigma\sqrt T\,\varphi\!\left(\frac{d}{\sigma\sqrt T}\right)-d\left(1-\Phi\!\left(\frac{d}{\sigma\sqrt T}\right)\right).

Proof. The loss is $(P^\ast_T-P^\ast_0-d)^+$ with $P^\ast_T-P^\ast_0\sim\mathcal N(0,\sigma^2T)$ : the Bachelier call value (One Quant Book 2, chapter 13). ∎

            "fills": len(res.agents["iceberg"].fills), "sold": int(sum(f[5] for f in res.agents["iceberg"].fills))}


def free_option(d: float, sigma: float, horizon: float) -> float:
    """Expected loss of a resting sell at distance d above the efficient price, picked off at the horizon: the
    Bachelier call value sigma sqrt(T) phi(d / sigma sqrt(T)) - d (1 - Phi(d / sigma sqrt(T)))."""
    s = sigma * math.sqrt(horizon)
    z = d / s

Listing 2.1. The free option of a resting order. code/microstructure/02-order-types-and-their-uses/python/mx_ordertypes.py

In the simulated hour of firm.tape the efficient price moves 0.27 ticks per square-root second. A sell half a tick above value that stays for 10 seconds gives away 0.15 ticks per share in expectation, and 0.60 ticks if it stays a minute: an order’s value decays with the time it stays unattended, which is why liquidity providers cancel so much (chapter 1). The measured cost is larger, because the informed can exercise at the best moment, not at a fixed one: marked to the efficient price 10 seconds after each trade, the resting side of trades against informed aggressors lost 1.22 ticks a share; against uninformed ones it gained 0.58; informed flow was 9.2% of volume, and all resting orders together gained 0.41. Chapters 4 and 5 turn this arithmetic into the theory of the spread.

2.6 Tutorial: one book, every order type

Goal. See the order types act on one engine, provoke a stop cascade, and try to find an iceberg in the public feed. End state: the table of section 2, Figures 2.1 and 2.3.

Validation. Read the order-type rules that run before matching:

def validate(msg, inst, phase: str, frozen: bool, band: tuple[int, int]) -> str | None:
    """First failing rule for an Enter message (namedtuple In_O), as the J reason; None if acceptable.
    `inst` has .tick; band is (lo, hi), 0 = none. Duplicates and post-only are checked by the engine."""
    if phase in "CH":
        return "H"
    if msg.qty <= 0 or msg.qty > MAX_QTY or msg.display_qty > msg.qty:
        return "Q"
    if msg.side not in "BS" or msg.tif not in "DGIFOC" or msg.display not in "YNMP" or msg.stp_mode not in "NOWBD":
        return "Q"
    if msg.min_qty and not (msg.tif == "I" or msg.display == "M"):
        return "Q"
    if msg.display_qty and msg.display != "Y":
        return "Q"
    if msg.price % inst.tick or msg.stop_price % inst.tick:
        return "X"
    if msg.tif == "O" and phase != "O":
        return "H"
    if msg.tif == "C" and (frozen or phase not in "TKO"):
        return "C" if frozen else "H"
    if msg.price and band[1] and not band[0] <= msg.price <= band[1]:
        return "B"
    return None

Listing 2.2. Validation of an entered order in firm.ordertypes. code/firm/ordertypes/firm_ordertypes.py

Showcase. mx_ordertypes.showcase() sends the eight orders to a bare engine and returns the reports of each.
Cascade. stop_cascade(n) for 0 to 20 stops, with stop orders and with stop-limit orders.
Icebergs. iceberg_study(mode, delay_ms, jitter) for the four cases, with the strict and the loose detector; draw with fig_ordertypes.py.
The option. passive_markout(session()) and free_option(0.5, sigma_per_sqrt_second(session()), 10).

What to change next. Space the stops two cents apart and find the spacing at which the cascade stops by itself; give the detector the iceberg’s price as a prior (it knows the level) and see how many false alarms that removes.

2.7 Build: the order-type layer

Purpose. One place for the rules each order type adds to matching, used by the exchange simulator’s engine in three languages.

Interface. EOrder (a firm_lob.Order with owner, firm, time in force, display, post-only, display quantity, reserve, minimum quantity, self-trade prevention group and mode, stop price, limit, container); validate(msg, inst, phase, frozen, band) returning a rejection reason; slice_for_display; peg_target(o, book, pegged); stp_conflict, stp_actions(mode); stop_triggered(o, last); marketable(side, limit, price).

Rules. Validation reasons are the order-entry protocol’s rejection codes; a midpoint peg is priced from the displayed quotes and capped by its limit; a primary peg follows the best unpegged displayed price on its side; minimum quantity only on IOC orders and midpoint pegs; a display quantity only on visible orders; stops trigger on trades, not quotes.

Acceptance tests. code/firm/exchsim/tests/test_engine_rules.py: post-only, IOC and FOK, market orders and bands, icebergs, self-trade prevention in each mode, replace priority, midpoint pegs with a minimum, stops, the opening auction, throttles and duplicates; the C++20 and Rust engines reproduce the Python engine byte for byte on the shared journal (chapter 26).

Stretch. Discretionary orders (displayed at one price, willing to trade at another); a price-sliding order that re-prices instead of locking an away market, with its priority stated.

Sources and further reading

SEC, In the Matter of EDGA Exchange, Inc. and EDGX Exchange, Inc., Release No. 74032, 12 January 2015.
Nasdaq Rule 4703 (Order Attributes), as reproduced in SR-NASDAQ-2026-055, Release No. 34-105718, June 2026.
T. E. Copeland and D. Galai, “Information effects on the bid-ask spread”, Journal of Finance 38(5), 1983.

2.8 Exercises

Exercise 2.1 ★

The best ask is 100.01 for 300 shares and 100.02 for 500. What does a buy limit at 100.02 for 600 shares do, and what does it leave in the book?

Solution

Solution of Exercise 2.1.

It is a marketable limit order: it buys 300 at 100.01 and 300 at 100.02, leaving 200 offered at 100.02; nothing of it rests.

Exercise 2.2 ★

With 300 shares offered at 100.01 and nothing behind them within the limit, what do a fill-or-kill and an immediate-or-cancel buy of 400 at 100.01 each do?

Solution

Solution of Exercise 2.2.

The fill-or-kill order needs 400 and finds 300: it is accepted and cancelled whole, and nothing trades. The immediate-or-cancel order takes the 300 and cancels the remaining 100.

Exercise 2.3 ★

Why does a hidden order rank behind a displayed order at the same price even if it arrived first?

Solution

Solution of Exercise 2.3.

Venues reward displayed liquidity: at one price, displayed orders rank ahead of non-displayed ones whatever their arrival times. A hidden order buys secrecy with priority.

Exercise 2.4 ★★

An iceberg of 10 000 shares shows 500. If it is executed in full, how many slices appear on the feed, and how many times does it go to the back of the queue?

Solution

Solution of Exercise 2.4.

$10\,000/500=20$ slices appear, and the order goes to the back of the queue 19 times (every slice after the first).

Exercise 2.5 ★★

A quote rests one tick from value; the efficient price moves 0.5 ticks per square-root second. What does the proposition give for a quote left for 30 seconds?

Solution

Solution of Exercise 2.5.

$\sigma\sqrt T=0.5\sqrt{30}=2.74$ ticks, $d/\sigma\sqrt T=0.365$ : $C=2.74\,\varphi(0.365)-1\times(1-\Phi(0.365))=0.665$ ticks per share.

Exercise 2.6 ★★

Explain why stop-limit orders shorten the cascade of Figure 2.1, and what their owners give up.

Solution

Solution of Exercise 2.6.

A stop-limit order that reaches a book with no bids at or above its limit rests as an offer instead of selling lower, so it does not consume the next bids or trigger the next stops: 25 cents instead of 37 with twenty stops. Its owner gives up certainty of getting out: in a real fall the order may rest unexecuted while the price keeps going.

Exercise 2.7 ★★★

Coding. Make the iceberg agent choose its refill price as the current best ask instead of its first price, rerun the strict detector, and explain the change.

Solution

Solution of Exercise 2.7.

iceberg_study with follow=True: the strict detector catches 43% of refills instead of 62% (13 false alarms): a refill at the new ask is not at the price of the slice that was consumed. The seller also sells only 23 700 of the 30 000 shares in the half hour, because refills that follow a falling ask rest behind a new queue instead of meeting buyers at a price the market left.

Exercise 2.8 ★★★

Find the flaw. “Midpoint pegs save half the spread on every trade, so an execution algorithm should send all its orders as midpoint pegs.”

Solution

Solution of Exercise 2.8.

A midpoint peg saves half the spread only when it executes; it executes only when someone crosses to the mid, which is when that someone knows more (adverse selection, chapter 9) or when a patient counterparty happens to be there. Orders that must complete take liquidity sometimes; a pegged-only algorithm has execution risk and trades mostly against informed flow.

2.9 Problem: The Iceberg in the Tape

Problem 2.1

Weekend problem — the iceberg in the tape

A fund sells 30 000 shares at the ask, 300 shown at a time. A competitor watches the public feed. You have firm.exchsim, Book 7’s background flow and the chapter’s detector.

Part I — The order types.

What is the difference between an iceberg and a hidden order in priority and in what the feed shows?
What happens to an iceberg’s priority when its slice is refreshed, and why?
What does a fill-or-kill order protect its sender from, and what does it cost?
Why do stop orders make a falling book fall faster?

Part II — The cascade.

How far does a 3 000-share market sell move the price with no stops, and with twenty?
How many shares trade in the twenty-stop case?
How far does the price fall with stop-limit orders one cent below their triggers?
What would you change in the bid ladder to stop the cascade?

Part III — The detector.

Describe the strict detector.
How many refills does the venue iceberg make, and how many does the strict detector catch? With how many false alarms?
Why does an algorithm that refills at once get caught less often than the venue’s iceberg?
What do a 200-millisecond random delay and a 30% random size do to detection?

Part IV — The race.

What does the loose detector detect with the delayed and randomised refills, and at what cost in false alarms?
State the named result: the detection and false-alarm rates of the refill detector against the refill’s delay and size randomisation.
What further information could the watcher use to separate true refills from coincidences?
What does the seller lose by delaying refills?
Is detecting icebergs from public data legal? Is trading on the detection?
Which order type would you use to sell 30 000 shares without any refill pattern?
How would a venue design an iceberg that is harder to detect?
In one sentence: what does an order type reveal about its owner?

Solution

Solution of Problem 2.1.

1. Both rank behind displayed orders at their price for their hidden part; the iceberg shows a slice and its refreshes appear on the feed, the hidden order shows nothing. 2. A refresh is an increase of displayed size: it goes to the back of the queue with a new reference, as any new arrival. 3. From a partial fill that leaves an unwanted remainder or a partly hedged position; it costs the fills it forgoes when the book is short. 4. Each triggered stop becomes a market sell that consumes bids and prints lower prices, which trigger the next stops. 5. Five cents; 37 cents with twenty stops. 6. 19 000 shares, for an initial sale of 3 000. 7. 25 cents. 8. More depth between the triggers (liquidity providers stepping in), wider spacing of the stops, or stop-limit orders. 9. After an execution removes a displayed order entirely, flag an add on the same side and price within 50 ms whose size equals the removed order’s original size. 10. 99 refills, all 99 caught, with 20 false alarms. 11. Its refill is a new order that travels to the venue and meets the market as it is: when the price has moved, part of it executes on arrival and the rest rests smaller, or at a different queue position; the venue’s refresh appears in the same event, at the same size. 12. Detection falls to 18% with the delay and 6% with the size randomised too. 13. 47% of refills (34 detections), with 378 false alarms: eleven false alarms for each true one. 14. Named result: the strict detector catches 100% of venue refreshes, 62% of immediate algorithmic refills, 18% with a 200 ms random delay and 6% with sizes randomised by 30%; the loose detector recovers 47% of the last at the price of 378 false alarms in half an hour. 15. The consumed slices’ sizes over time (the same size repeating), the persistence of one price level, and execution imbalance at that level. 16. Time: a random delay leaves the ask without its liquidity, and slices sell later; in a moving market some are never filled. 17. Inferring hidden interest from public data is legal and common; trading on it is ordinary competition. What is not legal is obtaining it from the venue or the broker (One Quant Book 9, chapter 29, for the enforcement record on manipulation; Book 16 for information barriers). 18. A midpoint peg in a dark venue, or an algorithm that varies slice size, price and timing. 19. Randomise the refreshed size within a band and delay the refresh by a random time; some venues offer exactly these options. 20. Its urgency, its size and its patience: every attribute is information for whoever reads the feed.

2.10 Interview questions

Interview question 2.1 ★ trader

When would you use an immediate-or-cancel order rather than a limit order that rests?

Solution

Solution of Interview question 2.1.

When the trade must happen now or not at all: hedging, taking a price that will not last, sweeping several venues, pinging a dark pool. A resting limit order reveals interest and risks being picked off.

What the interviewer is looking for: the link between order type and information leakage and adverse selection.

Interview question 2.2 ★ trader, researcher

What is a stop-loss order, and why can it execute far from its stop price?

Solution

Solution of Interview question 2.2.

An order that becomes a market order when a trade prints at or through its stop price; it then executes against whatever the book holds, which in a fast fall may be far lower (and other stops add to the selling).

What the interviewer is looking for: the conversion to a market order, the cascade, the stop-limit alternative.

Interview question 2.3 ★★ researcher

Why is a resting limit order like a written option? Who holds the option, and what is its strike?

Solution

Solution of Interview question 2.3.

A resting sell at $p$ is a call struck at $p$ written to the market: whoever learns first that value is above $p$ buys from it. A resting buy is a put. The option expires when the owner cancels, so its value grows with the time the order is left unattended and with volatility.

What the interviewer is looking for: Copeland and Galai; why cancellation speed is worth money.

Interview question 2.4 ★★ developer

How would you implement an iceberg order in a matching engine? What goes on the feed when the displayed slice is executed?

Solution

Solution of Interview question 2.4.

Keep the displayed slice in the book and the reserve in the order record; when the slice is fully executed and reserve remains, move the next slice to the back of the level with a new time stamp; on the feed, an execution of the old reference and an add under a new one (or a replace). Decide and document the priority of the reserve against other orders.

What the interviewer is looking for: priority of the refreshed slice, and that the feed must not reveal the reserve.

Interview question 2.5 ★★ trader, developer

A midpoint-pegged order is resting when the market locks (bid equals ask). What should the engine do, and why?

Solution

Solution of Interview question 2.5.

Nasdaq’s rule, for one: remove it from the book when the inside is crossed or missing and re-enter it at the new midpoint once there is a valid one, cancelling it if none comes within a second. A midpoint defined by a locked or crossed quote is not a fair price.

What the interviewer is looking for: that pegged prices depend on a reference that can be invalid, and the engine must say what happens then.

Interview question 2.6 ★★★ researcher, trader

How would you detect a large hidden seller from public market data alone?

Solution

Solution of Interview question 2.6.

Look for refill patterns (the same size reappearing at the same price after executions), a level that absorbs far more than it displays, persistent one-sided execution at one price, and hidden executions (non-displayed trade prints) clustering at a price; weigh each flag against its base rate of coincidence.

What the interviewer is looking for: a concrete detector and an awareness of false alarms.

Terms defined in this chapter

See all 2333 terms in the glossary