1. From backtest to market: what changes when the money is real

Level 13: Connecting to Real Brokers

In Level 12 you built a rigorous backtest: walk-forward, transaction costs, no look-ahead bias. That backtest is a simulation in which you control absolutely everything. You decide the price at which each trade executes, you decide that the order always fills, and you decide that the data arrives on time. In the real market you control none of that.

The fundamental difference is this: a backtest computes returns, a live system sends orders. They are two different engineering problems. The backtest is a data analysis problem; the live system is a distributed systems problem, with networks, latency, partial failures and state shared between your machine and the broker.

These are the new things that appear the moment you really connect:

• Latency. Between your model generating the signal and the order reaching the matching engine, milliseconds or seconds go by. The price may have moved.
• Slippage. The price at which you actually execute is rarely the price you saw on screen. In the backtest you estimated it; live, you measure it.
• Partial fills. You ask for 100 shares and get filled on 40. Your position is no longer what your code believed.
• Rejections. Insufficient funds, price out of range, market closed, rate limit exceeded. The API says no, and your program has to know what to do with that no.
• Operational risk. Your internet drops, the process dies, the server reboots. The position in the market stays open even though your program has died.

From this comes the most important rule of the whole level: the source of truth for state is the broker, not your local variable. If your code holds a variable position = 100 and the broker says you have 40, the broker is right. A well-designed system periodically queries the real state of positions and open orders, and reconciles what it believes with what is actually there. That process is called reconciliation and it is not optional.

The minimum architecture of a live system has five separate pieces, and they should be genuinely separate, in distinct modules:

1. Data ingestion: receive prices, clean them, detect gaps.

2. Signal engine: exactly the same code you used in the backtest. If it is not the same code, you are testing one strategy and executing another.

3. Risk manager: decides whether the signal becomes an order and at what size, and holds veto power.

4. Execution: turns the decision into API calls, handles retries and confirmations.

5. State and reconciliation: what I hold, what I asked for, what has been filled.

Having the signal engine be literally the same module you ran in the backtest is what makes it possible to compare real performance with simulated performance afterwards. If the logic is duplicated in two places, sooner or later they diverge and you will never know again whether the difference comes from the market or from a bug.