Inferensys

Glossary

Fill Simulation

The logic within a backtesting engine that determines whether a simulated order is executed, based on available historical volume, order book depth, and queue position.
Stylish WeWork-like workspace with hot desks and document wall, professional searching through enterprise knowledge base on a mounted ultrawide display, warm industrial pendants overhead.
EXECUTION LOGIC

What is Fill Simulation?

Fill simulation is the deterministic logic within a backtesting engine that adjudicates whether a simulated order transitions from 'pending' to 'filled' by matching it against available historical liquidity.

Fill simulation is the mechanism that replaces a live broker's execution report in a historical testing environment. It algorithmically determines the fill price and quantity by interrogating the reconstructed limit order book or historical quote/trade tape at the exact timestamp of order arrival. Unlike naive close-price assumptions, sophisticated fill logic accounts for the queue position of the simulated order and the available resting volume at each price level, ensuring that a large buy order only fills against sufficient sell-side depth.

The primary objective is to prevent unrealistic fills that would overstate a strategy's viability. A robust engine applies a slippage model to account for latency and market impact, often using a probabilistic fill model where execution likelihood decays as available volume is consumed. This logic is critical for high-frequency strategies where the difference between a fill at the bid versus the mid-price determines profitability, making fill simulation the core arbiter of backtesting fidelity.

FILL SIMULATION

Frequently Asked Questions

Clear, technically precise answers to the most common questions about how backtesting engines determine whether a simulated order gets executed.

Fill simulation is the deterministic logic within a backtesting engine that determines whether a simulated order is executed, and at what price, based on available historical volume, order book depth, and queue position. Unlike naive approaches that assume every order fills at the mid-price, a realistic fill simulator replays the sequence of trades and quotes to assess if sufficient opposing liquidity existed at the time of order submission. The core mechanism involves consuming historical tick data or aggregated volume bars, checking the order's limit price against the prevailing National Best Bid and Offer (NBBO), and decrementing available volume until the order quantity is satisfied or the bar is exhausted. This process is critical for accurately modeling slippage, market impact, and implementation shortfall in high-frequency and latency-sensitive strategies.

CORE COMPONENTS

Key Features of a Robust Fill Simulation Engine

A high-fidelity fill simulation engine is the critical bridge between a theoretical trading signal and its real-world execution cost. It must deterministically model the complex interplay of order book depth, queue position, and venue-specific microstructure rules.

01

Order Book Depth Reconstruction

Accurately replays the limit order book (LOB) at each price level to determine fill probability. The engine must reconstruct the bid/ask volume available at every tick, not just the top-of-book quote.

  • Volume-at-Price: Checks if the aggregated resting orders at a given limit price can absorb the simulated order's size.
  • Hidden Liquidity: Models iceberg orders and dark pool reference prices if the historical data feed supports hidden volume flags.
  • Tick-Level Granularity: Replays every insertion, cancellation, and execution event to avoid time-interpolation bias.
Level 3
Order Book Depth
02

Queue Position Mechanics

Simulates the first-in, first-out (FIFO) or pro-rata matching logic of the target exchange. A fill is not guaranteed just because the price trades through your level; your order must reach the front of the queue.

  • Time Priority: Assigns a virtual entry timestamp to the simulated order to determine its rank relative to the historical volume traded at that price.
  • Partial Fills: Calculates the exact executed quantity when the traded volume is less than the total queue size.
  • Exchange-Specific Rules: Models the distinct matching algorithms of venues like CME (FIFO) vs. Eurex (pro-rata).
FIFO / Pro-Rata
Matching Logic
03

Aggressive vs. Passive Fill Logic

Differentiates between liquidity-taking and liquidity-providing order fills. A marketable order sweeps the book, while a passive limit order joins the queue.

  • Market Orders: Consume available volume across multiple price levels, calculating the volume-weighted average price (VWAP) of the sweep.
  • Limit Orders: Only fill if the market price trades through the limit (for buys, trades at or below the limit price) and queue position is exhausted.
  • Crossed Markets: Handles the edge case where a simulated limit order is placed inside an already crossed national best bid and offer (NBBO).
< 1 ms
Latency Assumption
04

Slippage & Latency Modeling

Injects realistic execution latency between the signal generation timestamp and the order's arrival in the market. This delay causes slippage, the difference between the decision price and the actual fill price.

  • Deterministic Delay: Applies a fixed or stochastic delay (e.g., 500 microseconds) to simulate network and processing latency.
  • Adverse Selection: Models the probability that a quote fades or the book thins out during the latency window.
  • Tick-by-Tick Drift: Captures the price movement during the delay using the actual historical quote sequence.
500 μs
Typical Simulated Latency
05

Multi-Venue Smart Order Routing

Simulates the logic of a Smart Order Router (SOR) that splits a parent order across fragmented exchanges and dark pools to minimize total execution cost.

  • Venue Sweeping: Routes the order to the venue with the best available price first, then to the next, based on a configurable fee schedule.
  • Reg NMS Compliance: Models the protected quote status of US exchanges, ensuring the simulation does not trade through a better displayed price.
  • Fill Probability Decay: Assigns a lower fill probability to dark pool and non-displayed venue slices based on historical hit rates.
15+
Simulated Venues
06

Transaction Cost Analysis Integration

Outputs granular fill data to feed a Transaction Cost Analysis (TCA) module. Every simulated fill must carry its cost attribution for post-trade evaluation.

  • Explicit Costs: Tags each fill with the exact commission, exchange fee, and rebate based on the venue and order type.
  • Implicit Costs: Calculates the implementation shortfall by comparing the fill price to the arrival price at signal time.
  • Market Impact Decomposition: Separates the fill price drift into temporary (liquidity) and permanent (information) impact components.
Implementation Shortfall
Primary Cost Metric
Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.