Why a futures trading bot loses profit in the real market
A futures trading bot shows a smooth curve on test history but goes negative in the real market.
The reason is usually not the entry logic but execution: the delay between signal and order placement, price slippage, and failures during volatility eat up the profit that the model calculated.
Each of these causes has a measurable cost. A signal calculated from an outdated order book snapshot arrives when the price has already moved, and a market order fills volume at worse levels — in a thin order book, price slippage exceeds the expected trade income.
A futures trading bot that evaluates entry by the last trade price rather than book depth systematically enters at a higher price than expected.
Bot failure during volatility is a separate class of losses.
Loss of connection to the exchange, process restart, or rejected order at a moment of sharp movement leave the position unattended: the protective order is not moved, the add-on does not trigger, and leverage turns a short pause into liquidation.
Recovery after such an event is described in advance — by reconciling positions and re-placing protective orders.
And finally, the lack of position limits. Without limits on position size, number of simultaneous entries, and daily drawdown, a single strategy failure turns into a series.
Automation of futures trading relies on risk limited at account, instrument, and strategy level, not only on signal logic.
We analyze how this is closed: synchronization with the order book, execution quality control, resilience to connection loss, and strict risk limits.
What changes after implementation: reaction speed and risk control
Implementation changes not the "average return" but manageability: order execution speed, risk control in trading, and system behavior during failure become measurable values rather than a matter of faith in the strategy.
Previously, the bottleneck was the path from signal to order — while the value was recalculated and confirmed manually, some entries were missed, and the price had time to shift.
| Metric | Before | After | Confirmed by |
|---|---|---|---|
| Path from signal to order | tenths of a second, with manual confirmation | fractions of a second, consistently | event log with timestamps |
| Missed entries | depend on operator workload | only by strategy filter | reconciliation of signals and actual trades |
| Recovery after failure | manual position reconciliation, trading halted | auto-reconciliation with exchange in seconds | restart protocol |
| Position limits | check before trade, sometimes retroactively | calculation before order submission | risk module decision log |
Position limits are built into the order path: risk calculation happens before submission, so a whole class of failures disappears — when the position is already open and an excess by instrument or portfolio is discovered after the fact.
The order and state log is stored in PostgreSQL, so after a restart the bot restores the picture and reconciles it with the exchange rather than starting from scratch.
The resilience of a trading system is tested not on a lucky week but on connection loss: an event queue, retry requests, and protection against duplicate orders provide predictable behavior instead of manual position sorting.
Operating modes: signal, semi-automatic, full automation
The operating mode determines who presses the button — the bot or the person.
A signal bot calculates and sends a notification, while execution remains with you; a semi-automatic bot proposes a trade and waits for confirmation; a fully automatic bot goes through the cycle from calculation to position closing without human involvement.
Hence the difference in control requirements and the different scope of permissions when connecting to an exchange.
The choice depends on how much time you are willing to spend at the screen and how well-tuned the strategy is. While the logic is being tested, narrow access is safer; when behavior is predictable, automation removes the delay between signal and trade entry.
| Mode | When it fits | Restrictions and control |
|---|---|---|
| Signal bot | Strategy testing, manual position management, working on several venues at once | Exchange access is not needed at all or is given read-only; the result depends on discipline and reaction speed |
| Semi-automatic | Strategy works, but control is needed at trade entry | Confirmation for each order is required; a key with trading rights but no withdrawal; execution delay is possible |
| Full automation | Well-tuned rules, market works around the clock, many trades | Trading keys with reduced permissions, position size limits, protection against a series of losses, and stop on connection loss are needed |
Switching between modes is designed in at the design stage, so the transition from signals to automation does not require rewriting the logic from scratch.
Work stages: from strategy audit to handover to operation
Work proceeds sequentially: until the entry and exit logic is fixed in words and a diagram, the code reproduces not the strategy but a set of assumptions. Therefore each stage is closed with an artifact that shows whether it is possible to move on.
- Trading strategy audit. We analyze entry and exit conditions, leverage handling, stop-order logic, and position maintenance. The output is a formalized description of the rules, with no ambiguities like "enter on a pullback."
- Bot architecture design. We determine how the market data module connects to the decision and order placement module, where position state is stored, and how the bot behaves when the connection to the exchange is lost.
- Connection setup. Keys with trading-only rights, rate limits, a separate withdrawal procedure — so that a failure or key leak does not give access to the balance.
- Testing on historical data. We run the rules on past quotes with commissions, slippage, and funding rate. We look not only at returns but also at drawdown, number of trades, and behavior during sharp moves.
- Demo account check. The same code runs without real orders: we compare actual signals with calculated ones and make sure that delays and partial fills do not break the logic.
- Bot deployment. We deploy on a server, enable logging of every order, failure notifications, and emergency stop with one command.
- Handover to operation. We provide configuration documentation, start and stop instructions, the procedure for changing strategy parameters, and the regulations for actions in case of deviations.
What remains with you: code, configurations, documentation, regulations
Handover of a futures trading bot is not "server access and exchange login." As a result, you receive a kit with which the on-duty team and your developer work independently: from building from the repository to the procedure for actions when limits are triggered.
- Bot source code — a repository with change history: strategy logic, risk control, exchange adapters. The build is reproduced from the repository, not reassembled from memory.
- Trading system configuration — parameter files by environment: trading pairs, position size, leverage, limits, schedule. Secrets are moved out of the code and do not sit next to settings.
- Diagrams and descriptions — architecture, storage schema, order path from signal to confirmation, map of external services and failure points.
- Access policy and trading account keys — procedure for issuing keys with trading rights but no withdrawal rights, rotation, revocation, separation of roles.
- Operating regulations — actions on connection loss, triggering of general limits, position mismatch with the exchange, restart with an open position.
- Instructions for the on-duty shift — start and stop checklists, rollback to previous version, notification texts, and list of recipients.
- Project handover — recorded setup sessions, access to repository, monitoring and logs, review of incidents during the trial operation period.
Such a kit removes the main maintenance risk: the bot does not turn into a "black box" of one contractor. Parameters can be changed, pairs added, strategy updated — or the whole thing handed to another team without reconstructing the logic from logs.
Case: futures bot on an exchange with sharp price movements
A trading team came with a bot that worked confidently in a calm market and fell apart on days of sharp price movements.
The quote stream from the exchange kept breaking, the bot lost the current picture and continued to consider positions open, although some had already been closed by stop.
We analyzed the task on Binance, where the load on the connection at the moment of news releases grows many times over.
What it was before rework
Out of ten signals, six or seven got through: some commands were lost during a disconnection, some were duplicated after reconnection.
Each failure left up to four unclosed positions, and the review took 30–40 minutes of manual reconciliation — during that time the price moved against the position by several percent.
Entry commands were moved to a queue with delivery confirmation, and the order is now tagged with a key — resending after a disconnection does not create a second position.
On each reconnection and by timer, the bot reconciles state with the exchange: a discrepancy in volume or price switches it to protective mode, where new entries are disabled and open positions are covered by stop orders on the exchange side.
What it became
The share of executed signals grew to 99%, unclosed positions over three months of operation — zero, recovery after a disconnection takes less than a minute and proceeds without an operator. Manual interventions dropped to one or two per month instead of fifteen per week.
What to do if a custom bot is already running on an exchange?
Rewriting from scratch is almost always more expensive than it seems: a working custom trading bot already contains accumulated logic — handling partial fills, reconnections to the quote stream, bypassing rate limits, adjusting volumes to lot step.
All this was assembled over months from real failures, and in a new codebase the same pitfalls will have to be gone through again. Therefore we start with an audit of someone else's code and logic, and make the decision to rewrite only after a risk map.
The audit of someone else's code follows the order route: what generates the signal, how the target position is calculated, who places the order, how execution is confirmed.
Separately, we look at idempotency — whether the order has its own client identifier so that a retry after a timeout does not open a second position — and reconciliation of local state with the exchange after a connection loss.
Then a comparison of the backtest run with actual trades: the discrepancy there usually points to the bottleneck.
Typical bottlenecks that surface: a blocking network call inside the quote processing loop, position calculation by an internal counter instead of a request to the exchange, lack of a decision log by which it is impossible to reconstruct why the bot entered a trade.
Refinement of an existing bot in such cases is targeted — a module changes, not the whole system, and it can be rolled out on a separate account in parallel with the working one.
Refactoring a trading system makes sense when the layers are mixed: strategy, risk management, and execution live in one file.
Then we move them into separate modules with explicit interfaces to exchanges like Binance, add position recovery checks and drawdown limits, and before enabling on a real account we run the version in shadow mode — signals are calculated, orders are not sent.
Describe how the bot is currently structured and what has stopped being satisfactory — we will come back with an estimate and a refinement plan.
Technical doubts before starting development
Before starting development of a futures trading bot, clients ask the same set of questions: what happens on connection loss, how the bot lives on several exchanges, what happens to open positions on stop, and how access keys are protected.
Below are the answers as they are built into the architecture and tested on a test loop before going to a real account.
What happens if the connection to the exchange is lost?
The bot maintains a permanent market data channel and a control channel to the trading gateway.
On a disconnection, positions are not abandoned: the state of orders and positions is re-read from the exchange, reconciled with the local log, and work continues with the current picture.
Every disconnection is recorded with a timestamp — the incident is analyzed from logs, not from guesses.
Can the bot be connected to several exchanges at once?
Yes, through an adapter layer: each venue is described by a separate module, while the strategy logic remains common. This enables position transfer between venues and operation when one of the exchanges is unavailable.
The limitations of a specific venue regarding order types and limits are checked at the design stage.
What happens to open positions if the bot is stopped?
Stopping is a managed procedure, not a process interruption. The bot stops opening new trades but continues to maintain open ones: places protective orders and closes according to a specified scenario. Emergency closing and a mode for transferring positions to manual control are provided.
How are exchange access keys stored?
Keys are kept in a secure vault and issued to the bot for the duration of operation, rather than remaining in a configuration file.
They are granted the minimum necessary rights — trading without withdrawal, plus address restrictions and scheduled rotation according to regulations.
Let's discuss your task and come back with an estimate and plan
Before naming deadlines, we need to see the logic by which the bot makes decisions.
Estimating trading bot development always involves analyzing the rules for entry, holding, and closing a position: two strategies with outwardly identical descriptions like "trade the movement" require different amounts of work.
Therefore we suggest discussing the task concretely — based on the materials sent, we assemble a work plan for the bot broken down by stages and priorities.
What is worth attaching to the description so the conversation is to the point:
- Strategy description: which instruments we trade, what is considered an entry signal, by what condition the trade result is recorded.
- Position management rules: size, leverage, add-ons, transfer through settlement, behavior during a sharp price move against the position.
- Risk requirements: acceptable drawdown, loss limit per trade and per day, what the bot does on connection loss with the venue or a stuck order.
- List of venues and account types: one exchange or several, whether cross-venue trading is needed, whether a separate test loop is required for trial runs.
- Current work: code, scripts, manual trade tables, history exports — even a draft noticeably shortens the logic analysis time.
- Infrastructure and control: where we host the bot, who receives error notifications, what data should be visible in the observer panel.
Describe the task in free form and attach what you already have. Based on this set, we will come back with an estimate, stages, and questions that remain open.