Rust edition: this page follows the live DeepWiki structure but treats the current Rust crates as implementation authority. Non-Rust surfaces are identified at their boundary and are not presented as Rust APIs.

Venue Configuration and Models

Relevant Rust source files

• crates/backtest/src/config.rs
• crates/backtest/src/exchange.rs
• crates/execution/src/matching_engine/config.rs
• crates/execution/src/models/mod.rs

This page documents the configuration and simulation models used for venues in backtesting. A venue in NautilusTrader represents a trading venue or exchange (simulated or real) with specific characteristics, order matching behavior, fee structures, and execution constraints. During backtesting, venues are configured through BacktestVenueConfig objects and associated simulation models (FillModel, LatencyModel, FeeModel, MarginModel) that determine realistic execution behavior.

BacktestVenueConfig Overview

The BacktestVenueConfig class defines all parameters needed to simulate a trading venue during backtesting. Each backtest run can include multiple venue configurations, allowing simulation of multi-venue strategies.

Configuration structure:

configures

configures

BacktestRunConfig

List[BacktestVenueConfig]

BacktestVenueConfig
name='BINANCE'

BacktestVenueConfig
name='SIM'

BacktestNode

BacktestEngine

SimulatedExchange
Venue: BINANCE

SimulatedExchange
Venue: SIM

Sources:

Core Configuration Parameters

Account and OMS Settings

The venue configuration defines fundamental account characteristics and order management behavior:

Parameter	Type	Description
name	str	Venue identifier (e.g., "BINANCE", "SIM")
oms_type	OmsType	Order management system type: NETTING or HEDGING.
account_type	AccountType	Account type: CASH, MARGIN, or BETTING.
starting_balances	list[Money]	Initial account balances.
base_currency	Currency	The account base currency for the exchange.

OMS type determines position tracking:

Netting maintains one signed position per instrument and strategy; hedging permits separate long and short positions. The chosen OMS behavior must match the simulated or live venue contract.

Sources:

Order Book and Execution Configuration

Controls the granularity of market data and order behavior:

Parameter	Type	Description
book_type	BookType	L1_MBP, L2_MBP, or L3_MBO.
bar_execution	bool	If bars should be processed by matching engine(s).
trade_execution	bool	If trades should be processed by matching engine(s).
use_random_ids	bool	If venue order/position IDs will be random UUID4's.
liquidity_consumption	bool	If liquidity consumption is tracked per price level.
bar_adaptive_high_low_ordering	bool	Heuristic for bar price processing order.
queue_position	bool	Enables queue position tracking for limit orders.
price_protection_points	NonNegativeInt	Boundary to prevent aggressive marketable order prices.

Sources:

Simulation Models

Rust simulation models add realism to backtest execution and are queried by the OrderMatchingEngine during the matching loop.

FillModel

The FillModel determines whether and how orders are filled. The system provides several specialized implementations:

• DefaultFillModel: Standard logic where limit orders fill when the price is touched or traded through.
• BestPriceFillModel: Fills at the best available price (e.g., best bid/ask).
• TwoTierFillModel: Simulates venues with tiered liquidity.
• SizeAwareFillModel: Factors in order size relative to available market liquidity to determine partial fills or slippage.

The OrderMatchingEngine holds a FillModelHandle reference and sets parameters like fill_limit_inside_spread

Sources:

FeeModel

The FeeModel calculates commissions. The most common implementation is the MakerTakerFeeModel which applies different rates based on whether the order added (Maker) or removed (Taker) liquidity. Other models include FixedFeeModel and CappedOptionFeeModel

Fee Calculation Flow:

An accepted fill is passed to the configured fee model; the resulting commission is applied to account state using the fill currency and venue rules.

Sources:

LatencyModel

The LatencyModel introduces realistic delays. It simulates the time taken for an order to travel from the ExecutionEngine to the SimulatedExchange and back.

Latency Simulation:

Latency modeling schedules an order for a future simulated timestamp before SimulatedExchange submits it to the matching engine. It never changes the canonical command or order identity.

Sources:

Order Matching Core

The OrderMatchingEngine (Rust) is the component responsible for the actual price-trigger logic and order book management during backtesting. It utilizes OrderMatchingCore for the internal matching logic.

Key Characteristics:

• Venue/Instrument Bound: Each engine is specific to one venue and instrument.
• Book Management: Maintains an OrderBook and tracks target_bid, target_ask, and target_last.
• Queue Tracking: Can track queue ahead and consumption if configured.
• Precision Guarding: Includes checks for price/size precision mismatches to ensure realistic simulation.

Natural Language to Code Entity Mapping:

Price triggering, queueing and fill rules are owned by OrderMatchingCore, OrderMatchingEngine, the selected fill model and the simulated exchange configuration.

Sources:

Venue Simulation Parameters Summary

Parameter	Code Entity	Role
OMS Type	OmsType	Determines if positions are netted or hedged.
Book Type	BookType	Determines depth of book simulation (L1, L2, L3).
Fill Model	FillModelHandle	Logic for execution (Default, BestPrice, etc.).
Fee Model	FeeModelHandle	Commission calculation (MakerTaker, Fixed).
Latency	LatencyModel	Time delay simulation.

Sources: