Understanding order types is fundamental for every quant developer. The order type you choose determines how your order interacts with the exchange — whether it sits passively in the order book waiting to be matched, or aggressively sweeps available liquidity immediately. Getting this wrong in a live system has real consequences.
Passive vs Aggressive Orders
Before diving into specific order types, it’s important to understand the fundamental distinction between passive and aggressive orders.
Passive orders — sent with the intent to rest in the order book and wait for someone else to trade against them. They provide liquidity to the market. Examples: limit orders, GFD quotes.
Aggressive orders — sent with the intent to match immediately against resting orders. They consume liquidity. Examples: market orders, FAK/IOC orders.
This distinction matters because:
- Exchanges typically charge different fees for passive vs aggressive orders — passive orders often receive a rebate for providing liquidity
- Aggressive orders have immediate execution but uncertain fill quantity
- Passive orders have uncertain execution timing but known price
- In HFT market making, your system constantly does both — posting passive quotes and using aggressive orders to hedge or rebalance
Market Order
A market order instructs the exchange to buy or sell immediately at the best available price. It prioritises execution speed over price certainty.
Characteristics:
- Guaranteed to execute (assuming sufficient liquidity)
- Price is not guaranteed — you get whatever is available in the order book
- In a thin market, a large market order can move the price significantly (market impact)
- Not accepted during auction phases on most exchanges
When quant devs use them: Market orders are used when immediate execution is more important than price — for example, urgent position hedging or closing a position quickly.
Limit Order
A limit order specifies the maximum price you’re willing to pay (buy) or minimum price you’ll accept (sell). It will only execute at your specified price or better.
Characteristics:
- Price is guaranteed — you won’t get a worse price than specified
- Execution is not guaranteed — if the market never reaches your price, the order stays resting
- If not immediately matched, becomes a resting order in the order book
- The foundation of market making — MMs continuously post limit orders on both sides
When quant devs use them: Limit orders are the primary order type for market makers. A MM posts a bid limit order at $45.10 and an ask limit order at $45.12 — these sit in the book as resting orders until someone trades against them.
Stop Order
A stop order becomes active only when the market reaches a specified trigger price. Once triggered it converts to a market order.
Characteristics:
- Inactive until the stop price is reached
- Once triggered, executes as a market order — no price guarantee
- Used primarily for risk management — automatically exit a position if price moves against you
Stop-limit order — a variant that converts to a limit order rather than a market order when triggered. Provides price protection but risks not executing if the market moves too fast.
Time-in-Force Conditions
Time-in-force (TIF) conditions specify how long an order remains active. These are not separate order types but conditions applied to limit or market orders.
GTC — Good Till Cancelled
The order remains active until explicitly cancelled by the trader or fully filled. On most exchanges GTC orders persist across trading sessions.
Quant dev consideration: GTC orders need careful tracking. If your system restarts, you need to reconcile GTC orders that may still be resting at the exchange.
GFD — Good for Day
The order remains active only for the current trading session. At the end of the continuous trading session, any unfilled GFD orders are automatically cancelled by the exchange.
Quant dev consideration: GFD is the most common time-in-force for market making quotes. At end of day, the exchange cancels all unfilled GFD orders — your system must reconcile its internal order state against exchange confirmations to ensure no discrepancies.
FAK — Fill and Kill (also known as IOC — Immediate or Cancel)
The order executes immediately against available resting orders. Any unfilled quantity is immediately cancelled — nothing rests in the order book.
Characteristics:
- Aggressive by nature — designed to hit resting orders
- Partial fills are accepted — whatever is available gets filled, the rest is cancelled
- Not accepted during auction phases
When quant devs use them: FAK/IOC orders are heavily used by market makers and other participants to aggressively hit resting orders. For example, when a MM wants to buy stock to hedge a delta position, they send a FAK order to sweep available offers. The key advantage is no leftover resting order — you know exactly what you got and nothing is left dangling in the book.
FOK — Fill or Kill
Similar to FAK but stricter — the entire order must fill immediately or the entire order is cancelled. No partial fills.
When quant devs use them: FOK is used when you need a specific quantity guaranteed — a partial fill would be worse than no fill. Less common than FAK in practice.
Iceberg / Reserve Orders
An iceberg order has a visible quantity shown in the order book and a hidden reserve quantity. When the visible portion is filled it is automatically replenished from the reserve until the total quantity is exhausted.
Characteristics:
- Hides large order sizes from the market — reduces market impact
- Each replenishment typically gets a new time priority in the queue
- Supported natively in most exchange protocols
When quant devs use them: MMs often use iceberg orders when providing large quantities of liquidity without revealing their full size. Iceberg behaviour is typically configured at order submission time by specifying both a shown quantity and a total quantity.
Market-on-Close (MOC) and Limit-on-Close (LOC)
These order types are specifically designed to participate in the closing auction.
MOC — executes at the official closing price, whatever it turns out to be.
LOC — executes at the closing price only if it is at or better than the specified limit price.
When quant devs use them: Index funds and ETFs use MOC orders extensively to rebalance at the official closing price. Quant systems that track benchmarks need to handle these carefully.
Market Maker Specific Concepts
Modern exchanges provide a suite of features specifically designed for market making applications. Understanding these concepts is essential for quant devs building MM systems.
Two-Sided Quote Management
Rather than submitting individual bid and ask orders separately, market making applications typically submit two-sided quotes — a bid and ask pair for each instrument — in a single transaction. This reduces latency and network overhead when managing quotes across many instruments simultaneously.
Key considerations:
- When only one side of a quote is affected by a market move, only that side should be requoted — sending unnecessary updates wastes bandwidth and exchange capacity
- Quote updates need to be grouped by matching engine partition — instruments in different partitions must be updated in separate transactions
- If a quote is traded before your update arrives, most exchanges will still place your new quote — preventing the common race condition of trying to replace a quote that no longer exists
Bulk Delete / Mass Cancel
Rather than cancelling orders one by one, exchanges typically provide mechanisms to cancel a group of orders in a single transaction. The granularity varies by exchange — some support cancelling all orders for an underlying, others by instrument class, side, or client.
This is a critical capability for MM systems:
- In an emergency (market data feed drops, risk limit breached, system anomaly detected), you need to cancel all resting quotes as fast as possible
- Your OMS must be able to trigger bulk cancel as the first action when any abnormal condition is detected
- After a bulk cancel, your system must reconcile internal order state against exchange confirmations
Market Maker Protection
Most exchanges provide an automated protection mechanism that monitors a MM’s trading activity and automatically cancels all quotes for an underlying when predefined risk thresholds are breached within a rolling time window.
Two common protection triggers:
- Quantity protection — fires when total traded contracts exceed a configured limit within the time window
- Delta protection — fires when net delta exposure exceeds a configured limit within the time window
After protection fires, new quotes may be rejected for a configurable frozen period — giving the MM time to assess their position before resuming. Calibrating these thresholds requires careful analysis of historical trading data — too tight means constant false triggers, too loose means inadequate protection.
MM protection is a last line of defence. Your system should have its own pre-trade risk checks that fire before exchange protection kicks in.
Going Deeper — Exchange Protocols in Practice
Understanding order types conceptually is just the beginning. In a real trading system, every order type maps to specific messages defined in an exchange’s technical protocol specification.
For example, on ASX and HKFE, market making applications use the OMNet protocol — a binary messaging protocol that defines exactly how orders are submitted, amended and cancelled. Key messages include:
- A two-sided quote block entry message (MO36) that lets MMs insert or amend multiple bid/ask pairs in a single transaction, with built-in iceberg support and safety handling for race conditions
- A bulk delete message (MO4) that can remove a single order or an entire group of orders filtered by underlying, instrument class, side, or client
- A market maker protection message (DC87) that automatically cancels all quotes for an underlying when quantity or delta thresholds are breached within a configurable rolling time window
These protocol-level details — and how to build C++ systems around them — are covered in depth in Module 3: Market Data and Module 5: Execution & Risk.