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.
Glossary
Fill Simulation

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.
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.
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.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
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.
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.
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).
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).
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.
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.
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.

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.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us