Чому AI-трейдинг-бот дає збої на товарних ринках
Автоматична торгівля сировиною успадковує припущення ліквідного строкового ринку: безперервний стакан, миттєве виконання, доступна ціна на будь-який строк.
На товарних майданчиках ці припущення не виконуються — і AI-трейдинг-бот, відлагоджений на довгій історії, помиляється там, де сама логіка стратегії ще коректна.
Перша точка відмови — межі сесій.
Нічна сесія та аукціон відкриття на CME Group збирають ціну відкриття із заявок, яких у денному стакані не видно: між закриттям і стартом котирування проходить через рівні одним рухом, а захисні заявки виконуються за ціною, якої в момент розрахунку ризику не існувало.
Друга — тонка ліквідність контрактів дальніх строків. Спред за ними в рази ширший, обсяг за найкращими цінами вимірюється одиницями лотів, і заявка, більша за поріг, зсуває ринок проти себе.
Збої виконання заявок тут не аварія, а штатний режим: часткове виконання, скасування, залишки, що висять до кінця сесії, — зібрана по частинах позиція вже не відповідає розрахунковому ризику.
Третя й найдорожча — ручні втручання в стратегію. Оператор знімає заявку або перевертає позицію «за ситуацією», бот втрачає актуальний стан рахунку й продовжує рахувати ризик від застарілої моделі. Ламається не алгоритм, а контур управління — розбираємо, як це закривається.
Що дає керована автоматизація товарної торгівлі
AI-трейдинг-бот знімає з трейдера рутину, але цінність не лише в цьому: рішення ухвалюються за котируваннями, а не за розкладом, тому швидкість реакції на рух ціни вкладається в секунди.
На товарних контрактах, де ціна йде на новинах про поставки, цей розрив із ручним терміналом вирішує, чи потрапить заявка в ліквідність, чи залишиться осторонь.
Швидкість тягне за собою друге — частка ручних помилок падає. Лотність, напрямок і тип заявки проходять одну перевірку до відправлення, тому переплутаний контракт або задвоєний ордер відсікаються в черзі, а не виринають наприкінці сесії під час звірки угод.
Єдиний ризик-контроль за портфелем рахує сукупну позицію, а не кожен інструмент окремо. Ліміт за групою пов’язаних контрактів, вимоги до маржі та максимальна просадка за сесію перевіряються перед кожною заявкою; у разі вичерпання ліміту стратегія переходить у режим лише закриття.
На волатильних сесіях передбачуваність виконання важливіша за гарний графік дохідності. Повтор у разі відмови біржі, затримка відповіді, розрив з’єднання та часткове виконання відпрацьовуються одним сценарієм — і відмови, пов’язані з діями оператора, не виникають як клас.
Джерело котирувань звіряємо з біржовим: дані за товарними контрактами CME Group підтягуються за тією ж схемою, що й внутрішні довідники, тому розходження видно відразу, а не виявляється під час перерахунку позицій.
Режими роботи торгових алгоритмів: що вибрати
Режим експлуатації — це не «ступінь автоматизації загалом», а межі, у яких алгоритм ухвалює рішення сам.
Сигнальний режим залишає вибір за трейдером, напівавтоматичне виконання віддає машині розрахунок обсягу, ціни й моменту, повністю автоматичний режим знімає підтвердження, а перевірочний контур не виставляє заявки взагалі.
Вибір визначається ліквідністю контракту, ціною помилки та зрілістю статистики стратегії. Нижче — режими, між якими вибирають на практиці.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Сигнальний | Новий інструмент, відлагодження порогів входу, рішення залишається за людиною | Затримка між сигналом і угодою, ручне введення та облік позиції, розходження фактичної ціни з розрахунковою |
| Напівавтоматичний | Стратегія перевірена, але потрібен контроль на нештатних подіях; ризик-контур рахує обсяг і ставить стоп-заявку | Залежить від доступності підтвердження та каналу зв’язку, частина сигналів губиться в моменти різких рухів |
| Повністю автоматичний | Ліквідні контракти, стійка статистика, є контроль просадки й лімітів | Потребує моніторингу, оповіщень і швидкого відкату версії; помилка тиражується на весь обсяг |
| Перевірочний контур (перевірка стратегії на історичних даних) | Перед зміною логіки або параметрів, під час виходу на новий контракт | Історія не відтворює прослизання та розриви ліквідності; ризик підгонки під минуле |
Загальне обмеження в усіх режимів одне: біржові ліміти за позицією, зупинки торгів і якість ринкових даних. Тому перемикання закладаємо як прапорець конфігурації, а не переписування коду — повернення до попереднього режиму займає хвилини.
Як ми впроваджуємо торговий контур: етапи робіт
Починаємо не з коду, а з аудиту: якщо в поточній схемі торгівлі та обліку рішення ухвалюються наосліп, автоматизація лише закріпить ці помилки з більшою швидкістю. Тому кожен етап закінчується артефактом, який можна перевірити на реальних даних, а не описом на словах.
- Аудит схеми торгівлі та обліку — розбираємо, як формуються заявки, де ведеться облік позицій і як звіряються угоди; фіксуємо розходження між торговим журналом та обліковою системою.
- Проєктування торгового контуру — описуємо логіку входу й виходу, правила перерахунку позицій, точки відмови та поведінку системи під час обриву зв’язку.
- Підключення до брокера та джерела даних — налаштовуємо канали отримання котирувань і надсилання заявок, узгоджуємо затримки, формати та порядок підтвердження угод.
- Налаштування ризик-лімітів — задаємо граничний розмір позиції, ліміт збитку за торговий день, обмеження кількості заявок за одиницю часу та правила автоматичної зупинки.
- Прогін на історичних даних і в тестовому контурі — звіряємо поведінку AI-трейдинг-бота з фактичними угодами, шукаємо розходження в обліку та на межах ринку.
- Приймальні випробування та передача — проганяємо сценарії відмов, перевіряємо відновлення після перезапуску, передаємо конфігурацію, журнали й регламент супроводу.
Артефакти впровадження: регламенти, схеми та доступи
Після впровадження в команди залишаються не лише робочий контур, а й комплект документів, за якими систему експлуатують, передають новому інженеру та пред’являють перевіряльникам.
Без нього поведінку бота знає одна людина, а зміна параметра перетворюється на експеримент на живому рахунку.
- Регламент контролю ризику — ліміти на позицію, інструмент і денний збиток, умови автоматичної зупинки, порядок ручного втручання та рівні, де рішення ухвалює людина.
- Схема інтеграції з брокером — які канали несуть котирування та заявки, яке підтвердження вважається остаточним, де точка відмови й як перемикаються на резервний маршрут.
- Політики доступу та ролі — хто змінює параметри стратегій, хто бачить лише звітність, як видаються й відкликаються права під час зміни співробітника.
- Журнал угод і подій — що фіксується за кожною заявкою, з якою деталізацією і як відновити повну хронологію розбору конкретної угоди.
- Інструкція з інцидентів — ознаки збою, порядок аварійної зупинки, кроки відновлення позицій і відповідальний за кожну дію.
- Опис конфігурацій стратегій — який параметр за що відповідає, що допустимо змінювати на ходу, а що потребує прогону на тестовому контурі.
- Порядок виведення змін — шлях від правки в тестовому середовищі до допуску в робочий контур із точкою повернення до попередньої версії.
Комплект живе разом із системою: правки до регламенту та політик вносимо тим самим порядком, що й зміни до коду, і фіксуємо в журналі — під час розбору інциденту видно, яка версія правил діяла в момент угоди.
Кейс: торговий контур на портфелі товарних активів
Портфель: ф’ючерси на енергоносії та промислові метали плюс спотові позиції — вхід розносився за кількома контурами на майданчику CME Group.
Підтвердження кожної заявки йшло через трейдера: за сесію набігало близько сотні ручних операцій, і затримка з підтвердженням зсувала вхід щодо розрахункової ціни.
Гіршим був розрив зв’язку: канал губився, відкриті позиції залишалися без нагляду, а на відновлення йшло від семи до дванадцяти хвилин.
Ми перевели виконання в керований контур. Кожна заявка отримала свій ідентифікатор і запис у локальному журналі станів — повторне надсилання після обриву не створює дубль.
Звірка позицій із брокерським звітом іде за розкладом; розходження піднімає прапорець і зупиняє виставлення нових заявок до розбору. Ручне підтвердження залишилося лише на угодах, більших за ліміт ризику.
Що змінилося в метриках
| Метрика | До | Після |
|---|---|---|
| Частка операцій із ручним підтвердженням | 100% | ~12% (лише перевищення ліміту) |
| Відновлення після розриву зв’язку | 7–12 хвилин | до 40 секунд |
| Спірних виконань за сесію | 6–8 | 0–1 |
Стабільність виконання зросла завдяки тому, що контур виставляє заявки за розрахунковою ціною, а не за тією, що встигла піти, поки трейдер натискав кнопку.
Відхилення фактичної ціни входу від розрахункової скоротилося майже втричі, а розбір спірних виконань перестав бути окремою задачею на кожен вечір.
Чим AI-трейдинг-бот відрізняється від радника-сигнальника
Різниця починається там, де закінчується сигнал. Радник-сигнальник аналізує ринок і пропонує угоду: напрямок, орієнтир входу, захисний ордер. Далі вирішує людина — надіслати заявку чи пропустити. Зона відповідальності алгоритму тут закінчується.
Бот відповідає за весь шлях угоди: отримує ринкові дані, розраховує параметри й сам виставляє заявку. Перед надсиланням він перевіряє її на відповідність лімітам — розмір позиції на інструмент, сумарна експозиція за портфелем, допустиме відхилення ціни.
Якщо поріг порушено хоч за одним із них, заявка не йде, а до журналу потрапляє запис із причиною відмови.
Окрема робота — часткові виконання. На товарних ринках обсяг майже ніколи не набирається однією заявкою: частина проходить відразу, залишок висить у стакані.
Бот вирішує, що робити із хвостом — добрати за поточною ціною, переставити ліміт ближче або зняти залишок, якщо він не набирається за відведений час, — і тримає стан позиції узгодженим.
За результат відповідає той, у кого є доступ до виконання та даних. Радник не пояснить, чому сигнал залишився невідпрацьованим, а бот зберігає журнал: які котирування надійшли, які правила спрацювали, які заявки пішли і з яким підсумком. Це робить поведінку відтворюваною, а розбір спірних угод — предметним.
Межа проста: сигнальник продає думку, бот — виконання. Якщо в задачі є ліміти, часткові виконання та відмови біржі, це вже не радник.
Технічні сумніви перед запуском торгового контуру
Перед запуском торгового контуру замовники ставлять ті самі питання — про обриви зв’язку, ліміти ризику, оновлення стратегії та стикування з обліковою системою. Нижче — короткі відповіді; деталі розбираємо вже на ваших правилах торгівлі та даних.
Зник зв’язок із біржею — що з відкритими позиціями?
Контур стежить за якістю каналу й під час обриву переходить у захисний режим: нові заявки не виставляються, відкриті позиції залишаються під управлінням правила ризику.
Після відновлення зв’язок перепідключається, стан позицій звіряється з біржею — розходжень в обліку не залишається.
Як задаються ліміти ризику на угоду та на день?
Ліміти живуть у конфігурації, а не в коді стратегії. У разі вичерпання денного ліміту нові входи блокуються, управління вже відкритими позиціями продовжується — контур не кидає їх і не чекає ручного втручання.
Чи можна оновити стратегію без зупинки торгівлі?
Так: нова версія проганяється на історичних даних і включається в роботу, відкриті позиції доводяться за попередніми правилами. Кожна версія та її параметри фіксуються в системі контролю версій — за угодою видно, які правила її супроводжували, і є куди відкотитися.
Як контур стикується з чинною обліковою системою?
Через її штатні інтерфейси: угоди, комісії та позиції потрапляють у той самий контур, що й інші операції. Подвійне введення та розходження між торговою й управлінською звітністю не з’являються.
Обговоримо вашу задачу з автоматизації торгівлі
Точність оцінки AI-трейдинг-бота залежить від того, що відомо про ваш портфель і торгову інфраструктуру. Першу розмову ми ведемо не як презентацію, а як розбір задачі: які інструменти торгуєте, де виконуються угоди, якими даними розпоряджаєтеся і чого очікуєте від автоматизації.
- Склад портфеля та ринки: товарні групи, спот або строковий ринок, торгові сесії та часові пояси стратегії.
- Дані: за який період є історія котирувань і угод, чи потрібна глибина стакана, у якому вигляді ряди доступні зараз.
- Доступи: тестовий і робочий рахунок, права на виставлення заявок, ліміти за позиціями та правила управління ризиком.
- Правила рішень: що бот робить сам, а що йде на підтвердження людині; як рахуєте цільовий результат — дохідність, просадку, частку прибуткових угод.
- Обмеження: режим торгів і кліринг, корпоративні події, вимоги комплаєнсу та звітності.
- Що повернемо: план впровадження за етапами — підготовка даних, стенд для перевірки гіпотез, контур ризику, запуск із моніторингом і журналом угод.
- Оцінка строків і обсягу: розбивка за етапами з позначкою, які залежності залишаються на вашій стороні.
Порядок подальших кроків: описуєте задачу, надсилаєте те, що є за портфелем і даними, ми розбираємо це з інженерами й повертаємося з оцінкою строків і планом робіт. Якщо вихідних даних не вистачає — скажемо прямо, що потрібно зібрати до старту.
