Principle:Nautechsystems Nautilus trader Strategy Configuration
| Field | Value |
|---|---|
| sources | https://github.com/nautechsystems/nautilus_trader , https://nautilustrader.io/docs/ |
| domains | algorithmic trading, strategy configuration, immutable configuration, serialization |
| last_updated | 2026-02-10 12:00 GMT |
Overview
Strategy configuration defines the practice of capturing all tunable parameters and behavioral settings for a trading strategy in an immutable, serializable data structure that is fully determined before the strategy begins execution.
Description
In algorithmic trading systems, strategies require numerous parameters: order management system type, order ID tagging conventions, contingent order management flags, GTD expiry behavior, and market exit policies. If these settings are mutable at runtime, the system becomes vulnerable to accidental mid-execution changes that can cause subtle and dangerous bugs -- for example, silently switching OMS type while positions are open.
Strategy configuration solves this by separating what the strategy does (logic) from how it is parameterized (configuration). The configuration object is:
- Immutable (frozen): Once created, no field can be changed. This guarantees that the parameters observed at initialization are the same parameters throughout the entire lifecycle.
- Serializable: The configuration can be persisted to JSON, stored in databases, logged for audit trails, or transmitted across process boundaries. This enables reproducible backtests and configuration management at scale.
- Keyword-only: All fields must be specified by name, preventing positional argument errors that are common when configuration classes have many fields with similar types.
- Defaulted: Every field provides a sensible default, so users need only override the parameters they wish to customize.
The configuration object acts as a single source of truth for strategy behavior, decoupling parameter management from strategy logic and enabling:
- Reproducibility: Identical configurations produce identical strategy behavior across backtest runs.
- Auditability: Configuration snapshots can be recorded alongside trading results.
- Deployment safety: Configuration validation happens at construction time, before any market interaction.
Usage
Use the strategy configuration principle whenever:
- You are designing a trading strategy that has tunable parameters (thresholds, intervals, flags).
- You need to run the same strategy logic with different parameter sets (e.g., parameter sweeps, A/B testing across instruments).
- You require audit trails that link trading results to the exact configuration used.
- You want to serialize strategy parameters for storage, transmission, or display.
Theoretical Basis
The strategy configuration principle draws from two foundational concepts:
1. Separation of Concerns
Strategy logic and strategy parameters occupy distinct conceptual domains. Logic describes how to react to market events; parameters describe with what settings. By encoding parameters in a dedicated frozen structure, each concern can evolve independently. New parameters can be added to the configuration without modifying strategy logic, and strategy logic can be refactored without affecting configuration schemas.
2. Value Object Pattern
A configuration is a value object -- its identity is defined entirely by the values of its fields, not by any mutable state or object reference. Two configurations with identical field values are semantically identical. This property enables hashing, equality comparison, and safe sharing across threads or processes.
Pseudocode:
DEFINE ConfigSchema:
FIELDS:
strategy_id: optional identifier
order_id_tag: optional string
oms_type: enum (HEDGING | NETTING | UNSPECIFIED)
manage_contingent_orders: boolean, default false
manage_gtd_expiry: boolean, default false
manage_stop: boolean, default false
log_events: boolean, default true
CONSTRAINTS:
all fields keyword-only
object is frozen after construction
FUNCTION create_strategy(config: ConfigSchema):
VALIDATE config fields at construction time
RETURN new Strategy initialized with config
// config cannot change after this point
Key invariant: For any strategy instance s, s.config is referentially transparent -- reading it at any point during the strategy lifecycle yields the same values.