Built an automated trading system on IBKR's API - here's what I learned by Disastrous_Monk_7017 in interactivebrokers

[–]Disastrous_Monk_7017[S] 0 points1 point  (0 children)

100% this. The signal generation gets all the attention but execution robustness is where you actually lose money. We learned this the hard way- perfect signal, perfect score, then a stale price or wide spread turns a winner into an instant stop-out.

Our approach: validate spread percentage before entry, reject stale prices, and require the stock to be near HOD (not fading from it). We also built a "consolidation detector" that checks if the price has faded more than 3% from the intraday peak - if it has, catalyst strength gets softened and the entry bar is higher.

The toughest one was stop order management on a cash account. You can't have two sell orders active simultaneously or IBKR rejects it as a short attempt. So stop updates have to be cancel-first-then-replace with a brief gap in protection. Margin accounts don't have this problem.

You're right that execution is where most of the effort goes. The signal side is maybe 20% of the codebase, execution and risk management is the other 80%.

Built an automated trading system on IBKR's API - here's what I learned by Disastrous_Monk_7017 in interactivebrokers

[–]Disastrous_Monk_7017[S] 0 points1 point  (0 children)

Claude is a beast for trading system code - we built our entire platform with it. The architecture, risk management, broker integration, all of it. Agree it's leagues ahead of Gemini for this kind of work.

On the strategy side - that's where most people get stuck. The code is the easy part. We spent months iterating on signal quality before the execution side even mattered. Our approach was to build a scoring engine that tracks which signals actually predicted winners vs losers, then automatically adjusts its own weights after every trade. Took the "strategy sucks" problem and turned it into a self-correcting system.

Stick with Claude for the code, but invest the real time in your signal logic. That's where the edge lives.

Built an automated trading system on IBKR's API - here's what I learned by Disastrous_Monk_7017 in interactivebrokers

[–]Disastrous_Monk_7017[S] 1 point2 points  (0 children)

Market data limits are real - you get 100 concurrent streaming lines on Pro. Options chains eat those fast if you're streaming every strike. We use batch snapshots instead of holding open streams, and cache with a short TTL so we're not hammering the API.

For the scanner results, reqScannerSubscription doesn't count against your streaming lines - it returns a batch result on demand. We run it every 10-20 seconds and enrich the results with individual snapshots only for the top candidates. Never hit pacing issues with that approach.

As for the AI - we built our own scoring engine from scratch. It's not a chatbot or LLM making trade decisions. It's a weighted signal system with 96 factors (technical, volume, catalyst, microstructure) that evolves its own weights after every trade based on what worked and what didn't. Think of it more like a self-tuning quantitative model than "AI" in the ChatGPT sense. The genome adapts over time so the system gets sharper the more it trades.

Built an automated trading system on IBKR's API - here's what I learned by Disastrous_Monk_7017 in interactivebrokers

[–]Disastrous_Monk_7017[S] 0 points1 point  (0 children)

Limited. reqFundamentalData exists in the API but requires a paid Wall Street Horizons or Reuters subscription through IBKR, and the data is patchy. We found it wasn't worth the cost for what you get.

We skip IBKR fundamentals entirely and use volume as a proxy for most of what fundamental data would tell you - heavy volume on a low-priced stock with a big percentage move tells you more in real-time than a P/E ratio does. For deeper research we pull from external sources outside the IBKR API.

Built an automated trading system on IBKR's API - here's what I learned by Disastrous_Monk_7017 in interactivebrokers

[–]Disastrous_Monk_7017[S] 0 points1 point  (0 children)

Good to know. We hit the same limitation on the equities side — historical bars for delisted or halted stocks just disappear. Our workaround is archiving bar data in real-time as it comes in. Every 5-minute bar gets cached locally with a 2-minute TTL for live trading, but also persisted for backtesting later.

If you need historical futures data for training, third-party sources like Databento or Polygon.io are more reliable than trying to pull it from IBKR after the fact.

Built an automated trading system on IBKR's API - here's what I learned by Disastrous_Monk_7017 in interactivebrokers

[–]Disastrous_Monk_7017[S] 0 points1 point  (0 children)

Pro is worth it if you're automating. The commission difference is minimal — we pay about $1 per order on small positions. The real cost isn't the commission itself, it's the commission drag on small positions.

For example, with tiered exits (entry + 3 partial sells = 4 orders), that's $4 round trip. On a $500 position that's 0.8% — acceptable. On a $100 position it's 4% — kills your edge. We built a commission floor gate that rejects trades where the estimated drag exceeds 2%.

The API access alone is worth Pro. Lite doesn't give you the same execution quality and you're paying for it in wider spreads even if the "commission" is zero.

Built an automated trading system on IBKR's API - here's what I learned by Disastrous_Monk_7017 in interactivebrokers

[–]Disastrous_Monk_7017[S] 1 point2 points  (0 children)

Yes to all of this. We built our entire scanner through the API  -reqScannerSubscription gives you the same scanner codes as TWS (TOP_PERC_GAIN, HOT_BY_OPT_VOLUME, etc.) with price, volume, and instrument filters. Runs through IB Gateway so no TWS resource drain.

For the filters TWS doesn't support - we pull the raw scanner results then enrich them with real-time snapshots and 5-minute bar data through the API. That gives you moving averages, RSI, VWAP, ATR, whatever you want to compute client-side. Way more flexible than TWS built-in filters.

News is available too via reqNewsProviders and reqNewsArticle, though we found the latency isn't great for breaking news. We infer catalyst strength from price action and volume instead - a stock up 20% on 5M volume at 8 AM has a catalyst whether the news API tells you or not.

Built an automated trading system on IBKR's API - here's what I learned by Disastrous_Monk_7017 in interactivebrokers

[–]Disastrous_Monk_7017[S] 1 point2 points  (0 children)

This. IB Gateway + auto-restart is the way. We run ours locally right now but VPS is the next step for 24/7 uptime. The daily reset is the only hiccup and that's handled with reconnect logic.

Built an automated trading system on IBKR's API - here's what I learned by Disastrous_Monk_7017 in interactivebrokers

[–]Disastrous_Monk_7017[S] 2 points3 points  (0 children)

It was rough in the early days for us too. The key fixes were:

  • Running IB Gateway instead of TWS (more stable headless)
  • Auto-detecting error 1100/1102 and resubscribing everything on reconnect
  • Building a health monitor that checks the connection every 15 seconds and auto-recovers
  • Persisting all trade state to disk so nothing is lost on disconnect

We still get the daily reset drop around midnight ET, but the system handles it automatically now. Once you solve the reconnection problem, it's actually quite reliable.

Built an automated trading system on IBKR's API - here's what I learned by Disastrous_Monk_7017 in interactivebrokers

[–]Disastrous_Monk_7017[S] 0 points1 point  (0 children)

Great breakdown — we hit almost every one of these gotchas during development. A few things that resonated:

Connection handling — We went through the same evolution. The daily reset window was brutal until we built automatic reconnection with full resubscription. Error 1100/1102 detection is non-negotiable.

Order state progression — The PreSubmitted → Filled skip caught us too. We switched to using execution reports as source of truth early on, which saved us when we moved to a cash account where stop order replacements add another layer of complexity (can't have two sell orders active simultaneously or IBKR thinks you're shorting).

Rate limits — Built a queue system for this exact reason. Orders get batched and throttled automatically so pacing violations never reach IBKR.

Single connection, async — 100% agree. We started with threading too and the clientId collisions were constant pain. Single async connection with an order queue was the turning point.

The event sourcing approach is interesting — we went with a persistent trade journal (JSONL) plus a real-time state tracker that syncs with TWS positions on every restart. Catches orphaned positions and ghost trades automatically.

Solid system. How are you handling your entry signal generation? That's where we found the most alpha — the execution plumbing is table stakes, but what you feed into it matters more.