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.
Research map
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.
The interesting part is often not whether the market traded at a price, but whether your order was far enough forward to fill.
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.
Matching behavior, order types, fees, and queue rules decide how portable a simulation result really is.
From writing to replay
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
Trading Reality
Open questions
Executable references
In depth
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
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.
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.
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.
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.
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.