Going Live

Quick Start

Your strategy talks to one endpoint in paper and live trading: the Trading Gateway on localhost:8080. Once you've validated a strategy with backtests on the hosted Tektii platform, going live means running that same strategy against the self-hosted Gateway — moving from paper to live changes how you start the Gateway, not how your strategy connects. Three steps:

Start the Gateway with your chosen provider — follow Install → Starting the Gateway.
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 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

Your strategy code does not change between modes. Backtests run on the hosted Tektii platform — you do not launch them yourself. For paper trading, run the Gateway with a broker provider and the default mode (e.g. GATEWAY_PROVIDER=alpaca, GATEWAY_MODE=paper); for live trading, the same provider with GATEWAY_MODE=live — the protocol behaves identically, but executions affect real positions and balances. For the full mode reference and the platform identifiers the Gateway emits, see Trading API Concepts → Execution Modes.

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

Run the Gateway with your broker in paper mode (e.g. GATEWAY_PROVIDER=alpaca with GATEWAY_MODE=paper) 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

Restart the Gateway with GATEWAY_MODE=live and 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
[ ] Gateway secured: GATEWAY_API_KEY set, port not exposed publicly (see Setup → Securing the Gateway)

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