AI trading bot: where automated trading breaks in the live market
An AI trading bot shows steady returns on a test period, but in the live market the first thing that breaks is not the forecast, but execution.
The model can be strong, but if the bot loses connection to the exchange at the moment of a signal, sends an order twice, or gets filled at a price that is already gone, the result diverges from the calculation by multiples. We break down where automated trading breaks and how it is addressed.
The first bottleneck is connection loss with the exchange. The interface responds with a delay, the connection reconnects, and the order state at that moment is unknown: whether it went through or not.
A bot without reconciliation of actual positions against the trade log repeats the order and gets double volume where it planned single.
A wrapper over exchange interfaces CCXT provides a unified way to read positions and orders, but the reconciliation algorithm for each scenario is written separately.
The second is order slippage. The signal is calculated at one price, execution comes at another: on liquid pairs the difference is fractions of a percent, on illiquid pairs it is many times greater, and the entire calculated profitability of the strategy goes into that gap.
It is treated with limit orders with price tolerance, volume splitting, and a price deviation limit: if the price moves further, the trade does not open at all.
The third is the lack of drawdown control at the bot level. A risk limit per trade does not help when a losing streak and a stuck position add up in one day.
An independent layer is needed: a drawdown limit per day and per period, an auto-stop when it is reached, and bringing the portfolio to a safe state without human involvement.
None of these failures is visible in history — they appear only in the real market. Next we break down how each of them is addressed.
Reaction speed, discipline, and risk control in trading
Manual trading rests on three things: speed, discipline, and risk size per trade. While the trader sees a signal, checks the order book, and confirms entry, the price moves away along with part of the expected profit.
Then emotions kick in: after a losing streak, the rule "no more than N% per trade" imperceptibly turns into "I'll add to win it back."
A bot removes both problems at once. A signal from the model turns into an order in seconds, while limits per trade, daily drawdown, and number of positions are written in code and do not depend on mood.
Execution goes through CCXT — a unified access layer to exchanges, so the same strategy works on multiple venues without rewriting the logic.
| Parameter | Manually | With a bot |
|---|---|---|
| Reaction to signal | seconds to minutes, depends on availability | seconds, without misses |
| Entry rules | drift after a losing streak | fixed in the strategy code |
| Risk per trade | "by eye", revised under pressure | limit per trade, day, number of positions |
| Overnight positions | depend on who is awake | works without an operator |
| Trade review | manual exports, some are lost | order and signal log |
Risk is calculated separately: position size and stop levels are derived from current capital, so after a drawdown the volume of the next trade decreases automatically.
In sum, this means the same strategy behavior at any volume, predictable drawdown, and a log that shows where the rule worked and where the model erred.
Bot deployment options: cloud, own server, hybrid
Where the trading core lives determines latency to the venue, availability during volatility, and how quickly you roll back a failed release. The forecasting part is sensitive to memory for model inference and to the retraining schedule, not to tick reaction speed.
Therefore bot placement and the exchange connection method are chosen together: the launch scheme also defines the fault-tolerance architecture.
Below are three schemes actually chosen at the start and during scaling.
| Option | When it fits | Limitations |
|---|---|---|
| Cloud deployment | quick start, small turnover, infrequent retraining | dependence on the provider, network latency to venues, restrictions on long-running computations |
| Own infrastructure | sensitivity to latency, requirements for data storage and access | updates, monitoring, and fault tolerance remain on you |
| Hybrid | trading core near the venue, trade history and training in the cloud | two environments, need shared configuration and end-to-end monitoring |
Exchange connectivity is handled with a unified connector on CCXT: one interface to dozens of venues for orders, balances, and trade history.
Adding a new exchange is a configuration edit, not a rewrite of the trading core, so diversification across venues does not turn into a separate project. Keys are kept in secrets with separate permissions: trading without withdrawal rights, limits on volume and request rate.
Work stages: strategy audit, scheme, setup, verification
The order of stages is kept strict: until the strategy rules are reduced to formal conditions, neither the integration scheme nor the bot setup will produce a predictable result.
An error missed at any step surfaces on the live account, so each stage closes with a verifiable artifact.
- Strategy audit: analyze entry and exit rules, working timeframes, allowable drawdown, and position limits — translate them into unambiguous conditions that code executes without interpretation.
- Integration scheme: market data source, exchange communication module, storage of access keys, and separation of test and live environments.
- Data preparation: clean history, restore gaps, account for commissions and slippage — without this the forecast looks better than trading.
- Bot setup: signal calculation, risk manager, order executor, trade log — each module is checked separately.
- Verification on the test environment: first a run on historical data, then a demo account with a real quote stream.
- Failure testing: connection loss, rejected order, sharp price jump — see how the bot closes positions and restores connection.
- Handover to management: dashboard with open positions, failure alerts, manual stop procedure.
At the output — a working AI trading bot and a clear procedure in case the market behaves abnormally.
Configurations, integration schemes, and regulations at handover
The bot is handed over together with a kit for maintaining it, checking it, and transferring it to another team. Below is the delivery scope by area: configuration, integration scheme, key access policies, and update procedures.
- Bot configuration — files with the list of trading pairs, position volume limits, forecast trigger thresholds, and risk mode. Edits are made without code changes.
- Integration scheme — diagram of interaction with trading venues, market data source, history storage, forecast module, and order execution layer, with failure points marked.
- Key access policies — permission separation by venue, trading rights without withdrawal, key rotation, secure storage, and access log.
- Model documentation — what input features are used, how the forecast is calculated, by what metrics quality is assessed, and when retraining starts.
- Update and rollback procedure — configuration and model version snapshots, procedure for moving to a new branch and returning to the previous parameter set.
- Monitoring tools — latency to venue metrics, share of rejected orders, forecast vs actual discrepancy, and working chat alerts.
The kit is assembled during the work, not at the end: configuration and policies are fixed before the first trades, the integration scheme is refined when connecting a second venue, and the update procedure is tested on a training rollback.
Case: portfolio on four exchanges — metrics before and after
How the portfolio was managed manually
A portfolio on four exchanges was managed by one trader: consolidated order books manually, monitored price discrepancies between venues, and placed order pairs himself. At night and during sharp moves signals were lost — according to the log, misses reached up to a third.
Some orders went out with an error in volume or at a price that managed to move in the seconds between decision and entry; reviewing such trades and reconciling balances took hours every week.
What was changed and what the metrics showed
Execution was moved to a unified exchange access layer on CCXT instead of four disparate sets of scripts. The forecast model calculates the probability of movement and works as a filter: a signal goes to execution only if the model, risk limits, and liquidity check align.
Orders are idempotent by their own identifier, and after a connection loss the bot reconciles actual positions with expected ones and brings them to target.
Two manual actions remained: adjusting limits and reviewing the weekly report. The trader stopped being a bottleneck — the portfolio works during night hours and on all four venues simultaneously.
What to do if a classic trading bot is already deployed?
Yes, there is no need to rewrite the bot from scratch — the forecast model is embedded into an already working environment. The rules remain the execution layer: they maintain the connection with the exchange, calculate the position, and comply with risk limits.
The model is added as a separate module and answers only one question — is it worth entering a trade right now at all.
The separation is clean: the model outputs the probability of movement based on a set of features — volatility, market regime, volume behavior — and the rules translate it into position size, stop, and entry moment. Such an environment is easier to debug.
If the forecast is wrong, it is immediately visible at which layer: features, the model itself, or order execution.
You already have the data for training — the bot's own logs of signals and trades. From them, the history of decisions is reconstructed and market series for the same period are attached.
The key condition: features are calculated by the same code as in real trading, otherwise the model trains on one distribution but sees another, and historical quality does not transfer to the live account.
Rollout proceeds in stages, without stopping trading. First shadow mode: the model calculates forecasts and writes them next to the rule decisions, while the bot trades as usual.
When accumulated statistics are enough to compare accuracy under the same conditions, the share of capital under the model is increased gradually — from a small part to full. Reverse switching to the rules is done with one setting.
Thus upgrading an existing bot does not turn into a leap: the old logic remains insurance until the new one proves quality on your data and your market regime.
Technical doubts: latency, risk, failures, access
Before launch, the client asks the same engineering questions: what happens if the channel to the exchange breaks, can the model forecast be trusted, what rights does the bot get on the account, and how does it behave on failure. Below are short answers for each point.
The general principle is one: any abnormal state puts the bot into conservative mode — stopping new entries and reducing positions according to strategy rules, rather than trying to "force" a trade.
What happens if connection to the exchange is lost?
The channel is monitored by response time and error rate. If the connection drops, the bot does not send new orders, and after restoration it reconciles the actual account state with internal accounting. The discrepancy is recorded in the log and closed by repeat reconciliation. Orders sent before the break are tracked by identifiers — no lost positions remain.
How reliable is the model forecast?
The model gives a probability estimate, not a guarantee. Quality is checked on historical data without lookahead, and separately on a period the model has not seen. In real trading, a position size limit and a mandatory protective order work on top of the signal. If signal quality falls below the threshold, the bot reduces volume or stops trading.
What rights does the bot need on the exchange?
Only trading keys, without withdrawal rights. Funds remain on the client's exchange account, and the bot physically cannot withdraw them. Keys are stored in secure storage with restricted access. Revoking the key instantly deprives the bot of access and does not affect fund withdrawal.
How does the bot behave on failure?
Several independent limits work: daily loss limit, limit on the number of trades, and a manual "kill switch" to stop trading. When any of them triggers, positions are closed according to strategy rules, and the bot goes into waiting mode until operator confirmation. Every action is written to the log with time and reason — incident review takes minutes.
Let's discuss the strategy and come back with an assessment and plan
To make the assessment based on data, not feelings, a few inputs are enough to start. Then we analyze the logic of entries and exits, run it on historical data, and only after that state the scope of work and timelines.
What to send so we can start calculating:
- strategy rules: entry and exit conditions, working timeframe, list of instruments;
- venues and account types where the bot should work;
- current code, if any: repository or archive, configs, logs of recent runs;
- how risks are calculated now: position size, drawdown limits, stop conditions;
- requirements for the forecast model: horizon, feature set, allowable signal latency;
- infrastructure constraints: where the bot will run, whether there is access to servers and keys with trading rights without withdrawal.
In response you get a module interaction scheme (data collection via CCXT, feature calculation, forecast, order execution), scope of work by stages, an implementation plan with control points, and a timeline estimate.
If on history the stated rules do not produce a stable result, we will say so directly and suggest adjusting the logic, not fitting the report to expectations.
Describe the task — we'll come back with an assessment and plan.
