Going Live
Quick Start
Your strategy talks to one endpoint in every mode: the Trading Gateway on localhost:8080. Moving from backtest to paper or live trading changes how you start the Gateway — not how your strategy connects. Three steps:
Start the Gateway with your chosen provider — follow the Trading Gateway setup.
Point your strategy at the Gateway — the same URLs work in every mode:
WS_URL=ws://localhost:8080/v1/ws REST_URL=http://localhost:8080
Run your strategy — it connects and trades using the same protocol, with zero code changes between modes.
Only the Gateway's GATEWAY_PROVIDER (plus broker credentials and optional GATEWAY_MODE) changes between backtest, paper, and live. Your strategy code and connection URLs stay the same.
Risk Warning: Trading involves substantial risk of loss. Past backtest performance does not indicate future results. Backtests are hypothetical and subject to biases including survivorship bias, look-ahead bias, and unrealistic fill assumptions. Live markets exhibit slippage, partial fills, order rejections, and latency that backtests cannot fully replicate. Only trade with capital you can afford to lose. The Trading Gateway is infrastructure software — it executes what your strategy tells it. It does not provide investment advice and is provided as-is.
Execution Modes
The Trading Gateway runs in one of three modes. You select a mode by how you start the Gateway — specifically the GATEWAY_PROVIDER and GATEWAY_MODE environment variables. Your strategy code does not change between modes.
Backtest Mode
Simulated trading against historical market data. Run the Gateway with GATEWAY_PROVIDER=tektii to connect it to the Tektii simulation backend; the simulation provider controls time progression, and your strategy must acknowledge each batch of events before time advances. This ensures deterministic, reproducible results.
Paper Trading Mode
Real market data with simulated order execution. Run the Gateway with a broker provider (e.g. GATEWAY_PROVIDER=alpaca) and GATEWAY_MODE=paper (the default) to validate your strategy against current market conditions without risking capital.
Live Trading Mode
Real orders on real markets. Run the Gateway with a broker provider and GATEWAY_MODE=live. The protocol behaves identically to paper mode, but executions affect real positions and balances.
See Supported Brokers in the Trading Gateway README for the full provider matrix and required credentials.
Platform Identifiers
TradingPlatform is a string emitted by the Gateway on subscription entries and on some response fields (for example, Bar.provider, Quote.provider, and the broker field on connection events). Your strategy does not set it — it is metadata that tells you which upstream broker/market a given event came from.
Canonical values (from the Trading Gateway OpenAPI spec):
alpaca-live,alpaca-paperbinance-spot-live,binance-spot-testnetbinance-futures-live,binance-futures-testnetbinance-margin-live,binance-margin-testnetbinance-coin-futures-live,binance-coin-futures-testnetoanda-live,oanda-practicesaxo-live,saxo-simtektii— Tektii simulation (backtest)mock— in-memory mock provider used for development
The Gateway's openapi.json is the source of truth; treat the list above as the current set rather than a closed enum.
Recommended Progression
Do not jump straight from backtesting to live trading. Follow a staged approach:
Stage 1: Validate Your Backtest
Before advancing past backtest, ensure your results are robust:
- Test across multiple market regimes (bull, bear, sideways, high volatility)
- Enable realistic transaction costs and slippage in your simulation
- Verify results are not dependent on a single favourable period
Stage 2: Paper Trade a Single Instrument
Connect to alpaca-paper or binance-spot-testnet and trade one instrument. The goal is to validate the plumbing:
- Orders arrive at the broker and fills come back
- WebSocket reconnection works if the connection drops
- Your strategy handles all message types the Gateway sends
Run until you have at least 30-50 round-trip trades for a meaningful sample.
Stage 3: Paper Trade Your Full Universe
Expand to your full instrument set. Run for at least 1-2 weeks and verify:
- Portfolio-level behaviour matches backtest expectations within reasonable tolerance
- Order rejection rates are acceptable
- Fill prices are close to expected (some slippage is normal)
- No unhandled error states
Stage 4: Live with Minimal Capital
Switch to alpaca-live or binance-spot-live with the smallest position sizes your strategy supports. The goal is to confirm real execution:
- Real fills, real commissions, real settlement
- Compare results against your paper trading period
Stage 5: Scale to Target Capital
Once live results match expectations, gradually increase position sizes to your target capital allocation. Monitor actively during the initial scaling period.
Do not advance to the next stage if:
- Paper results diverge materially from backtest expectations (investigate first)
- You observe unhandled errors or unexpected Gateway behaviour
- Your strategy does not correctly handle order rejections, partial fills, or WebSocket disconnections
Pre-flight Checklist
Before connecting a strategy to live money, verify each item:
- [ ] Paper traded with a sufficient sample size (30+ round-trip trades minimum)
- [ ] Strategy handles WebSocket disconnections and reconnects gracefully
- [ ] Strategy handles order rejections and partial fills
- [ ] Maximum drawdown limit configured
- [ ] Kill switch ready (know how to emergency stop)
- [ ] Broker margin requirements understood
- [ ] Fees and commissions accounted for in your model
- [ ] Local regulatory requirements reviewed (see below)
- [ ] Strategy runs on a server, not a laptop that can sleep
Risk Controls
Position Sizing
Never risk your entire account on a single position. Common approaches:
- Fixed percentage — risk 1-2% of account equity per trade
- Volatility-adjusted — size positions relative to instrument volatility
If your backtest used fixed position sizes, live results will diverge as your account balance changes. Size relative to current equity, not a hardcoded amount.
Maximum Drawdown Limits
Set hard limits that halt trading automatically:
- Per-day loss limit — stop trading if down more than X% in a single day
- Per-week/month limit — broader loss threshold
- Peak drawdown — halt if portfolio drops more than X% from its high-water mark
When a limit is hit, the correct behaviour is to flatten all positions and stop trading — not just stop opening new positions.
Kill Switch
Have at least two independent ways to stop your strategy:
- Stop the strategy process — terminates the WebSocket connection, no new orders sent
- Close positions at the broker — log into your broker's dashboard and manually close any open positions
The Gateway does not manage orphaned positions. If your strategy process crashes while positions are open, those positions remain open at the broker. You are responsible for monitoring and closing them.
Common Failure Modes
Things that go wrong when moving from backtest to live:
| Failure | Cause | Mitigation |
|---|---|---|
| Duplicate orders | Strategy assumes instant fills but real fills have latency | Track order state; don't re-submit while pending |
| Stuck positions | Strategy doesn't handle partial fills | Handle PARTIALLY_FILLED status explicitly |
| Missed data | WebSocket disconnects during market hours | Implement reconnection with state recovery |
| Order rejections | Broker API rate limits during high activity | Implement backoff and retry logic |
| Orphaned positions | Strategy crashes with open positions | Monitor strategy health; have manual close procedure |
| Wrong trading hours | Time zone mismatch | Verify your strategy's clock matches market hours |
Monitoring
After deployment, actively watch these metrics:
- Fill price vs expected — measure slippage; investigate if consistently worse than expected
- Order rejection rate — should be near zero; high rates indicate a problem
- Round-trip latency — time from order submission to fill confirmation
- Trades per day — should match your backtest frequency; major deviations indicate a bug
Where to Run
Run your strategy on a server or cloud instance, not a personal laptop. If the machine sleeps, your strategy stops but positions remain open. Use process monitoring (e.g., systemd, Docker restart policies) to restart the strategy if it crashes.
Regulatory Considerations
This is not legal advice. Algorithmic trading is regulated in most jurisdictions — you are responsible for compliance:
- EU/UK — MiFID II has specific requirements for algorithmic trading including testing, risk controls, and record-keeping
- US — SEC and FINRA rules cover pattern day trading, market manipulation, and automated trading
- Broker terms — some brokers require disclosure that you are using automated trading; check your broker's terms of service
- Tax — automated trading can create complex tax situations (e.g., wash sale rules in the US); consult a tax professional
- Record keeping — log all orders, fills, and strategy decisions; this is both good practice and may be legally required
Next Steps
- Trading Gateway Setup — Configure and verify the Gateway
- Connection Guide — Detailed WebSocket and REST connection patterns
- Trading API Concepts — Understand the unified protocol