Де ламається контроль над максимальною просадкою
Позиції відкриті за кількома інструментами, ризик-ліміт за просадкою портфеля заданий, і тут ринок іде одним рухом — за хвилини, без проміжних відскоків.
Захист при цьому спрацьовує не тоді, коли треба: ціна оракула надходить із запізненням, ризик-модуль рахує просадку за останнім збереженим знімком станів, а заявка на примусове закриття стає в чергу й виконується вже за межею ліміту. Підсумок — закривається не одна позиція, а весь кошик, і не за нашим рішенням, а за чужим.
Корінь у тому, що контроль максимальної просадки тримають поза циклом виконання: окремий монітор опитує стан раз на інтервал, ліміт перевіряється до угоди, але не після, а між розрахунком і виконанням немає атомарності.
Варто додати різкий рух ринку — і всі три припущення ламаються одночасно: сигнал запізнюється, ліміт рахується за застарілими даними, а в торгової системи немає стану «пауза», у який можна піти безпечно.
На Ethereum це посилюється тим, що порядок транзакцій і комісії змінюються швидше, ніж устигає оновитися розрахунковий знімок.
Ще одна тиха точка відмови — округлення та прослизання: ліміт формально не пробито, а фактична просадка портфеля вже за порогом, бо в перевірці не закладено запас на виконання. Найгірше, що такий збій не відтворюється на спокійному ринку й не видно за логами звичайної торгівлі.
Розбираємо, як це закривається: ліміт просадки стає інваріантом, який перевіряється до та після кожної зміни позиції, з окремим аварійним режимом і заздалегідь описаним порядком виходу.
Що дає безперервний контроль ризику: ефект у метриках
Просадку рахуємо не за підсумками торгового дня, а на кожному оновленні потоку угод і котирувань: реалізований результат складається з нереалізованим, враховується глибина стакана й очікуване прослизання.
Тому час реакції на ризик скорочується з хвилин до секунд — поріг перевіряється до того, як позиція піде далі, а не після закриття свічки.
Частка хибних спрацювань лімітів падає, бо поріг рахується за повною оцінкою позиції, а не за останньою ціною. На тонкому ринку додаємо згладжування за вікном і вимогу підтвердження: одиничний викид котирування більше не зупиняє стратегію, а справжнє пробиття ліміту — зупиняє.
Зникає цілий клас відмов — розрив між розрахунком і виконанням.
Раніше просадка пробивалася за той час, поки черговий помічає відхилення й вручну виставляє заявку; тепер правило спрацьовує в тому самому циклі, де надійшло оновлення, і незакритої позиції в момент пробиття не залишається.
Автоматизація контролю ризику знімає з чергової зміни рутинні звірки: правила самі приводять позицію до ліміту, пишуть подію в журнал і надсилають повідомлення.
Людина залишається на аномаліях і розборі інцидентів — частка шляхів, покритих перевірками, зростає, а не тримається на пам’яті конкретного чергового.
Формати контролю максимальної просадки: пороги й автостоп
Ліміт просадки — не одне число, а набір порогів, прив’язаних до вікна вимірювання. М’які пороги дають запас на реакцію, жорсткі обмеження закривають сценарій, де реакція не встигла. Залишений лише верхній поріг спрацьовує або пізно, або на звичайному ринковому коливанні.
Варіанти відрізняються тим, хто ухвалює рішення — оператор чи код.
Спостереження й попередження залишають вибір людині, обмеження обсягу й автостоп торгівлі виконуються детерміновано: перевірка йде за ціною з оракула на кожному кроці, і спрацювання не залежить від того, чи встиг хтось натиснути кнопку.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Спостереження | Калібрування порогів на історії, збір статистики за стратегією | Нічого не блокує: збиток продовжує накопичуватися |
| Попередження (м’який поріг) | Рання стадія, висока волатильність, потрібна гнучкість | Працює за умови дисципліни оператора, легко ігнорується |
| Обмеження обсягу | Плавне скорочення позиції у разі наближення до ліміту | Складніше в налаштуванні, можливі невигідні часткові виходи |
| Повна зупинка | Жорсткий контур там, де ціна помилки вища за втрачений прибуток | Потрібне ручне підтвердження повернення, реагує на короткий сплеск |
На практиці режими ставлять зв’язкою: спостереження для калібрування, м’який поріг як попередження, повна зупинка як жорсткий контур. Пороги тримають у конфігурації стратегії — їх змінюють без перезбирання логіки.
Етапи впровадження: від аудиту потоків даних до передачі
Роботи йдуть послідовно: спершу фіксуємо, як ризик-контур улаштований зараз, потім проєктуємо правила контролю максимальної просадки і тільки після того пишемо код.
Така черговість прибирає переробки — кожне наступне рішення спирається на підтверджену схему потоків даних, а не на припущення про неї.
Розбір і проєктування
- Аудит ризик-контуру. Розбираємо, звідки надходять ціни, як часто оновлюються, де саме зараз фіксується просадка і які пороги задані вручну.
- Схема потоків даних. Зводимо джерела, розрахункові модулі й точки зупинки в одну діаграму: стає видно, на якій ділянці виникає затримка і де контроль втрачає актуальність.
- Проєктування правил. Формалізуємо, що вважати піком капіталу, як рахувати просадку і що слідує за спрацюванням порога — пауза, зниження позиції чи повна зупинка.
Перевірка та передача
- Налаштування та стрес-сценарії. Прогоняємо різкі обвали, довгі плавні зниження й розриви ліквідності: правила не повинні спрацьовувати хаотично на кожному коливанні.
- Перевірка на історії. Рахуємо метрики на минулих періодах — скільки разів спрацював контур, яка частка хибних зупинок, наскільки глибоко вдавалося втриматися в заданій межі.
- Передача системи. Віддаємо регламент порогів, журнали спрацювань та інструкцію зі зміни параметрів, навчаємо команду змінювати їх без правок у коді.
Конфігурації, політики лімітів і регламенти на виході
Здаємо не лише робочий контур контролю, а й пакет документів, за яким система живе після запуску. Без нього пороги максимальної просадки змінюються «з пам’яті», а спрацювання захисту залежить від того, хто сьогодні на зміні.
- Файли конфігурації — порогові значення просадки за кожною стратегією та інструментом, базова лінія розрахунку й вікно усереднення. Одне джерело правди замість правок у коді.
- Політики лімітів — три рівні реакції: попередження, часткове зниження позиції, повна зупинка. Рівні прив’язані до глибини й швидкості просадки, а не до однієї цифри.
- Матриця ролей — хто задає пороги, хто підтверджує зміну другим підписом, хто бачить телеметрію лише для читання. Права розведені між випробувальним і робочим контурами.
- Схеми потоків даних — у якій точці знімається метрика, в який момент рахується просадка, яким каналом іде сигнал і хто його отримує.
- Регламент дій при спрацюванні — покроковий сценарій для чергової зміни: що перевірити в перші хвилини, хто ухвалює рішення про ручну зупинку, точка ескалації й норматив часу на відповідь.
- Порядок зміни порогів — заявка, перевірка нового значення на історичних даних, викочування на обмеженому контурі, запис у журнал із автором і обґрунтуванням.
- Журнал аудиту — фіксуються всі спрацювання, ручні втручання й правки лімітів. Хронологія інциденту відновлюється без опитування учасників.
Кейс: як зняли серію ризик-відмов на волатильному ринку
Точка відліку: контроль був, реагував пізніше за ринок
Ризик-контур рахував максимальну просадку за однією ціною з внутрішнього кешу, яка оновлювалася раз на хвилину. На різких рухах це давало затримку: поріг спрацьовував пізніше за ринок, а ручний розбір у чергового інженера займав до 15 хвилин.
За квартал накопичилося понад 40 спрацювань, і 6 з 10 виявилися хибними — ціна встигала повернутися, а позиції вже були закриті за ринковою ціною.
Що перебудували
Ціну збираємо як медіану з кількох незалежних джерел, а ліміти перераховуємо на кожному блоці, а не за таймером. Джерело, що відхилилося більше за заданий поріг, випадає з медіани — одиничний викид більше не тягне за собою закриття портфеля.
Пороги й склад джерел винесені в конфігурацію, тому режим змінюється без правки коду; журнал спрацювань і відхилення за кожним джерелом знімаються в Grafana.
Метрики до і після
Частка хибних спрацювань упала з 6 з 10 до 1 з 20. Час реакції: було до 15 хвилин ручного розбору, стало автоматичне рішення за секунди. Позиції, як і раніше, закриваються при реальному пробої ліміту — механізм не відключений, він просто перестав спрацьовувати на шумі.
Клас відмов, який більше не відтворюється, — каскадне закриття портфеля за застарілою ціною одного джерела.
Що робити, якщо ліміти налаштовані, але спрацьовують пізно?
Найчастіше проблема не в самих правилах, а в конвеєрі даних: ліміт рахується за знімком позиції, який устигає застаріти.
Якщо стан портфеля потрапляє в ризик-рушій через періодичне опитування, проміжну чергу й відкладену агрегацію, то на момент розрахунку зафіксований максимум уже не відповідає ринку.
Звідси й пізня реакція системи — поріг формально виставлений правильно, але вхід у нього запізнюється.
Перший крок — виміряти затримку по всьому ланцюжку й розкласти її на етапи: підтвердження, читання стану, агрегація подій, перерахунок метрики. Вузьке місце в даних майже завжди одне й локальне — його видно за розбіжністю між часом події та часом, коли метрика оновилася.
Далі потік переводиться на безперервну обробку з міткою часу події, а не моменту обробки. Це дає коректний порядок перерахунку при наздоганяючих пакетах і повторних доставках: пік просадки не занижується й не роздувається дублями.
Достатньо ідемпотентного запису й дедуплікації за ідентифікатором угоди — переписувати систему цілком не потрібно.
І тільки після цього має сенс налаштування порогів. Поріг прив’язується до вікна розрахунку й до фактичної затримки потоку: вводиться випереджальний рівень, що обмежує зростання ризику, і підтверджувальний, який спрацьовує на стійкому перевищенні.
Гістерезис і час утримання прибирають тремтіння, а ескалація за рівнями — від попередження до примусового скорочення позицій — робить реакцію передбачуваною.
Технічні сумніви: затримки, хибні спрацювання, відмови
Перше, що перевіряють перед запуском, — поведінка контуру при затримці даних. Ціна береться з кількох незалежних джерел, між ними рахується розбіжність, а кожен тік має мітку часу.
Якщо потік за одним каналом зникає або дані застаріли сильніше за заданий поріг, рішення ухвалюється за резервним джерелом, а сам факт розбіжності потрапляє в журнал.
Хибні спрацювання народжуються не з логіки, а з шуму на короткому вікні. Тому поріг просадки рахується за підтвердженим значенням — з вікном усереднення й вимогою втримувати умову кілька відліків підряд.
Для кожної стратегії задається свій набір порогів, вікон і допустимого ризику, а відмовостійкість контуру будується так, щоб падіння виконавця не залишало позицію без контролю.
Що станеться, якщо потік котирувань зникне на кілька хвилин?
Контур переходить на резервне джерело, а якщо недоступні обидва — переводить стратегію в захисний режим: нові входи блокуються, супровід відкритих позицій іде за останнім підтвердженим значенням.
Пропуск даних фіксується з точним часом, щоб після відновлення потоку рішення можна було відтворити й розібрати.
Як налаштовуються різні пороги для стратегій?
Поріг, вікно підтвердження й правила часткового скорочення позиції описуються окремим профілем на кожну стратегію. Профілі версіонуються: зміна порога проходить перевірку на історичних даних і тільки потім потрапляє в роботу, а попередня версія залишається доступною для відкату.
Чи може хибне спрацювання закрити позицію марно?
Спочатку контур запускається в режимі спостереження — умови рахуються, рішення пишуться в журнал, ордери не виставляються. За ним видно, скільки разів поріг спрацював би і на якому шумі.
Далі підбирається вікно підтвердження, за якого спрацювання припадають на реальні рухи, а не на ринковий шум.
Що з відмовами заліза, зв’язку й перезапусками?
Стан стратегії та всі рішення зберігаються в журналі, дії ідемпотентні — повтор після обриву не виставить другий ордер. Збій виконавця не відключає контроль просадки: контур піднімається, звіряє фактичну позицію з розрахунковою й продовжує з того самого місця. Чергування та оповіщення налаштовуються окремо, з розбором інцидентів після запуску.
Обговорімо завдання: що потрібно від вас і з чого ми почнемо
Щоб оцінка максимальної просадки була робочою, а не теоретичною, нам потрібен мінімум вихідних даних. Зберіть те, що є під рукою: для першого розбору достатньо чорнового опису — уточнювальні деталі діберемо по ходу обговорення.
- Логіка стратегії та правила входу/виходу: як відкривається позиція і за якою подією закривається.
- Перелік активів, майданчиків і сегментів, де ведеться торгівля — включно з обміном і виведенням коштів між контурами.
- Поточні правила управління ризиком: ліміти на позицію, поріг зупинки, хто і як його змінює.
- Джерела даних: історичні ряди угод і котирувань, глибина вибірки, частота, наявність пропусків і розривів.
- Доступи для інтеграції: ключі до біржових інтерфейсів, вузлів мережі та зовнішніх джерел даних — з розподілом прав за середовищами.
- Вимоги до контуру: де розміщуємо систему, чи потрібна ізоляція, які затримки реакції критичні.
- Критерії приймання: яку поведінку системи ви вважаєте коректною при різкому русі ринку і при розриві зв’язку з майданчиком.
Зберемо це воєдино, звіримо припущення за даними й повернемося з оцінкою та планом робіт: порядок етапів, що робимо ми, що залишається на вашому боці, де точки контролю результату. Опишіть завдання — решту уточнимо на розборі.
