Live Trading Systems

Learning Objectives

• Explain why technical divergence between research and production is a primary failure mode in live trading, and how a unified framework reduces that risk
• Design a dual-mode, event-driven trading architecture in which deterministic strategy logic runs unchanged in backtest, paper, and live execution
• Compare broker, exchange, and managed-platform deployment paths and evaluate them in terms of asset coverage, execution quality, operational burden, and control
• Model order handling as an explicit state machine that supports partial fills, cancellations, rejections, reconciliation, and idempotent crash recovery
• Verify technical parity across the full pipeline, from raw data and features to predictions, sizing decisions, and generated orders
• Plan a staged live rollout using pre-flight checks, shadow or paper trading, kill switches, reconciliation procedures, and awareness of venue and jurisdictional constraints

This section identifies technical divergence between backtest and live systems as the most common self-inflicted failure in algorithmic trading, where feature calculation differences, timing assumptions, and data handling edge cases cause live performance to diverge from expectations. The unified framework solution uses the same strategy code in both modes: ml4t-backtest for research and validation, ml4t-live for paper and live trading, with abstract interfaces for data and execution hiding the source. The nine case studies from Chapters 16-19 each define complete pipelines that can move from backtest to live runtime without rewriting strategy logic, making the unified framework the payoff of the book's consistent architecture.

2 notebooks

The section covers IBKR's TWS and IB Gateway connection options, essential reliability patterns (heartbeat requests for idle connection detection, exponential backoff for reconnection), and the order types most relevant for algorithmic trading including market, limit, and stop orders with SmartRouting across venues. It details position and account management through callbacks for positions, account values, and execution reports, along with error handling for the most common failure codes. The practical emphasis is on IBKR Pro's SmartRouting that does not sell order flow, with research evidence that broker routing architecture explains more execution cost variation than commission schedules.

1 notebook

This section presents Alpaca as the easiest broker path for early live-trading experiments, with commission-free US stock/ETF trading and a clean REST/streaming API, while noting that routing quality and spread capture still determine realized cost. It compares Alpaca with IBKR across asset classes, order types, rate limits, and execution routing, and covers crypto support through the same unified API. The section also introduces direct crypto exchange APIs (Binance, Bybit, OKX, Deribit) for derivatives strategies, with geographic restrictions and venue eligibility treated as legal prerequisites that must be verified before strategy development.

2 notebooks

The section evaluates managed platforms against self-hosted systems across development speed, flexibility, cost structure, intellectual property, and operational burden, positioning QuantConnect's open-source LEAN engine as a hybrid option supporting cloud, local, and self-hosted deployment. It argues that platforms suit retail-scale operations, rapid prototyping, and teams with limited engineering bandwidth, while self-hosted stacks are better when strategy portability, custom data handling, or tighter operational control matters more. Migration considerations including code portability, independent data vendor relationships, and hybrid operation across platforms address the platform lock-in concern.

1 notebook

This section models the order journey from strategy signal through submission, acknowledgment, partial fills, and terminal states as an explicit state machine with 11 states and 23 valid transitions, handling edge cases like out-of-order messages, concurrent events, and network timeouts. End-of-day reconciliation comparing internal records against broker statements for positions, orders, and cash catches discrepancies before they accumulate, with the recommendation to halt automated trading when reconciliation detects problems. Client order IDs provide idempotent crash recovery, ensuring orders are never duplicated due to system failures.

1 notebook

The section establishes a systematic verification methodology that feeds identical inputs through backtest and live systems at each pipeline stage (raw data to features, features to predictions, predictions to signals, signals to orders) and compares outputs to isolate divergence sources. It addresses common culprits including look-ahead bias, data adjustment differences, missing data handling, timezone confusion, and exchange-level distribution shift from training on one venue's data while running inference on another. The crypto perpetuals case study demonstrates the complete ML-to-live pipeline, deploying a Chapter 12 LightGBM classifier to OKX with minute-level feature computation, prediction-flip exits, and stop-loss protection.

2 notebooks

This section covers pre-launch requirements including startup gates for environment health, authentication verification, state coherence, and market context validation that must all pass before automated trading begins. It presents a four-level kill switch hierarchy from pausing new signals through canceling orders to flattening positions to full shutdown, emphasizing that each action should be executable through one clear control that has been tested in advance. Regulatory and jurisdictional considerations across the US, EU, and India are surveyed practically, with transaction taxes, leverage caps, and venue access constraints treated as deployment prerequisites rather than afterthoughts.

1 notebook