ML Model Deployment for Live Trading
Training a model to predict market moves is the easy half; deploying it to trade the market live is where professionals are separated from amateurs. A live ML trading system is an engineering pipeline - data, model, decisions, orders, monitoring - built for failure tolerance and substanceless drift. This guide covers the deployment architecture, live-loop decisions, monitoring, and the risk rules that keep an ML system from quietly destroying a trading account.
The Deployment Architecture
Data feed → feature engine → model inference → signal generator → risk gate → broker API → ledger/monitoring1. Data Feed and Feature Engine
Live differs from backtests: data arrives late, sparse, or dirty on real feeds. The feature engine must exactly replicate the training pipeline's features (same lookbacks, same normalisation, same point-in-time logic) - a model that sees different features in production will silently degrade. Version the feature code alongside the model.
2. Model Inference
Serve the model (pickle, ONNX, or an API) with a latency budget; the inference pipeline must be fast enough for the strategy's horizon - a 20-second inference loop kills a scalping system and is fine for an end-of-day system. Use a feature-store or cached inference to survive market hours without recomputing everything each bar.
3. Signal Generator and Risk Gate
Signals become trade orders through a risk gate - rules that override the model: position limits, max notional, volatility stops, cooldowns after a string of losses. The model proposes; the risk gate disposes. This split is the single most important architecture decision: the ML system is never allowed to trade outside the gate.
4. Broker API and Ledger
Fills flow through the broker API with order management (reject handling, partial fills, timeouts). Every fill must be reconciled to a ledger (backtrader-in-live style) so your live P&L is recorded independently of the broker's view.
Monitoring: The Drift That Kills
- Concept drift: the market regime changes and the model's edge decays - track live prediction-vs-outcome (PSI/Pearson) on a rolling window
- Data drift: feature distributions shift; monitor per-feature means/std and alert on statistical breaks
- Execution drift: fills vs expected prices, slippage widening, latency spikes
- System health: process alive, orders acknowledged, API connectivity - a dead pipeline is a silent equity killer
Alert on every abnormal value; your monitoring dashboard is your only early-warning system between model refresh cycles.
Model Refresh and Rolling Validation
No model is evergreen. Schedule re-training on a cadence (daily/monthly depending on regime sensitivity), always validating on chronologically held-out data before going live. Keep a champion model live while the challenger trains; only swap when the challenger wins on out-of-sample metrics plus simulated live performance. Cap retraining frequency - each swap invites instability.
When to Kill the System
- Rolling out-of-sample Sharpe drops below threshold for N weeks
- Drawdown hits the pre-agreed maximum loss - stop trading, not debate
- Data drift alerts that the validation can't explain
- Regime change (a structural break - new regulation, crisis) that invalidates the model's universe
A professional system has a kill switch wired to P&L, not just to technical errors. The best ML traders treat "when to stop" as a designed rule, not an emotional decision.
Risk Rules for Live ML
- Trade small: live capital sized as a fraction of what the backtest survived
- Disconnect the ego: model managers fail when they prevent the kill switch from working
- Paper-trade the deployed pipeline for a period with live data before realtrading it
- Document every override - a human override is a new trading rule needing its own validation
Bottom Line
Deploying ML for live trading is engineering, not magic: feature-exact replication, model inference until latency budget, a risk gate the model can never override, full monitoring of data/model/execution drift, champion-challenger retraining, and a pre-designed kill switch. The system that survives is the one built for the failures - lagging feeds, drifting regimes, stale models - not the one tuned to vanity backtests.
SEBI Disclaimer
Live trading with ML systems involves substantial risk. This article is educational and is not investment advice.
The Feature Store: The Shared Surface You Need
The live system's most fragile component is not the model; it is the feature stream. Production must recompute every feature exactly as training computed it - same windows, same scaling, same missing conventions, same timestamps - and the only way to hold that truth is a feature store that defines each feature once and serves it to both the training pipeline and the live scorer. A feature drift between the two paths is the classic silent killer: the training set computed a rolling mean over full sessions while the production reader computes over rolling minutes, and the model quietly stops seeing what it learned. Version the feature definitions, test the live values against a replay of the historical table, and make the equality check a part of every release.
Backfilling Parity: Live Values vs Training Values
The audit that matters is backfill parity: replay the live feature logic over a historical window and confirm the series reproduces the values training used, within tolerance. Run it at every refactor, on a couple of months of data, and hold the output as an artifact. When a live prediction diverges unexpectedly, the first suspect is the parity check's last green run, and a green run makes the suspect someone else. The trader who cannot prove their live features match their training features is trading a model whose training data no longer exists.
Canary vs Shadow vs Full Deployment
Three deployment geometries exist between the backtest and the live risk: shadow logs the model's signals while the account trades nothing from them, canary trades a tiny fraction under tight monitoring, and full flips the system on. The professional sequence climbs the ladder on evidence, never on schedule: shadow for a month to measure signal stability, canary at a small size to measure fills and costs, full only after the canary's cost-corrected numbers match the shadow's. Each rung generates evidence the next depends on, and skipping one converts a system launch into an experiment with live capital.
The Human Kill Switch and Its Logging
Every automated system earns a human kill switch with three properties: one action that flattens and cancels, a log that records who pulled it and when, and a post-mortem that asks why the system needed pulling at all. The switch is not an embarrassment; it is the documented boundary where human judgment asserts itself, and its invocation is data, not failure. Pair the switch with the drift dashboard so that pulling it on evidence leaves a trail the review can convert into the next improvement. The absence of a kill switch is the real operational risk, because the market will occasionally produce the reason everyone forgot to install one.
Costs and the Rupee Runbook
Run the deployment cost in rupees before the deployment: the server, the websocket or data feed subscriptions, the broker API plan if any, and the compute for the daily refit. The honest total is a monthly line item the strategy's edge must beat, and the runbook - the 3 AM procedures for a connection drop, a token expiry, a broker outage - is where the cost is rescued on days nothing works. Write each runbook step as commands, not prose, and rehearse it in a dry run. A system whose operator drills the failure procedures is a system whose failures are cheap, and cheap failures are the strategy's cheapest alpha.
- Define every feature once in a store; serve the same version to train and live.
- Run the backfill parity audit on every release.
- Climb shadow, canary, full on evidence, not schedule.
- Install, log, and drill the human kill switch.
- Price the monthly stack and rehearse the failure runbooks.
