Research map

Market microstructure

A durable page for the questions that show up whenever simulated fills start to matter: queue position, hidden liquidity, venue rules, partial fills, and what the data can actually prove.

Queue position

The interesting part is often not whether the market traded at a price, but whether your order was far enough forward to fill.

Hidden liquidity

Granular order-book data can reveal clues, but the inference has limits. The useful work is separating observable queue behavior from assumptions that belong in the simulator.

Venue behavior

Matching behavior, order types, fees, and queue rules decide how portable a simulation result really is.

From writing to replay

Turn market-structure questions into inspectable runs.

Start with a Trading Reality essay or an open GitHub discussion, then reduce the claim to a replay fixture: what was visible in the book, where did the order join, what queue was ahead, and which event caused the fill or miss.

Working index

Reading, questions, executable references.

In depth

A market is a queue, not a price series.

Microstructure is the part of trading that decides whether a backtest result is going to survive. The strategy is right about direction — fine. The fill happens or it doesn't, at the price the model assumed or three ticks worse — that is the contest with the order book.

The interesting questions are usually not the ones a clean ML pipeline likes. Where was the order in the queue when the trade printed? How much liquidity was ahead? Was there a hidden order between the visible levels? Did the venue cancel the order in front because of a price-improvement rule the model never knew about? None of those questions get cleaner with more data. They get answerable when the data is reduced to specific events, with timestamps you trust.

There is a more general way of saying this. A market is not a price series. It is a queue of intents that arrive at a venue and get matched under rules — most of which are mundane until they are the reason your order did not fill. Microstructure is the discipline of treating those rules as primary. The maker/uninformed-trader frame on Trading Reality is the conceptual partner to this; the ordersim pipeline is the executable one.

The honest framing on hidden liquidity is the one most people don't like: it can sometimes be inferred, often only partially, and the residual uncertainty has to live in the simulator as an explicit assumption — not be hidden inside an averaged number.

Frequently asked

Questions that come up.

What does "queue position" actually mean for a passive order?

When a limit order arrives at a price level it joins the back of the queue at that price. To fill passively, the order has to wait for everything ahead of it to fill, get cancelled, or get modified out of the way. Queue position is the number of contracts ahead of you at the same price — and it changes as the book evolves.

Why do simulated fills often diverge from real ones?

Three usual reasons: queue-position assumption was too generous, hidden liquidity ahead was ignored, and venue rules around price improvement or self-match prevention were not modeled. Each one is small. Together they are usually the gap.

Can hidden liquidity be inferred from public data?

Sometimes, partially. Trades that print at sizes larger than the visible top-of-book are evidence. So are cancel patterns and order-book responses to large prints. But inference is bounded — anything that does not produce an observable trace cannot be inferred at all. The honest move is to make the residual uncertainty an explicit modeling assumption, not a tunable parameter.

How does venue choice affect a simulation?

Matching rules, fee schedules, order types, tick sizes, and price-improvement mechanics differ by venue. A simulation calibrated against one venue is not portable to another without re-checking those primitives. The strategy may be portable; the fills are not.

Where do I start reading?

The Trading Reality essays on adverse selection and the maker/taker distinction are the conceptual entry points. Then the ordersim simulation-assumptions document, which writes down what the simulator does and does not model — followed by the latency demo to see how those assumptions land in a runnable example.