Build Simple Algorithmic Logic
Turn rules into logic
The conversion from idea to logic is mostly an exercise in removing words that cannot be checked.
"Enter when the market looks ready" is an intention. "Enter when price closes back inside the zone after trading through it" is a condition. The difference is that the second one is either satisfied or not, and you can tell which within a second.
If-then conditions
Write each rule as a condition and a consequence. If structure on the hourly chart is rising, then only upward setups are permitted. If price has entered a marked zone and closed back out of it, then the trigger is met. If the loss cap is reached, then the session ends. Each sentence has a test in it, and the test is what makes the rule enforceable against yourself.
Entry and exit rules
On a fixed-expiry contract the exit is the expiry, which tempts people to skip the exit rule entirely. It still has to be decided: which expiry length, chosen in advance, matched to how long the idea takes to resolve. Write it as a rule rather than a habit, because habits drift after a near miss and rules do not.
- Regime. Read the higher chart and record one word: trending, ranging or unresolved. Unresolved permits nothing.
- Direction. If trending, record up or down. Only setups pointing that way are permitted for the session.
- Location. Mark two or three zones before the session. Setups outside a zone do not exist.
- Trigger. One price event, defined numerically. A close beyond, or a close back inside, with a stated proportion of the candle.
- Confirmation. One independent check, stated as a yes or no question. Momentum on the correct side of its midline, or the next candle continuing.
- Stake. A fixed fraction of the balance, unchanged inside the session.
- Expiry. One length, chosen in advance and constant for the session.
- Stop. A trade count, a loss cap and a clock. First one reached ends the session.
There is a useful order to writing these for the first time. Start from the trade you are most confident about, the one you would take without hesitation, and describe it condition by condition until the page reproduces it. That gives you a system built around something you already believe rather than around an idea borrowed from an article. Afterwards you can widen it, but starting from a borrowed system means the first losing week arrives with no conviction behind the rules and they get abandoned.
A written checklist
Keep the whole thing on one page and read it before every session. The reading is not ceremony: a rule you have not read in two weeks has already started drifting, and you will not notice because the drift happens in the direction of taking more trades. Traders who keep the checklist visible on the desk report the same thing, which is that the rules they break are the rules they cannot currently see.
One more property is worth designing in from the start. Every rule should be recordable in your log with a single mark, so that afterwards you can tell which rule was met and which was approximated. A checklist that cannot be scored produces the same problem as an unwritten one, arriving a month later.
A rule is logic when two readers would agree on whether it is satisfied. Anything less is an intention.
Keep the system simple
The pressure in system building is always toward more conditions, and almost every addition makes the system worse in a way that is invisible at the time.
The reason is not aesthetic. Each additional condition reduces how often the full set aligns, which shrinks your sample, and it increases the chance that the set is describing the specific history you built it on rather than anything durable.
Few clear conditions
Four or five conditions is a working system. Beyond that, two things happen together: setups become rare enough that you get impatient, and the rare setups that do appear cannot be assessed because there are too few of them. Impatience plus an unassessable sample is the exact combination that produces improvisation, which is what the system was written to prevent.
Avoiding over-fitting
Over-fitting is adding conditions until past losses disappear. It feels like refinement and it is closer to memorisation. The tell is that each new condition is introduced to exclude a specific bad trade you remember rather than because it follows from the idea. A useful discipline is to require that every condition can be justified before you look at the results, in terms of what it says about the market rather than about your record.
| System property | Healthy | Warning sign |
|---|---|---|
| Condition count | Four or five | Growing after every losing week |
| Setup frequency | A few per session | Rare enough that you wait days |
| Reason for each condition | Explains something about the market | Excludes a specific remembered loss |
| Parameter precision | Round, unfussy values | Oddly specific numbers arrived at by tuning |
| Stability | Unchanged for a month at a time | Edited mid-week |
Notice also that simplicity protects the sample. A system firing several times a session accumulates a hundred observations in a few weeks; one firing twice a week takes most of a year to say anything. Since the whole purpose of writing rules down is to make your record readable, a condition that halves your setup count has doubled the time until you learn anything. That cost is real and it is almost never weighed against the supposed improvement the condition brings.
Reproducible steps
Reproducibility is the property that makes a system worth having. If you can hand the page to someone else and they can apply it, the system exists independently of your mood, which is the entire point. If applying it requires your judgement at several points, you have written a description of how you trade rather than a system, and it will drift exactly as your judgement drifts.
A practical test costs ten minutes: take a chart from a week ago, apply your written rules from left to right without looking ahead, and mark every entry. If you find yourself needing to make calls the page does not cover, those are the gaps. Fill them with conditions, not with intentions.
Four or five conditions, each justifiable before you see the results, unchanged for a month at a time.
Backtest honestly
Testing a system against history is useful and easy to do dishonestly, usually without any intention to deceive.
The dishonesty is structural rather than moral: you know what happened next, and that knowledge leaks into every decision you make while testing unless the process prevents it.
It helps to separate two questions that testing usually blurs. The first is whether the rules describe something real about the market. The second is whether you can apply them. A backtest can only address the first, and it addresses it weakly. The second is answered by running the rules forward on the practice account, where you experience the waiting, the near misses and the temptation to adjust. Both questions matter, and forward testing is the one most people skip in favour of the version that can be completed in an afternoon.
Adequate sample size
A handful of examples proves nothing, because runs of good and bad outcomes occur constantly by chance. What counts as adequate depends on how often your system fires, but the principle is that the sample must be large enough that a lucky stretch cannot account for the result. If your rules produce very few setups, gathering an adequate sample takes months, and that is information about the system rather than an obstacle to be worked around.
Out-of-sample checks
Develop the rules on one period, then freeze them and apply them unchanged to a different period you did not look at while developing. This is the single most valuable step in the whole exercise, and it is the one almost always skipped, because the result is frequently disappointing. A system that performs on the development period and not on the untouched one has been fitted rather than discovered, and finding that out costs nothing except the illusion.
A second bias worth guarding against is period selection. Testing on the most recent three months is convenient and tells you about three months of one market condition. If the period you chose contained a strong trend, a trend-following system will look excellent and a range system will look broken, and neither result says much. Where you can, test across a stretch that visibly contains more than one condition, and note which parts of it produced which outcomes.
Realistic assumptions
- Test bar by bar, left to right. Never with the later chart visible.
- Count the setups you would have missed. Sleeping, working, away from the screen.
- Include the payout arithmetic. A hit count means nothing without it.
- Record ambiguous cases as taken. In real time you would have taken them.
The last point matters more than it looks. Historical testing has a strong tendency to resolve every borderline case in the system's favour, because you can see how it turned out. Deciding in advance that ambiguity counts as a trade removes most of that bias and usually removes a good deal of the apparent performance with it, which is the correct outcome.
Develop on one period, freeze the rules, run them untouched on another. That single step separates a system from a memory.
Know a system's limits
A system is a way of behaving consistently, not a claim about the future, and confusing the two is where systematic traders get into trouble.
The limits below are not defects to engineer away. They follow from the fact that rules are written from past behaviour and markets are not obliged to continue behaving that way.
Markets change
Conditions that produced your setups can persist for months and then stop. Participation shifts, volatility regimes change, and a rule tuned to one environment finds fewer valid setups or the same number with different outcomes. Nothing in your written page notices this, which is why a review schedule is part of the system rather than an optional extra.
No permanent edge
Even a rule set well matched to current conditions is describing something temporary. That is not pessimism; it is the reason review exists and the reason a system should be simple enough to reassess. Complex systems are hard to review, so their owners tend to keep running them long after the assessment should have happened.
Reviews also need a defined trigger for stopping, not just for adjusting. Decide in advance what would make you shelve the system entirely: a number of consecutive sessions without a qualifying setup, or a stretch where the conditions your rules assume have plainly disappeared from the chart. Without that, a system tends to be run indefinitely at a lower and lower standard, because each individual week never looks bad enough to justify stopping.
Discipline to follow it
The most common failure of a systematic approach is not that the system stopped working but that it stopped being followed. Drift is gradual: a setup taken at four conditions out of five, then three, then a trade taken because the session had been quiet. Your log is the only instrument that detects this, and it detects it easily if you mark each entry as full or partial. You can run the checklist live on virtual funds for a few weeks and see your own drift rate before any money is involved, which is a more useful number than anything a backtest produces.
- Review on a schedule. A fixed day, whether or not anything feels wrong.
- Change one thing at a time. Two changes make the result unreadable.
- Date every change. So the record splits cleanly into before and after.
- Track full versus partial entries. The drift rate is the health measure.
Systems decay and traders drift. A dated review schedule and a full-versus-partial mark catch both.
Algo-logic takeaways
Writing the system down is the whole exercise. Everything after that is maintenance.
Structure beats guessing
A written checklist does not make you right more often. It makes your decisions comparable, which means your record becomes evidence instead of a collection of anecdotes. That is the difference between a trader who improves over a year and one who has the same year several times, and it costs one page and ten minutes.
Simplicity endures
Few conditions, round parameters, no rule added to explain away a remembered loss. Simple systems are testable, reviewable and followable, and each of those properties fails first in complicated ones. If you find yourself unable to explain a condition without referring to your own trade history, that condition is fitted rather than reasoned.
- Every rule has a test. Satisfied or not, in a second.
- Four or five conditions. Enough to filter, few enough to fire.
- Frozen rules, fresh data. The honest test.
- Scheduled review, one change at a time. Maintenance, not reaction.
Worth naming as well: a system does not have to be original. Most durable rule sets are ordinary combinations of direction, location and a trigger, and their value lies in being applied consistently rather than in containing an insight nobody else has. Traders searching for a novel edge often skip the consistency, which is where the actual difference is made. Ordinary rules followed exactly beat clever rules followed loosely, and that comparison is one you can run on yourself within a month.
No system guarantees profit
Nothing on this page produces certainty, and any product claiming otherwise is described on the scam-bot page. A system clears the payout arithmetic or it does not, and only your own record over a meaningful stretch can tell you which. What a written system does guarantee is that you will know why you took each trade, which turns a losing month into information rather than into a reason to start over. That is a modest promise and it is the only honest one available.
Write it, freeze it, test it on data you did not use, review it on a schedule. That is the entire discipline.
What readers ask about this setup
Do I need to know how to code to build a trading system?
No, and starting with code is usually a mistake. A system is a written checklist precise enough that two readers would reach the same decision on the same chart, and a page of if-then conditions does that job. Code becomes relevant only after the rules have survived manual testing, and by then it introduces the platform question about automated software, which the bot-rules page covers.
How many rules should a simple system have?
Four or five conditions covering regime, direction, location, trigger and stake is a working system. Beyond that, setups become rare enough that you lose patience, and the sample becomes too small to assess. Systems that grow after every losing week are being fitted to memory rather than developed, and the growth is the symptom rather than the fix.
What is out-of-sample testing and why does it matter?
You develop the rules on one period, then freeze them and apply them unchanged to a period you did not look at while developing. It matters because any set of rules can be improved indefinitely against history it was shaped on. The untouched period is the only part of the test that carries information, and it is the step most often skipped because the result is frequently disappointing.
How do I avoid over-fitting my rules?
Require that every condition can be justified in terms of what it says about the market, before you look at what it does to your results. Conditions added to exclude a specific remembered loss are memorisation. Round, unfussy parameter values and a stable condition count are both good signs; oddly specific numbers arrived at by tuning are the opposite.
How long should I run a system before changing it?
Long enough that a run of luck in either direction cannot explain the result, and with changes made on a schedule rather than in reaction to a bad week. When you do change something, change one thing, date it, and treat the record as split at that point. Two simultaneous changes leave you unable to say afterwards which one mattered.