ICT models

What an ICT model actually is

An ICT model is a recipe that combines the blocks in a fixed order: a point of interest on a higher timeframe, a structure shift on a lower one, then an entry into the imbalance that shift left behind.

What the most widely taught ICT models add relative to one another comes down to very little: a retracement demanded on top, a divergence, a time window. The skeleton stays the same.

If the acronyms still slow you down, the lesson Getting started with ICT translates the vocabulary and says where the corpus comes from. This lesson redefines nothing, it assembles.

A model is therefore a chain of conditions, and each condition is a block. That is where everything else is decided: if you misread structure, the whole thing collapses, and you will wrongly conclude that the model does not work.

⚠️ It is also what makes a model hard to judge honestly. One that fails may have failed because it is poor, or because it was applied to a false reading. Without a record that notes the reading AND the result, you will never know which.

The five recipes, and what they share

The most common cuts keep five of them, and they resemble each other more than they differ. All demand a direction decided in advance, a level to sit at, and a trigger.

What changes from one recipe to the next is the trigger. A structure break on a lower timeframe for one, a liquidity sweep for the second, a divergence between two instruments for the third, a time window for the fourth, a measured retracement for the fifth.

Every one of those triggers already has its own lesson in this course, and that is the important point: a model adds no new knowledge, it fixes an order. The value of the order is what has to be measured, not the value of the blocks taken separately.

The real benefit of a written recipe is that it stops you changing your mind halfway. A condition written before the open cannot be renegotiated at noon, and that is probably eighty per cent of the value of the whole approach.

The rest, the question of whether one sequence beats another, is not settled by discussion. It is settled by counting, and nobody can count on your market for you.

ICT 2.0, or the version that adds time

ICT 2.0 is the name given to the more recent version of the corpus, the one that puts session timing at the centre rather than zones alone. The idea is that a level is not worth the same thing depending on when in the session it is reached.

That is a methodological improvement in itself, because an hour is objective data. A zone touched at three in the morning and the same zone touched at the New York open have neither the same volume behind them nor the same sequel.

What it adds is therefore a constraint, and a constraint reduces the number of cases. Fewer cases means fewer trades, and also less sample to check that the constraint is worth anything.

The test is a comparison: take the same recipe with and without the timing constraint, on the same history, and see whether the reward-to-risk rises enough to make up for the cases lost.

If it does not rise, the constraint is only reducing your activity. That is a useful conclusion, and it is in no video.

The Friday model, and why it is testable

The best known of the timing models is the TGIF model ICT traders talk about, which claims that price tends to retrace part of the weekly range on a Friday.

It has a quality most of them lack: it is testable without ambiguity. One week, one range, one Friday, one retracement percentage. Two people doing the calculation get the same number.

It is also the kind of claim that looks obvious once you only remember the weeks where it worked. Memory keeps the spectacular Fridays and erases the rest.

The protocol is short: fifty-two weeks, one column for the range, one for the retracement observed on the Friday. A year of history and an hour of work give an answer that three years of video will not.

And the result depends on the instrument. An index, a currency pair and a commodity have no reason to share the same end-of-week behaviour.

When to enter, the question no model settles

The question people actually search for is ICT trading when to enter, and it deserves a straight answer: none of these models tells you when.

They tell you where a reaction became visible after the fact. Turning that into an entry means adding a trigger of your own, and then measuring whether that trigger pays.

That is exactly the subject of the lesson on entry models, which compares the edge, the midpoint and the confirmation on the same setup.

Confusing the two levels, the model and the entry, explains a good part of the disappointment. People test a model while changing the entry every time, get incoherent results, and conclude the model is worthless.

⚠️ Fix a single entry before testing a model, even an imperfect one. A test that varies two things at once measures neither of them.

Practising: one model, fifty cases

Pick a single model and write its conditions on a sheet, in order. Three lines are enough, and if you cannot manage it in three lines, the model is not yet clear enough to be tested.

Fix your entry and your stop too, once and for all. That is the condition for the test to measure the model rather than the way you happened to apply it that day.

Go back through a history and collect fifty cases where every condition was met, moving forward without looking ahead. For each one note the theoretical entry, the stop and what happened.

Then compute three numbers: the frequency, the hit rate, and the ratio between the average win and the average loss. The third decides, the other two explain it.

Then change ONE condition and start again. It is the only way to learn which block carries the result, and it is what a trading journal sorted by setup gives you without your having to remember anything.