What is automated trading?

Automated trading uses software to decide one or more trade parameters from predefined rules, with limited or no human input for each decision. Those parameters can include whether to trade, when to trade, price, quantity, and how to manage an order after submission.

A conventional definition

Everyday use of "automated trading" is broad. It covers systems that automate decisions from a slow portfolio rebalance to a high-frequency market-making strategy. "Algorithmic trading" is often used as a synonym, although some people use it more narrowly for software that optimizes order execution.

The regulatory definition is more precise. Article 4(1)(39) of MiFID II describes algorithmic trading as a computer automatically determining order parameters such as initiation, timing, price, quantity, or post-submission management. It excludes systems used only to route an unchanged order, confirm an order, or process a completed transaction.

That definition gives a useful practical test: what does the software decide? A platform can automate signals without routing an order. A broker can route and execute an order without holding the customer's assets itself. Labels such as "bot" or "automated" do not identify the whole chain.

The four layers of an automated trading system

The layers can sit in one product or in several connected products. Separating them makes vendor claims and operational risks easier to assess.

Routing and execution are related but not identical. The SEC's trade execution guide explains that a broker can route an order to different markets or market makers before it executes. The route can affect price and total cost.

Custody is separate again. The SEC's investor bulletin on custody describes custody as holding client funds or securities, directly or indirectly, or having authority to obtain them. Before connecting any system, identify which entity holds the assets and which credentials can move them.

• Signal
• Modeled position
• Live API event
• User receiver

Common types of automated trading

The most useful classifications describe the job rather than the speed:

• Rule-based strategy automation: indicators, prices, or portfolio conditions trigger decisions.
• Portfolio rebalancing: software restores target weights at set times or thresholds.
• Execution algorithms: software divides a larger order or adjusts timing and price to seek a defined execution objective.
• Market making: software posts and manages quotes on both sides of a market.
• Arbitrage and relative-value systems: software acts on measured differences between related instruments or venues.
• High-frequency trading: specialized systems use low-latency infrastructure and high message rates. It is one subset, not a synonym for all automated trading.

The category does not establish quality. A slow system can be complex, and a fast system can use simple rules. The relevant tests depend on its data, holding period, turnover, and path to execution.

Benefits and tradeoffs

Automation can apply the same rule each time, monitor more inputs than one person, record decisions, and respond without waiting for a manual click. It also makes repeatable historical and paper tests possible.

The tradeoff is that software repeats mistakes with the same consistency. It can act on stale data, a bad parameter, a duplicate event, or an invalid assumption. Faster action can increase losses before a person notices. FINRA's algorithmic trading guidance emphasizes testing, change controls, monitoring, alerts, reconciliation, and ways to stop a malfunctioning system.

Automated trading also keeps the usual market risks. It does not guarantee profit or remove drawdowns, gaps, slippage, fees, liquidity limits, or changing market behavior. A historical result is evidence about a sample, not a forecast.

Failure modes worth testing

Start with failures that can change a decision or duplicate an action:

• Data failure: delayed, missing, duplicated, or incorrectly adjusted market data.
• Logic failure: look-ahead bias, a sign error, an invalid default, or a condition that never fires.
• Model risk: rules fit past noise or stop working in a different market regime.
• Cost error: the test understates spread, slippage, fees, funding, or market impact.
• Integration failure: a timeout, retry, or restart creates missed or duplicate messages.
• Execution mismatch: simulated prices differ from available prices, or an order fills only in part.
• Control failure: size limits, stale-signal checks, monitoring, or stop controls do not work as intended.
• Credential risk: a connected service receives more account authority than it needs.

No single test covers this list. A backtest checks historical behavior. A live-data paper run checks the decision process on unseen observations. A controlled integration test checks message handling and execution assumptions. Production monitoring checks what happens after release.

Where Tradee stops

Tradee covers signal generation and a modeled position layer. It can publish Live API events for a receiver that the user operates. Tradee does not store exchange keys, route or execute orders, receive venue fills, or hold customer assets. The figures in this article's images are a worked example of that boundary: 4 layers, and 0 routed orders.

This boundary matters when reading results. A Modeled position or output event is not an exchange order or fill.

A practical next step

1. Write the rule in terms that another person can reproduce.
2. Identify the data available at each decision time.
3. Backtest the rule on more than one historical period with realistic cost assumptions.
4. Review expectancy, drawdown, trade count, and exposure, not only win rate.
5. Run the unchanged version on incoming data. The paper trading and backtesting comparison explains what this adds.
6. Map every system boundary before any external execution test. Record who routes, who executes, who holds assets, and how duplicate or stale instructions are rejected.

If the objective is to test a Tradee strategy, start with a first strategy, then keep the tested version fixed through the backtest and paper stages.

Methodology and sources

This explainer uses the MiFID II definition to separate automated decisions from routing-only systems. It uses SEC investor material for order routing and execution and custody. The control examples follow FINRA Regulatory Notice 15-09. Regulatory scope varies by product, activity, and jurisdiction. This article explains system roles and does not provide legal, investment, or trading advice.