Market Microstructure

Open the matching sandbox and play both roles. Rest a bid, then send aggressive orders against it. Watch where your order sits as others join the level behind you and leave in front of you.

The vocabulary, with what each term means for a participant:

• Quoted spread (best ask − best bid) is what an impatient trader pays to cross immediately. Depth is how much size is resting at or near the touch, which tells you how far a large order will have to walk the book.
• Tick size. In a large-tick instrument the spread is almost always exactly one tick, because the tick is big relative to the price. Nobody can improve the price without crossing the spread, so competition moves to time: whoever joins the level first is first in line. Speed and queue position become the game. In a small-tick instrument the spread varies, quotes can improve in tiny steps, and you can jump ahead of a queue for a negligible price concession.
• Matching algorithm. Your engine is price-time (FIFO). Some futures markets, with interest-rate futures at CME the classic example, use pro-rata or hybrid allocation instead: an incoming order is shared among resting orders in proportion to their size. That rewards size more than speed and encourages over-quoting.
• Fees. Many equity venues charge takers a fee and pay makers a rebate ("maker-taker"). Some do the reverse ("inverted"). For a market maker the rebate can be a large part of the economics, which you'll see in week 42's PnL drill.

The classic decomposition splits the spread into three costs the liquidity provider has to recover:

• Order-processing costs: fees, technology, the people running the desk.
• Inventory-holding costs: a dealer who buys has to carry the position until someone sells, and is exposed to price moves while doing so. The more volatile the instrument and the longer the wait, the wider the spread.
• Adverse selection: some counterparties know something you don't. Glosten and Milgrom (1985) showed that even a risk-neutral market maker with zero costs must quote a positive spread when some traders are informed. The spread is what makes trading with the uninformed pay for the losses to the informed. Kyle (1985) models an informed trader hiding among noise traders, with prices moving in proportion to order flow.

You measure these per trade. Let D be +1 for a buyer-initiated trade and −1 for a seller-initiated one, P the trade price, and M the midquote:

quoted spread      = ask − bid                       (at the time of the trade)
effective spread   = 2·D·(P − M_t)                   (what the taker actually paid)
realized spread    = 2·D·(P − M_{t+Δ})               (what the provider kept after Δ)
price impact       = 2·D·(M_{t+Δ} − M_t)             (how far the mid moved toward the taker)
effective spread   = realized spread + price impact

If the realized spread is near zero or negative, liquidity providers are being adversely selected: the price impact eats everything they charged. Roll (1984) showed how to estimate the spread from trade prices alone. If the only thing moving prices tick to tick is trades bouncing between bid and ask, consecutive price changes are negatively correlated, and spread ≈ 2·sqrt(−cov(ΔP_t, ΔP_{t−1})).

With an order-by-order (L3) feed such as Nasdaq TotalView-ITCH, each add, execute and delete message carries an order reference, so you can track exactly how much size is ahead of your order. With an aggregated (L2) feed you only see total size per price, and you have to estimate:

• Trades at your price consume the queue from the front, so they're always ahead of you.
• Cancels could have come from anywhere. You can assume they were all behind you (pessimistic), all ahead (optimistic), or spread in proportion to how much size is ahead versus behind (a common middle ground). Each assumption gives a different estimate, and backtests that use them come out very differently (week 44).

The value of a queue position comes from fill probability and from which fills you get. At the front, you're filled by ordinary flow. At the back, you're often filled only when a large aggressive order sweeps the whole level, and that's often exactly when the price is about to move through you. So the last order in the queue gets the fills it least wants. For a first model of fill probability, treat taker volume at your price as a Poisson process. Real order flow is clustered (one trade makes more trades likely), so treat Poisson as an approximation to improve on, not a truth.

/// Estimated queue position of ONE of our resting orders at one price
/// level, maintained from an L2 feed (you only see the total size of the
/// level, not the individual orders in it).
pub struct QueueEstimate {
    /// Estimated lots resting AHEAD of us at our price.
    ahead: f64,
    /// Our unfilled quantity.
    remaining: u64,
}

impl QueueEstimate {
    /// We joined the BACK of a level that already held `level_qty` lots.
    pub fn new(level_qty: u64, my_qty: u64) -> Self {
        todo!()
    }

    pub fn ahead(&self) -> f64 {
        todo!()
    }

    pub fn remaining(&self) -> u64 {
        todo!()
    }

    /// `traded` lots printed at our price. Price-time priority: trades
    /// consume the queue from the FRONT. Never let `ahead` go below 0.
    pub fn on_trade(&mut self, traded: u64) {
        todo!()
    }

    /// The level shrank by `cancelled` lots without a trade: someone
    /// ELSE cancelled. `level_qty_before` is the level size just before the
    /// cancel and includes our `remaining`. We can't see where the
    /// cancelled order was, so assume cancels are spread uniformly over
    /// the other orders:
    ///     ahead −= cancelled × ahead / (level_qty_before − remaining)
    /// (do nothing if there are no other orders).
    pub fn on_cancel(&mut self, cancelled: u64, level_qty_before: u64) {
        todo!()
    }

    /// Our own execution report: `qty` lots of our order filled. Under
    /// price-time priority, everything that was ahead of us is gone.
    pub fn on_my_fill(&mut self, qty: u64) {
        todo!()
    }
}

/// Probability our order fills COMPLETELY within a horizon, if taker
/// volume hitting our price arrives as a Poisson process with a mean of
/// `mu` lots over the horizon: P(N ≥ ahead + my_qty), N ~ Poisson(mu).
/// Hint: P(N ≥ k) = 1 − Σ_{i<k} e^(−mu) · mu^i / i!  — build each term
/// from the previous one instead of computing factorials.
pub fn fill_probability(ahead: u64, my_qty: u64, mu: f64) -> f64 {
    todo!()
}

Look at case 5 in the drill. With an expected 20 lots of taker flow, an order with 5 lots ahead fills completely 99.5% of the time. Put 25 lots ahead and it fills about 2% of the time. Same price, same instrument, and a fill probability fifty times lower. That's why firms spend so much on being first to a new price level.

A markout scores each fill by what the market did afterwards. For a fill at price P, with M the mid h after the fill:

buy  markout(h) = M_{t+h} − P
sell markout(h) = P − M_{t+h}

Average the markouts over all your passive fills at several horizons (for example 10 ms, 100 ms, 1 s, 10 s) and plot them against h. A typical passive curve starts at about half the spread, which is what you earned against the mid at the moment of the fill, and then falls as the price moves toward the takers who traded with you. If the curve goes negative and stays there, your fills are worth less than the spread you collected. You're the counterparty informed traders were looking for.

One common source of toxic flow is your own stale quotes. When public information changes, such as a related futures contract moving or a news headline, there's a window in which your quote is out of date. Anyone faster than you can trade against it before you cancel. Budish, Cramton and Shim (2015) argue that continuous limit order books make this race inevitable, because tiny speed advantages translate directly into profits taken from slower liquidity providers. They propose frequent batch auctions instead. You don't have to agree with the remedy to find their description of the problem very useful.

Three short-horizon quantities appear throughout the microstructure literature:

• Queue imbalance (bid_qty − ask_qty) / (bid_qty + ask_qty). In large-tick instruments it's a well-documented predictor of the direction of the next mid move. A thin ask queue is likely to be depleted first.
• Weighted mid (bid_px·ask_qty + ask_px·bid_qty) / (bid_qty + ask_qty). Note the cross-weighting: a large bid pulls the estimate toward the ask, because the ask is more likely to give way. People often loosely call this "the microprice". Stoikov (2018) defines a more careful micro-price as the limit of expected future mids, and the two aren't the same.
• Order-flow imbalance (OFI) from Cont, Kukanov and Stoikov (2014) aggregates every change at the top of the book (new bids, cancelled bids, asks eaten, asks added) into one signed number. Their finding is that short-horizon mid changes are approximately linear in OFI, with a slope inversely related to depth.

/// Top of book: best bid and best ask with their sizes. Prices in ticks.
#[derive(Clone, Copy, Debug, PartialEq)]
pub struct Top {
    pub bid_px: i64,
    pub bid_qty: u64,
    pub ask_px: i64,
    pub ask_qty: u64,
}

/// Queue imbalance (bid_qty − ask_qty) / (bid_qty + ask_qty), in [−1, 1].
/// 0.0 when both sides are empty.
pub fn imbalance(t: &Top) -> f64 {
    todo!()
}

/// Size-weighted mid: (bid_px·ask_qty + ask_px·bid_qty) / (bid_qty + ask_qty).
/// Note the cross-weighting: a big bid pulls the estimate TOWARD the ask.
/// Falls back to the plain mid when both sizes are 0.
pub fn weighted_mid(t: &Top) -> f64 {
    todo!()
}

/// Order-flow imbalance of one top-of-book update (Cont, Kukanov &
/// Stoikov, 2014). With [c] = 1 if c is true, else 0:
///   e =  [bid_px ≥ prev.bid_px]·bid_qty − [bid_px ≤ prev.bid_px]·prev.bid_qty
///      − [ask_px ≤ prev.ask_px]·ask_qty + [ask_px ≥ prev.ask_px]·prev.ask_qty
/// Positive e = buying pressure (bids building or asks being eaten).
pub fn ofi(prev: &Top, cur: &Top) -> i64 {
    todo!()
}

/// Sum of ofi over consecutive pairs (tops[0], tops[1]), (tops[1], tops[2]), …
pub fn ofi_sum(tops: &[Top]) -> i64 {
    todo!()
}

Outside participants have to guess at things your engine knows exactly. Each Trade event carries the taker's side, so you never need a trade-classification heuristic like Lee–Ready, which infers direction from the trade price relative to the quotes. Each Rested, Cancelled, Reduced and Trade event names the order, so queue position is exact: the size of everything resting ahead of the order at its price, in FIFO order. And the sequence number the engine gives each command (Engine::seq(); events themselves carry none) gives you an exact event clock for markout horizons, alongside the simulator's time.