AI drawdown control: де ламається автоматична зупинка торгівлі
Автоматична зупинка торгівлі ламається не на етапі розрахунку просадки, а на стиках: між джерелом даних, вирішальним модулем і виконавчим шлюзом. Контур контролю просадки зазвичай збирають з кількох незалежних частин, і кожна додає свою затримку.
Поки метрика доходить до вирішального модуля, позиція вже пішла глибше розрахункового рівня — автозупинка спрацьовує, але пізніше, ніж мала б.
Перший типовий збій — затримка сигналу. Дані надходять з біржі з плаваючим інтервалом, агрегатор згладжує ряд, і поріг просадки перетинається фактично, але формально ще не підтверджений.
Якщо вирішальний модуль чекає закриття свічки або підтвердження від другого джерела, між фактом і командою на зупинку накопичується розрив.
Другий збій — хибні спрацювання: різкий, але короткочасний провал ліквідності рухає метрику вище порога, автозупинка торгівлі закриває позиції, а за хвилину ціна повертається. Такі спрацювання знецінюють ризик-контур: оператор починає вимикати захист вручну.
Третій і найдорожчий збій — відсутність єдиного журналу рішень. Коли розрахунок просадки, спрацювання порога і команда на зупинку живуть у різних логах, відновити хронологію неможливо.
На розборі інциденту не видно, що саме спрацювало першим: оновлення метрики, ручне втручання чи регламентна перевірка. Без наскрізного запису рішень не можна ні довести коректність автозупинки, ні налаштувати пороги за фактом.
Ми будуємо контур так, щоб рішення про просадку ухвалювалося в одній точці, а кожне спрацювання залишало незмінний запис із вхідними даними та причиною. Розбираємо, як це закривається.
Що дає керований контур контролю просадки
Керований контур переводить контроль просадки з ручного режиму в вимірюваний інженерний процес. Ключова метрика тут — швидкість реакції: від моменту, коли просадка перетинає заданий поріг, до фактичної зупинки торгівлі.
Ручне втручання оператора займає хвилини і залежить від того, чи стежить він за екраном; автоматичний контур реагує за секунди і не пропускає момент через людський фактор.
Другий параметр — частка хибних спрацювань. Простий поріг за відсотком просадки зупиняє торгівлю на нормальній волатильності ринку, і кожна така зупинка коштує втраченого прибутку.
Контур враховує не лише глибину просадки, а й її швидкість, історичний профіль стратегії та кореляцію між позиціями — тому зупиняє там, де просадка справді виходить за межі допустимого ризику, а не там, де ринок просто смикнувся.
Третій параметр — час відновлення після спрацювання. Зупинка без зрозумілого протоколу повернення перетворюється на простій: незрозуміло, коли і за яких умов відновлювати торгівлю.
Керований контур фіксує причину спрацювання, стан портфеля на момент зупинки та умови для відновлення — оператор повертає систему в роботу за чек-лістом, а не за інтуїцією.
Окремо проєктується клас відмов, які контур зобов'язаний зловити: різкий розворот тренду, каскадна ліквідація, відмова каналу даних, завислий ордер.
Стійкість контуру перевіряється на історичних даних із цими сценаріями — якщо система не спрацьовує на відомому обвалі в минулому, вона не спрацює і на наступному.
Режими роботи автостопу: порівняння підходів
Автостоп торгівлі будується на одному з трьох контурів, і вибір між ними — не питання «який сучасніший», а питання того, які відмови ви хочете ловити і якою ціною хибних спрацювань.
Пороговий режим реагує на заздалегідь задану просадку від піку капіталу: просто, передбачувано, легко пояснюється ризик-комітету.
Статистичний контур оцінює поточну поведінку стратегії відносно її ж історичного розподілу — ловить аномалії раніше, ніж спрацює жорсткий поріг, але потребує накопиченої історії та коректної переоцінки при зміні ринкового режиму.
Навчальна модель додає до цього ознаки ринку та мікроструктури, знижуючи кількість хибних зупинок, але платить за це складністю контролю та ризиком дрейфу.
| Режим | Коли доречний | Обмеження |
|---|---|---|
| Пороговий | Прості стратегії, жорсткі вимоги ризик-політики, потрібна повна пояснюваність кожного спрацювання | Спрацьовує пізно на швидких розворотах; при вузькому порозі дає хибні зупинки на нормальній волатильності |
| Статистичний контур | Стратегії з накопиченою історією, де важливо впіймати відхилення від норми до пробою порогу | Залежить від якості та довжини історії; зміна режиму ринку зміщує базовий розподіл і потребує переоцінки |
| Навчальна модель | Багато різнорідних сигналів, потреба відокремлювати тимчасову просадку від структурної поломки стратегії | Складніше валідувати та пояснювати; потрібен контроль дрейфу та регулярне перенавчання на свіжих даних |
На практиці режими не конкурують, а вибудовуються в каскад: навчальна модель дає ранній сигнал, статистичний контур підтверджує його значущість, пороговий залишається останньою лінією захисту та аварійним гальмом.
Така схема зберігає пояснюваність для комплаєнсу і водночас знижує частку хибних зупинок — торгівля не зупиняється на нормальному ринковому шумі.
Вибір підходу ми робимо за даними: дивимося на довжину історії, частоту зміни режимів і те, який клас помилок для вас дорожчий — пропущена просадка чи зайва зупинка.
Як ми впроваджуємо AI-систему контролю просадки
Впровадження починається не з моделі, а з інвентаризації того, як просадка контролюється зараз. Ми збираємо чинні правила ризик-менеджменту — ліміти на позицію, денні стопи, ручні втручання, — і фіксуємо, де вони конфліктують між собою або не спрацьовують вчасно. Без цього кроку будь-яка автоматика дублює хаос, а не усуває його.
- Аудит правил. Розбираємо журнали угод та інцидентів: які просадки були, на якому порозі зупинялися, скільки часу втрачали на рішення. На виході — карта поточних обмежень і список місць, де реакція запізнюється.
- Проєктування схеми. Визначаємо рівні контролю: попередження, м'яке скорочення ризику, повна автозупинка. Для кожного — свій тригер і своя дія, щоб система не рубала торгівлю через разовий сплеск.
- Налаштування контуру. Збираємо потік даних про позиції та результати, налаштовуємо розрахунок поточної просадки та пороги спрацьовування. Логіка відокремлена від торгового ядра — збій контролю не зупиняє саму торгівлю.
- Перевірка на історії. Прогоняємо контур на накопичених даних: дивимося, скільки хибних зупинок він дає і які реальні просадки пропускає. Пороги калібруємо до прийнятного балансу.
- Передача системи. Віддаємо налаштований контур, документацію щодо порогів і регламент змін. Команда замовника може правити ліміти сама, без нас.
Кожен етап закінчується артефактом, який можна перевірити: карта правил, схема рівнів, конфігурація порогів, звіт за історичними прогонами, регламент експлуатації. Такий порядок дозволяє побачити ефект до того, як система стане на бойовий контур.
Артефакти на виході: конфігурації, схеми, регламенти
Проєкт закривається не демонстрацією працюючого контуру, а передачею комплекту, за яким система живе й розвивається без нас. Нижче — що замовник отримує на руки: файли, схеми та регламенти, кожен з відповідальним і версією в системі контролю змін.
- Конфігурації контролю просадки — параметри порогів за кожним торговим контуром, вікна усереднення, правила ескалації від попередження до автозупинки. У репозиторії, з історією правок і обов'язковим рев'ю: зміна порогу не проходить мовчки.
- Схеми потоків даних — від джерела котирувань і брокерського шлюзу до модуля розрахунку метрики та виконавчого контуру. З точками відмови та межами затримок, щоб при збої було видно, де рветься ланцюжок.
- Політики доступу — ролі на зміну порогів, ручне зняття блокування, читання журналу. Розподіл прав між трейдером, ризик-менеджером і черговим інженером, щоб зупинку не можна було скасувати одноосібно.
- Журнал рішень — хто, коли і на якій підставі змінював параметри або знімав блокування. Незмінний запис: використовується і для розбору інциденту, і для аудиту.
- Регламент автозупинки — покроковий порядок дій при спрацюванні: хто підтверджує, що перевіряється перед відновленням торгівлі, куди ескалюється.
- Інструкції з експлуатації — запуск, планове обслуговування, відновлення після збою, процедура відкату на попередню конфігурацію порогів.
- Методика перевірки — набір сценаріїв зі штучно заданою просадкою, за якими замовник сам переконується, що автозупинка спрацьовує на заданому рівні, а не «колись».
Комплект розрахований на передачу: інженер замовника розгортає контур за схемами та регламентами без звернення до нас. Опишіть ваш випадок — повернемося з оцінкою та планом.
Кейс: зниження просадки на торговому контурі
Що було до впровадження
Торговий контур працював на жорстких порогах: при просадці за рахунком вище заданого рівня спрацьовував ручний стоп, який черговий інженер знімав за регламентом.
Поріг не враховував волатильність інструмента та кореляцію між стратегіями, тому на спокійному ринку він не спрацьовував вчасно, а під час новинних сплесків вибивав позиції на тимчасовому відкаті.
Реакція на реальну просадку займала десятки хвилин — за цей час збиток встигав зрости, а частина зупинок припадала на нормальні коливання і вимагала ручного розбору.
Що змінили
Ми поставили модель, яка оцінює просадку не за одним числом, а за сукупністю ознак: швидкість падіння equity, волатильність, кореляцію відкритих стратегій і глибину відносно історичного розподілу.
Модель працює онлайн, перераховує ризик на кожному оновленні позиції та при підтвердженому сигналі ініціює автозупинку торгівлі — без очікування чергового.
Поріг спрацьовування адаптивний: на спокійному ринку він м'якший, у турбулентному — жорсткіший, що знімає основну причину хибних спрацьовувань.
Метрики до і після
| Метрика | До | Після |
|---|---|---|
| Максимальна просадка за період | базовий рівень | знизилася приблизно втричі |
| Час реакції на просадку | десятки хвилин | одиниці секунд |
| Частка хибних зупинок | висока, розбір вручну | скоротилася кратно |
| Ручні втручання чергового | постійні | поодинокі, за винятками |
Окремо відстежували зворотний бік — пропущені сигнали: їхня частка не зросла, тобто система не «перестрахувалася» на шкоду стратегії. Контур MetaTrader залишився робочим, автозупинка вбудована як зовнішній шар контролю і не вимагає переписувати логіку стратегій.
Чим навчальний контур відрізняється від порогового?
Пороговий контур — це набір статичних правил: просідання перевищило заданий рівень, спрацював тригер, торгівлю зупинено. Він передбачуваний, легко перевіряється і не потребує історії угод.
Проблема в тому, що ринок змінює характер: у спокійному режимі волатильність низька, і жорсткий поріг вибиває стратегію на нормальному відкаті, а в турбулентному — той самий рівень виявляється занадто далеко, і збиток встигає накопичитися до спрацювання. Один і той самий поріг не може бути одночасно чутливим і стійким до шуму.
Навчальний контур замість фіксованого числа тримає модель поточного режиму ринку. Він оцінює, як поводиться стратегія в схожих умовах: яке просідання для цього стану нормальне, а яке виходить за межі історичної поведінки.
Поріг стає не константою, а функцією від волатильності, ліквідності та кореляцій. Це дає різну чутливість у різних режимах — контур раніше реагує на аномалію і не смикається на очікуваних коливаннях.
Різниця у вимогах до даних принципова. Пороговому контуру достатньо потоку угод і поточного значення просідання. Навчальному потрібна історія, що покриває різні режими: тренди та боковики, спокійні періоди та стресові епізоди, зміни кореляцій.
Якщо в даних є лише один тип ринку, модель вивчить його і на зміні режиму помилиться — причому в бік хибних зупинок, що для торгівлі не менш дорого, ніж пропущене просідання.
Супровід теж влаштований інакше. Поріг налаштовується один раз і живе до зміни стратегії. Навчальний контур потребує регулярного контролю: дрейф розподілів, деградація якості сигналу, перенавчання на нових даних.
Потрібен контур зворотного зв'язку — як часто спрацювання виявлялися хибними, як швидко система відновлювала торгівлю після зупинки. Без цього модель тихо застаріває і перестає відображати ринок.
Практичний висновок: пороговий контур залишається страхувальним шаром, який спрацьовує незалежно від моделі. Навчальний працює поверх нього і бере на себе тонке налаштування чутливості.
Такий поділ дає і передбачуваність жорсткого ліміту, і адаптивність до режимів — за умови, що дані та супровід закриті.
Технічні сумніви перед запуском
Перед запуском контуру автостопу торгівлі технічна команда замовника ставить одні й ті самі питання: як система вбудується в наявний стек, чи не додасть затримок у критичний шлях виконання угод і що станеться, якщо рішення доведеться відкочувати. Нижче — відповіді по суті, без загальних слів.
Як система суміститься з поточною торговою інфраструктурою?
Контроль drawdown підключається як окремий шар спостереження і не вимагає переписувати ядро торгівлі.
Ми працюємо через штатні інтерфейси брокера та біржі: потік угод і позицій читається з журналів та API, а команда на зупинку йде тим самим каналом, яким користується ваш ризик-модуль.
Якщо у вас уже є власний ризик-движок, контур вбудовується як додатковий запобіжник, а не дублююча логіка.
Чи не додасть контроль затримок у виконання угод?
Оцінка ризику йде поза критичним шляхом: розрахунок метрики просадки виконується на потоці даних, а не блокує виставлення заявок. Поріг спрацювання та вікно усереднення налаштовуються так, щоб система реагувала на стійкий рух, а не на ринковий шум.
На практиці затримка між порушенням ліміту та зупинкою вкладається в частки секунди — цього достатньо, щоб відсікти лавиноподібний збиток.
Як відкотити зміни, якщо щось піде не так?
Конфігурація контуру версіонується, кожне правило зберігається окремим файлом. Відкат — це повернення до попереднього набору правил і перезапуск сервісу, без правок у торговому ядрі.
Перед виводом у бій ми проганяємо сценарій на історичних даних і в режимі спостереження: система рахує сигнали, але не втручається, — так ви бачите її поведінку на реальному потоці до включення автостопу.
Які ризики залишаються і як ви їх закриваєте?
Головні ризики — хибне спрацювання та розрив зв'язку з брокером. Перший знімається налаштуванням порогів і підтверджувальним вікном, другий — резервним каналом і правилом «немає даних — немає торгівлі».
Усі події зупинки та зняття ліміту пишуться в журнал з мітками часу, щоб розбір інциденту займав хвилини, а не години.
Якщо залишилися питання щодо інтеграції під ваш стек — опишіть задачу, повернемося з оцінкою та планом.
Обговоримо ваше завдання контролю просадки
Щоб оцінка була предметною, а не «плюс-мінус порядок», на вході нам потрібні три речі: як зараз рахується просадка (за еквіті, за реалізованим PnL чи за маржею), де проходить поточний поріг зупинки і хто його знімає вручну, а також які дії система має право виконати сама — зняти заявки, закрити позиції, заблокувати нові входи.
Далі дивимося на дані: історія угод і котирувань за період, який охоплює хоча б один сильний пролив, журнали ризик-модуля, конфігурація лімітів за інструментами та рахунками.
Окремо уточнюємо режим роботи: контроль лише на торговому контурі чи з дублюванням на боці ризик-офісу, чи потрібне ручне перепідтверджене розблокування після спрацювання, як система поводиться при розриві зв'язку з біржею.
Це визначає архітектуру — де живе розрахунок метрики, як швидко надходить сигнал і що відбувається, якщо він не надійшов.
- Схему розрахунку просадки: вікно, база відліку, врахування незакритих позицій і комісій.
- Політику порогів: рівні попередження та зупинки, різні ліміти за інструментами та рахунками.
- Логіку автозупинки: які дії виконуються автоматично, які потребують підтвердження.
- Процедуру зняття блокування: хто і за яких умов повертає торгівлю.
- Обробку відмов: поведінка при втраті зв'язку, затримці даних, розбіжності з брокером.
- Схему журналювання: що пишемо за кожним спрацюванням для подальшого розбору.
- План перевірки на історичних даних і в тестовому контурі перед виводом у бій.
Опишіть завдання та надішліть те, що є за даними й поточними лімітами, — повернемося з оцінкою термінів і планом робіт за етапами: підготовка даних, розрахунок метрики, логіка зупинки, перевірка, вивід в експлуатацію.
Якщо частина даних недоступна, запропонуємо, чим її замінити, і зафіксуємо припущення прямо в плані.
