Automation and Bots - When It Makes Sense

Introduction

Automation is the most overrated stage of systematic trading. Beginners want a bot before they have an edge. An advanced trader knows: a bot does not create an edge, it only scales and enforces an edge that already exists and has been measured. If you have an EV of 0.05R after costs, automation will make you lose faster. If you have an EV of 0.25R and the problem is your discipline, a bot makes sense.

This lesson answers the question “when”, not “how to write a bot in 10 minutes”. You will go through the readiness criteria for automation, the architecture of a safe bot, the modes of operation (alert -> semi-auto -> full auto), and an operational risk checklist that protects capital better than a stop-loss.

When automation makes sense - 5 filters

A bot only makes sense if you pass 5 filters. If one fails - stay with semi-automated or manual trading with a protocol.

Decision:
5x YES = you can go full auto with small capital and limits
3-4x YES = semi-auto (alert + manual confirmation)
<3 YES = no automation, go back to lessons 3-5

Most systematic retail losses come from bots launched at 1x YES.

Three modes of automation - from safe to risky

Mode 1: Alert + manual execution (recommended start)

TradingView alert -> notification -> you open the trade manually according to the checklist. What you gain: you eliminate market scanning, you keep control. The bot has no access to capital.

Flow:
Pine alert webhook -> Discord/Telegram -> you check the regime filter -> order at the broker

Mode 2: Semi-auto - the bot sends an order with confirmation

The bot computes the signal in Python, sends a draft order, you click confirm in the broker app, or the bot waits 60s for a cancel.

Mode 3: Full auto

The bot has API keys with trading permission (never withdraw). It runs on a VPS, has monitoring, logs, a daily stop.

Rule: go through the modes sequentially, at least 30 days each. Do not jump from an alert straight to full auto.

Architecture of a safe bot - the minimum you must have

Components:

1. Data Feed - websocket or REST with re-connect and data-gap validation
2. Signal Engine - the same logic as in the backtest (the same shift, the same parameters)
3. Risk Manager - checks before every order:
   - Is the position ≤ max_position_size?
   - Is daily loss < max_daily_R?
   - Is spread < max_spread?
   - Is there no open position (if 1 position max)?
4. Execution Module - sends LIMIT or MARKET with an ID and retry logic
5. Logger - every signal, every rejection by the Risk Manager, every API error -> file + Telegram
6. Kill Switch - a /stop command that kills the process and cancels orders, plus a hard stop after the daily MaxDD
7. State Recovery - after a VPS restart the bot knows whether it has a position and restores SL/TP

Risk Manager pseudo-code:

def can_trade(signal, account):
    if account.daily_pnl_R < -MAX_DAILY_LOSS_R:
        log("BLOCK: daily loss")
        return False
    if spread > MAX_SPREAD_PCT:
        log("BLOCK: spread")
        return False
    if open_positions >= MAX_POS:
        return False
    if not is_market_open():
        return False
    return True

Without a Risk Manager, a bot is a weapon without a safety catch.

Hidden costs of full auto that are not in the backtest

Operational cost checklist before full auto:
- Have you accounted for the funding rate on perps? (0.01% * 3 a day can eat your edge)
- Does the bot have a slippage limit for MARKET?
- Do you have an alert when the bot has not sent a heartbeat for 15 min?

30-day demo + shadow trading

Never launch a bot on live without:

1. 14 days of paper trading on the same VPS and the same code as live (not a different notebook).
2. 14 days of shadow trading: the bot sends signals on live data but you execute manually and compare: do the bot and you have the same entry +/- 0.05%?
3. A divergence journal: every difference >0.1% explained.

Only then go live with 0.25% risk per trade for 30 days.

When the plan says do not trade (automatically)

1. When you have no kill-switch and no monitoring: A bot that runs unsupervised is a ticking bomb. Do not trade automatically without /stop and a daily loss limit.
2. When the API has withdrawal permission (withdraw enabled): Never. Trade only, never withdraw, IP whitelist.
3. When the bot trades M1-M5 without a x2 slippage test: Real slippage on M1 during news is 0.1-0.3%. Your backtest does not have it. Pause.
4. When you have not tested a VPS restart while in an open position: What does the bot do after a restart? If you do not know, do not launch it.
5. When you emotionally want a bot because “you don’t have to watch”: That is not a reason. The reason is a measured edge plus your inability to execute manually. Otherwise you are automating laziness.

Mistakes that cost the most

1. Writing a bot before the laboratory from lessons 4-5. A bot without a backtest with x2 costs is a guarantee of an operational loss.
2. One machine, one exchange, one key. A failure = no control. Have a backup VPS, a second way to close a position (the broker’s mobile app), a second internet connection.
3. A martingale bot - it increases the position after a loss. The backtest looks great, the forward test ends in liquidation. Never increase risk after a loss in an automated system.
4. No daily limit in R. A bot can make 30 trades a day in chop and generate -6R before you notice. A daily stop in R is mandatory.
5. Trusting free bots from Discord/YouTube. You do not know what is in the code. If you cannot read the code, do not run someone else’s bot with your keys.

Measurable exercise

Goal: Build an automation readiness checklist and simulate a failure.

90-minute task:

1. Choose one system from lesson 5 that has an EV >0.15R after costs x2.
2. Fill in the 5 filters from the start of the lesson. For each YES/NO give numerical evidence.

Example evidence:
Filter 1 Edge: Yes, N OOS=180, EV=0.22R, PF=1.4 after costs x2 -> attach the PDF report
Filter 3 Costs: AvgWin=1.8R, costs 0.08R = 4.4% of AvgWin -> Yes

3. Design your bot’s architecture on paper: Data -> Signal -> Risk -> Execution -> Log -> Kill Switch. Draw boxes and arrows.
4. Run a failure test on demo:

• Open a position manually
• Cut the internet for 5 minutes
• Reconnect, check whether you know how much risk you have and how to close it
• Write down the conclusion: what you must add to the bot so it survives this automatically.

5. If you have <5 YES, write a 30-day plan of what you must measure to reach 5 YES.

Check yourself

1. Name the 5 automation readiness filters and the threshold for each.
2. What are the 3 automation modes and which one is recommended to start with?
3. What must the Risk Manager contain before every order? Name 4 conditions.
4. Why is an API key with withdraw enabled a critical mistake and what do you use instead?
5. Describe shadow trading - what do you compare and how long should it last before going live?

Frequently asked questions

Do I need a VPS for a bot? Yes if the bot is to run >8h a day or on intervals lower than H1. Your laptop on WiFi has interruptions, sleep, restarts. A VPS has 99.9% uptime and a static IP for a whitelist.

How much does it cost to maintain a bot per month? VPS 20-50 USD, data 0-100 USD if you need a paid feed, monitoring (Telegram free). You are leaving out the biggest cost: the time to maintain and debug it.

Can a bot trade on a prop firm account? Check the rules. Most prop firms prohibit full auto bots and allow semi-auto with manual confirmation. Automation without consent = breaking the rules and losing the account.

Can I hire a programmer to write a bot for me? Yes, but you must provide: the report from lesson 5, the signal definition with shift, the Risk Manager spec, failure tests. Without that the programmer will write whatever they want and you will not be able to verify it.

What is a heartbeat and why do I need one? Every 5 minutes the bot sends “alive” to Telegram/a log file. If there is no heartbeat for 15 min -> an alert that the bot has died and you must take manual control. Without it you do not know that the bot is down while in a position.

---