You already know what an order block is. You can mark a fair value gap in your sleep, you know which killzone you trade, and you have watched price run the Asian high and reverse often enough to trust the model. So the open question is not whether ICT works for you. It is whether the version of it living in your head survives being written down as fixed code.
That question usually arrives the same way. You see an expert advisor for sale with a spotless equity curve, or a build tutorial that makes the whole thing look like a weekend project, and you start estimating how many weekends it would really cost — and whether the result would trade anything like you do.
Here is the short answer before the detail: an EA can detect almost every pattern in the ICT vocabulary, often more reliably than you can. What it struggles with is the sequence of decisions you make around those patterns. This article separates the two, names the exact decisions that break when you freeze them into rules, and gives you a way to place your own process on the automation scale.
Key Takeaways
The vocabulary can be automated; the strategy resists it. Order blocks, fair value gaps, sweeps, structure shifts and killzone windows are geometry and clock arithmetic — code handles them more consistently than you do.
Five decisions break when hard-coded: forming today's bias, choosing the real draw on liquidity, telling manipulation from a genuine break, rejecting valid-but-wrong setups, and managing the open trade.
Rejection rate is the hidden edge. A discretionary trader skips most technically valid setups; a rule-only EA takes them all, which is why it trades more and earns less per trade.
The hybrid model is the honest answer for most traders: the EA detects, alerts and executes the mechanics; you keep the judgment calls — and the alert log tells you later whether heavier automation is justified.
Table of Contents (20 min read)Contents
What "Automating ICT" Actually Means
Two very different projects hide under the same phrase, and almost every disappointing ICT bot is the result of confusing them.
The first project is automating the vocabulary. Order blocks, imbalances, equal highs, sweeps, displacement, session windows, premium and discount — these are geometric and time facts about a chart. Given a written definition, code finds them the same way every time, on every pair, at three in the morning, without getting bored. This project is entirely solvable on MetaTrader 5.
The second project is automating the strategy. That is the ordering, weighting and rejecting you do on top of the vocabulary: which of the eleven fair value gaps currently on your chart matters today, whether the sweep you just saw was the setup or the trap, and whether this particular instance is worth your risk at all. That project is not a detection problem. It is a judgment problem wearing a detection problem's clothes.
The vocabulary can be automated; the strategy resists it. Hold onto that sentence, because it explains almost every "my ICT bot backtests badly" post you will ever read. The builder usually wrote a competent detector, then bolted three crude proxies onto the places where their own judgment used to sit — and never noticed that the proxies, not the detector, were the strategy. An EA reads the geometry of a setup perfectly; the empty pedestal is the part of the job it never picks up.
The Building Blocks an EA Can Genuinely Detect
Before the pessimism, give code its due. The mechanical layer of ICT is real, substantial, and genuinely codable — this is not a case of a methodology being too vague to program.
Order blocks and fair value gaps. Both reduce to candle geometry: a specific body or wick relationship, a gap between two non-adjacent candles, a zone with coordinates and an expiry. An algorithm marks them faster and more consistently than a human with a rectangle tool.
Liquidity pools. Equal highs and lows, session extremes, prior-day and prior-week highs and lows are just coordinates. Mapping where resting liquidity sits is arithmetic, not intuition.
Sweeps. "Wick through the level, close back inside it" is a boolean test. Code evaluates it on every bar close without argument.
Market structure shifts. A displacement candle closing through a protected swing point is measurable. There is a well-defined subset of market structure shifts an EA can trade off, and detecting them is the easy part.
Killzones and session timing. This is the one place where automation is strictly better than you. A trading session filter applies the same windows in every timezone, through daylight-saving changes, without a single missed open.
The AMD daily cycle. Splitting the day into accumulation, manipulation and distribution windows, and flagging which phase price is in relative to the session, is scheduling plus range arithmetic.
Premium and discount. Dividing a dealing range and checking which half price is trading in is a single line of math.
There is one honest caveat here. Detection is not free of choices: how much displacement counts as displacement, how many candles a gap must survive, whether a swing point needs two or three bars either side. Two "correct" detectors will disagree on real charts. But these are definitional disagreements — you can write down each version, test it, and pick one. That is a different animal from the decisions in the next section, where there is no version to write down.
Where the Mechanics End and Judgment Begins
Here is the core of the answer. Five decisions sit between "a valid pattern exists" and "this trade gets taken," and every one of them is a judgment call rather than a measurement.
1. Forming today's bias. You read the higher timeframes and decide the market is more likely to reach for one side than the other. You are weighing a weekly draw against an unfilled daily gap against the way yesterday closed — and the same chart genuinely supports two readings. Ask three competent ICT traders for a bias on an ambiguous morning and you will get at least two answers. A rule that always returns one answer is not capturing the skill; it is hiding the ambiguity.
2. Choosing the real draw on liquidity. Your chart has several candidate pools at once: last week's high, an equal-highs cluster, a session extreme, an old wick. You pick the one price is actually reaching for based on context — how price arrived, what has already been taken, what time it is in the cycle. Code can list every pool perfectly and still have no basis for ranking them.
3. Telling manipulation from a genuine break. Structurally, the trap and the real move look almost identical at the moment they happen: price takes a level and pushes through. You separate them with the quality of the reaction — how fast, how deep, into what, against what backdrop. This is the single richest source of a false signal in any mechanized ICT build.
4. Filtering A+ setups from valid look-alikes. This is the one builders consistently underestimate. On a normal London session your detector might flag eight technically valid setups. You take one. That rejection rate is not housekeeping around the strategy — it is the strategy. A rule-only build has no rejection engine, so it takes all eight and pays the spread on seven of them.
5. Managing the open trade. Whether to take a partial into the first pool, hold for the next one, cut early when the reaction is wrong, or leave a runner alone through a retracement — you decide these live, from information that appears after entry. Fixed management rules are not wrong, but they turn a variable-outcome trade into a fixed-outcome one, and ICT trades are frequently won or lost after entry.
The automation boundary
What code owns, and what you still own
The mechanical layer
Order blocks, fair value gaps and imbalances located by pure candle geometry
Liquidity pools mapped as coordinates: equal highs and lows, session and prior-day extremes
Sweeps and displacement confirmed as a yes or no test on the bar close
Killzone windows applied exactly, in every timezone, on every pair, every day
Position sizing, stop placement, break-even and partials executed without hesitation
Code does this more consistently than you ever will.
VS
The judgment layer
Forming today's directional bias from a chart that honestly reads both ways
Choosing which liquidity pool is the real draw among several live candidates
Telling a manipulation leg from a genuine break while it is still happening
Rejecting the near-identical setup that is technically valid but wrong today
Deciding live whether to hold a runner, cut early, or leave the trade alone
Code can only approximate this with a proxy.
The split that decides your build: every item on the left is a measurement, every item on the right is an opinion.
What Happens When You Force the Judgment Calls Into Rules
Nobody sets out to skip the judgment layer. What happens instead is that each judgment call quietly becomes a proxy, because a proxy is the only thing you can compile:
Bias becomes "higher-timeframe close above or below the previous day's range."
Draw on liquidity becomes "the nearest untapped pool in the direction of bias."
Manipulation-versus-genuine becomes "require a displacement candle of at least N times average range."
A+ selection becomes "a confluence counter — take it if at least three of seven boxes tick."
Trade management becomes "break-even at 1R, fixed target at 2R."
Every one of those is defensible in isolation. Read them together and the problem is obvious: each proxy is a statement about the average day, and an ICT edge is mostly built out of the days that are not average. The proxy is right when it does not matter much and wrong precisely when it does.
The second-order effect is worse. Once the proxies exist, they become the parameters you tune. You now have seven knobs and a strategy tester, and the tester will happily hand back a set of values that made the last two years look excellent. That is textbook overfitting: you have not encoded your judgment, you have fitted a curve to the window you tested on.
Illustrative comparison
Every judgment call replaced by a proxy rule
Takes every setup that passes the confluence counter — roughly eight a week
Bias comes from a higher-timeframe close, so it is wrong on exactly the reversal days that matter most
Winners and losers end up close to the same size once management is fixed
Net over the sample: negative R, driven almost entirely by trades a human would never have taken
The same playbook, judgment left to the trader
Takes roughly one in eight of the same alerts; the rest are logged and skipped
Bias uses context the rule set never saw — the weekly draw, the news day, the shape of the sweep
Win rate improves only modestly; the real change is average winner versus average loser
Net over the sample: positive R, from far fewer trades
Same detector, same playbook, different result — created by the trades the discretionary version refuses to take.
An illustrative comparison, not a published result: the gap comes from rejection, not from better entries.
Treat that comparison as a shape, not a number. Two warnings apply to every version of it you will see online, including the ones with real equity curves attached. First, the discretionary side is usually run over a much shorter window than the automated side, because a human has to sit through every bar — a two-month manual run against a one-year automated run is not an apples-to-apples test, and a small sample size flatters whichever side got the shorter run. Second, a discretionary sample cannot be replayed; the rule-only side can be backtested again by anyone, and the human side cannot. If you want the broader picture rather than a single build, the aggregate data on whether ICT bots actually work is a separate question with its own evidence.
What survives both warnings is the mechanism, and the mechanism is not controversial: the rule-only version trades far more often at a lower quality threshold. Its expectancy per trade falls, its trade count rises, and costs scale with the trade count. Anything you commit real money to belongs behind our risk warning — an ICT EA is not a shortcut around that, it is a faster way to find out whether the edge was ever there.
Can ICT Be Partially Automated?
Yes — and for most readers this is the honest answer rather than a consolation prize.
The division of labour writes itself once you accept the split: give the machine every fact and every execution mechanic; keep every opinion. In practice that means the EA scans your whole watchlist through the right session windows, confirms the sweep and the structure shift, and then stops and taps you on the shoulder. You supply bias, draw, the manipulation read and the take-or-skip. Once you confirm, the EA goes back to being a machine: sizing the position to your risk per trade, placing the stop and target, moving to a break-even stop at your defined point, and scaling out on schedule.
The practical middle path
The hybrid loop: the EA detects, you decide, the EA executes
1
The EA holds the session window
It watches every pair on your list through the killzones you defined, without fatigue and without quietly drifting off the plan at 3 a.m.
2
It detects, then it stops
Sweep, displacement, structure shift, zone. The geometry is confirmed in code, the setup is marked, and the EA goes no further on its own.
3
You get the alert with context
The alert names the pair, the level that was swept and the zone in play, so you arrive at the chart with the read already framed.
4
You make the four calls
Bias, draw, manipulation or genuine, A+ or skip. This is the part you are deliberately not delegating.
5
The EA executes the mechanics
On your confirmation it sizes to your risk, places stop and target, moves to break-even and takes partials exactly as specified.
Detection and execution are machine work; the four calls in the middle stay yours.
Three practical notes make this model work rather than annoy you:
Alerts must carry context, not just a ping. A push notification reading "EURUSD setup" is noise. One naming the swept level, the session and the zone lets you judge in seconds instead of rebuilding the chart from scratch.
Run it where it never sleeps. A detection EA on your laptop misses the sessions you are asleep for, which is most of the reason you wanted it. A VPS plus a kill switch for news days or bad weeks is the whole infrastructure requirement.
Log every alert, including the ones you skip. This is the quiet payoff nobody mentions. After a few months you can compare the trades you took against the alerts you rejected and find out, with your own data, whether your judgment is adding anything. If the skipped alerts would have performed as well as your picks, your selectivity is a story rather than an edge — and heavier automation suddenly makes sense.
That last point is the reason the hybrid model is not a compromise. It is the only configuration that measures the thing you are arguing about.
Choosing Your Own Automation Level
The right level is not a matter of taste. It depends on two properties of your own trading that you can check today.
Self-assessment
Which automation level fits your ICT process?
Take itProceed with careSkip / stand aside
The gate is not coding skill — it is whether your process is written down well enough for a stranger to reproduce it.
Two questions place you: is the process reproducible, and does your edge come from picking few trades or covering many?
Four checks sharpen the same decision:
Is your bias rule writable? If you cannot state it so that a stranger reaches your conclusion from the same chart most of the time, it is not a rule yet — it is a skill, and skills do not compile.
How long has your playbook been stable? A process you have changed twice this quarter is not a specification. Automating it just freezes the current draft.
Where does your edge live? Selectivity is the hard thing to automate. Coverage is the easy thing — and it is the case where a machine genuinely beats you, because it can watch twenty pairs through every session.
Have you forward-tested anything before? If not, budget for that, not for the build. The coding is rarely the long part; the months of watching it behave on live data are.
If you decide the answer is a real build, the mechanics of building an ICT EA on MT5 — the strategy-to-code workflow, testing and deployment — are a separate job from this feasibility question, and worth treating as one.
The Honest Bottom Line
You can automate ICT. You cannot automate an ICT trader. Those two sentences are not a contradiction, and the difference between them is the entire subject.
Everything in the ICT vocabulary is codable, and on execution the EA beats manual trading: no missed session, no rectangle drawn slightly wrong, no fatigue at the end of a long week. What does not transfer is the layer that decides which of those detections deserves risk today. When people say a strategy is "too discretionary to automate," this is what they mean, even when they cannot name it — not that the patterns are vague, but that the selection among valid patterns is where the edge was hiding the whole time.
So the practical verdict, for most people asking this question: build the detector, keep the judgment, and let the two of you specialize. If a year of alert logs later shows your judgment was not the thing adding value, you will have earned the right to automate it — and the data to do it properly. That is a far better position than starting from a fully autonomous build and spending six months tuning proxies for decisions you were making well by hand.
FAQ
Can an EA detect order blocks and fair value gaps accurately?
Yes, with one qualification. The detection itself is candle geometry and code does it consistently, but "accurately" depends on the definition you gave it. Two reasonable definitions of displacement or of a valid gap will mark different zones on the same chart. Pick one definition, test it, and be aware that a disagreement with your eye is usually a definition mismatch rather than a bug.
Why does an ICT EA often underperform the trader who built it?
Because the trader rejects most of what the detector finds, and the EA rejects almost nothing. The builder's selectivity — refusing valid-but-wrong setups — never made it into the code, because it was never written down. The EA then trades many more times at a lower quality threshold, and costs scale with every one of those extra trades.
Is a semi-automated ICT setup actually worth building?
For most discretionary ICT traders, it is the highest-return version of the project. It costs a fraction of a fully autonomous build, it removes the failure modes that are genuinely mechanical (missed sessions, sloppy sizing, forgotten break-even), and it leaves the judgment layer where it currently works. It also produces the alert log that tells you whether full automation is justified later.
Can AI or machine learning solve the judgment problem?
It moves the problem rather than removing it. A model can learn a statistical version of "which setups looked like the good ones," which is genuinely more flexible than a confluence counter. But it needs a large, labelled, honest history of your decisions to learn from, it inherits every bias in that history, and it will fail in unfamiliar regimes without telling you it is failing. Be especially wary of any product that advertises AI as if it removed risk — regulators publish warnings about exactly that claim.
What should I automate first if I only do one thing?
Session timing and alerting. It is the cheapest piece to build, it is the piece where a machine is unambiguously better than a human, and it changes your trading immediately: you stop missing setups because you were asleep, in a meeting, or looking at the wrong pair. Everything else can wait until you have watched that run for a few months.
Sources & Further Reading
Want to go deeper? These independent, authoritative sources shaped this guide — each one is worth reading in full:
The Cross-Market Desk is the SignalBots editorial team for topics that span every market — platform connectors, copy trading, partnership and IB programs, and the general mechanics of trading automation. We research and write the guides that apply no matter what you trade.
Discussions 0
Leave a comment