Why an AI trading bot fails on commodity markets
Automated commodity trading inherits assumptions of a liquid futures market: continuous order book, instant execution, available price for any maturity.
On commodity venues these assumptions do not hold — and an AI trading bot tuned on a long history makes mistakes where the strategy logic itself is still correct.
The first failure point is session boundaries.
The overnight session and opening auction on CME Group assemble the opening price from orders that are not visible in the daytime order book: between the close and the start, the quote passes through levels in one move, and protective orders execute at a price that did not exist at the time of risk calculation.
The second is thin liquidity of far-dated contracts. Their spread is several times wider, volume at best prices is measured in single lots, and an order larger than the threshold moves the market against itself.
Order execution failures here are not an emergency but standard mode: partial fills, cancellations, remainders hanging until the end of the session — a position assembled in parts no longer matches the calculated risk.
The third and most costly is manual intervention in the strategy. An operator cancels an order or reverses a position "as the situation dictates," the bot loses the current account state and continues to calculate risk from an outdated model. What breaks is not the algorithm but the control loop — let's examine how this is closed.
What managed commodity trading automation provides
An AI trading bot removes routine from the trader, but the value is not only in that: decisions are made based on quotes, not on a schedule, so the speed of reaction to price movement is within seconds.
In commodity contracts, where price moves on supply news, this gap with a manual terminal determines whether an order gets into liquidity or remains aside.
Speed brings a second thing — the share of manual errors falls. Lot sizing, direction, and order type go through one check before sending, so a mixed-up contract or duplicate order is cut off in the queue, not surfacing at the end of the session during trade reconciliation.
Unified portfolio risk control calculates the aggregate position, not each instrument separately.
The limit for a group of related contracts, margin requirements, and maximum drawdown per session are checked before each order; when the limit is exhausted, the strategy switches to close-only mode.
In volatile sessions, execution predictability is more important than a nice return curve. Retry on exchange rejection, response delay, connection loss, and partial fill are handled by one scenario — and failures related to operator actions do not arise as a class.
We reconcile the quote source with the exchange: data on CME Group commodity contracts is pulled in the same scheme as internal reference data, so a discrepancy is visible immediately, not discovered when recalculating positions.
Operating modes of trading algorithms: what to choose
An operating mode is not "the degree of automation in general," but the boundaries within which the algorithm makes decisions itself.
Signal mode leaves the choice to the trader, semi-automatic execution gives the machine the calculation of volume, price, and timing, fully automatic mode removes confirmation, and the validation loop does not place orders at all.
The choice is determined by contract liquidity, the cost of error, and the maturity of the strategy's statistics. Below are the modes chosen between in practice.
| Mode | When suitable | Limitations |
|---|---|---|
| Signal | New instrument, tuning entry thresholds, decision remains with a human | Delay between signal and trade, manual entry and position accounting, discrepancy between actual price and calculated |
| Semi-automatic | Strategy tested, but control is needed for non-standard events; the risk loop calculates volume and places a stop order | Depends on availability of confirmation and communication channel; some signals are lost during sharp moves |
| Fully automatic | Liquid contracts, stable statistics, drawdown and limit control present | Requires monitoring, alerts, and fast version rollback; error is replicated across the entire volume |
| Validation loop (strategy testing on historical data) | Before changing logic or parameters, when launching on a new contract | History does not reproduce slippage and liquidity gaps; risk of overfitting to the past |
A common limitation across all modes is the same: exchange position limits, trading halts, and market data quality. Therefore we design switching as a configuration flag, not a code rewrite — returning to the previous mode takes minutes.
How we implement a trading loop: stages of work
We start not with code but with an audit: if in the current trading and accounting scheme decisions are made blindly, automation will only cement these errors with greater speed.
Therefore each stage ends with an artifact that can be verified on real data, not a verbal description.
- Audit of the trading and accounting scheme — we examine how orders are formed, where positions are accounted for, and how trades are reconciled; we record discrepancies between the trading journal and the accounting system.
- Design of the trading loop — we describe entry and exit logic, position recalculation rules, failure points, and system behavior during connection loss.
- Connection to the broker and data source — we configure channels for receiving quotes and sending orders, agree on delays, formats, and the trade confirmation procedure.
- Risk limit setup — we set the maximum position size, loss limit per trading day, limit on the number of orders per unit time, and automatic stop rules.
- Run on historical data and in the test loop — we compare AI trading bot behavior with actual trades, look for discrepancies in accounting and at market boundaries.
- Acceptance testing and handover — we run failure scenarios, check recovery after restart, and hand over configuration, logs, and the support procedure.
Implementation artifacts: procedures, diagrams, and access
After implementation, the team has not only a working loop but also a set of documents by which the system is operated, handed to a new engineer, and presented to auditors.
Without it, only one person knows the bot's behavior, and changing a parameter turns into an experiment on a live account.
- Risk control procedure — limits on position, instrument, and daily loss, automatic stop conditions, manual intervention procedure, and levels where a human makes the decision.
- Broker integration diagram — which channels carry quotes and orders, which confirmation is considered final, where the failure point is, and how they switch to a backup route.
- Access policies and roles — who changes strategy parameters, who sees only reporting, how rights are granted and revoked when an employee changes.
- Trade and event log — what is recorded for each order, with what detail, and how to restore the full chronology of a specific trade review.
- Incident instructions — signs of failure, emergency stop procedure, position recovery steps, and the person responsible for each action.
- Strategy configuration description — which parameter is responsible for what, what may be changed on the fly, and what requires a run in the test loop.
- Change deployment procedure — the path from an edit in the test environment to admission into the production loop with a rollback point to the previous version.
The set lives with the system: edits to the procedure and policies are made in the same order as code changes, and recorded in the log — during incident review it is visible which version of the rules was in effect at the time of the trade.
Case study: trading loop on a portfolio of commodity assets
Portfolio: energy and industrial metals futures plus spot positions — order entry was spread across several loops on the CME Group venue.
Each order confirmation went through a trader: about a hundred manual operations per session, and a delay in confirmation shifted entry relative to the calculated price.
Worse was connection loss: the channel dropped, open positions were left unattended, and recovery took seven to twelve minutes.
We moved execution into a managed loop. Each order received its own identifier and a record in the local state log — resending after a dropout does not create a duplicate.
Position reconciliation with the broker report runs on a schedule; a discrepancy raises a flag and stops the placement of new orders until review. Manual confirmation remained only for trades above the risk limit.
What changed in the metrics
| Metric | Before | After |
|---|---|---|
| Share of operations with manual confirmation | 100% | ~12% (only exceeding the limit) |
| Recovery after connection loss | 7–12 minutes | up to 40 seconds |
| Disputed executions per session | 6–8 | 0–1 |
Execution stability increased because the loop places orders at the calculated price, not at the one that had time to move while the trader pressed the button.
The deviation of the actual entry price from the calculated one decreased almost threefold, and review of disputed executions stopped being a separate task every evening.
How an AI trading bot differs from a signal advisor
The difference begins where the signal ends. A signal advisor analyzes the market and proposes a trade: direction, entry benchmark, protective order. Then a human decides — send the order or skip. The algorithm's area of responsibility ends here.
The bot is responsible for the entire trade lifecycle: it receives market data, calculates parameters, and places the order itself. Before sending, it checks it against limits — position size per instrument, total portfolio exposure, allowable price deviation.
If the threshold is breached in at least one of them, the order does not go out, and a log entry with the rejection reason is recorded.
Partial fills are separate work. In commodity markets, volume is almost never filled with one order: part fills immediately, the remainder hangs in the order book.
The bot decides what to do with the remainder — fill at the current price, move the limit closer, or cancel the remainder if it is not filled within the allotted time — and keeps the position state consistent.
The one with access to execution and data is responsible for the result. An advisor will not explain why a signal was not acted on, while the bot keeps a log: what quotes came, what rules triggered, what orders went out, and with what result. This makes behavior reproducible and review of disputed trades substantive.
The boundary is simple: a signal provider sells opinion, a bot sells execution. If the task has limits, partial fills, and exchange rejections, it is no longer an advisor.
Technical doubts before launching a trading loop
Before launching a trading loop, clients ask the same questions — about connection losses, risk limits, strategy updates, and integration with the accounting system. Below are short answers; we discuss the details based on your trading rules and data.
Connection to the exchange lost — what about open positions?
The loop monitors channel quality and enters a protective mode on connection loss: new orders are not placed, open positions remain under risk rule management.
After recovery, the connection is re-established, position state is reconciled with the exchange — no accounting discrepancies remain.
How are risk limits set per trade and per day?
Limits live in configuration, not in strategy code. When the daily limit is exhausted, new entries are blocked, management of already open positions continues — the loop doesn't abandon them or wait for manual intervention.
Can strategy be updated without stopping trading?
Yes: a new version is run on historical data and enabled; open positions are managed by previous rules. Each version and its parameters are recorded in version control — a trade shows what rules accompanied it, and there is a rollback point.
How does the loop integrate with the existing accounting system?
Through its standard interfaces: trades, commissions, and positions go into the same loop as other operations. Double entry and discrepancies between trading and management reporting don't appear.
Let's discuss your trading automation task
The accuracy of an AI trading bot assessment depends on what is known about your portfolio and trading infrastructure.
We conduct the first conversation not as a presentation but as a task review: what instruments you trade, where trades are executed, what data you have, and what you expect from automation.
- Portfolio composition and markets: commodity groups, spot or futures market, trading sessions, and strategy time zones.
- Data: for what period quote and trade history is available, whether order book depth is needed, and in what form the series are available now.
- Access: test and production account, rights to place orders, position limits, and risk management rules.
- Decision rules: what the bot does itself and what goes to human confirmation; how you calculate the target result — return, drawdown, share of profitable trades.
- Constraints: trading and clearing mode, corporate events, compliance and reporting requirements.
- What we return: a stage-by-stage implementation plan — data preparation, hypothesis testing environment, risk loop, launch with monitoring and trade log.
- Timeline and scope estimate: breakdown by stages with a note on which dependencies remain on your side.
Next steps: describe the task, send what you have on the portfolio and data; we review it with engineers and return with a timeline estimate and work plan. If source data is insufficient, we'll say directly what needs to be collected before the start.
