LiquidityScan

· ГАЙДИ Й АНАЛІТИКА · 9 MIN READ · UPDATED 2D AGO

Конструктор сканера без коду

Конструктор сканера без коду

Конструктор сканера без коду поєднує detection engines, індикатори й фільтри контексту в одне boolean-правило. Ти задаєш логіку, а платформа щогодини перевіряє ліквідні ринки й надсилає лише точні збіги.

Що таке custom scanner builder без коду?

Custom scanner builder — це інструмент без програмування, який об’єднує detection engines, індикатори й фільтри контексту в одну логічну умову. Ти обираєш потрібні блоки, з’єднуєш їх через AND/OR, а платформа сканує всі доступні ринки й повідомляє лише тоді, коли спрацьовує саме твоє правило.

Від фіксованого сканера його відрізняє контроль. Готовий сканер постачає чуже визначення сетапу. Builder дає базові елементи й дозволяє зібрати визначення, за яким ти реально торгуєш. У LiquidityScan цей інструмент називається Scanner Studio, а спільний каталог Confluence — це просто набір Studio-сканерів, опублікованих для всіх.

Чому кожній торговій перевазі потрібен власний builder

Стабільні трейдери не шукають на ринку одне й те саме. Один чекає на Change of Character (CHoCH) на 1H, а потім на сильний retest order block у London kill zone. Іншому потрібні liquidity sweep і reclaim на старшому таймфреймі, але лише на інструментах із реальним обсягом. Це не різні індикатори — це різні комбінації тих самих блоків.

Фіксований сканер таку логіку не витримає. Він спрацьовує на власному патерні, а решту confluence тобі доводиться вручну перевіряти на сотнях графіків. Розрив між «патерн надрукувався» і «мій повний сетап присутній» — саме там custom scanner builder виправдовує себе: він кодує весь чекліст, а не одну його стрічку.

Найбільше це відчувається, коли ти не біля термінала. Один фіксований alert на «CHoCH на 1H» може десятки разів загудіти в телефоні, але майже жоден із цих розворотів не буде твоєю угодою, бо твоєму сетапу ще потрібні retest, сесія та обсяг.

Коли ти кодуєш усе правило, отриманий alert уже пройшов попередній відбір. Гранична ціна такого сповіщення наближається до цінності самого сетапу, а не до цінності графіка, який тобі ще доведеться повністю перевірити.

  • Специфічність: твоя перевага зазвичай складається з 3–5 умов, а не з однієї.
  • Охоплення: правило сканує весь ринок одразу, а твої очі — ні.
  • Дисципліна: формалізоване правило спрацьовує однаково щоразу й прибирає бажане pattern-matching, яке руйнує discretionary scanning.
  • Узгодженість із backtest: письмове правило можна обдумано перевіряти й допрацьовувати, на відміну від розмитого «я впізнаю його, коли побачу».

Що можна об’єднати в одному правилі

Сила builder без коду — у ширині доступних компонентів. У Scanner Studio одне правило може брати елементи з трьох сімейств, з’єднаних boolean-логікою.

Detection engines — це патернові legs: Super Engulfing, сильні order blocks OB+ / OB++, Market Structure (BOS / CHoCH), розворотний Liquidity Sweep, RSI-confluence filter від Pulse, узгодження Core Layer та решта сканерів. Кожен engine — це checkbox-умова, а не скрипт.

Індикатори додають класичні технічні обмеження: RSI, EMA, SMA, volume, ATR і percent-change. Ними ти кваліфікуєш окремий leg — наприклад, вимагаєш RSI нижче певного порога, коли спрацьовує bullish-патерн.

Фільтри контексту визначають, де і коли правило може спрацювати: ICT kill zone, trading session, asset class — crypto чи TradFi, мінімальний 24-годинний volume і день тижня. Вони нічого не виявляють, а вирішують, які кандидати залишаться.

Саме розділення цих трьох сімейств робить правило читабельним. Engines відповідають на питання «що сталося», індикатори — «за якої технічної умови», а фільтри контексту — «де і коли це має значення». Правило, яке використовує всі три рівні, частіше описує справжній сетап; правило лише з engines часто ловить патерн, що друкується всюди.

Будівельний блокРоль у правиліПриклади
Detection enginesПатернові legs, які мають бути присутніOB+, CHoCH, Liquidity Sweep, Super Engulfing
ІндикаториКваліфікують або обмежують legRSI, EMA, SMA, volume, ATR, %-change
Фільтри контекстуОбмежують, де і коли може бути спрацюванняKill zone, session, asset class, volume floor, day-of-week

Як створити custom scan: крок за кроком

Створення правила в custom scanner builder — це послідовність виборів, кожен із яких звужує коло підходящих кандидатів. Ось порядок, який зберігає логіку скана цілісною.

1. Обери legs engines і спосіб їх з’єднання

Почни з патернів, що визначають сетап. Припустімо, твоя модель — retest order block, який має сенс лише після зміни структури: обираєш OB+ і Market Structure CHoCH, з’єднуєш через AND. Тепер для збігу на символі мають бути істинними обидві умови. OR використовуй тоді, коли кандидата може кваліфікувати будь-який із кількох патернів.

2. Додай фільтри контексту

Звузь торговий всесвіт. Додай kill-zone filter, щоб правило спрацьовувало лише у вікні London, і задай мінімальний 24-годинний volume — наприклад, тільки для інструментів із показником понад $20M, щоб неліквідні пари не потрапляли в результати. Session, asset class і day-of-week працюють так само.

3. Вибери режим event або holds-now для кожного engine

Кожен leg engine читається в одному з двох режимів. Event означає, що патерн має щойно спрацювати на останній закритій свічці — це свіжий тригер. Holds-now означає, що умова істинна зараз, незалежно від того, коли вона з’явилася, тобто це поточний стан. CHoCH зазвичай є event, а активний bias або невідмітований zone — holds-now.

3a. Додай обгортку старшого таймфрейму

Будь-який leg можна обгорнути так, щоб він оцінювався на старшому таймфреймі, ніж решта правила. Так ти кодуєш top-down логіку в одному скані: leg із bias на 4H, що обгортає entry leg на 1H, змушує правило вимагати узгодження зі старшим таймфреймом ще до спрацювання entry-патерну.

4. Увімкни узгодження напрямку

Увімкни direction-agreement enforcement, щоб кожен leg вказував в один бік. Без нього bullish CHoCH може збігтися з bearish order block і створити шум. З ним правило спрацьовує лише тоді, коли весь стек bullish або весь стек bearish — саме це і є справжня confluence.

Sequence rules: перевага впорядкованого плейбука

Більшість сканерів, кастомних чи готових, перевіряють, чи відбуваються одночасно певні умови. Сильна функція серйозного builder — це sequence-правило, у якому legs мають спрацювати в конкретному часовому порядку, причому кожен наступний крок починається після закриття попереднього.

Візьмімо класичне читання розвороту: CHoCH показує зміну структури, і лише після цього ти хочеш побачити tap order block, що формується в новому напрямку. Co-occurrence logic не здатна передати слово «потім». Sequence rule може: leg один — CHoCH, leg два — tap OB+, і збіг з’явиться лише на символі, де tap стався після CHoCH.

Це відповідає тому, як насправді будуються ICT-плейбуки. Sweep, потім shift, потім entry. Bias, потім displacement, потім retrace. Впорядковані правила перетворюють багатокроковий плейбук на одну умову для сканування, чого не дасть набір окремих alert — у нього немає пам’яті про порядок подій.

Порядок також прибирає false positives, які co-occurrence непомітно пропускає. На одній свічці, всередині рваного range, символ може майже одночасно надрукувати bullish order block і bearish читання структури, а co-occurrence rule все одно дасть збіг.

Sequence rule, яке вимагає спочатку flip, а потім tap, відкине цей хаос, бо legs не вишикувалися в послідовності, потрібній твоєму плейбуку. На виході ти отримуєш менший і чистіший набір збігів — реальний розвиток ціни, а не випадкове накладання патернів.

Розібраний приклад — і чого Scanner не робитиме

Припустімо, ти торгуєш розвороти на London session у ліквідній крипті. Твоє формалізоване правило в builder може виглядати так:

  1. Leg 1, sequence, крок один: Market Structure CHoCH на 1H, режим event, bullish.
  2. Leg 2, sequence, крок два: tap OB+ на 1H, holds-now, має спрацювати після leg 1.
  3. HTF wrapper: leg із bias на 4H має бути bullish, щоб flip узгоджувався зі старшим таймфреймом.
  4. Контекст: лише London kill zone; 24-годинний volume понад $20M; crypto asset class.
  5. Узгодження напрямку: увімкнено, тому кожен leg bullish.

Після збереження цей scan щогодини перевіряє весь ринок на закритих свічках і надсилає збіг одразу, щойно символ відповідає повному впорядкованому правилу. Сповіщення приходить у web або native push та в застосунок. Ти оцінюєш кандидата з alert, а не відкриваєш 300 графіків у пошуках потрібного.

Чітко розділяй, чим цей інструмент є, а чим — ні. Builder знаходить кандидатів, які відповідають твоєму правилу. Він не прогнозує результат угоди, не публікує win rate і не виставляє ордери. Збіг означає лише одне: «мої умови присутні», і нічого більше.

Якість результатів повністю обмежена якістю правила, яке ти написав. Розмите правило дає розмитих кандидатів, і жоден engine не виправить погано сформульовану перевагу.

Scanner Studio наразі також є поверхнею для адміністраторів, а опублікований результат доступний усім через спільний каталог Confluence. Тож DIY-builder іще не відкритий для кожного акаунта, але сетапи, які він створює, уже працюють у live-каталозі.

Кожен запис у Confluence, зокрема плейбуки з упорядкованою послідовністю, — це Studio-сканер, опублікований глобально. Чесна картина така: сьогодні ти споживаєш результат builder через каталог, а self-serve-версія є логічним наступним кроком для цього інструмента.

Підхід із закритими свічками відповідає і базовій ринковій дисципліні: дослідження BIS про мікроструктуру ринку показують, чому момент і якість виконання не можна плутати з випадковим внутрішньосвічковим wick.

Помилки, які вбивають custom scan

На більшість непотрібних сканів припадають дві помилки, і обидві виникають через неправильне використання свободи, яку дає builder.

Надмірна фільтрація до нуля. Кожен доданий AND leg зменшує кількість збігів. Додай шість engines, три індикатори, kill zone і фільтр дня тижня — і легко отримаєш правило, яке не спрацює жодного разу за рік. Якщо scan кілька днів поспіль повертає нуль, прибери найменш важливий leg і розшир поріг. Правило, яке ніколи не спрацьовує, нічого тебе не вчить.

Фальшива confluence. Legs, що вимірюють одне й те саме, — не confluence, а надлишковість, замаскована під rigor. RSI-oversold gate на bullish-momentum engine, який уже вимагає сильного bullish close, — це той самий сигнал, порахований двічі. Справжня confluence поєднує незалежні прочитання: структуру, zone і timing window. Direction agreement та HTF wrapper додають реальну незалежність, а три momentum legs — ні.

  • Починай із вузького набору engines і широких threshold; звужуй їх лише після того, як побачиш частоту збігів.
  • Обирай один сильний context filter — kill zone або volume floor — замість п’яти слабких.
  • Додавай rigor через sequence order, а не через нагромадження legs, що просто відбуваються одночасно.

Часті запитання

Чи потрібно вміти програмувати, щоб створити custom scanner?

Ні. Builder без коду показує engines, індикатори й фільтри як checkbox та dropdown, з’єднані логікою AND/OR. Ти візуально складаєш правило й зберігаєш його. Вивчати мову скриптів не потрібно — саме в цьому сенс custom scanner builder порівняно з написанням власного detection code.

Як часто запускається custom scan?

У LiquidityScan Scanner Studio оцінює збережені правила по всьому ринку щогодини — завжди на підтверджених закритих свічках, тому результати не перемальовуються. Коли символ відповідає правилу, ти отримуєш push alert у web або native та сповіщення в застосунку, замість того щоб самостійно стежити за стрічкою.

Яка різниця між режимами event і holds-now?

Event mode вимагає, щоб патерн щойно спрацював на останній закритій свічці — це свіжий тригер. Holds-now mode вимагає, щоб умова була істинною зараз, незалежно від часу її появи, тобто описує поточний стан. Structure breaks зазвичай є events, а активний bias або невідмітований zone — holds-now condition.

Чи може custom scanner сказати, коли купувати або продавати?

Ні. Він показує кандидатів, які відповідають заданим умовам, але не видає trade calls, не гарантує результат і не рахує win rate. Більшість engines виводять патерн або zone, а не entry, stop і target. Сприймай кожен збіг як відфільтровану стартову точку для власного аналізу, а не як сигнал до дії.

Розширюй роботу від builder до engines, з яких він складається, і до торгового процесу, у який він вбудовується.

  • Як працює LiquidityScan Scanner — подивися на шлях від сирих свічок до сетапу, поверх якого виконуються твої правила.
  • Order Block Scanner: OB і FVG у реальному часі — пояснення engine legs, які ти додаєш у custom rule.
  • ICT top-down analysis: узгодження кількох таймфреймів — логіка HTF wrapper, яку ти додаєш до кожного leg.
  • Як знайти свою перевагу в ICT-трейдингу — визнач умови, які справді варто кодувати, ще до створення правила.
  • Як побудувати повну ICT-модель — перетвори scannable rule на повний план entry, stop і trade management.
  • Як обрати найкращий ICT Scanner — де custom builder стоїть у порівнянні з фіксованими сканерами.
  • Scanner, Pulse і Core Layer: три поверхні LiquidityScan — інший погляд на зв’язку scanner, Pulse та Core Layer.
Hayk Muradian

Hayk Muradian

Founder & Lead Analyst at LiquidityScan · 12+ years ICT/SMC trading · Institutional order flow specialist

Hayk Muradian is the founder of LiquidityScan, a professional trading intelligence platform built for ICT (Inner Circle Trader) and Smart Money Concepts (SMC) traders. With over a decade of hands-on experience reading institutional order flow across crypto, forex, and futures markets, Hayk specializes in identifying liquidity events, order blocks, and CISD setups on closed candles.

He built LiquidityScan after years of frustration with retail charting tools that ignored the mechanics institutions actually use. The platform now scans 400+ markets in real-time, surfacing the same patterns floor traders watch — without the noise.

Hayk writes about the methodology behind ICT and SMC, with a focus on practical, data-driven analysis rather than hype.

Not trading advice. LiquidityScan publishes educational content for informational purposes only. Trading involves substantial risk of loss.