Algorithmic trading terms, in plain English

Algorithmic trading

Trading in which software places orders according to written rules, instead of a person deciding each trade by hand. The rules come from the trader; the software applies them consistently and without hesitation. Custom trading software →

API (application programming interface)

The doorway a broker or exchange gives to software. Through its API a program can read prices, check positions and place orders without anyone clicking in a trading screen. Broker API integration →

API key

A credential that lets a program use an account through its API. Most brokers and exchanges let the account holder limit what a key can do and revoke it at any time.

Backtest

Running a strategy’s rules over historical data to see how they would have behaved. A backtest is a test of the rules, not a forecast; a careless one can look far better than the live market would allow. Backtesting software →

Bid-ask spread

The gap between the highest price a buyer will pay and the lowest price a seller will accept. Every market order pays it, which is why an honest backtest charges the spread instead of trading at the mid price.

Bracket order

An entry order sent together with a profit-taking order and a stop order. When one of the two exits fills, the other is cancelled.

Broker adapter

The part of a trading system that speaks one broker’s API. A system with an adapter per broker can run the same strategy at several brokers while the rest of the code stays the same. Multi-broker platforms →

Co-location

Placing a trading server in or next to an exchange’s data centre to cut the time orders and prices take to travel. It matters for a small group of very latency-sensitive strategies and is wasted money for most others. When you actually need co-location →

Continuous contract

A single price history stitched together from successive futures contracts, so a strategy can be tested over years instead of one contract’s short life. How the joins are adjusted changes the test, so it has to be a deliberate choice. Futures rollover and contract continuity →

Drawdown limit

A risk rule that stops or reduces trading once an account has fallen a set amount from its high point. It is one of the limits a trader sets and the software enforces.

End-of-day (EOD) data

One price bar per instrument per day: open, high, low, close and volume. Enough for many positional strategies, and far cheaper than tick data. Market-data engineering →

Execution engine

The part of a trading system that turns a decision into orders: it sizes them, checks them against risk limits, sends them to the broker and tracks what happens to them. Execution engines →

Expert Advisor (EA)

An automated strategy that runs inside MetaTrader 4 or 5, written in MQL4 or MQL5. It only trades while its MetaTrader terminal is running. MetaTrader development →

F&O (futures and options)

The common Indian name for the futures and options segment of an exchange, such as index and stock derivatives on NSE. Options trading automation →

FIX protocol

Financial Information eXchange, the standard message format banks, brokers and exchanges use to send orders and fills between systems. Institutional desks often connect over FIX. Institutional trading systems →

Funding rate

A periodic payment between long and short holders of a perpetual futures contract that keeps its price close to the spot price. A system holding perpetuals has to account for it. Crypto exchange integration →

IB Gateway

Interactive Brokers’ lightweight, screen-free program that a trading system connects to through the TWS API. It restarts daily and asks for a fresh login from time to time. Interactive Brokers API integration →

Idempotency

The property that repeating a request has the same effect as sending it once. In trading software it is what stops a retried or duplicated signal from becoming two orders.

Kill switch

A control that stops a trading system from placing new orders, and optionally cancels open ones, at once. Every live system should have one that a person can reach quickly. Edge cases in live trading systems →

Latency

The delay between an event and the system’s response, such as the time from a price change to an order reaching the exchange. Only some strategies are sensitive to it. Trading system architecture →

Limit order

An order to buy or sell at a set price or better. It controls the price but may not fill.

Look-ahead bias

A backtest error in which the rules use information that would not have been available at the time, such as a day’s closing price to make a decision earlier that day. It makes results look better than reality. How to backtest an options strategy →

Margin

The money a broker requires an account to hold to open or keep leveraged positions. A system has to check margin before it trades and react when the broker’s requirement changes.

Market data feed

A live stream of prices from a broker or a specialist provider. Feeds differ in speed, depth, history and cost, and the right one depends on the strategy. Market-data engineering →

Market order

An order to buy or sell at the best price available now. It fills quickly, at whatever price is available, which can be worse than expected in fast or thin markets.

Monte Carlo simulation

Re-running a strategy’s trades many times in shuffled or varied order to see the range of outcomes the same rules could produce. It shows how much of a result could be luck. Quantitative research →

Multi-leg order

One order that combines several instruments, such as the two or four options in a spread, so the legs fill together instead of one at a time. Options trading automation →

NinjaScript

The C#-based language used to write strategies, indicators and add-ons for NinjaTrader 8. NinjaTrader development →

OCO (one-cancels-other)

A pair of orders in which the fill of one automatically cancels the other, such as a profit target and a stop on the same position.

OMS and EMS

An order management system keeps the record of orders, positions and allocations across a firm; an execution management system works orders in the market. Institutional desks usually run both. Institutional trading systems →

Out-of-sample testing

Testing a strategy on data that was kept aside and never used while building or tuning it. It is the simplest guard against rules that only fit the past.

Overfitting

Tuning a strategy’s rules so closely to past data that they describe its noise rather than anything that repeats. An overfitted strategy looks excellent in a backtest and disappoints live. Case study: resisting overfitting →

Pacing violation

Interactive Brokers’ term for sending API requests faster than its limits allow. Repeated violations get requests rejected, so a system has to pace itself. Interactive Brokers API integration →

Paper trading

Running a system against a simulated account with live prices but no real money. It catches most engineering problems, though simulated fills are kinder than real ones.

Partial fill

When only part of an order is executed. A system has to track the filled and unfilled parts and decide what to do with the rest.

Perpetual futures

Futures contracts with no expiry date, common on crypto exchanges. They are kept near the spot price by the funding rate and are usually traded with leverage. Crypto trading automation →

Pine Script

TradingView’s language for indicators and strategies. Pine Script strategies run on TradingView; to trade them automatically at a broker they need webhooks or a rewrite. TradingView automation →

Position sizing

The rule that decides how large each trade is, for example a fixed quantity, a fixed amount of money, or a size based on the distance to the stop.

Rate limit

The maximum number of requests a broker or exchange API accepts in a period. Exceed it and requests are refused, sometimes at the worst moment. Broker API comparison →

Reconciliation

Regularly checking the system’s own record of orders and positions against what the broker reports, and resolving any difference. It is how a system stays sure of what it holds. Edge cases in live trading systems →

Repainting

When an indicator or signal changes its past values after new data arrives, so the history shows signals that were never visible in real time. A repainting strategy cannot be trusted live without changes. TradingView strategy to bot →

Rollover

Moving a futures position from an expiring contract to the next one. Automated systems need clear rules for when and how to roll. Futures rollover →

Slippage

The difference between the price a strategy expected and the price it actually got. It is a real cost and belongs in every honest backtest.

Stop order

An order that becomes active once the price reaches a set level, often used to exit a losing position. In a fast market it can fill well beyond that level.

Survivorship bias

Testing only on instruments that still exist today, leaving out the ones that were delisted or went bust. It flatters the results of many stock strategies.

Tick data

Every individual trade or quote, rather than summary bars. Needed for scalping and some arbitrage strategies; unnecessary and costly for most others. Market-data engineering →

Walk-forward analysis

Testing a strategy in rolling steps: tune it on one period, test it on the next unseen period, then move forward and repeat. It shows whether the rules hold up as conditions change. Quantitative research →

Webhook

A message one system sends to a web address when something happens, such as a TradingView alert firing. A webhook receiver turns that message into an action, after checking it. TradingView automation →

0DTE (zero days to expiry)

Options that expire on the day they are traded. Automating them demands fast data, careful strike selection and tight order handling. Case study: automating a 0DTE strategy →

Definitions are general and educational. They are not trading or investment advice.