Principle:Nautechsystems Nautilus trader Simulated Venue Setup

Field	Value
sources	https://github.com/nautechsystems/nautilus_trader , https://nautilustrader.io/docs/
domains	backtesting, venue simulation, exchange modeling
last_updated	2026-02-10 12:00 GMT

Overview

Simulated Venue Setup is the principle of constructing a faithful, parameterized model of a trading exchange within a backtesting environment so that order matching, account management, and market microstructure behave realistically.

Description

A simulated venue (or simulated exchange) is the backbone of any high-fidelity backtest. It replaces the live exchange with a software component that accepts orders, maintains an order book, applies fill logic, tracks account balances, and generates execution reports -- all driven by historical data rather than a live feed.

The principle addresses the following concerns:

• Order Management System (OMS) type -- Venues can operate in HEDGING mode (each fill creates a new position, allowing long and short simultaneously) or NETTING mode (a single net position per instrument). The choice profoundly affects position tracking and PnL attribution.
• Account type and balances -- The venue must model CASH or MARGIN accounts, each with distinct rules for buying power, leverage, and borrowing. Starting balances seed the simulation.
• Fill model -- Determines how orders are filled (immediate, partial, probabilistic slippage). Different fill models let you stress-test strategies under pessimistic execution assumptions.
• Fee model -- Computes commissions per trade (maker/taker, fixed, or custom). Accurate fee modeling prevents overfitting to gross PnL.
• Latency model -- Simulates communication delay between the strategy and the exchange, essential for testing latency-sensitive strategies.
• Book type -- Controls the depth of the simulated order book (L1 top-of-book, L2 depth, L3 full). Higher fidelity requires more data but yields more realistic matching.
• Execution flags -- Fine-grained switches control bar execution, trade execution, liquidity consumption, queue position tracking, stop-order rejection, GTD support, contingent orders, and more.

Usage

Apply this principle whenever you need to:

• Simulate a single or multi-venue trading environment.
• Test strategies under varying exchange rules (e.g., HEDGING vs. NETTING).
• Evaluate the impact of transaction costs, slippage, or latency on strategy performance.
• Model exotic venue behavior such as frozen accounts, price protection, or settlement prices for derivatives.

Theoretical Basis

Venue simulation is grounded in the concept of a discrete-event matching engine. The engine maintains internal state (order book, open orders, account balances) and transitions between states in response to market data events and trading commands.

Key theoretical elements:

• SimulatedExchange as state machine -- The exchange object encapsulates the venue state and exposes a process(ts_ns) method that advances it in time. Each data event (quote, trade, bar, book delta) triggers matching logic.
• Execution client binding -- The simulated exchange is paired with a BacktestExecClient that translates the kernel's execution commands into venue operations. This mirrors the production architecture where each venue has its own execution client.
• Account initialization -- Starting balances are frozen at setup time. The account is only initialized (balance events emitted) when the backtest run begins, ensuring the portfolio and cache see consistent state.
• Composable models -- Fill, fee, latency, and margin models are injected at venue creation time, following the Strategy pattern. Default models (e.g., FillModel(), MakerTakerFeeModel(), LeveragedMarginModel()) cover the common case.

Pseudocode:

FUNCTION add_venue(engine, venue_id, oms_type, account_type, starting_balances, ...):
    VALIDATE venue_id not already registered
    VALIDATE starting_balances is non-empty

    SET default leverage, fill_model, fee_model, margin_model if not provided

    exchange = SimulatedExchange(
        venue_id, oms_type, account_type, starting_balances,
        fill_model, fee_model, latency_model, margin_model,
        book_type, execution_flags, ...
        kernel.portfolio, kernel.msgbus, kernel.cache, kernel.clock
    )

    REGISTER exchange in engine.venues
    CREATE BacktestExecClient bound to exchange
    REGISTER exec_client with kernel.exec_engine
    ENSURE market data client exists for venue

    LOG "Added {exchange}"

Related Pages

• Implementation:Nautechsystems_Nautilus_trader_BacktestEngine_Add_Venue