Introduction to Algorithmic Trading

Why this lesson matters

Algorithmic trading is not just “write code that buys and sells.” It is the engineering of a decision system that observes market data, evaluates rules or models, manages risk, and sends orders under real-world constraints.

Because this is the first lesson, we’ll set the mental model for the whole course:

• What an algorithmic trading system actually does
• Why time series data is central
• Where C++ fits well
• How to think about risk before thinking about profit

In later lessons, we’ll go deeper into data retrieval, preprocessing, modeling, backtesting, and deployment. For now, we’ll build the map.

What is algorithmic trading?

Algorithmic trading means using a computer program to make or assist trading decisions.

At minimum, an algorithmic trading system answers four questions:

1. What is happening?
   Read market data: prices, volumes, timestamps, spreads, order book updates.

2. What does it mean?
   Transform raw events into useful state: returns, ranges, moving measures, volatility estimates, or custom features.

3. What should we do?
   Produce an action: buy, sell, reduce exposure, wait, cancel, rebalance.

4. Are we allowed to do it?
   Apply risk, sizing, capital, and operational constraints.

The key idea: the algorithm does not need to be complicated. It needs to be explicit, testable, and controlled.

The trading system lifecycle

A practical trading system is usually a pipeline:

Market Data
    ↓
Data Handling
    ↓
Signal / Strategy Logic
    ↓
Risk Controls
    ↓
Order Generation
    ↓
Execution / Monitoring
    ↓
Performance Review

This course follows that same path. Today we focus on the overall shape of the system, not the full implementation of each stage.

A useful habit: separate research logic from execution logic. A promising idea is not production-ready until it can survive bad data, delays, sizing limits, and unexpected market behavior.

A minimal trading decision loop

With your C++ background, think of an algorithmic trader as a program that receives events and produces intentions.

An intention is not the same as a filled trade. It is simply what the strategy wants to do before brokerage rules, liquidity, slippage, and risk checks are considered.

The example below is intentionally simple. It shows structure, not a real strategy.

```cpp
#include <iostream>
#include <string>

struct Tick {
    double price;
    int volume;
};

struct OrderIntent {
    std::string side;   // "BUY", "SELL", or "HOLD"
    int quantity;
};

OrderIntent decide(const Tick& tick, double referencePrice) {
    if (tick.price < referencePrice * 0.99) {
        return {"BUY", 10};
    }
    if (tick.price > referencePrice * 1.01) {
        return {"SELL", 10};
    }
    return {"HOLD", 0};
}

int main() {
    Tick latest{98.50, 1200};
    double referencePrice = 100.00;

    OrderIntent intent = decide(latest, referencePrice);

    std::cout << "Latest price: " << latest.price << "\n";
    std::cout << "Decision: " << intent.side
              << " " << intent.quantity << " units\n";

    return 0;
}
```

Quick check

In an algorithmic trading system, what is the best description of a strategy’s role?

Markets are dynamic time series

Financial data is ordered by time. That sounds obvious, but it changes how we program.

A trading algorithm usually does not process one isolated value. It processes a sequence:

t0: price = 100.00
t1: price = 100.15
t2: price =  99.90
t3: price = 100.40

From that sequence, the algorithm may care about:

• The latest value
• The change from previous values
• The behavior over a recent window
• The difference between multiple time frames
• Whether incoming data is delayed, missing, or inconsistent

Later, we’ll build more formal data retrieval and preprocessing flows. For now, remember: in trading, time order is part of the data.

Risk controls are not optional

A trading algorithm can be logically correct and still dangerous.

Examples:

• It can request too much size.
• It can trade during abnormal data conditions.
• It can keep buying when exposure is already high.
• It can react to a bad tick as if it were real.

A healthy architecture treats strategy output as a proposal, not a command. Risk logic can reduce, reject, or delay that proposal.

Here is a tiny C++ example of a risk guard that caps order size before execution.

```cpp
#include <iostream>
#include <algorithm>
#include <string>

struct OrderIntent {
    std::string side;
    int quantity;
};

OrderIntent applyRiskLimit(const OrderIntent& intent, int maxQuantity) {
    OrderIntent adjusted = intent;
    adjusted.quantity = std::min(intent.quantity, maxQuantity);

    if (adjusted.quantity <= 0) {
        adjusted.side = "HOLD";
        adjusted.quantity = 0;
    }

    return adjusted;
}

int main() {
    OrderIntent proposed{"BUY", 250};
    int maxAllowed = 100;

    OrderIntent approved = applyRiskLimit(proposed, maxAllowed);

    std::cout << "Proposed: " << proposed.side << " " << proposed.quantity << "\n";
    std::cout << "Approved: " << approved.side << " " << approved.quantity << "\n";

    return 0;
}
```

True or false?

If a trading algorithm is automated, it no longer needs risk limits because it follows code exactly.

Innovative does not mean uncontrolled

Your interest in alternative algorithms is valuable. Many useful trading ideas come from non-obvious ways of viewing data:

• Regime changes instead of fixed signals
• Event-driven behavior instead of only fixed time bars
• Multi-time-frame agreement or disagreement
• Nonlinear curves and parabolic-style relationships
• Custom market state machines

But every innovative idea still needs the same engineering discipline:

Clear input → explicit logic → controlled output → measurable result

A creative algorithm becomes useful only when it can be tested, explained, monitored, and constrained.

Fill in the blank

In trading systems, a strategy’s proposed buy, sell, or hold action before execution is often best thought of as an order ____.