Direct Answer
Live deployment is the process of moving a strategy from simulation to real capital. It requires four things that a backtest does not: reliable infrastructure that runs continuously without human intervention; broker API integration that handles real order submission, fill confirmation, and error recovery; position reconciliation to ensure the system's internal state always matches the broker's actual records; and a size ramp plan that starts with reduced capital and scales up only after confirming the live system behaves as expected.
The most common mistake in live deployment is treating it as a single step — submitting full-size orders on day one because the backtest and paper trading both looked good. A staged deployment, starting at 10–20% of target size and increasing over 4–8 weeks as execution quality is confirmed, limits the cost of any bugs or unexpected behavior that only become visible under real market conditions.
Key Takeaways
- Live infrastructure requires a server that runs 24/7 with reliable connectivity — a VPS or cloud instance, not a laptop that sleeps. A $10/month DigitalOcean or AWS EC2 instance is sufficient for most retail strategies.
- The production code must be the same code as the paper trading code, not a rewrite. Every rewrite introduces divergence between what was tested and what runs live.
- Position reconciliation — comparing the system's internal position model against the broker's confirmed positions — must happen at least once per trading session and after every order batch. Position drift accumulates silently and can result in orders against non-existent positions.
- A size ramp plan starts at 10–25% of target capital and escalates only after observing 4+ weeks of execution quality metrics within expected ranges: slippage, fill rate, reconciliation errors, and P&L vs expected.
- Broker API authentication tokens typically expire. A strategy that runs for weeks without attention will eventually fail to authenticate — the expiry mechanism must be handled automatically, not relied on human intervention.
- Market open and close are highest-risk execution windows: data feeds spike, order volumes surge, and API rate limits are most likely to be hit. Strategies that execute near open or close require extra error handling in those windows.
- Every live deployment needs a manual override capability — the ability for the operator to stop the strategy, cancel all open orders, and flatten positions within minutes, without executing complex code. A simple kill script should exist before day one.
- Paper trading is not live trading. Even 8 weeks of perfect paper trading does not guarantee the first real trading day will be smooth — real capital triggers margin requirements, account-level rate limits, and broker compliance checks that do not apply to paper accounts.
Core Concepts
Infrastructure checklist before first live order
Production infrastructure for an algorithmic trading strategy has more components than most first-time deployers expect. The minimum production stack includes: a compute environment that runs without human attendance (VPS, cloud VM, or dedicated server); process management that restarts the trading process if it crashes (systemd, supervisor, or PM2 on Linux); authenticated broker API connectivity with automatic token refresh; a real-time data feed for live price and order status; a persistent position and order database that survives process restarts; a monitoring and alerting system that sends notifications when the process stops, fills are rejected, or P&L crosses thresholds; and a logging system that records every order, fill, and error with timestamps.
Checklist items that are frequently skipped and frequently cause failures: (1) clock synchronization — the server's system clock should be synchronized with an NTP server, because timestamps matter for order submissions in time-sensitive windows; (2) timezone handling — the trading calendar operates in Eastern Time (U.S.), but servers default to UTC; a single timezone mismatch can cause a strategy to trade an hour early or late; (3) corporate action handling — price-adjusted data in the live feed may differ from the backtest data source's adjustment method, causing signal divergence after splits or dividends; (4) API rate limit awareness — brokers enforce limits on API requests per second or minute; a strategy that fires many orders simultaneously can hit these limits and have orders rejected silently.
Paper trading transition: what it validates and what it does not
A paper trading period (typically 4–8 weeks minimum) validates the execution plumbing: that orders are submitted at the correct times, fill confirmations are processed correctly, positions update as expected, and the strategy's signal calculations produce the same outputs in real time as they did in the backtest. Paper trading also reveals operational bugs: timezone errors, data feed disconnection handling, order type mismatches, and any divergence between the backtest data source and the live data source.
Paper trading does not validate anything about the strategy's profitability because: (1) the time period is too short for statistical conclusions about Sharpe or alpha; (2) paper accounts typically do not experience real bid-ask spread, market impact, or partial fills — they fill at the mid-price for any quantity instantly; (3) paper account behavior may differ from real account behavior in edge cases like margin calls, corporate action processing, and account-level restrictions. The paper trading conclusion should be: "the execution infrastructure works as designed" — not "the strategy is profitable."
Position reconciliation architecture
The trading system maintains two position records: the internal model (what the system believes it holds based on orders submitted and fills received) and the broker record (what the broker's systems actually show as the account's positions). These can diverge due to: fill confirmations that were sent but not received by the system; orders that the broker rejected after the system marked them as submitted; corporate actions that the broker processed but the system did not; or connectivity interruptions during a fill notification. The reconciliation process compares the two records and resolves any discrepancy before the next trading cycle.
A robust reconciliation flow: at the start of each trading session (or at a specified reconciliation time for intraday strategies), query the broker's current positions via the account endpoint of the broker API. Compare quantity, symbol, and direction against the system's internal model for each position. For any discrepancy, apply a reconciliation rule: if the broker shows more shares than the system model (e.g., a fill was processed but the fill event was lost), update the internal model to match the broker and log the discrepancy. If the broker shows fewer shares (an order was rejected without the system knowing), update the model and trigger a decision about whether to re-enter the position according to the strategy's rules. Log all reconciliation events with full detail for audit purposes.
The size ramp plan
A size ramp plan controls how quickly capital is deployed into a new live strategy. Starting at full target size on day one maximizes the cost of any bug or unexpected behavior discovered during live operation. A staged ramp limits this exposure while still generating real execution data that paper trading cannot provide.
A typical 8-week ramp plan for a strategy targeting $50,000 in capital: weeks 1–2 at $5,000 (10% of target); weeks 3–4 at $12,500 (25%); weeks 5–6 at $25,000 (50%); weeks 7–8 at $37,500 (75%); full size at week 9 if all execution quality metrics are within expected ranges. At each ramp checkpoint, evaluate: average slippage per trade vs backtest assumption; fill rate vs expected; reconciliation error frequency; and daily P&L standard deviation vs expected based on position size. Significant deviations at any checkpoint warrant investigation and pausing the ramp until resolved.
Error handling and recovery in live code
Live trading code must handle errors that backtests never encounter: network timeouts, broker API rate limit responses (HTTP 429), authentication failures, partial fills, orders rejected for insufficient margin, and data feed interruptions. Every error path must have an explicit handling strategy — not just a generic exception catch that logs and continues. For order submission errors, the handling strategy must decide: retry immediately (risk of duplicate order), retry with delay (risk of missing the trading window), or abort and log for manual review (risk of unintended flat position). The correct choice depends on the error type and the strategy's time sensitivity.
For connectivity interruptions during active trading, the system must have a safe default state. The safest default is to stop generating new orders and wait for reconnection rather than making assumptions about what filled or did not fill while disconnected. After reconnection, a full reconciliation must occur before any new orders are submitted. A system that continues trading through a connectivity gap on stale assumptions is more dangerous than one that pauses and waits for a clean state.
Worked Scenario: 10-Week Deployment Ceremony
- Week 1–2 (Infrastructure setup): Provision a $12/month Ubuntu VPS on DigitalOcean. Install Python environment, broker SDK, and dependencies. Set up process management with systemd to auto-restart on crash. Configure NTP time sync. Set up structured logging to file with daily rotation. Test broker API authentication and order submission with a single test order (buy 1 share, cancel immediately).
- Week 3–4 (Paper trading): Connect to paper account. Run live signal generation and paper order submission for 2 weeks. Compare signal values against backtest signal for the same dates — any divergence indicates data feed discrepancy. Verify positions in paper account match system model at end of each session. Check that process survives a simulated restart.
- Week 5 (Pre-live checklist): Run the risk control checklist (see Algo Risk Control Checklist). Confirm kill switch works: simulate an emergency stop from the command line, verify all orders cancelled and no new orders submitted. Test alert notifications: verify email/SMS alerts fire when simulated thresholds are crossed.
- Week 6 (10% size live): Switch to real account. Fund with $5,000 (10% of $50,000 target). Run at 10% size for 2 weeks. Review fill quality: compare average fill price vs signal price for each trade. Measure actual slippage: 8 bps average, within the 10 bps backtest assumption. Zero reconciliation errors. One authentication token expiry mid-week — handle caused by missing refresh logic; fix immediately and re-deploy.
- Week 8 (25% ramp): Increase to $12,500. Continue execution quality monitoring. First large drawdown week: strategy loses 2.1% in one week, within the expected volatility range based on backtest. Resist urge to adjust parameters — this is expected behavior, not a signal to intervene.
- Week 10 and beyond: Continue ramp to 50%, 75%, full size at 4-week intervals assuming no execution quality deterioration. By week 14, strategy is at full $50,000 target size with 8 weeks of execution quality data confirming the live system matches backtest expectations within acceptable tolerance.
Measurement Framework
| Measurement | What it tells you |
|---|---|
| Signal divergence (live vs backtest) | Whether live data produces the same signal values as the backtest data source; divergence indicates data pipeline discrepancy |
| Execution slippage per trade | Average gap between signal price and fill price; growing slippage signals execution quality deterioration |
| Fill rate | Fraction of target quantity filled; consistently below 90% suggests orders are too passive or market is less liquid than assumed |
| Reconciliation error frequency | Number of position discrepancies per session; any non-zero rate requires investigation before size ramp continues |
| API error rate | Fraction of order API calls returning errors; rising error rate signals infrastructure or broker-side issues |
| Daily P&L vs expected range | Whether observed daily P&L falls within ±2 standard deviations of backtest distribution; sustained deviation warrants strategy review |
Common Failure Modes
Running production code on the development machine
Running an algo on a laptop or desktop that is used for other tasks creates multiple failure risks: the machine may sleep, restart for updates, lose internet connectivity, or be shut down without the operator realizing the strategy is mid-cycle. A dedicated server instance running only the trading process, with a process manager configured to restart on crash, is the minimum reliable infrastructure for any strategy that executes more frequently than once per day.
Not testing the kill switch before going live
A kill switch that exists in code but has never been tested is not a kill switch — it is an untested script that may have bugs preventing it from working when needed. Test the kill switch procedure before the first live trade: simulate a triggering condition, execute the kill script, verify all open orders are cancelled, and confirm no new orders are generated. This test should be repeated after any code change that touches the order management or kill switch logic.
Deploying full size immediately after paper trading
Even after weeks of successful paper trading, the first real trading day may reveal behavior that paper accounts never show: real bid-ask spreads affecting limit order fills, margin requirements temporarily locking capital, or account-level API rate limits different from paper account limits. Deploying at 10–25% of target size for the first few weeks limits the cost of discovering these differences. The performance cost of starting small is negligible; the protection against undiscovered bugs is significant.
Failing to handle stale data gracefully
Data feeds can lag, drop ticks, or freeze without sending an explicit disconnection signal. A strategy that computes signals based on prices that are 15 minutes stale is effectively trading blind. The live system must timestamp every data event and trigger a halt or alert if data freshness falls below a threshold — for example, if the last price update for a position was more than 60 seconds ago during market hours, treat the data as stale and do not submit new orders until fresh data is confirmed.
Parameter drift between research and production environments
If the strategy uses different parameters in production than in the validated backtest — due to code refactoring, configuration file mismatches, or accidental overrides — it is not the tested strategy. Production configuration files should be version-controlled alongside the strategy code, with a startup check that logs and validates all parameters against expected values before the first order is submitted.
Frequently Asked Questions
What cloud provider is best for running an algo trading system?
For retail algo strategies, the cloud provider matters less than instance reliability, latency to the broker's API, and cost. AWS, Google Cloud, and DigitalOcean are all commonly used. A general-purpose t3.small or t3.medium instance on AWS ($15–$30/month) is more than sufficient for most daily-to-intraday retail strategies. For strategies that route orders through Interactive Brokers, AWS us-east-1 has the lowest latency to IB's servers. DigitalOcean is often slightly cheaper for equivalent compute and simpler to configure for users without AWS experience.
How do I handle broker API authentication token expiry in production?
Most broker APIs use OAuth tokens or session tokens with finite lifetimes — typically 24 hours to several weeks. Production code must implement automatic token refresh before expiry, logging the refresh event and alerting if refresh fails. A common pattern: refresh the token on startup, then schedule a refresh at 80% of the token's expected lifetime, with a fallback retry on failure and an alert if three consecutive refresh attempts fail. Never rely on a human to log in and refresh the session for a strategy that may be actively trading when the token expires.
How do I reconcile positions after a weekend when markets are closed?
At Monday morning startup, before any signal computation or order submission, query the broker's positions endpoint and compare against the stored end-of-Friday position snapshot. Any discrepancy should be investigated: corporate actions (splits, mergers, special dividends), broker margin calls, or error corrections can change positions over the weekend. Resolve all discrepancies before market open. A position reconciliation that takes 5 minutes at Monday open prevents a week of compounding errors from a stale position model.
Should the live strategy code be identical to the backtest code?
The signal computation logic should be identical — the same formula, same parameters, same data preprocessing pipeline. The execution infrastructure will necessarily differ: backtests use simulated order placement and fill events; live systems use real API calls and real fill confirmations. The risk is that refactoring the signal code for production introduces subtle differences from the validated backtest. Best practice is to have the signal computation module be a shared, version-controlled library that both the backtest and live system import — ensuring the exact same code runs in both environments.
What happens if the system submits a duplicate order?
Duplicate orders — two buy orders for the same symbol when only one was intended — create double the intended position. This can happen when a network timeout causes the system to retry an order submission without knowing whether the first submission succeeded. Prevention requires a client-order-ID (a unique identifier generated by the system and included in every order request); if the broker receives two orders with the same client-order-ID, it should reject the duplicate. Most modern broker APIs support client-order-IDs precisely for this reason. Using unique client-order-IDs for every order submission is a mandatory safety practice, not optional.
How do I handle a strategy that should be flat (no positions) when the market is closed?
For intraday strategies that should exit all positions before market close, add an explicit end-of-day flatten check: 15 minutes before market close, verify that all open positions have been exited or have active exit orders. If any positions remain, submit market orders to close them regardless of the signal state. For strategies that hold positions overnight, the market-close check should verify position quantities match the intended holdings, not that positions are zero. In both cases, logging the end-of-day state to a permanent record is essential for reconciliation.
What is the right size ramp speed for a new strategy?
A conservative ramp that doubles size every 4 weeks (10% → 25% → 50% → 100%) takes about 12 weeks to reach full size. This is appropriate when the strategy is new, there is limited live execution data, or the position sizes are large relative to typical daily volume. A faster ramp (doubling every 2 weeks) is acceptable when: the strategy has been running in a similar form before (parameter recalibration rather than full redesign), paper trading execution was confirmed to match backtest expectations closely, and the capital amounts are small enough that a complete loss would not be catastrophic. Never ramp faster than every 2 weeks — the goal is to accumulate enough real execution data at each size to confirm behavior before scaling further.
What should I do if the live strategy is significantly underperforming the backtest in the first month?
First, diagnose before adjusting. One month of live data is typically 20–22 trading days — not enough to distinguish between bad luck and genuine strategy failure. Check execution quality first: is slippage significantly higher than assumed? Are fill rates lower than expected? Is the data feed producing the expected signals? If execution quality is within expected ranges and the underperformance is in the P&L, it may simply be a drawdown period within the strategy's expected distribution. Compare the drawdown to the worst single-month drawdown observed in OOS backtesting. If the live drawdown exceeds the worst historical month by more than 50%, that warrants deeper investigation of whether the strategy has entered a new regime the backtest did not cover.
Sources
Disclaimer
This article is for educational purposes only and does not constitute investment advice. Live trading involves risk of loss. Infrastructure, regulatory, and operational requirements vary by broker, jurisdiction, and strategy type. Verify all requirements with your broker before deploying a live automated trading system.