AI trading bot: where trade execution breaks
The signal is there, but the trade goes to the wrong place or at the wrong time. The model confidently produces an entry point, but the order is executed at a price that is no longer in the order book — this is how price slippage arises, eating into the strategy's estimated edge. A few such executions per session, and the statistics stop matching the backtest.
Worse is when the connection to the broker breaks. The terminal shows a connection, the quote feed lags by seconds, and the sent order remains unanswered — in the log it is active, but the broker does not have it.
This is a stuck order: the bot considers the position open, a repeated signal opens a second one, and instead of one trade the account ends up with a double position at different entry prices.
Then manual intervention in trading begins. An engineer or trader manually reconciles the order table with the transaction log, cancels extra orders and adjusts the position — during volatility, when the price moves quickly.
An hour of troubleshooting kills not only the day's result but also trust in the strategy: it is unclear where the model error is and where the consequences of an execution failure are.
A separate problem is accounting divergence. The position in the terminal and the position in the strategy log live separately, so returns are calculated from data that was not present in the account.
Such an AI trading bot can be neither scaled nor moved to multiple instruments: every failure has to be closed manually.
The root is usually not in the model, but in the layer between the signal and the broker: there is no trade confirmation, no order idempotency, no account state control during reconnection. We explain how this is addressed.
What trading automation delivers: the effect in metrics
The trading cycle breaks down into measurable segments: from an event — a level breakout, a change in the order queue, a report release — to a placed order. For a human this takes several seconds, and almost always they are watching more than one instrument.
The bot in QUIK goes through the same path in fractions of a second and does not get distracted: reaction speed to an event stops depending on how many positions are being monitored simultaneously.
The second cut is the share of manual operations. Trading automation takes over the rules: moving protective orders, position maintenance, time-based closing, bringing shares back to targets when they deviate.
The log shows what portion of actions were performed without manual involvement, and this number is a direct indicator of process maturity. What remains with the human is where a decision is needed: a non-standard situation, logic adjustment, incident investigation.
The third effect is a whole class of failures that disappears. A missed order due to distraction, a forgotten stop, a double click with doubled volume, a price error — these are not 'human factor in general' but specific failures that a rule eliminates.
Added to this is resilience to infrastructure failures: logging of every step, position reconciliation with the terminal, retry when there is no response, correct restart without duplicate orders.
Hence the fourth metric — the cost of process downtime. As long as trading relies on a single workstation, unavailability of the terminal or the channel to the broker means missed events and position mismatch, which is then sorted out manually.
Separated roles, state control and automatic logic recovery reduce this window to minutes, and position reconciliation removes discrepancies before they become a loss. All four metrics describe execution discipline, not promised returns — we do not forecast those.
Ways to connect trading logic: comparison of options
The modes of connecting trading logic determine where the strategy lives and how much time passes between a market event and an order. Below are three schemes that are actually chosen between when integrating with a trading terminal, and their connection limitations.
| Option | When it fits | Limitations |
|---|---|---|
| Direct integration with the terminal | Reaction is needed within seconds, the logic is compact, external data is not required | The logic lives in the same process as the terminal: restarting or updating the platform stops the bot. There is nowhere to scale computation or connect new data sources |
| Intermediate service | Model computation, trade history, multiple accounts, external data | A network hop and latency appear. Control of position desynchronization between the service and the account is required, along with monitoring of both circuits |
| Delayed launch | The strategy is not sensitive to seconds: signals on interval close, historical testing, going live after tests | An event inside the interval cannot be processed — arbitrage and news spikes are cut off. Some scenarios are simply not feasible |
The schemes are often combined: computation and history storage are moved to an intermediate service, orders are sent via direct integration with QUIK, and delayed mode is left for position reconciliation.
Connection limitations are affected not only by latency but also by venue rules: limits on order frequency, requirements for logging the bot's actions, and behavior during a connection break.
Implementation order: from strategy audit to handover
We start not with code but with a strategy audit: the implementation stages are arranged so that by the first real order both the signal logic and risk boundaries have been checked. Below is the order in which the project proceeds and by which it is clear what step we are at.
- Strategy and risk boundary audit. We examine what data the signal is built on, where the logic loses robustness, and what limits on position, drawdown and trade frequency we consider acceptable.
- Flow and failure point diagram. We establish where quotes come from, where the decision is calculated, and how the order reaches the QUIK trading terminal via QLUA — including system behavior during a connection break.
- Test environment assembly. An isolated copy of the working environment: the same order routing and the same limits, but without a real account — mistakes here cost nothing.
- Historical data validation. A run across several market regimes — trend, range, sharp moves; we look at drawdown, the share of rejected orders, and divergence from the calculation model.
- Limits and safeguards. Emergency stop on daily loss, limit on the number of trades, blocking on data desynchronization, a log for every bot decision.
- Handover to operation. Start and stop procedures, monitoring and alerts, access separation, instructions for the on-duty engineer.
- Support. Adjustments after volatility changes, incident analysis, review of checks before each limit expansion.
What remains with the client: configurations, diagrams, procedures
The package is handed over not as an archive 'for memory' but as a working set that your team can use to operate the bot and change its behavior without us. Below is exactly what is handed over and why each part is needed.
- Configuration files — instrument list, risk limits, trading session schedule, signal trigger thresholds. They are edited without a rebuild: you can change a limit or disable an instrument as part of normal operations.
- Integration diagram — how the bot is connected to the terminal via QLua, what events and tables it reads, where the failure points are, and how it behaves during a connection break, terminal freeze or restart.
- Access rules and limits — role separation, key issuance and revocation procedure, maximum position per instrument and daily stop. Removing a limit requires a second confirmation, not a single action.
- Operations log — every bot decision with its rationale: entry, exit, size, rejected signals. Export for any period — to investigate disputed trades based on facts, not memory.
- Incident procedure — failure levels, who responds and within what time, when trading is stopped manually, and how the investigation result is recorded.
- Stop and recovery instructions — the correct scenario for taking the bot out of trading, checks before return, and rollback to the previous working configuration.
- Change procedure — how new rules are handed over, how they are tested on history and versioned, so changes do not overwrite each other.
We go through all of this with your team during handover: we show what is where and answer operational questions.
Practice: how execution losses on orders were eliminated
We worked with the QUIK brokerage terminal: the robot placed orders, and actual execution was reconciled with the calculation manually, after the shift had already closed.
Implementation proceeded under load, without stopping trading, and the very first sessions during rising volatility showed where the circuit loses controllability.
Discrepancies between the calculated and actual price accumulated, some sessions remained unclosed until morning, and the on-duty engineer noticed a connection break with the broker from the logs when the position was already left hanging open.
| Metric | Before | After |
|---|---|---|
| Share of orders with price discrepancy | 0.7% | 0.04% |
| Unclosed sessions per week | 11 | 0 |
| Recovery after connection break | 35–40 minutes manually | 80–100 seconds automatically |
| Position reconciliation with broker | once a day, manually | every 5 seconds, automatically |
What was changed
The order flow was made idempotent: each order has its own identifier, a retry after a break does not create a duplicate but returns the status of the already sent order.
Risk control was moved inside the loop — the limit is checked before sending, not after, and if the deviation goes beyond the boundary the robot cancels the order itself.
A separate watchdog process monitors connection liveness: during a break the circuit goes into safe mode, new orders are not sent, open positions are recorded at the last confirmed price. Position reconciliation was moved from manual daily to automatic, with a log of every discrepancy.
The share of execution failures decreased by a factor of 17, there are no more unclosed sessions, and recovery takes less than two minutes without involvement of the on-duty engineer.
Technical concerns before starting: briefly to the point
The bot works through a trading terminal, not through direct connections to the exchange — this removes most of the questions about access, limits and control.
Below are the things usually clarified before starting: what rights the bot receives, what happens during a connection break, and how to test the logic without risking the live account.
What rights does the bot receive and can risk be limited?
Rights only to place and cancel orders within the allocated account — withdrawal of funds is technically unavailable. Risk limitation is set in the configuration: maximum position size, number of active orders, daily drawdown stop. When any of the limits triggers, the strategy stops rather than continuing to average down.
What happens during a connection break with the terminal?
The state of positions and open orders is written to disk after every operation, so after a restart the bot restores the account picture and continues from the current point, not from scratch.
If the break occurred at the moment an order was placed, when the connection returns reconciliation with the actual account state takes place, and discrepancies are closed forcibly.
How is the logic tested before the live account and who refines it?
First a run on historical data, then a test launch on a demo account with the same limits and parameters, and only after the results match — a live account with minimum volume.
Code and configurations are handed over in full, without closed modules; we handle logic refinement as part of support, and every change goes through the same testing cycle.
Let's discuss the task: what to send for an accurate estimate
The more accurate the input data, the fewer assumptions in the project estimate — and the lower the chance that timelines will have to be revised mid-work. It is enough to send everything in text, without a formal technical specification and without closed access at this stage.
- A description of the strategy in words: what signals, on which instruments, what is considered entry and exit, how the system behaves when data is absent.
- List of instruments and trading mode — derivatives market, stock market, evening session — to estimate the scope of checks and depth of history for tests.
- Risk and limit requirements: maximum position per instrument, daily drawdown stop, behavior during a connection break with the terminal.
- Access to the QUIK test environment with QLUA and confirmation that the required instruments are available on it.
- Examples of trading system and robot logs: several days of records in their original form — they show what the order and error flow actually looks like.
- Where the bot runs: the same computer with the terminal or a separate server, who stops it manually during a failure and how.
Then we review what was sent, clarify disputed points and come back with an estimate and work plan: stages, what we check in the test environment, what we consider acceptance.
If some data has not been collected yet — come with what you have, and we will clarify the rest with questions.
What to do if a trading bot is already deployed?
A deployed trading bot is a working asset, and intervention changes its behavior in the moment. So the question is not whether to rewrite the system, but how much change it can withstand without stopping trading.
Below we examine three scenarios: an audit with targeted refinement, moving logic into a separate layer, and migration to another platform.
A trading logic audit begins with reconstructing the actual strategy from code and trade logs: what conditions open a position, how partial fills are handled, what happens during a connection break, whether the bot can place a duplicate order.
Then a historical run and reconciliation of signals with what actually went to the broker — discrepancies are usually the source of drawdowns. The output is a risk map and a list of changes with an estimate of scope.
If the logic is generally working, refining the existing bot is cheaper: we change only the entry, position sizing and protective stop modules, and leave the rest of the circuit untouched.
More robust is to move decision-making into a separate layer that communicates with QUIK through a thin adapter. The trading circuit remains the same, the new logic is tested in parallel and enabled with a switch, and rollback takes seconds.
Migration to a new platform is justified when the current one is constrained by instrument or response speed limits. The risk here is one: the behavior must be replicated down to the last condition.
Therefore both circuits calculate signals in parallel on the same market, discrepancies are investigated, and only then is trading moved to the new one.
Support after changes — strategy versioning, connection and limit control, update procedure and incident investigation from logs. Then the next change does not turn into a rewrite from scratch.
