What automated day trading means
Automated day trading uses software to evaluate a defined process and send orders intended to open and close positions within a trading session. The software may handle research, entry conditions, position sizing, order submission, protection and exits. Those responsibilities can live in separate components; a product that scans for opportunities does not necessarily execute trades.
Automation describes who performs the steps. It does not establish that the strategy has an advantage, that an order will fill, or that a position will close before the end of the day. Market halts, unavailable liquidity and system failures can leave exposure open. The operator still owns the account, configuration and response to exceptions.
Automatic Day Trader, or ADT, applies this operating model to eligible US stocks and broad ETFs through Interactive Brokers. It runs locally, researches a candidate and manages a defined execution workflow. This guide explains the general concepts first, then shows where ADT fits.
Signals, algorithms and execution
These terms overlap, but they answer different questions:
| Term | The question it answers | What to inspect |
|---|---|---|
| Research or signal | What instrument might meet the criteria? | Sources, timestamps, exclusions and the reason for selection |
| Strategy | Under what conditions should the system act? | Entry, sizing, protection, exit and skip rules |
| Execution engine | How are those rules translated into orders? | Broker integration, order types, fills and recovery |
| Trading bot | A broad label for automated software | Its actual responsibilities; the label alone is insufficient |
| Backtest | How would rules behave on a historical dataset under assumptions? | Data quality, costs, fill assumptions and out-of-sample testing |
| Paper trading | Does the configured workflow operate against a broker simulator? | Connection, permissions, orders, logs and recovery |
An execution algorithm may split or route an order without choosing the security. An AI research tool may choose a candidate without having permission to place an order. A useful product evaluation establishes exactly where each responsibility begins and ends.
The components of a complete system
Start with a diagram you can explain without using the word “AI”:
- Market and research inputs — prices, timestamps, calendar, instrument details and source material.
- Decision and validation — selection criteria, eligibility checks, sizing and recorded rationale.
- Execution service — strategy state, durable order intent and broker requests.
- Broker and market — acknowledgments, rejections, actual executions and positions.
- Monitoring and reconciliation — compare the expected state with the broker evidence; resume, block or request an exit.
Each boundary can fail independently. A healthy research provider does not establish a healthy broker connection. A broker login does not establish data permissions. A green connection indicator does not prove that a protective order was accepted. The interface should expose these distinctions in terms an operator can use.
ADT separates its desktop interface from its local trading service. Closing the window leaves the service running. Turning the computer off stops local processing. The architecture page shows how the interface, service, local records and broker connection relate.
From research to a submitted order
A workflow should preserve the decision that was used for the trade. Record when it was produced, the candidate, the relevant source material and the checks it passed. If research cannot produce a usable result, “no trade” must be a defined outcome.
In ADT, preliminary and final research run on the configured schedule. The ranked candidate pool and session envelope are validated and persisted. Entry admission checks both individual position constraints and aggregate capacity. The engine uses the saved intent with the selected strategy, exchange calendar, broker state and authorization. A research model does not rewrite the active execution rules during the session.
Before entry, inspect account identity, account mode, available funds, whole-share quantity, instrument eligibility, data mode and session timing. A complete system also needs a policy for an existing position or working order. Ignoring existing exposure can turn a restart into a second purchase.
The broker API is the interface used to request account data and submit orders. ADT uses the TWS API through a locally authenticated IB Gateway or Trader Workstation. It does not collect your broker password. See the IBKR connection guide for the actual setup and boundaries.
Understand the order lifecycle
An order can be submitted, acknowledged, partially filled, filled, cancelled or rejected. Those events are related to the position but are not interchangeable. An order for ten shares with a four-share execution leaves four shares of exposure and potentially six shares still working. Cancelling the remainder does not close the four shares already bought.
A limit order restricts the acceptable price but may never fill. A market order prioritizes execution rather than a specific price. An opening order adds an auction and timing constraint. Order support, routing and execution remain subject to the broker and venue. IBKR documents its API order submission and callbacks in Placing Orders.
ADT’s entry path uses whole shares and an opening limit order. A capped marketable-limit fallback is conditional on fresh real-time quotes. The resulting position is based on broker fills, not on the quantity requested. Protection and exit logic then operate against the confirmed exposure. The execution page explains the current implementation.
When evaluating any system, ask how it handles a fill that arrives during cancellation, repeated execution messages and an ambiguous submission after a network interruption. The answers should involve identifiers, persisted intent and broker evidence, not an assumption that a timeout means failure.
Reconcile after a restart or disconnect
Reconciliation compares local records with broker orders, executions and positions. Its purpose is to establish the current account state before the software resumes normal activity. A local log explains what the application attempted; the broker supplies evidence of what actually executed.
Consider a buy request followed by a lost connection. Resubmitting immediately could duplicate a trade if the original request reached the broker. Treating the order as filled could create a nonexistent local position. A recovery process must resolve that uncertainty before deciding what to do next.
ADT persists session information and order intent locally. On reconnect, it requests broker records and reconciles them before resuming. Discrepancies can block normal trading and require operator attention. The reconciliation guide covers partial fills, restarts and manual broker activity in more detail.
Protection and exits
Risk controls constrain behavior; they cannot guarantee a maximum loss. A stop can execute beyond its trigger price during a gap. A stop-limit can remain unfilled. An exit request can be rejected or delayed. A halted security may remain impossible to close.
The location of a control matters. An accepted broker-held order may remain working when the application disconnects, subject to the broker’s rules. A locally monitored trigger depends on the computer, running service, network and timely data. Do not interpret a configured stop level as proof that a broker order exists.
ADT distinguishes broker-held protection from application-monitored protection in its interface. Its strategy can ratchet a stop upward, and its session schedule can request flattening before the actual exchange close. Operators should inspect the accepted orders, current protection authority and actual position. The risk controls and operator recovery instructions show the relevant surfaces.
Paper testing and the transition to live
A useful paper rehearsal checks more than whether a trade completes. It covers a skipped session, rejected order, delayed data, partial fill where supported, gateway restart and manual intervention. Record the expected outcome, broker evidence and actual observed outcome for each case.
Broker simulation has limits. IBKR explains that paper fills use top-of-book simulation and that some order types and stop behavior differ from production. A paper result is not a verified live return or proof of execution quality. See IBKR’s paper-account limitations.
ADT also has isolated demonstration fixtures used in this website’s actual application screenshots. Those fixtures are separate from broker paper trading: they render fictional state and cannot submit an order. The website walkthrough proves what the interface displays, not how a live trade performed.
Live authorization in ADT is disabled by default and bound to the selected account. Before enabling it, the operator must understand the configuration and failure procedures. Read the paper-trading checklist for a practical rehearsal record.
Data quality, latency and slippage
Every decision is limited by its inputs. A stale price can be perfectly valid historical data and still be unsuitable for a current executable-price decision. Inspect timestamps, whether the feed is live or delayed, bid and ask availability, and instrument identity.
Latency includes research time, local processing, network travel, broker processing and the market’s response. Lower latency is not a universal substitute for correct state handling. ADT is a session-based desktop workflow; it is not marketed as high-frequency or colocated execution infrastructure.
Slippage is the difference between a reference or expected price and an actual execution price. Its interpretation depends on the benchmark and timing. Spreads, price movement, liquidity and order type all matter. Record the reference timestamp and fill details before interpreting the difference. See real-time versus delayed data for the implications in ADT.
Costs and operating responsibilities
Budget for the complete environment, not just the software fee. Categories include software access, onboarding, broker commissions and fees, market-data subscriptions, research/search APIs, hardware, electricity, connectivity and any maintenance arrangement. Trading capital is separate from all of these costs.
ADT’s published pricing distinguishes the subscription and setup fee from customer-paid broker, data and research-provider charges. Provider usage varies with model, search requests, retries and configuration. No fixed monthly model bill or trading return is promised.
Keep the machine available through the session and maintain broker authentication. Plan who checks alerts and what they do if the account state is uncertain. Before maintenance, inspect actual positions and working orders directly at the broker. A system that runs automatically still needs an operating procedure.
Logs that make a session understandable
A useful session record connects the research decision, strategy version, account mode, requested orders, broker identifiers, executions, protection changes and exit result. Timestamps should make the sequence reconstructable. Repeated events should not be mistaken for repeated fills.
ADT provides session reports and diagnostics through its advanced settings. Review exported material before sharing; even sanitized operational records deserve care. Logs help investigate behavior. They do not establish a profitable strategy, eliminate software defects or replace broker statements.
Rules, suitability and account constraints
Automation does not exempt an account from broker permissions, settlement requirements, margin rules, taxes or applicable law. Requirements depend on the account, jurisdiction, instruments and broker implementation. Confirm the current rules directly with your broker before operating; do not select a system on the assumption that it bypasses them.
FINRA’s current frequent intraday trading guidance discusses cash-account funding, margin requirements, trading costs and loss risk. This guide describes software architecture and does not decide whether trading is suitable for you. ADT’s risk disclosure describes the product’s limitations.
Where ADT fits
ADT is for an operator who wants a defined local workflow for eligible US equities through IBKR: configuration-aware candidate pools, bounded session entries, whole-share long positions, explicit live authorization, independent protection and automatic configured exits through broker-confirmed flat.
It is not a general strategy marketplace, unrestricted strategy builder, multi-broker router or managed investment account. ADT Desktop is built for Mac and Windows: Apple silicon on macOS 13 or later, and Intel/AMD Windows x64. The Windows build is currently a testing release; see the platform requirements and validation status. Access is guided; this website does not provide an unrestricted download or a self-service checkout.
Start with the actual application walkthrough, read the setup requirements and compare the operational responsibilities with your needs. The right question is whether the workflow, constraints and support arrangement fit the system you intend to operate.
Configure an envelope, not a mandatory trade quota
A user allowing 100 entries with a $10 whole-share cap needs a different candidate plan from a user allowing three entries with a $5,000 cap. ADT passes these constraints into research before ranking, retains qualified reserves and checks current execution eligibility again before every order. A price crossing above the cap cannot silently increase the budget.
Each broker-confirmed position receives independent protection and automatic configured exit handling. The session orchestrator enforces shared capital and concurrency limits. A maximum of 100 means up to 100 qualifying attempts, not an instruction to invent 100 trades. See the configuration and verified limits and the provisional protection evidence.