Why an AI trading bot loses trades at the junction with brokerage API
An AI trading bot makes decisions based on its own state model, while actual positions live on the broker side. If the connection breaks at the moment an order is confirmed, position desynchronization occurs: the bot considers the entry open even though it no longer exists.
This is discovered not immediately, but when risk management calculates drawdown on a nonexistent position.
After reconnect, the second half of the problem begins — duplicate orders. The request was sent, the response did not return, the connection came back up, and the bot sends the order again because the identifier is generated anew on each run.
On entry, size quietly doubles; on exit, part of the position remains open, and risk is calculated on the wrong base.
Partial fills add a third class of failures: the order is not fully closed, but the stop and targets have already been recalculated for the full volume. The remaining tail lives on the account as a separate line and is visible only during reconciliation, not in the bot interface.
While these junctions are not closed, a human enters the process — morning discrepancy review, manual trade edits, position reconciliation from exports. This consumes hours of team work time and masks a systemic error as a one-off issue.
We treat the bot-account link as a separate layer: what to consider the source of truth, how to reconcile after any broker connection break, and how to make order sending resilient to retries. Then — how this is closed at the integration level.
What managed integration gives: speed, resilience, control
Managed integration changes the time scale in which the bot operates.
Instead of periodically polling the account and quotes, we subscribe to market events and maintain a persistent connection to Interactive Brokers — the bot's reaction time to a price change shrinks from seconds to fractions of a second. The order is sent before the level moves, not after it.
The resilience of trading logic rests on three decisions: entry and exit rules along with risk limits are moved out of the code into configuration, position state is restored from the trade log, and repeated order sending is cut off by a unique key.
On a connection break, the bot does not go blind — it recomputes state from execution facts and continues from the point where it stopped, not from scratch.
This adds up to the share of automatic trades: closing by stop and target, processing partial fills, trailing the protective level and reversing a position happen without manual intervention.
At the same time, a whole class of failures goes away — double orders, unconfirmed orders, positions left without a protective order.
Position reconciliation becomes a procedure, not a manual check. Positions, active orders, average price and free margin are reconciled at start, after a connection break, and on schedule; a discrepancy is logged and raises an alert.
Trading logic remains manageable: limits, stops and rules change in configuration, without rebuilding the bot.
Options for connecting the bot to a trading account
Connection to an account at Interactive Brokers is built in one of four modes, and the choice determines what the bot knows about the account and how quickly it reacts to changes.
| Option | When suitable | Connection limitations |
|---|---|---|
| Periodic synchronous requests | Low trade frequency and logic debugging | Delay between polling and reaction, extra load on the channel, missed fast price movements |
| Streaming subscriptions to account events | Reaction to order execution and position change | Dependence on connection continuity: on a break events are lost, resynchronization is needed |
| Subscriptions plus local bot state | Main mode: many instruments, frequent trades | Need to reconcile local state with broker state after every break and restart |
| Intermediate layer between bot and account | Multiple strategies, common risk control, action log | Another point of failure: layer crash stops trading entirely |
The hybrid wins in practice: the bot keeps positions, orders and balances in its own state, while streaming subscriptions only confirm changes.
Then a connection break does not lead to incorrect decisions — after recovery, reconciliation restores state to order, and duplicate orders are not sent.
The intermediate layer is justified when there are several strategies: it maintains a single risk limit and an action log. But it has its own cost — additional delay in the signal path and another component that must be maintained.
How integration proceeds: stages of engineering work
Integration of a trading bot with a brokerage account is not connecting a library, but assembling a loop where an error in one node nullifies the strategy's work.
Therefore the order is: first we analyze existing logic and execution scheme, then build, test on history, launch in a limited way and hand over procedures to your team.
Sequence of work
- Audit of trading logic and current scheme. We analyze entry and exit rules, signal sources, position sizing. Result — a decision map: where the bot acts on its own and where confirmation is needed.
- Design of the execution loop. We determine how position and order state is stored and what we consider the source of truth — the quote stream or broker reports.
- Account access layer. Requests are idempotent, with retries, duplicate control and recovery after a connection break. Each order is tagged with an identifier and enters the log — we analyze a failure by facts.
- Testing on historical data. Run on past quotes adjusted for slippage, commissions and execution delays. We look at drawdown and behavior on gap moves, not only return.
- Test loop. We compare bot signals with what would actually have been executed: discrepancies are visible before launch.
- Limited launch. Small volume of operations, strict limits on position and losses, daily monitoring. Volume grows only after behavior matches the expected one.
- Handover of procedures. Documentation: deployment, emergency shutdown, signs for intervention, state recovery after failure.
What the customer receives: configurations and procedures
The customer receives not only a working bot, but also a kit with which it can be operated, handed over to another engineer and brought back up after a failure.
Everything listed lies in the repository next to the code and is updated together with it — otherwise documentation diverges from reality in a couple of months.
- Working bot configurations. Profiles for test and live account: instruments, limits on position and daily turnover, trading intervals, protection thresholds. Switching environment is done by changing profile, without code changes.
- Account interaction scheme. How exchange with the brokerage gateway Interactive Brokers is arranged: quote subscription, sending orders and confirmations, partial fills, connection breaks and points where the bot must stop trading itself.
- Access and key policies. What credentials are needed, where they are stored, who and how changes them, what to do in case of a leak. The right to trade and the right to change settings are separated across different roles.
- Recovery instructions. Procedure: bring the bot up from scratch, reconcile positions with the broker report, close discrepancies, return to trading after an emergency stop.
- Support procedure. What is considered an emergency event, what the duty engineer monitors, response time, strategy update procedure and contents of the regular report.
- Change log and historical backtests. Every strategy change is accompanied by a historical data test and a test account check — it is visible what exactly influenced the result.
Case: eliminated order breaks and reduced manual edits
The customer traded via Interactive Brokers, and an AI trading bot placed orders according to its own model. The link rested on a single long-lived connection: scheduled broker maintenance, channel degradation or gateway restart — and the event stream was lost.
The bot continued to believe positions were open, although the account picture was already different.
The cost of such a break is not the downtime itself, but the silent loss of account state. Some executions did not reach the bot, duplicate orders were cut manually, instrument limits were calculated from stale data.
The duty engineer corrected about a third of triggered signals, and each review is a risk of placing a position twice or missing a stop.
How the link was rebuilt
The bot's local memory ceased to be the source of truth. Every execution, cancellation and partial fill is written to the log, and on start the bot does not trust its model, but reconciles it with the broker by open orders and positions.
Separately, automatic reconciliation was set up: account state, positions and active orders are compared with local state at a short interval.
A discrepancy raises an alert and blocks new entries for the affected instrument until reconciliation — the error does not have time to turn into an extra position.
Metrics before and after: share of manual edits — from a third of signals to less than 2%, recovery after failure — from half an hour of analysis to automatic recovery in seconds, discrepancies during scheduled reconciliation — zero over a month of observations. The failure class “bot does not know a position exists” is closed at the launch logic level.
How synchronous exchange differs from streaming and what to choose
These are two different modes of obtaining account state, and the choice between them is determined not by implementation convenience, but by how long the trading decision lives. In synchronous exchange, the bot requests positions, balance and quotes on a schedule itself. In streaming, it subscribes to events once and then receives changes as they appear.
The cost of the choice is visible in update latency. While there is a pause between two requests, the account has already changed: part of the order was executed, margin dropped, price moved away from the entry level.
Logic built on a snapshot makes a decision on stale data and gets execution at a price that no longer existed at the time of calculation. On a calm market this is almost unnoticeable; on a volatility spike the discrepancy becomes the main loss item.
Difference in requirements:
| Mode | When suitable | Limitations |
|---|---|---|
| Synchronous exchange | Scheduled rebalancing, reporting, strategies on daily bars | Account changes between requests — decisions on stale data |
| Streaming exchange | Maintaining open positions, stop orders, margin control | Need duplicate cutting, break handling and resubscription |
| Mixed | Intraday trading with discrepancy control | More expensive to support: two loops must be coordinated |
In practice, a hybrid works more often: at start we take a full snapshot synchronously, then maintain streaming subscriptions, and leave polling for periodic reconciliation — it catches discrepancies after connection breaks.
The choice of mode is a question of acceptable data age: if a trading decision lives longer than the polling interval, synchronous exchange is sufficient.
Technical doubts before start: point-by-point breakdown
Engineering objections before start repeat from project to project: what happens on a connection break, how not to send an order twice, who is responsible for risk limits.
We sort them out before work begins — on integration with Interactive Brokers these points are covered by concrete mechanisms.
How to prevent duplicate trades on a connection break?
Each order has a unique key in the log, and before placement the execution layer reconciles the intent with actual positions and active orders at the broker. After a break, recovery goes by order number, not by blind retry.
What happens if the process crashes or the channel is lost?
The bot runs under a watchdog process: it starts again and restores state from the log, not from scratch. If the channel is unavailable longer than the threshold, an emergency scenario triggers — trading stop or position flattening, according to your rules.
Who is responsible for risk limits and can several accounts be managed?
You set the rules, we embed them in a separate check layer before order sending: limit per instrument, per portfolio, daily stop. The strategy does not bypass them. Accounts are managed as separate loops, limits and log calculated separately for each.
How is handover of control and access done?
According to procedure: stop trading, lock in positions, hand over access, configuration and documentation. Then the loop operates under your control — with or without support.
Let's discuss the task: where integration begins
The first discussion of the task is needed to gather input data, not to show a presentation. It is important for us to understand the trading logic: by what events the bot enters and exits, how it calculates position size, where hard risk constraints are.
Architecture depends on this — where to keep state, how often to contact the broker, and what to do on a discrepancy between our data and its report.
- trading logic: signals, trading intervals, instrument list, rules for entering and exiting a position;
- risk constraints: position limit, daily loss limit, number of simultaneous orders, behavior when a protective order triggers;
- operating conditions: live account or test loop, access, market data source, mode — signals only or automatic execution;
- what is already ready: strategy code, trade history exports, existing scripts, event log requirements;
- failure rules: repeated order sending, connection break handling, manual kill switch and procedure for closing open positions.
Based on these answers, we assemble a work plan — from connecting to the broker API and reconciling data with the terminal to switching to a live account. We return with a breakdown by stages, timeline estimate for each and a list of what will be needed from your side.
The next step is to determine who on your side makes decisions on trading logic and when test access can be obtained.