Identify the data before using the price
A quote should be understood as a value with context: instrument, field, source, timestamp and data mode. A last trade is different from a bid or ask. A current display of an old event is still old information. A delayed feed is intentionally behind the market; a stale feed may simply have stopped updating.
Those differences matter when software turns prices into orders. If an action depends on an executable bid or ask, a historical last price is not an equivalent substitute. The application should make freshness and permissions visible rather than presenting every number as equally current.
ADT labels delayed data and checks freshness for the entry fallback that requires real-time quotes. Its opening-auction path and app-side protection calculations have different dependencies, described below.
A broker connection does not include every feed
Authentication, trading permissions and market-data entitlement are separate checks. A client can connect successfully and still lack the subscription needed to receive live quotes through the API. Data available in one broker product may not imply the same entitlement for an API connection.
IBKR documents live, frozen, delayed and delayed-frozen data modes and how the API reports the type received in its market-data behavior reference. Check the current permissions and subscription details for your account rather than copying another operator’s package name or cost.
Use ADT’s connection and readiness checks, then inspect the actual mode and quote timestamp shown in the application. The IBKR setup guide covers the connection separately from data and order capability.
Different actions need different evidence
| Action | Relevant input | Consequence of an unsuitable input |
|---|---|---|
| Research screening | Current source material and appropriately timed reference data | A candidate can be based on outdated conditions |
| Opening limit order | Eligible instrument, session timing, reference and price cap | The limit may miss the auction price; execution is not guaranteed |
| Marketable-limit fallback | Fresh real-time bid/ask information and a cap | ADT does not use this path with delayed quotes |
| Local high-water and stop updates | Timely price observations | Updates based on delayed observations also lag |
| Broker-held stop | Accepted broker order and broker-side trigger handling | The configured level alone does not prove acceptance or execution |
ADT can use a delayed reference for its opening limit because the limit constrains the requested auction price; it does not transform the delayed reference into a live quote. That tradeoff does not make delayed data suitable for every other action.
Separate broker-held and local protection
When a protective stop is accepted and held by IBKR, the broker’s order handling determines how its trigger is evaluated. That is distinct from ADT observing prices and submitting stop modifications. If the application observes delayed prices, a local ratchet can update late even while the last accepted broker stop remains working.
Application-monitored protection has a different dependency: the local service and its data must be available to observe a condition and request an action. Read the current protection authority and verify the actual broker orders. The risk-controls page shows these distinctions in the real interface.
Neither mode guarantees a stop price, maximum loss or successful exit. Gaps, halts, rejected orders and outages remain possible. The risk disclosure covers those limitations.
A practical data-readiness check
Before a paper session, confirm the intended instrument and account, the subscription’s API availability, displayed data mode, most recent quote timestamp and bid/ask availability. Compare the application with the broker using the same instrument and time context.
If the application reports delayed data when live data was expected, inspect subscriptions and permissions before altering trading rules. If timestamps stop advancing, investigate the feed and connectivity. Preserve the error message and time for diagnosis; do not substitute an arbitrary last price to make a readiness indicator pass.
Rehearse the unavailable-data case as well as the healthy one. The important test is whether the system behaves consistently with the input it actually has. Record the outcome in the paper-testing matrix.
Include data in the cost and operating model
Subscriptions can vary with venue, account classification and use. Confirm current charges directly with the provider. Research APIs, search services and broker market-data subscriptions are different expenses; purchasing software access does not automatically supply all three.
ADT’s pricing page keeps those costs separate. A suitable setup balances the workflow’s data requirements with its operating environment, then validates the complete path in paper mode. Faster data cannot compensate for incorrect account state or a strategy that does not fit the operator’s needs.
News and quote capacity in a larger session
Free public news discovery supplies research context, not an execution quote feed. Each entry still needs the permitted price, spread, liquidity and broker state. An unavailable or stale news source cannot be replaced with an LLM’s remembered facts.
More simultaneous positions require more quote subscriptions and monitoring work. ADT displays an effective concurrency limit; its default IBKR adapter reserves four of 80 quote slots for validation, leaving at most 76 active lifecycle subscriptions. Your broker entitlement or entry window may lower participation. This bound comes from software and adapter controls, not a broker throughput certification.