Order Flow аналіз: де ламається картина потоку
Свічка на графіку показує, де закрилася ціна, але не показує, хто її туди привів. Тому Order Flow аналіз часто будують на агрегованому обсязі: він усереднює потік заявок і приховує дисбаланс між лімітними та ринковими ордерами. Модель бачить рівну картину там, де в реальному потоці була явна перевага однієї сторони.
Основне вузьке місце — не алгоритм, а підготовка даних. Знімок стакана беруть рідше, ніж надходять події, мітки часу в різних джерел нормалізуються по-різному, а під час зведення стрічки втрачається порядок заявок. Після агрегації відновити, хто стояв у черзі першим і знімав ліквідність, уже неможливо.
Якість сигналів падає непомітно: дельта обсягу зростає, формально підтверджуючи попит, хоча перевага створена зняттям великих лімітних заявок.
На ліквідних майданчиках, наприклад під час розбору даних CME Group, той самий інтервал дає різну картину — усереднення за знімками або послідовність окремих заявок зі збереженою черговістю.
У підсумку рішення про вхід, розмір позиції та зупинку ухвалюються наосліп за метрикою, яка не описує потік заявок. Далі розбираємо, як це закривається: відновлення порядку подій, ознаки потоку заявок і перевірка сигналів на історичних даних.
Що змінюється після впровадження моделі потоку ордерів
Точність моделі зростає не за рахунок складнішої архітектури, а за рахунок зміни предмета аналізу. Замість ціни та її похідних модель читає поведінку учасників: перекіс між агресивними та лімітними заявками, швидкість набору обсягу, зняття великих заявок до виконання. Сигнал формується до руху ціни, а не підтверджує його постфактум.
Практичний ефект видно на частці хибних спрацювань. Раніше сплеск обсягу давав сигнал і на технічних викидах: тонкий стакан, одинична заявка, яка знімається за мить.
Тепер такі ситуації відсікаються фільтром за стійкістю потоку — чутливість до реальних аномалій при цьому зберігається.
Час реакції змінюється радикально. Ручне спостереження за потоком не встигає за темпом надходження заявок: аналітик бачить аномалію, коли вона вже відпрацьована.
Події потрапляють у Apache Kafka й обробляються в міру надходження, тому сигнал приходить одночасно з аномалією, а не після неї.
Окремо зникає цілий клас відмов — реакція на вигаданий обсяг. Враховуються скасовуваність заявок, їхня агресивність і розподіл виконання за рівнями: замість правила «обсяг зріс → сигнал» рішення спирається на кілька незалежних ознак.
Кожне спрацювання записується в журнал разом з ознаками та фактичним результатом, тому точність і частка помилок вимірюються на історії, а не оцінюються на око.
Режими розрахунку потоку заявок: порівняння підходів
Режим розрахунку задає, що саме модель бачить у потоці заявок: намір учасників ринку чи вже сформовану картину книги. Від цього залежать затримка реакції, стійкість до розривів з’єднання та обсяг даних, який потрібно зберігати для повторних прогонів і навчання.
На практиці вибір зводиться до трьох варіантів: потік подій, періодичний зріз стакана та гібридна схема. Нижче — їхні обмеження без рекламних спрощень.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Потік заявок (постановка, зняття, угода) | Потрібна мікроструктура: прихована ліквідність, швидкість набору позиції, сплески скасувань | Чутливий до пропусків у каналі даних; потрібна буферизація та повторне збирання при розриві |
| Зріз стакана (знімок книги через рівні інтервали) | Огляд ліквідності, довга історія, навчання моделей на широких вікнах | Між знімками губляться короткі події; за зрізом не відрізнити реальний попит від виставлених і знятих заявок |
| Гібридна схема (зріз як каркас, події як уточнення) | Потрібні і історія, і мікроструктура; є вимоги до відновлення після збою | Дорожче в супроводі: два джерела синхронізуємо за часом і валідуємо розбіжності |
Зазвичай зріз стакана беремо як базовий режим розрахунку, потік заявок — там, де без мікроструктури губиться сенс сигналу, гібридну схему — коли потрібні обидва і є чим покрити навантаження на синхронізацію.
Формат даних і розмітку фіксуємо до старту, щоб при зміні джерела модель не довелося перенавчати з нуля.
Як проходить впровадження моделі аналізу потоку
Порядок робіт вибудовано так, щоб модель зустрілася з реальним ринком лише після того, як ми зрозуміємо якість даних і поведінку сигналу на історії. Нижче — етапи, які впровадження Order Flow аналізу проходить від першого розбору до передачі в експлуатацію.
Порядок робіт
-
Аудит даних. Перевіряємо глибину історії стакана, наявність угод і міток часу, розбіжності між джерелами, пропуски в записі. Окремо звіряємо синхронізацію годинників: розсинхрон змішує причину й наслідок у потоці ордерів і знецінює навчання.
-
Схема інтеграції. Фіксуємо, звідки йде потік — шлюз брокера, біржовий інтерфейс або архів — і як він приводиться до єдиної події: час, інструмент, сторона, ціна, обсяг. Тут же описуємо буферизацію та поведінку системи при розриві каналу.
-
Ознаки та горизонт. З потоку збираються дисбаланс сторін, інтенсивність і розмір агресивних заявок, поведінка великих учасників. Горизонт прогнозу та поріг спрацювання задаємо із задачі, а не за замовчуванням.
-
Тестовий контур. Прогін на історичних сесіях у режимі відтворення, потім на живому потоці без видачі сигналів. Рахуємо частку хибних спрацювань, стійкість на різних режимах ринку та затримку від події до сигналу.
-
Регламент впровадження. Виведення сигналів з обмеженням частки капіталу, журнал рішень, моніторинг розбіжності між прогнозом і фактом. План відкату до попередньої версії моделі описано заздалегідь.
-
Передача в експлуатацію. Віддаємо конфігурації, схему потоку, інструкції з перенавчання та пороги, за яких модель зупиняється. Далі — супровід і контроль дрейфу.
Артефакти проєкту: схеми, правила, регламенти
Проєкт здано не тоді, коли модель видала перші сигнали на живому потоці, а тоді, коли ваша команда може змінювати її без нас. Тому разом із працюючим сервісом передаємо комплект артефактів — за кожним можна провести приймання й далі супроводжувати рішення своїми силами.
- Документація моделі — які ознаки потоку ордерів беруть участь у розрахунку, з яким вікном агрегації, які пороги спрацювання та як відрізняти сплеск обсягу від розвороту.
- Схеми потоків даних — шлях від джерела до вітрини: де нормалізація та дедуплікація, на якій ділянці накопичується затримка, які поля обов’язкові.
- Правила доступу — ролі за підрозділами: хто бачить сирий потік, хто лише агрегати, як журналюються запити до моделі.
- Регламент супроводу — періодичність перевірки метрик, дії при дрейфі моделі, порядок перенавчання та відкат на попередню версію.
- Опис контурів і приймання — тестовий стенд на історичних даних, чек-ліст перевірок перед викаткою, критерії допустимої деградації.
- Інструкція щодо інцидентів — що дивитися при зникненні потоку, кому ескалювати, за який час реакція вважається нормальною.
- Журнал рішень — чому вибрано такий горизонт сигналу і від яких варіантів калібрування відмовилися; через місяці це економить дні на розборі.
Комплект залишається у вас і оновлюється в міру змін у контурі. Опишіть задачу — повернемося з оцінкою та планом.
Кейс: хибні сигнали моделі та що ми змінили
Що було
Модель навчалася на агрегованих хвилинних свічках: ознаки рахувалися за фактом закриття бару, і сплеск ліквідності вона бачила вже після руху ціни.
На спокійному ринку точність трималася близько 58%, а у вікні виходу макростатистики частка хибних сигналів сягала 41% — майже кожна друга угода закривалася за захисним ордером.
Що змінили
Перезібрали набір ознак на сирих даних потоку заявок: дисбаланс обсягу на ближніх рівнях стакана, швидкість поглинання лімітних заявок, поведінка великих учасників. Історичні зрізи стакана брали з Databento, розмітку робили за фактичним виконанням, а не за свічками.
Додали фільтр волатильності, який вимикає сигнали у вузькому вікні навколо новин, і калібрування порогу ймовірності. Навчальну вибірку збалансували за режимами ринку, щоб модель не переоцінювала спокійні періоди.
Що стало
Точність на позавибірковому інтервалі зросла з 58% до 76%, частка хибних сигналів упала з 41% до 13%. Середній строк утримання позиції скоротився майже вдвічі — вихід став раніше й за фактом, а не за розкладом. Кількість днів з негативним результатом зменшилася приблизно на третину.
Метрики — на історичних даних, що пройшли перевірку на ковзному вікні; на живому ринку результат залежить від режиму та ліквідності інструмента. Правила перегляду моделі фіксуємо заздалегідь, щоб деградація ловилася до того, як проявиться в результатах.
Аналіз потоку заявок проти обсягу угод: у чому різниця
Різниця тут у природі даних, і плутати ці джерела в одній моделі найдорожче. Обсяг угод — реєстрація факту: угода виконана, ринок уже відреагував. Потік заявок — реєстрація наміру: заявку виставлено, змінено або знято, а угоди за нею може не бути взагалі.
Зріз стакана — моментальна фотографія книги заявок: що стоїть за кожною ціною прямо зараз. Потік заявок — подієвий журнал у часі: хто і як цю книгу змінював.
Модель на зрізах бачить стан, але не бачить, за рахунок чого він склався, і тому не відрізняє щільність, яку тримають усвідомлено, від щільності, яка зникне за мить.
Для прогнозу це принципово. Випереджальний сигнал — дисбаланс між швидкістю виставлення та зняття ліквідності на стороні купівлі й продажу. За виконаними угодами він проявляється із затримкою: поки обсяг накопичився, ціна вже пройшла більшу частину руху.
Потік заявок дає раніший горизонт, обсяг угод — підтвердження, що тиск реальний, а не залишився наміром.
На практиці джерела не конкурують: потік заявок працює як випереджальна ознака, обсяг угод — як фільтр хибних спрацювань.
Різниця є й у вимогах до даних: потік заявок у рази об’ємніший, чутливий до точності міток часу та пропусків подій, стрічка угод коротша й стійкіша до розривів.
Тому ми зводимо обидва ряди в спільну часову шкалу й перевіряємо на історичних даних, який із них дає приріст точності саме на вашому горизонті прогнозу.
Технічні сумніви перед стартом проєкту
На старті проєкту з аналізу потоку ордерів найчастіше виринають три інженерні сумніви: затримка даних, якість історії та перенавчання моделі. Розбираємо, як ми закриваємо кожен із них у контурі замовника.
Чи вистачить пропускної здатності, щоб обробляти стрічку без затримок?
Потік ордерів — це події за стаканом і угодами: на ліквідних інструментах рахунок іде на десятки тисяч повідомлень за секунду. Приймаємо стрічку асинхронно, пишемо в чергу й агрегуємо в секундні та хвилинні вікна.
Рахувати ознаки на гарячому шляху не потрібно — для аналітики потоку достатньо такту в секунди; жорсткі вимоги до відгуку обговорюються окремо й задаються під конкретний сценарій використання.
Наскільки повною має бути історична стрічка?
Реальна історія майже завжди йде з розривами, дублями та різною глибиною стакана за інструментами. Відновлюємо стакан за інкрементальними оновленнями, звіряємо з незалежним джерелом і позначаємо інтервали, де дані неповні.
Навчання йде лише на ділянках із підтвердженою якістю: на виході отримуєте набір даних із мітками достовірності, а не «як вийшло».
Як переконатися, що модель не перенавчена?
Перевіряємо на ковзному вікні: навчання на одному періоді, перевірка на наступному, який модель не бачила, і повтор на різних режимах ринку — тренд, боковик, висока волатильність. Дивимося не лише частку правильних сигналів, а й стійкість ознак між періодами.
Якщо результат тримається на одній ділянці історії — переробляємо модель, а не підганяємо поріг спрацювання.
Обговоримо задачу та повернемося з оцінкою й планом
Щоб оцінка проєкту спиралася на дані, а не на загальні міркування, до розмови достатньо принести те, що вже є в роботі. Готове технічне завдання не потрібне — обговоримо задачу в тому вигляді, у якому вона стоїть зараз.
- Історію потоку ордерів: знімки стакана та стрічку угод за період, який охоплює і спокійний ринок, і різкі рухи. На такому наборі видно, чи відрізняється тиск покупця від звичайного шуму.
- Поточну логіку рішень: за якими правилами зараз читається дисбаланс, де виставлені пороги, що у вашій практиці вважається хибним спрацюванням.
- Цільові метрики: яку частку хибних сигналів готові терпіти, наскільки критична затримка між подією в стакані та видачею сигналу.
- Обмеження контуру: де буде рахуватися модель, чи є прискорювачі, як сигнал потрапляє в торгову систему і хто його підтверджує.
- Формат видачі: чи потрібна числова оцінка ймовірності, мітка на графіку або готова подія у вашій інфраструктурі.
Далі ми розбираємо вивантаження й перевіряємо, чи відтворюється в ній сама гіпотеза сигналу. Потім повертаємося з оцінкою та планом впровадження: етапи, точки контролю, вимоги до даних і до того, де рахується модель. Якщо даних для перевірки гіпотези не вистачає, скажемо про це до старту, а не в середині роботи.
Опишіть задачу у вільній формі — де сигнал має спрацьовувати і що заважає зараз. Цього достатньо, щоб повернутися з оцінкою та планом.
