What is algorithmic trading in the era of machine learning?

What is algorithmic trading? At the regulatory level, it is not "using a bot" and it is not "asking ChatGPT whether to buy NVDA." It is a system in which a computer determines order parameters—whether to place an order, when to place it, at what price, in what size, or how to manage it after submission—with limited or no human intervention.

That definition is deliberately dry. It should be. The profitable part of quantitative trading is rarely the signal itself. It is the chain of constraints around the signal: data timestamps, execution assumptions, position sizing, kill switches, and the unpleasant arithmetic of drawdowns.

I have backtested strategies that looked nearly perfect until I moved the feature timestamp back by one bar. The edge disappeared. Nothing mystical happened. The model had been reading information it could not have known. That is the practical distinction between a systematic execution model and a spreadsheet with delusions of competence.

Algorithmic trading is a decision-and-execution system

Under MiFID II, algorithmic trading exists when software automatically determines individual order parameters with limited or no human intervention. The parameters matter:

• Whether to initiate an order at all.
• The timing of that order.
• The price or pricing logic.
• The quantity.
• Instructions that manage the order after it reaches the market.

A system that merely routes an already-defined order is not necessarily algorithmic trading under that definition. Nor is post-trade processing, confirmation software, or a basic order management workflow that does not decide trading parameters.

This distinction clears up a persistent retail misconception. Clicking "buy" manually after seeing an RSI alert is not algorithmic trading. Writing a script that alerts you to the same condition is still not necessarily algorithmic trading. Writing rules that calculate the signal, determine the size, decide whether liquidity is sufficient, submit the order, and manage the exit is much closer to the real thing.

The phrase "automated trading systems" gets used too broadly. Automation can sit at several different layers:

The useful mental model is not "algorithm versus manual." It is a pipeline. A real quantitative process begins with observable market data and ends with a fill, a position, and a measurable P&L distribution. Every stage can inject noise, bias, or friction.

Manual trading has discretion. Algorithmic trading has explicit rules. That does not automatically make the latter better. It makes its failures easier to locate—assuming you actually log the system instead of admiring the equity curve.

An algorithm is not an edge. It is a machine for expressing an edge, including all the ways you failed to define one.

Algorithmic trading versus manual trading: the difference is repeatability

The cleanest answer to algorithmic trading vs manual trading is not speed. It is repeatability under identical inputs.

A discretionary trader may look at a chart and conclude that a breakout has "good structure." That conclusion can be intelligent. It can also be impossible to reproduce. The same trader may make a different decision tomorrow while looking at the same setup, because volatility feels different, recent losses are still fresh, or a headline has shifted attention.

A systematic model has to state the condition in testable terms. For example:

1. Define the universe: liquid futures, large-cap equities, FX pairs, or another tradeable set.

2. Define the feature set: returns, realized volatility, volume imbalance, spread, cross-sectional ranking, or event data.

3. Define the forecast horizon: next bar, next session, five-day return, or intraday mean reversion window.

4. Define position construction: equal risk, volatility targeting, capped Kelly fraction, rank weighting, or a simple binary allocation.

5. Define execution: marketable limit, passive limit, participation cap, cancellation logic, and maximum tolerable slippage.

6. Define failure conditions: stale market data, rejected orders, unexpected position, breached exposure limit, or abnormal fill rate.

This is why "I use an EMA crossover bot" is not a serious description of a trading system. It describes one conditional branch in a much larger program.

The market does not pay you for having a rule. It pays you, occasionally, for having a rule whose conditional expectancy remains positive after spread, fees, slippage, adverse selection, and the regime change you did not model.

That last term matters. Most indicator strategies fail not because the indicator is mathematically wrong, but because the trader treats a conditional relationship as a permanent law. A moving-average crossover can capture persistent directional movement. It can also produce serial losses in low-range, high-noise conditions. An RSI mean-reversion signal can work in a stable range and become a reliable method for shorting a strong trend at exactly the wrong time.

The indicator is not lying. Your regime assumptions are incomplete.

High-frequency trading is a subset, not a synonym

One of the fastest ways to identify sloppy market commentary is to see "algorithmic trading" and "high-frequency trading" used interchangeably. They are not interchangeable.

High-frequency algorithmic trading is a specific subset characterized by latency-minimizing infrastructure, system-driven order generation and routing, and high intraday volumes of messages: orders, quotes, amendments, and cancellations. It is an implementation technique with a particular infrastructure profile.

HFT is often used to implement more traditional economic activities: market making, arbitrage, liquidity provision, execution optimization. It is not a standalone strategy category. "Fast" does not explain what the system predicts, what risk it warehouses, or why it should earn a return.

A daily rebalance of a cross-sectional value-and-momentum portfolio can be algorithmic trading. A VWAP execution schedule for an institutional order can be algorithmic trading. A market-making engine responding to order-book changes in milliseconds can be algorithmic trading.

The common element is automated determination of order parameters. The differences are horizon, data granularity, market microstructure exposure, infrastructure cost, and the shape of the drawdown.

For most independent quants, HFT is a distraction. You do not compete with low-latency firms by renting a faster virtual machine and calling an API. At that horizon, the edge is inseparable from queue position, colocation, feed normalization, inventory control, and transaction-cost modeling. A signal that looks statistically attractive at one-second resolution may be entirely consumed by a few milliseconds of delay.

The viable question is simpler: at what holding period does your data remain informative after execution costs? Start there. Do not start with a buzzword.

Machine learning is a signal layer, not a trading strategy

Machine learning changed quantitative trading, but not in the way marketing copy suggests. It expanded the set of functions we can approximate: nonlinear relationships, interaction effects, feature ranking, volatility classification, text-based sentiment extraction, and probability estimates from large, messy datasets.

It did not repeal non-stationarity.

A machine-learning model can be useful as one layer in an algorithmic system:

• A classifier can estimate the probability that a breakout follows through.
• A regression model can forecast expected return or realized volatility.
• A clustering model can label market regimes.
• A natural-language pipeline can convert news flow into a structured sentiment feature.
• A reinforcement-learning framework can be researched for execution choices under inventory and cost constraints.

Each of these can be valid research. None of them proves profitability.

I am especially skeptical when a model is sold as "AI trading" without specifying its target, horizon, labels, feature availability, rebalance schedule, and cost model. If the vendor cannot tell you whether the model forecasts a five-minute return, a close-to-close return, or a volatility-adjusted ranking, then there is no model discussion. There is only branding.

Large language models are a good example. They can summarize filings, classify financial news, and extract sentiment from unstructured text. That is useful. But converting semantic analysis into a tradeable return stream requires far more than a coherent summary. You need timestamp integrity, a defensible mapping from text to expected return, a delay model, a universe definition, and evidence that the result survives after the crowd discovers the same information.

The difficult part is not generating a feature. Python can generate thousands of them before lunch. The difficult part is proving that the feature has incremental information after controlling for simpler factors and after accounting for how it would have been traded in real time.

More model capacity does not create more edge. It creates more ways to fit noise with confidence.

I usually begin with a baseline that is almost offensively simple: a linear model, a ranked factor, or a threshold rule. If a gradient-boosted model or neural network cannot beat that baseline after costs and across multiple out-of-sample periods, I do not call it sophistication. I call it additional operational risk. Capacity also brings capacity for overfitting, capacity for hidden leakage through target encoding, capacity for silent data drift when the feature distribution shifts, and capacity for catastrophic generalization failure when the regime changes. None of those problems are solved by adding layers. They are usually amplified.

TimeSeriesSplit solves one problem. It does not solve your research.

Ordinary cross-validation is built on an assumption that is disastrous for financial time series: observations can be shuffled because they are independent and identically distributed.

Markets are not like that. Today's volatility is connected to yesterday's. Corporate actions get revised. Macroeconomic releases have publication times. Liquidity conditions cluster. And the future must remain unavailable to the training process.

That is why time-aware validation is non-negotiable. In scikit-learn, TimeSeriesSplit is designed to preserve temporal order. Training data comes before test data. The documented default is five splits, and the default gap is zero samples.

That final detail deserves more attention than it gets. A gap of zero is not a stamp of validity. It merely means the framework does not automatically create separation between the training window and the test window. Whether you need an embargo or gap depends on the horizon and on feature construction.

Suppose your label is a five-day forward return. If adjacent samples overlap, then the return information attached to one observation may bleed into the next fold. Suppose your features use end-of-day data but the model is assumed to trade at the close. That is not a minor implementation detail. It is a timestamp problem that can invert the result.

A defensible validation process usually includes several layers:

1. Walk-forward testing. Train on the past, test on the next block, roll forward, and record performance by period rather than admiring an aggregate line.

2. Feature timestamp audit. For every input, identify when the market could actually have observed it. "Daily data" is not a timestamp.

3. Purge and gap logic where needed. If labels overlap or events leak across folds, separate the training and evaluation windows.

4. Out-of-sample parameter stability. Small changes in lookback length, thresholds, or universe membership should not turn a robust signal into rubble.

5. Regime decomposition. Measure behavior through high-volatility periods, low-volatility periods, trend, range, stress, and liquidity deterioration.

6. Multiple-testing discipline. If you tried 400 feature combinations and report the best one, the backtest is a selection artifact until proven otherwise.

I do not care that a strategy produces a beautiful Sharpe ratio in one historical sample. I care whether its return distribution remains recognizable after you shift the start date, change the instrument set, delay execution, widen spreads, and remove the one period that made the chart look intelligent.

This is less glamorous than model selection. It is also where the work is.

The backtest is usually too clean

Backtesting frameworks are useful, but they are not market simulators. Backtrader itself makes this point: a backtest cannot guarantee real market conditions. Its slippage model is configurable, and the documented default percentage slippage is 0.0.

Zero slippage is not a neutral assumption. It is an assumption that your fills are free of one of the primary costs of trading.

In documented percentage terms, slip_perc = 0.01 represents 1%, while 0.001 represents 0.1%. The syntax is simple. Calibrating a realistic number is not.

Execution costs depend on the instrument, time of day, order size relative to available liquidity, order type, volatility regime, venue, and whether your signal tends to trade precisely when everyone else has the same idea. A mean-reversion model that enters after a sharp move may face wider spreads and adverse selection. A breakout system may buy into fast price movement and receive systematically worse fills than the bar-close backtest assumes.

The backtest should model, at minimum:

The cleanest equity curve in the world has no authority over a model that cannot survive friction.

I also separate signal alpha from execution alpha. A forecast can be correct directionally and still fail financially because the entry is too expensive. Conversely, a modest forecast can become useful when execution is patient, participation is controlled, and position turnover is constrained.

That is why systematic execution models deserve their own research budget. Most retail systems spend the overwhelming majority of their effort on signal discovery and a small fraction on trading mechanics. In live markets, that allocation is backwards.

Risk controls are not bureaucracy bolted onto the strategy

A strategy is not complete when it produces an order. It is complete when it can fail safely.

For U.S. broker-dealers with market access, SEC Rule 15c3-5 requires documented risk-management controls and supervisory procedures designed to prevent orders that exceed preset credit or capital thresholds, erroneous orders, unauthorized access, and orders that fail applicable pre-trade regulatory checks. The controls and procedures must be reviewed no less frequently than annually.

The exact legal obligations depend on jurisdiction, entity status, asset class, and market-access arrangement. A retail trader running a small system is not automatically subject to the same framework as a regulated broker-dealer. But the engineering logic remains sound regardless of account size.

Your algorithm should have hard limits that you actually test under stress, not admire on paper. A risk framework that has never been exercised has not been built. It has been drafted.

The same logic that produces pre-trade credit checks, order throttles, and maximum message rates at a broker-dealer can be applied in a smaller system at a different scale. Position-level exposure caps relative to account equity. A maximum order size relative to recent average daily volume. A ceiling on the number of orders per session. A maximum loss per session, per day, and per week. A ceiling on gross and net exposure. A kill switch that actually disconnects, not one that fires an alert that someone promises to read. An automatic halt when data freshness fails. A duplicate-order check. A reconciliation step that compares intended fills to actual fills, intraday, not only at month-end.

You do not need a regulator to insist on these. You need the humility to assume your model will eventually be wrong, on a day when being wrong is expensive.

What is algorithmic trading in the era of machine learning, then? It is the same thing it has always been: a system that turns a hypothesis into orders under explicit constraints, and that knows how to stop. The machine learning layer is interesting. It is not the foundation. The foundation is timestamps, execution assumptions, validation discipline, and the willingness to be told you are wrong by your own risk controls before the market tells you louder.