Independent operational-risk monitoring for IBKR accounts.
An independent, read-only supervisory layer that watches account risk, API health, exposure changes, and silent failure modes — running independently from your trading strategy.
The problem: traders monitor markets, not operations
Almost all trading effort goes into market risk — direction, sizing, strategy. Very little goes into the layer between a strategy and the broker.
An automated strategy can be correct and still lose money because the IB Gateway disconnected overnight, the data feed froze after a reconnect, a logic loop fired hundreds of orders, or margin crept across the whole book while attention was on one position.
These failures are silent — they look like nothing happening, not a visible loss — so they are found late. Risk Radar makes them visible the moment they occur.
This is operational-risk oversight — not market prediction, and not loss prevention.
What it is / is not
Not: a signal service · a strategy or indicator · a broker · a replacement for broker stop orders.
Is: an independent, read-only supervisory layer · a deterministic rule engine for account-level and operational anomalies · an alerting and incident-record system · a monitor that runs outside the trading process and survives its failure.
Architecture
Local agent → IBKR API → rule engine → alert dispatcher → backend & dashboard.
- Local agent (read-only). Runs on your machine or VPS, connects to IB Gateway/TWS over a read-only session. Credentials never leave your machine. Polls account state every ~5 seconds and probes connection and data liveness. It has no order-placement path.
- Rule engine. Deterministic rules evaluated on every poll. Explicit thresholds you configure; every alert carries the values that tripped it. Same input, same verdict.
- Alert dispatcher. Maps breaches to alerts, applies de-noising, delivers via Telegram. High-priority rules are not delayed by batching.
- Backend & dashboard. FastAPI + SQLite store account snapshots, alerts, and incident history. Multi-currency positions are valued in your base currency with per-poll FX — not summed across currencies.
Monitoring must be monitored: the backend tracks whether the agent is currently posting (a connection-status heartbeat on the health endpoint), and an external uptime watchdog alerts if it stops (when configured — optional by default, enabled on the founder's own deployment). (A dedicated in-product self-offline alert rule, FR-108, is designed but not yet armed — today the agent's own liveness is covered by the connection-status flag plus the external watchdog.)
Failure modes it detects
| Failure mode | What it catches |
|---|---|
| Disconnect | IB Gateway/TWS link drops (scheduled restarts distinguished from real outages) |
| Stale data | Feed stops updating though the socket is open |
| Zombie connection | API answers but data is frozen / competing session — looks alive, isn't |
| Margin stress | Margin cushion erodes across the whole book |
| Exposure jump | Sudden large change in position value (logic drift, runaway loop) |
| Reject spike | Broker rejecting orders repeatedly |
| Order-rate spike | Abnormal orders/minute — usually a bug |
| Daily loss | Account daily P&L breaches your configured threshold |
| Intraday drawdown | Sharp give-back from the intraday high |
| Position / bucket P&L | Configurable per-position or per-bucket threshold |
| Agent offline | The monitor itself has stopped — via connection-status heartbeat + external watchdog (dedicated in-product FR-108 alert designed, not yet armed) |
Why broker stop-losses are not enough
Stop-losses are good — they protect a single instrument's price, server-side, even with your computer off. Keep them.
But a stop acts on price, on one position. It can't see a silent disconnect, a frozen feed, a runaway loop, a reject storm, or whole-book margin stress. Those are operational failures, not price events.
Risk Radar and stop-losses are complementary: stops cover instrument price; Risk Radar covers the operational layer stops can't see.
Why the monitor must be independent
Monitoring built into the trading bot dies with the bot. If the process that should alert you is the one that just crashed, you get silence exactly when you need the alert.
Risk Radar runs as a separate process, on its own connection, and watches its own liveness. Independence — of the trading strategy — is the design, not a feature. (Independent of the strategy it watches: a technical separation from the trading process, not organizational risk independence.)
Alert de-noising
A monitor that cries wolf gets muted. Risk Radar applies per-rule cooldown, flap suppression, recovery hold-down (only confirm "recovered" after the condition stays clear), and root-cause suppression (one cause, not ten symptoms). High-priority alerts are not delayed by batching.
Reliability evidence (from live operation)
Operational-risk discipline means measuring reliability, not claiming it. Risk Radar logs operational events — connection incidents, alerts, recoveries, and a per-incident timeline — from which uptime and time-to-recovery are derived. Fuller instrumentation (detection latency and false-positive rate per rule) is planned, not yet a complete metrics system. Reliability figures will be published only when the data supports them.
Limitations
No execution. No kill switch. No financial advice. IBKR-only (v1). Not loss prevention — it reduces time-to-awareness of operational and account-level anomalies; broker stops remain the right tool for instrument price risk.
Request an IBKR Operational Health Assessment
For traders and small teams running systematic or semi-automated strategies on Interactive Brokers who want independent operational-risk oversight — monitoring that runs independently of the strategy it watches. Engagements begin with a paid assessment (not a free beta); Risk Radar is deployed as a controlled, staged step during the engagement.