Principle:Nautechsystems Nautilus trader Venue Configuration Schema
| Field | Value |
|---|---|
| sources | https://github.com/nautechsystems/nautilus_trader, https://nautilustrader.io/docs/ |
| domains | backtesting, venue-simulation, configuration-management |
| last_updated | 2026-02-10 12:00 GMT |
Overview
A Venue Configuration Schema defines a declarative, structured specification for describing the properties of a simulated trading venue so that a backtest engine can faithfully reproduce exchange-level behavior without imperative setup code.
Description
In backtesting, the simulated exchange must mirror the rules and constraints of a real trading venue: order management semantics, account types, starting capital, leverage, fee structures, fill logic, latency characteristics, and order book depth. Rather than requiring users to write procedural code that calls multiple setter methods, a venue configuration schema captures all of these properties in a single, serializable data structure.
The schema-based approach solves several problems:
- Reproducibility -- Every parameter governing venue behavior is recorded in one place, making it trivial to reproduce a backtest exactly.
- Validation -- Declared types and constraints can be checked at configuration time, before the expensive simulation begins.
- Composability -- Multiple venue configurations can be combined in a single backtest run to simulate multi-exchange strategies.
- Separation of concerns -- The what (venue properties) is decoupled from the how (engine construction), enabling configuration-driven orchestration.
Key dimensions that a venue configuration schema typically captures:
- Order management system type (netting vs. hedging) -- determines how position IDs are generated and merged.
- Account type (cash vs. margin) -- controls balance tracking and margin requirements.
- Starting balances -- one or more currency amounts that seed the simulated account.
- Leverage and margin model -- per-instrument or default leverage ratios and the formula for computing margin.
- Fill model, fee model, latency model -- pluggable components that determine how orders are filled, what fees are charged, and what simulated latency is introduced.
- Order book type -- the depth of market data the matching engine uses (L1 top-of-book, L2 MBP, L3 MBO).
- Execution flags -- bar execution, trade execution, liquidity consumption, queue position tracking, price protection, and contingent order support.
Usage
Use the Venue Configuration Schema principle whenever you need to:
- Set up one or more simulated exchanges for a backtest run.
- Define cash or margin accounts with specific starting capital.
- Control matching engine behavior such as fill logic, bar processing order, or queue position tracking.
- Combine multiple venues in a single multi-exchange backtest.
- Store and version-control backtest venue parameters alongside strategy code.
Theoretical Basis
The Venue Configuration Schema follows the declarative configuration pattern, where the desired state of a system is described in a data structure rather than through imperative instructions. This is analogous to infrastructure-as-code principles applied to simulation environments.
Pseudocode for a generic venue configuration schema:
VenueConfig:
name : string # Unique venue identifier
oms_type : enum(NETTING, HEDGING)
account_type : enum(CASH, MARGIN)
starting_balances : list[Money] # One per currency
base_currency : Currency | None # None for multi-currency
default_leverage : float # Default leverage ratio
leverages : map[InstrumentId -> float] # Per-instrument overrides
margin_model : MarginModelConfig | None
fill_model : FillModelConfig | None
fee_model : FeeModelConfig | None
latency_model : LatencyModelConfig | None
book_type : enum(L1_MBP, L2_MBP, L3_MBO)
bar_execution : bool
trade_execution: bool
routing : bool
frozen_account : bool
...additional execution flags...
Validation rules:
VALIDATE(config):
ASSERT config.name is non-empty string
ASSERT config.starting_balances has at least one entry
IF config.account_type == MARGIN:
ASSERT config.default_leverage > 0
IF config.book_type in (L2_MBP, L3_MBO):
ASSERT matching order book data is available
The schema is consumed by a venue builder that translates each declared field into a concrete exchange simulator component, ensuring that the configuration is the single source of truth.