More and more traders are using Claude Code, ChatGPT, Cursor, and other LLMs to build and automate their trading systems. It works. You can go from strategy idea to a working bot in a day. The code compiles, the backtest looks good, orders fire on paper trading, and you move to production.
Then stuff breaks. Not the strategy logic - the infrastructure around it.
Over the years, we’ve repeatedly seen traders run into the same production issues after going live. Some are annoying. Some are expensive. Most are completely invisible until they happen for the first time.
Based on those conversations and our own experience running production trading systems, we put together a list of 10 operational pitfalls that every trader should understand before going live.
These examples are drawn from Interactive Brokers specifically, but the broader lessons apply to most broker APIs and automated trading infrastructures.
1. Your Data Can Go Stale and Your App Won't Know
Someone reached out to us after their algo traded all afternoon on a price that hadn’t updated since 11 AM. The app looked completely normal. Connection status said connected, prices were still showing on screen, nothing appeared broken.
Earlier that day, they only had a brief internet disconnect. The broker gateway reconnected automatically, everything came back online, and from the outside it looked like the system recovered fine.
But it hadn’t.
The market data had silently stopped updating.
No error. No disconnect warning. The last price just stayed there looking valid, and the algorithm kept making decisions based on a number that was hours old.
That’s one of the dangerous parts about broker APIs. A connection can look perfectly healthy while the actual market data stream is dead. Your system sees a price, assumes it’s current, and keeps trading unless you explicitly check how old that data is.
The fix is simple in theory: track when each ticker was last updated and stop trading if the data becomes stale. A lot of people don’t realize they need this until it happens in production.
2. Two Algorithms + One Ticker = Cancelled Orders
Two algorithms running on SPY. End of day, Algorithm A submits a MOC BUY for 200 shares, Algorithm B submits a MOC SELL for 150 shares.
IBKR cancelled one of them. Error code 202: “Order would cross.”
Each algorithm tracks its own position correctly. But IBKR sees one account with a BUY and a SELL for the same symbol and rejects the conflicting one. No prominent documentation about this.
The fix: Monitor for MOC cancellations via order status and error events. If a MOC gets cancelled, schedule a fallback market order before close. Or net out positions across all strategies before submitting close orders so you’re only sending one side.
3. Historical Data Rate Limits Are Worse Than Documented
IBKR’s docs basically say: “don’t request too much data too quickly.” In practice, the limits are much easier to hit than most people expect.
A few historical data requests are usually fine. But once several requests happen at the same time, IBKR can start throwing pacing violations or returning empty responses. The dangerous part is that the failure is not always obvious. Sometimes the request simply returns no data and the algo keeps running with missing indicators.
This gets worse throughout the day when indicators like VWAP repeatedly trigger historical data requests across multiple tickers. Even small bursts can eventually hit pacing limits because IBKR tracks request frequency over time.
The real fix is understanding IBKR’s pacing limits extremely well or using a dedicated market data provider instead. IBKR itself explicitly states that it is not a specialized market data provider and recommends using one if your strategy requires heavier historical data usage. Otherwise, you need to aggressively manage request timing, caching, and batching to avoid random throttling or silent failures during live trading.
4. MOC Orders Have Submission Deadlines
Market-on-Close orders can’t be submitted or modified after 3:50 PM ET on the NYSE. If your algorithm tries to close positions at 3:55 PM via MOC, the order gets rejected.
The fix: Submit MOC orders before the cutoff (we use 3:49:55 ET) and have a fallback market order ready at 3:59:58 in case the MOC gets rejected.
5. Early-Close Sessions Can Silently Break Your Logic
A handful of U.S. trading sessions close early each year - typically at 1:00 PM ET instead of 4:00 PM. The day after Thanksgiving, Christmas Eve, and a few others.
Most systems implicitly assume the market always closes at 4:00 PM. On an early-close day, that assumption quietly breaks everything downstream. Your MOC orders get submitted hours after the market already closed - rejected. Your intraday indicators keep computing on a session that ended at 1:00 PM. Your end-of-day position closing logic fires at 3:49 PM into a market that’s been shut for nearly three hours.
Nothing crashes. The system just does the wrong thing at the wrong time.
We’ve also seen that some data providers continue emitting bars after the official close on half-day sessions, while others truncate the session correctly. If your system consumes that extra data, your indicators and signals are contaminated without any obvious error.
The fix: Maintain an official exchange calendar and dynamically adjust your scheduling logic and MOC cutoffs based on the actual close time for that day. Don’t hardcode 16:00.
6. Your Server’s Clock Is Probably Wrong
Your system schedules checks at specific times – “execute at 10:29:58”, “send MOC at 15:49:55”. A typical computer clock can drift several seconds per day. If your VPS hasn’t synced in a while, your MOC order that should arrive at 3:49:55 actually arrives at 3:50:02 – rejected.
The fix: Keep your server clock synced and monitor for clock drift. Even a few seconds off can cause scheduled orders to arrive too late.
7. Multi-Account Routing Fails Silently
If you use a single gateway connection for multiple accounts, every order must explicitly specify the account. If you don’t set it, IBKR routes to the default account. No error, no warning, just the wrong account.
This becomes particularly dangerous in multi-client or advisor-style setups, where a routing mistake can unintentionally allocate trades to the wrong portfolio.
8. Reconcile Against the Broker on Every Restart
Even if you persist your state in a database, you should still reconcile against IBKR’s execution records on startup. Your DB might have missed a fill – maybe the app crashed between receiving the fill event and writing it. Maybe a partial fill came in after the crash. Maybe someone manually traded in the account while your system was down.
The fix: On startup, query IBKR for today’s executions and compare them against your own records before making any new trading decisions. Tag every order with a reference that includes the strategy name and date (e.g., SPY-MyStrategy-20250227) so you can filter which executions belong to which algorithm. If there’s a mismatch between what IBKR says happened and what your DB says happened, trust the broker.
9. Paper Trading and Live Trading Don’t Behave the Same
This one ties back to several points above. IBKR’s paper trading environment does not enforce the same rules as live. For example, conflicting MOC orders (see #2) will be accepted on paper – both sides go through, no Error 202, no cancellation. You test your multi-algo setup, everything works, you go live, and suddenly orders start getting rejected for crossing.
Paper trading will not catch every production issue. Some broker-level validations, order conflicts, and margin checks only kick in on a live account. If your entire testing was done on paper, expect surprises on day one.
Some traders work around the crossing issue by using equivalent instruments on different sides – going long SPY on one algorithm and short VOO or a Vanguard S&P 500 ETF on the other, for example. That avoids the same-symbol conflict at the broker level. But however you handle it, you need to be actively managing how your algorithms interact at the account level. The broker doesn’t care about your internal strategy separation.
These operational issues become even more critical when strategies are deployed across dozens of separately managed accounts, where synchronization, execution consistency, and routing reliability become central.
10. DST and Timezone Mismatches Will Break Your Scheduling
U.S. markets and European countries do not switch to Daylight Saving Time on the same dates. The U.S. springs forward in March, Europe follows a few weeks later. In the fall, the reverse happens. For about two weeks twice a year, the time offset between your server and the exchange shifts by one hour.
If your server is in Europe and anything in your stack references local time instead of market time, your entire schedule silently shifts. MOC orders go out an hour late. Your algorithm misses market open. Signal calculations run on incomplete sessions. Rebalancing triggers at the wrong time.
The dangerous part is that nothing crashes. The system runs normally - just at the wrong hour. And because it only happens for a couple of weeks a year, it’s easy to miss in testing.
The fix: Always use the exchange’s timezone (America/New_York for U.S. equities) for all scheduling and time comparisons. Never derive trading schedules from your server’s local clock. Test your system across DST transition dates specifically - don’t assume that because it works in January it will work in March.
This list is obviously not exhaustive. What breaks depends on your broker, infrastructure, execution architecture, and the complexity of the systems you run.
But one lesson tends to repeat itself consistently: building a strategy is often the easy part. Building a robust production environment around it is usually much harder.
In recent years, the rise of LLMs and AI coding tools has dramatically lowered the barrier to creating trading algorithms. What has not become easier, however, is dealing with the operational realities of live execution: broker-specific edge cases, multi-account routing, order synchronization, failover handling, stale data detection, reconciliation procedures, and execution reliability under real market conditions.
These are not concepts most people learn from textbooks or backtests. In many cases, they are lessons that only emerge after years of deploying and maintaining live trading infrastructure.
At Concretum Group, part of our work involves helping private investors, advisors, and professional allocators automate systematic strategies efficiently across Interactive Brokers environments, including multi-account and portfolio-based execution workflows.
If you are exploring trading automation and would like support in designing a more robust production setup, feel free to reach out to us by email at info@concretumgroup.com
If you found this article useful, feel free to leave a comment and reach out via direct message or email at info@concretumgroup.com for any questions.
Disclaimer
This publication is provided by Concretum Group for informational, educational, and research purposes only. It does not constitute investment, financial, legal, or tax advice, nor a recommendation to buy or sell any security, instrument, strategy, or investment product. All investments involve risk, including possible loss of principal. Past performance, backtested performance, and historical analysis are not reliable indicators of future results. Readers should conduct their own research and consult qualified professionals before making investment decisions.
Full disclaimer: https://concretumgroup.com/disclaimer/
Error management is the difference between an evaluation algo and a production implementation. Good tips where to focus for error management. Don't trust on the AI agents about this.
For the second scenario: Two Algorithms + One Ticker = Cancelled Orders, I have separate solution to solve this.
Using message queue and IBKR subaccount to address two algorithms issue
https://medium.com/@mikelhsia/how-2-escape-interactive-brokers-connection-trap-with-the-help-of-ai-905fc773ec10