A trading bot is an execution system, not a money machine
A trading bot turns market and account data into actions under predefined rules. It may calculate a signal, check risk, create an order, send it to a venue and reconcile the result. Calling it a bot tells you nothing about whether the strategy makes money or the software is safe.
Many bots do not use AI at all. Ordinary code can run a scheduled rebalance, a price grid or a moving-average rule. AI enters the picture only when a model classifies market state, forecasts an outcome, chooses an action or adapts execution. See AI for trading for that model layer.
A bot's job continues after order submission
Sending an order is the middle of the loop, not the end. The bot must read the authoritative venue or onchain state and update its own records. Otherwise its next decision may rely on a position that never existed—or ignore one that did.
The six pieces a live bot needs
| Component | Job | Typical failure |
|---|---|---|
| Data adapter | Normalizes market, reference and account data | Stale feed, missing events, bad timestamps or units |
| State store | Tracks signals, orders, fills, balances and strategy state | Restart loses context or two workers disagree |
| Strategy engine | Turns current state into a proposed action | Overfit logic, duplicate signal or wrong regime |
| Risk engine | Allows, changes or rejects the proposal | Limits exist only inside strategy code or use stale positions |
| Execution adapter | Translates intent into venue-specific orders | Wrong symbol, precision, order type or retry behavior |
| Reconciliation and monitoring | Compares intended, submitted and actual state | Partial fill, external trade or silent drift remains unseen |
Keeping strategy, risk and execution separate makes the system easier to test. A strategy may propose an action, but an independent policy should decide whether the account, instrument, size and price are allowed. The execution adapter should not silently invent a substitute when the proposal is invalid.
Common bot strategies and their weak points
These labels describe how the bot generates an action. None implies a return, and every one can fail when market structure changes.
| Bot family | Basic rule | What can go wrong |
|---|---|---|
| Scheduled buy or DCA | Buy a fixed amount on a schedule | Insufficient balance, duplicate runs or unsuitable exposure |
| Rebalancing | Trade back toward target portfolio weights | Excess turnover, tax effects or unavailable liquidity |
| Grid | Place buys below and sells above selected price levels | Inventory accumulates during a persistent trend |
| Trend-following | Enter or exit when a trend condition changes | Repeated whipsaws in sideways markets |
| Mean-reversion | Trade an expected return toward a reference level | The relationship breaks and the “temporary” move persists |
| Market-making | Quote both sides while managing inventory | Adverse selection, toxic flow and rapid inventory imbalance |
| Arbitrage | Trade a price difference across related markets | One leg fails, latency removes the spread or transfer is blocked |
| Funding-rate or basis | Combine offsetting exposures to capture a rate or spread | Basis movement, financing, liquidation or venue divergence |
| Signal or copy executor | Translate a third party's action into follower orders | Leader risk, lag, sizing drift and incompatible account state |
Strategy-specific mechanics are covered in futures trading bots, arbitrage bots, funding-rate arbitrage and social trading.
A “buy” signal is only the beginning
A signal such as “buy” is not an executable instruction. The bot needs an instrument, side, maximum size, order type, price protection, time in force, expiry and unique identifier. Derivatives add leverage, margin and reduce-only behavior.
signal → intent → risk decision → order request → acknowledgement → fill or cancel → reconciled position | State | What it proves | What it does not prove |
|---|---|---|
| Intent created | The strategy proposed an action | That the action passed risk checks |
| Order submitted | A request left the bot | That the venue accepted it |
| Acknowledged | The venue recognized an order identifier | That any quantity traded |
| Partially filled | Some quantity executed | That target exposure was reached |
| Filled | The requested order quantity executed | That the strategy's total position is correct |
| Reconciled | Orders, fills and balances agree with authoritative state | That the trade was profitable or suitable |
Order type changes the risk, not just the fill speed
A market order prioritizes immediate execution but does not guarantee the final price. A limit order controls the worst permitted price but may not fill. A stop order changes behavior when a trigger is reached; it does not guarantee execution at the trigger price. Venue definitions and behavior should be checked directly before use.
- Spread: the difference between available buy and sell prices.
- Slippage: the difference between the expected price and actual fill.
- Market impact: price movement caused by the bot's own order.
- Maker/taker treatment: fees can differ depending on whether an order adds or removes liquidity.
- Partial fill: only part of the requested size trades, leaving residual exposure.
- Queue position: a resting limit order may sit behind earlier orders at the same price.
- Funding or financing: holding leveraged or perpetual exposure can create time-dependent cost.
Onchain execution adds network fees, confirmation uncertainty, smart-contract risk, price movement before inclusion and transaction-ordering effects. A quote is not a receipt; the bot needs to verify the transaction and resulting wallet or contract state.
Treat API permissions as financial exposure
A non-custodial exchange bot commonly sends orders through an API key while assets remain in the exchange account. That does not make the integration risk-free. A trading-enabled key can create large exposure even if withdrawals are disabled, and a compromised read-only key can reveal sensitive financial information.
- Create a dedicated credential rather than sharing a password or primary account session.
- Enable only the functions, accounts, venues and assets required by the strategy.
- Leave transfer and withdrawal permission disabled when the bot does not need custody.
- Use a separate account or subaccount to limit exposure and simplify reconciliation where available.
- Store secrets outside source code and logs; rotate and revoke them after suspected exposure.
- Restrict network origin or IP address where the venue supports it.
- Test the independent pause and revocation path before funding the setup.
Measure the result after every cost
Strategy return must include every cost the strategy creates. To keep the accounting clean, measure strategy P&L at documented decision prices, then subtract one execution-shortfall figure. That figure captures the combined effect of crossing the spread, slippage and market impact without counting any of them twice.
Net result = strategy P&L at decision prices − execution shortfall − trading fees − funding − software and infrastructure Example: $350 gross becomes $99 net
Consider a hypothetical $10,000 account whose strategy shows $350 of P&L at its documented decision prices for a month. The result is not 3.5% until the costs are included.
| Item | Amount | Running result |
|---|---|---|
| Strategy P&L at decision prices | +$350 | +$350 |
| Trading fees | −$72 | +$278 |
| Execution shortfall | −$96 | +$182 |
| Funding or financing | −$34 | +$148 |
| Software and infrastructure | −$49 | +$99 |
The hypothetical net result is $99, or 0.99% of the starting account before tax. A different turnover, venue, account tier or market condition changes every cost. The example shows why a gross dashboard and a live account statement can tell different stories.
What a backtest cannot reproduce
| Backtest shortcut | Live reality | Better test |
|---|---|---|
| Use the candle close as signal and fill | The close was known only after the interval and may not be tradable | Separate decision time from later executable prices |
| Assume unlimited fill at one price | Available size, queue and impact constrain execution | Use order-book or conservative slippage assumptions |
| Ignore rejected or missing orders | Precision, balance, margin and API rules cause rejections | Replay venue validation and failure states |
| Use today's asset list | Failed or delisted assets disappear from the sample | Use point-in-time membership and delisting data |
| Choose rules after seeing all results | Repeated search finds patterns that do not persist | Lock rules before an untouched evaluation period |
| Assume continuous uptime | Networks, feeds, workers and venues fail | Test gaps, restarts, delayed data and outages |
Read backtests versus live results for a deeper treatment of evidence states. A backtest can reject a bad idea, but it cannot by itself prove live execution quality.
Earn the right to use live capital
- Component tests: verify symbols, units, rounding, time, indicators and position calculations.
- Historical simulation: test strategy logic with point-in-time data and conservative costs.
- Out-of-sample evaluation: freeze choices and test untouched periods and regimes.
- Venue sandbox: validate authentication, order fields, cancellations and error handling where supported.
- Paper or shadow mode: process live data and record intended orders without capital movement.
- Failure injection: simulate stale data, timeouts, duplicate events, partial fills and restarts.
- Bounded live pilot: use narrow permissions, small capital and hard exposure limits.
- Controlled scaling: increase size only after costs, fills and state reconcile across enough observations.
FINRA calls pre-production testing an essential part of effective algorithmic-trading controls and emphasizes review after a strategy is launched or changed. ESMA's 2026 supervisory briefing likewise focuses on pre-trade controls, governance, testing and outsourcing. These sources apply to regulated firms, but the engineering lesson is useful at smaller scale: automation needs controls before and after deployment.
Recovery logic belongs in the bot from day one
| Failure | Unsafe reaction | Safer recovery pattern |
|---|---|---|
| Stale market data | Continue using the last value | Reject new intents after a freshness limit and alert |
| Order timeout | Submit the same order again immediately | Query authoritative order state using a unique client identifier |
| Partial fill | Assume the full target exists | Recalculate remaining quantity and total exposure |
| Websocket disconnect | Assume no events occurred | Fetch a snapshot and replay from a known sequence |
| Rate limit | Retry every request in a tight loop | Back off, prioritize risk actions and reduce request load |
| Authentication failure | Keep creating unsubmitted intents | Pause execution, protect state and require credential repair |
| Position mismatch | Trust the bot's local database | Treat venue state as authoritative and reconcile before resuming |
| Runaway order rate | Wait for a person to notice | Automatic circuit breaker plus independent kill switch |
| Venue outage | Assume open orders are cancelled | Enter a documented safe state and verify when access returns |
Retrying an order is itself a trading decision. If the venue accepted the first request but its response was lost, a blind retry can double the position. Stable client identifiers and post-timeout state checks reduce that risk, but the implementation must match the venue's API contract.
The dashboard should answer operational questions
- Is market and account data fresh, complete and synchronized?
- What positions, open orders, margin and available balances exist now?
- Which strategy intents were allowed, resized or rejected—and why?
- Which orders are acknowledged, partially filled, cancelled, rejected or uncertain?
- What fees, funding, spread and slippage has the bot actually incurred?
- Is live behavior inside the validated ranges for turnover, exposure and drawdown?
- Can an operator pause new risk and revoke authority independently of the bot?
Alerting should distinguish urgency. A stale dashboard is not the same as an unknown live position. The latter may require an immediate safe state and human response. Keep enough records to reconstruct the sequence from input and intent through policy, request, venue response, fill and final balance.
“Does it work?” hides two separate questions
A bot “works” operationally when it executes its specified rules and handles failures correctly. A strategy works economically only when its live, net, risk-adjusted outcome meets a predefined objective. Those are separate claims. Reliable automation can faithfully execute an unprofitable idea, while a profitable period can hide unsafe software.
Market conditions also change. A grid can appear stable until a prolonged trend builds unwanted inventory. Arbitrage can disappear as competitors react. A trend model can suffer repeated reversals. Evaluate by regime and retain a rule for reducing or stopping the bot when live behavior leaves the validated range.
For a first bot, boring is a virtue
A sensible first bot is boring: one understandable rule, no withdrawal permission, a small account, conservative sizing, no leverage, visible logs and an independently tested stop. Run it in paper or shadow mode first so you can see how intended orders and actual fills diverge.
- Be able to explain the rule without referring to a profit chart.
- Know the maximum amount the bot can lose or expose under its hard limits.
- Understand every credential and how to revoke it.
- Confirm how the bot behaves during a restart and an unavailable venue.
- Review actual account statements rather than only the bot dashboard.
- Never use money needed for living expenses or obligations.
If you are comparing packaged products, use the AI trading app framework. If a system can choose tools and alter a plan across multiple steps, read AI trading agents. For the wider operational and governance view, continue to automated trading systems.
Sources and scope
- CFTC — AI Won’t Turn Trading Bots into Money Machines
- FINRA — Algorithmic Trading: Supervision and Control Practices
- SEC — Market Access Risk-Management Control FAQ
- ESMA — Supervisory Briefing on Algorithmic Trading
- Investor.gov — Artificial Intelligence and Investment Fraud
- Onchain Off Emotion risk disclosure
The system diagram and rollout steps are a starting point, not proof that a bot is safe. Live requirements depend on the venue, instruments, account permissions and local rules.