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.

Execution System

Relevant Rust source files

• crates/execution/src/engine/mod.rs
• crates/execution/src/client/mod.rs
• crates/execution/src/matching_engine/mod.rs
• crates/execution/src/reconciliation/mod.rs

Overview

The Execution System processes trading orders from strategy submission through risk validation, emulation, and venue routing. This system manages the full order lifecycle, including position accounting, state persistence, and reconciliation with external venues. It is designed for high-performance, asynchronous operations, utilizing both Rust implementations for critical components.

Sub-pages:

• ExecutionEngine Architecture — Order lifecycle management, client routing, and position updates.
• RiskEngine and Pre-trade Checks — Pre-trade validation, notional limits, and rate limiting via throttlers.
• OrderEmulator and Complex Orders — Local stop orders, trailing stops, and matching core triggers.
• Execution Algorithms — Automated execution frameworks (TWAP, VWAP, etc.) and custom implementations.
• Contingent Orders and Order Manager — OTO/OCO order management and command routing patterns.

---

System Architecture

The execution system routes TradingCommand messages through specialized components via the MessageBus. Each component handles a specific stage of order processing, from high-level strategy logic to low-level venue communication.

Component Mapping

Component	Primary Implementation	Key Methods/Fields
Strategy		submit_order(), _manager: OrderManager
OrderManager		cache_submit_order_command(), OrderManagerAction
ExecAlgorithm		on_order_event(), submit_order()
RiskEngine		execute(), _handle_submit_order()
ExecutionEngine		execute(), routing_map: HashMap<Venue, ClientId>
ExecutionClient		submit_order(), modify_order(), cancel_order()

Execution Pipeline Diagram

Diagram — Order Execution Pipeline with Code Entity Mapping

Emulation and execution algorithms may transform a strategy command before the risk boundary, but they do not bypass it. The selected broker adapter implements the standard Rust data and execution client factory contracts; it does not become the order, account, or portfolio model.

Sources:

---

Command and Event Flow

The execution system is entirely asynchronous, relying on TradingCommand subclasses (like SubmitOrder, ModifyOrder, CancelOrder) for requests and OrderEvent subclasses for state updates.

Command Flow Sequence

The outbound amber path in the figure is conditional: a denied command becomes an OrderDenied event and never reaches the execution client. An approved command is routed by venue or configured client identity and submitted through the client contract.

Sources:

Event Flow Sequence (Fills and Positions)

The returning teal path represents venue truth: acknowledgements, fills, cancellations, and generated reconciliation reports enter ExecutionEngine, update cached order state and portfolio projections, then publish typed events to interested strategies and actors.

Sources:

---

Core Components

Strategy Trading Commands

The Strategy base class provides the primary interface for initiating execution. Commands are routed through an internal OrderManager.

Method	Implementation Behavior
submit_order	Submits a single order for execution.
submit_order_list	Submits a list of orders (e.g., OCO/OTO).
modify_order	Modifies an existing order's price or quantity.
cancel_order	Requests cancellation of an order.

Sources:

RiskEngine Validation

The RiskEngine performs pre-trade checks and rate limiting via the Throttler

• Throttling: Separate throttlers for submission and modification rates
• Trading States: Supports ACTIVE, REDUCING, and HALTED states
• Checks: Validates order price, quantity, notional value, and account balances
• Denial Reasons: Standardized codes like NOTIONAL_EXCEEDS_FREE_BALANCE or RATE_LIMIT_EXCEEDED

Sources:

ExecutionEngine Orchestration

The Rust ExecutionEngine manages multiple ExecutionClient instances and maps them to venues.

• Routing: Uses routing_map (Venue to Client) and default_client
• OMS Support: Handles both NETTING and HEDGING position management
• Reconciliation: Includes logic for inferred fills and external order status generation
• Snapshots: Periodic snapshots of positions and orders for persistence

Sources:

---

Position Management

Position updates are driven by fills. The system determines the appropriate PositionId based on the strategy's OmsType.

OmsType	Logic	ID Format
NETTING	Single position per strategy/instrument	{instrument_id}-{strategy_id}
HEDGING	Multiple positions per instrument	Unique ID from PositionIdGenerator

The Portfolio component tracks these positions and updates PnL calculations based on market data events It utilizes an AccountsManager to handle balance updates across cash and margin accounts

Sources:

---

External Order Claims

Strategies can "claim" orders that were not originated by the platform (e.g., manual trades on the exchange UI).

• Claims are registered in ExecutionEngine.external_order_claims
• This is critical for reconciliation in live environments where external clients might interact with the same account

Sources: