What is algorithmic trading

What is algorithmic trading, in practice?

Algorithmic trading is the use of computer programs to decide, size and place orders according to predefined rules. Instead of a person clicking buy or sell, software reads market data, applies logic written in advance, and sends instructions to one or more trading venues. Asking what is algorithmic trading is really asking about that chain: who wrote the rules, what the program is allowed to do, and how anyone can tell whether it did what was intended.

The term covers different activities. Some algorithms only handle execution, splitting a large order over time to reduce market impact, as time-weighted or volume-weighted schedules do. Others make the trading decision itself using trend, mean-reversion or relative-value rules. What they share is automation; what separates them is how much judgement has been delegated to code.

This article comes from IMRYN, which publishes educational material about systematic trading infrastructure and order routing across several venues. It explains concepts rather than recommending any strategy, and nothing here is investment advice.

The components that turn a rule into an order

A working system usually has five layers: market data intake, decision logic, risk checks, an execution layer that talks to venues, and monitoring. Readers often focus on the signal because it feels like the clever part, but failures can also arise at the joins: stale data, a misread position, or a venue rejecting orders in a way the code did not anticipate.

Each layer needs a clear contract. The data layer should know when inputs are late or missing. The risk layer should be able to block an order regardless of what the signal wants. The execution layer should record what it sent, what was acknowledged and what was filled, so the record can be reconciled against the venue's own reports.

• Data: timestamps, gaps and source of every price used
• Decision: written rules with versioned parameters
• Risk: hard limits checked before each order
• Execution: routing, order types and fill records per venue
• Monitoring: alerts tied to named people who can act

Execution quality is where the strategy meets the market

A rule that looks sound on paper can lose money once real costs appear: spreads, fees, slippage between intended and achieved price, and partial fills. When orders are spread across several venues, each adds its own latency, rules and failure modes. That is why observable execution matters: every order should leave a trail showing intent, timing and outcome.

In practice, check whether a system compares achieved prices against a reference such as the arrival price or a period average, and whether that comparison is visible to the people responsible rather than buried in logs. If execution cannot be inspected, there is no reliable way to tell a weak strategy from a weak implementation.

Risk limits and human oversight are design choices

Explicit risk limits are boundaries the program cannot cross: maximum position size, maximum loss per session, order rate caps, and permitted instruments and venues. They should be written down, enforced in code before orders leave, and tested. A limit that exists only in a policy document does not stop a looping order.

Autonomy is a spectrum. A guardrailed system can act on its own within limits while people watch continuously and keep the authority to pause, reduce or stop it. IMRYN frames its approach in those terms, automated action inside defined risk controls with ongoing monitoring, and its public methodology and architecture pages describe how it draws that boundary. Such documentation describes intended controls; it does not by itself prove they work in a given live environment. For any system you evaluate, ask who can trigger the stop control, how quickly, and whether that has been rehearsed.

Reproducible evaluation: reading backtests with care

Backtests and simulations replay rules over past data. They are useful for finding bugs and understanding behaviour, but a historical or simulated result only describes how a rule behaved under particular conditions; it does not establish what will happen next. Repeated testing and parameter tuning can overfit historical data, which is a well-known trap.

Reproducible evaluation means another person can rerun the test and get the same answer: same data snapshot, code version, cost assumptions and parameters. It also means separating the data used to design a rule from the data used to judge it, and stating slippage assumptions openly. If a result cannot be reproduced, treat it as a claim, not evidence.

Worked example: a checklist before relying on an algorithm

Example (hypothetical): a small team is considering an automated rule that trades a liquid futures contract and routes orders to two venues. Before letting it run unattended, they answer the questions below in writing. Any 'no' becomes a task to fix, not a risk to accept silently.

The checklist does not say whether the rule will make money; it says whether the team will understand what happened when it does or does not. That is a realistic threshold for relying on an algorithm: not confidence in outcomes, but confidence in the controls and the record.

• Are position, loss and order-rate limits written down and enforced before each order?
• Can every fill be traced to the signal, parameter version and data that produced it?
• Is achieved price compared with a stated benchmark, per venue, on a regular schedule?
• Does a named person receive alerts, and can they pause the system within a defined time?
• Can the backtest be rerun from stored data and code with identical results?
• Were costs, slippage and an out-of-sample period included in the evaluation?