Strip the marketing off any automated trading system and what's left is a loop doing four things. It receives prices. It checks whether a set of conditions is true. If they are, it builds an order. Then it writes down what it did, so it knows where it stands next time around.
That's the whole machine. Everything that goes wrong with one of these systems goes wrong at one of those four points, which is reason enough to know what each of them does.
The four stages
| Stage | What happens | What it produces | How often it runs |
|---|---|---|---|
| 1. Market data | Prices arrive from the exchange through the platform | Ticks, assembled into bars | Continuously, thousands of times a minute |
| 2. Evaluation | Conditions are checked against the current data | True or false | Once per bar, or once per tick |
| 3. Order construction | Entry, stop and target are built and sent | Live orders resting at the exchange | Only when the conditions are true |
| 4. State and logging | The system records what it holds and what it did | Position, order IDs, a written record | Every time anything changes |
The strategy logic (the part everyone argues about) is stage two, and it's the smallest piece of code in the system. What makes an automated system reliable or unreliable lives in stages one, three and four: the data it sees, the orders it builds, and whether it knows what it already holds.
Stage one: the market data feed
Everything starts with prices arriving. Your platform holds a connection to a data provider, which is connected to the exchange. For US index futures that exchange is the CME. Every transaction generates a tick: a price, a size, a timestamp and a note of whether it hit the bid or the ask.
Tick data is a torrent. Around the 8:30 AM ET release, thousands of ticks per second is normal, and almost no strategy consumes that raw.
Bars versus ticks
So ticks get aggregated into bars. A bar collects everything inside some boundary and reduces it to five numbers: open, high, low, close, volume. The boundary is usually time (a 1-minute bar, a 5-minute bar), but it doesn't have to be. A 1,000-tick bar closes every thousand transactions; a volume bar closes every N contracts traded; a range bar closes when price has moved a fixed distance.
The choice is not cosmetic, because a bar is when your strategy is allowed to think. With time bars, activity is uneven: a 5-minute bar at 3 AM might hold four ticks and one at 8:30 AM forty thousand. With tick or volume bars each bar holds the same amount of activity, so bars form faster when the market is busy and the strategy looks more often exactly when things are moving. For a system built around a data release, that difference is the design.
Bars also decide when a decision becomes final. Most strategies evaluate on the close of a bar, because a forming bar can still change: a high can be exceeded, and a close isn't a close until the bar ends. A strategy that acts on an in-progress bar can enter on a condition that stops being true one tick later. Backtests that make this mistake produce beautiful results nobody can reproduce live.
Stage two: evaluating the conditions
Every time a bar closes the platform hands your strategy a call (in NinjaTrader 8, a method that runs on each bar update) and the strategy answers a series of yes/no questions.
The questions are ordinary. Is it inside the trading window. Has it traded already today. Are the conditions present in the data. Is there enough history loaded. Is a position already open. Only if every answer is the right one does anything happen.
Notice how many have nothing to do with market analysis. Most of a strategy is refusing to trade. Rentabilio evaluates once a day, in one window at 8:30 AM ET, when US economic data is released and the pre-open starts moving with intent. Every other bar of the day the first condition fails and nothing else is checked. That isn't a limitation, it's most of the edge. There is more in how it works and what a trading bot actually is.
Order matters too. Cheap conditions go first: checking the clock costs nothing, computing an indicator over 200 bars costs something. And conditions must be written so two can't be true at once, or you get a system trying to buy and sell simultaneously. That bug surfaces on the one day the market does something unusual.
Stage three: building the order
Conditions are true. Now the strategy turns intention into instructions a broker will accept, and this is where careless systems give back what the strategy earned.
A serious entry is not one order. It's three, sent as a bracket: the entry, a protective stop below (for a long) and a profit target above. Stop and target are linked so one cancels the other: fill the target and the stop is pulled automatically. Without that link you close a winner and leave a live stop sitting in the market, waiting to open a position you never wanted.
Rentabilio places the stop and the target in the same instant as the entry, with the target at 2× the risk. The worst case is defined before anything can happen. That matters more than it sounds: a system that computes its stop after the entry fills has a window, however brief, where its risk is undefined.
Why the order type changes what you pay
Order type decides the trade-off between certainty of fill and certainty of price. You only get one.
- Market order. Fills immediately at whatever is available. Certain to get in, uncertain what you'll pay. In a thin book during a release, the gap between the price you saw and the price you got can be several ticks.
- Limit order. Fills only at your price or better. You control the price and give up certainty: if the market runs without you, there's no trade.
- Stop order. Rests until price reaches a trigger, then becomes a market order. This is what a protective stop usually is, which is why a stop doesn't guarantee your exit price: it guarantees an attempt, and in a fast move you can fill beyond it.
- Stop-limit. Triggers like a stop, then behaves like a limit. It protects your price and introduces the worst outcome available: a losing position with the protective order unfilled because price blew through the limit.
None of this is theoretical at 8:30 AM ET. The seconds around a scheduled release are when spreads widen and books thin out, and a backtest assuming perfect fills at the bar close overstates results in exactly that window. Any backtest worth reading subtracts costs: the numbers here are quoted gross and net, about 5% off at roughly $1 per micro contract. See slippage and commissions.
88 months of day-by-day simulation, 4,557 trades, every one a bracket with the stop and target placed on entry.
Stage four: state, and why it decides everything
A strategy is not a formula. It's a machine with a memory, and the memory is called state.
At minimum it has to know: am I in a position, and which way. How many contracts. Have I traded today already. What working orders do I have and what are their IDs. Where is the stop, where is the target.
Without state, a strategy whose conditions stay true for three consecutive bars enters three times. It believes it's flat every time it's asked, because nothing told it otherwise. That single bug has emptied more accounts than any bad prediction, and it doesn't look like a bug: it looks like a system that suddenly took triple size.
A strategy that doesn't know what it already owns will happily buy it again.
State also has to survive the world. Orders get rejected. Fills arrive partially, leaving you long two contracts when you asked for five. A stop can fill while a target is still working. Each of those needs an update in the strategy's own record, driven by what the broker reports rather than what the strategy assumed.
What happens when the platform restarts
Here is the scenario that separates careful systems from the rest. You are long, stop and target resting at the exchange, and the platform crashes. Or Windows updates. Or the power goes out.
Two things are true at once. Your strategy's state is gone, because it lived in memory. Your orders are not: they're at the exchange, working, exactly as sent. That is the whole argument for real orders over software-held stops: your machine can die and the risk stays capped.
When the platform comes back, the strategy has to be told what it holds rather than assuming it holds nothing. NinjaTrader has explicit handling for this, and how a strategy is set to resume (adopt the existing position, or start flat and leave the old orders alone) is a real decision with real consequences. A system that restarts and re-enters a position it already holds has just doubled your size without telling you.
The practical version is boring and effective: restart before the session, not during it, and check the position after any interruption. More on that in what can go wrong.
What breaks at each stage
Why the boring stages are what you should ask about
Sellers talk about stage two because that's where the story lives. Most of your questions belong everywhere else: what data it needs, whether the backtest evaluated on closed bars, whether stop and target are real orders at the exchange, what it does on restart, what happens on a rejection or a partial fill.
The published Rentabilio simulation runs 88 months on a $50,000 account: $274,406 gross, ≈$260,700 net after commissions, 4,557 trades, a 46.2% win rate and a $4,379 maximum drawdown. Every trade is a bracket built the same way, which is the only reason the run is reproducible. Load the strategy into the Strategy Analyzer and the same trades come out. That's a property of the plumbing, not the strategy. The full report is on the performance page.
Hypothetical performance. Those figures come from a backtest over historical data, not a live account. Simulated results are prepared with the benefit of hindsight, carry no financial risk, and cannot fully account for real execution, slippage or liquidity. Past performance, real or simulated, does not guarantee future results.
Frequently asked questions
Does a trading algorithm run on ticks or on bars?
Both are used, and the choice shapes the strategy. Bar-based systems evaluate when a bar closes, which is slower but far more stable, since a closed bar can no longer change. Tick-based systems react to individual transactions where speed matters, at the cost of much more processing and far more noise. Most retail systems on NinjaTrader are bar-based, and most should be.
What is a bracket order?
A bracket is an entry paired with a protective stop and a profit target, linked so filling one cancels the other. It defines the trade's best and worst outcomes before the market can move against you. The alternative (entering first and adding protection afterward) leaves a window where the position has no defined risk, which is exactly when a fast market finds you.
Why does my live result differ from the backtest?
Mostly execution. A backtest assumes fills at prices available in historical data, while live trading gives you what was actually there when your order arrived, including slippage and spread. Commissions, data quality and the exact moment of evaluation contribute too. This is why a serious backtest subtracts realistic costs, and why the gap should be small rather than absent.
What happens to my orders if my computer turns off?
Orders already sent to the exchange stay live, because they exist on the broker's systems rather than yours. Your strategy stops watching and cannot react to anything new, but the stop and target keep protecting the position. That is the practical argument for real orders over software-held stops, and the reason to check your position on the platform as soon as you are back online.
Do I need to understand the code to use a system?
No, but you should understand the four stages well enough to ask the right questions. What data it needs, when it evaluates, what orders it sends and how it handles a restart are things any seller can answer plainly. Vague answers tell you something about the engineering regardless of the strategy. The rest of the checklist is in how to choose a trading bot.