Прогнозування волатильності: де ламається ручна оцінка ризику
Ручна оцінка ринкового ризику спирається на останній помітний рух: аналітик бере денний розмах, порівнює з минулим тижнем і переносить масштаб на майбутній горизонт.
Такий підхід ламається на зміні режиму — волатильність криптовалют кластеризується, і перехід від спокою до сплеску відбувається швидше, ніж оновлюється оцінка. Запізнілий сигнал тут не помилка виконавця, а властивість методу: він усереднює те, що вже сталося.
Друга точка відмови — одна усереднена модель на всі стани ринку.
Навчена на всій доступній історії, вона видає «середню» волатильність і системно недооцінює хвости: у боковику завищує ризик і гальмує логіку, у каскаді примусових закриттів занижує та пропускає момент, коли позицію потрібно скорочувати.
Спокійний тренд, боковик і ліквідаційний сплеск описуються різними ознаками й потребують різної чутливості спрацювання.
Робоча модель ризику будується на ознаках, які змінюються раніше за ціну: реалізована волатильність на кількох горизонтах, спред і глибина склянки, ставки фінансування, відкритий інтерес, частка примусових закриттів, поведінка провідного активу.
Прогнозування волатильності тут — не передбачення ціни, а оцінка розкиду: наскільки широким буде рух на горизонті від години до тижня і з якою ймовірністю він вийде за заданий поріг.
Далі розбираємо, як це закривається: які дані збираємо, як розділяємо режими ринку і чим перевіряємо якість прогнозу на історичних вікнах.
Що дає модель: точність, стійкість, швидкість реакції
Ми оцінюємо прогнозування волатильності за чотирма вимірюваними властивостями: помилкою оцінки на відкладеному періоді, стійкістю до зміни режиму ринку, часом реакції на аномалію та горизонтом, на якому прогноз зберігає силу.
Базові моделі родини GARCH дають непогану відправну точку, але на розривах ліквідності й новинних шоках їхня помилка зростає кратно — саме там, де прогноз потрібен найбільше.
Точність моделі вважаємо часткою періодів, де фактична волатильність потрапила в передбачений коридор: середня помилка згладжує сплески, заради яких модель і будується.
Горизонт оцінки фіксуємо заздалегідь і рахуємо метрики окремо для кожного — модель, упевнена на короткому вікні, часто втрачає якість на сусідньому.
Стійкість моделі перевіряємо на історичних стрес-сценаріях: обвал, боковик, різке зростання, розрив ліквідності. Відбір проходить та, у якої помилка оцінки залишається в робочому коридорі, а не відлітає в рази.
Окремо дивимося деградацію — наскільки просідає якість, якщо модель довго не перенавчати на свіжих даних.
Час реакції на аномалію найчастіше й вирішує результат. Система порівнює реалізовану волатильність із прогнозною і піднімає сигнал, коли розходження виходить за поріг; на потокових даних це секунди замість очікування закриття свічки.
Завдяки цьому зникає цілий клас відмов: рішення, ухвалені за моделлю, яка вже не описує поточний режим ринку.
Режими розрахунку: статистика, машинне навчання, ансамблі
Режим розрахунку визначає, на якому горизонті оцінка волатильності залишається робочою: на годинах, днях чи тижнях.
Порівняння підходів має сенс вести не за точністю на одному вдалому історичному відрізку, а за стійкістю до зміни ринкового режиму, пояснюваністю результату та вартістю супроводу.
На практиці ми працюємо з трьома класами: статистична модель, машинне навчання на ознаках і ансамбль моделей. Статистика прозора й передбачувано поводиться на короткому ряді, але згладжує нелінійності.
Навчання на даних ловить складні зв’язки, зате потребує довгої історії та захисту від перенавчання. Ансамбль моделей згладжує провали окремих компонент — ціною ускладнення контролю.
| Режим розрахунку | Коли підходить | Обмеження |
|---|---|---|
| Статистична модель умовної волатильності | Режим ринку стабільний, історії мало, потрібна пояснюваність | Слабко реагує на структурні зсуви та шоки |
| Машинне навчання на ознаках | Довга історія, є зовнішні ознаки: обсяги, ставки, потік подій | Чутливе до перенавчання, погано переносить рідкісні сценарії |
| Ансамбль моделей | Потрібна стійкість на горизонтах від години до тижня | Дорожче в супроводі, потрібен контроль розходження компонент |
| Гібрид: статистика як база, навчання на залишках | Ринок чергує спокійні та турбулентні періоди | Складніше налаштування й валідація на історичних даних |
Вибір фіксуємо за задачею: для розрахунку заставових вимог важливіші стійкість і пояснюваність, для короткострокової оцінки ризику ліквідації — реакція на зміни. Далі показуємо, як це поєднується з рештою системи.
Етапи впровадження: від аудиту даних до передачі моделі
Етапи робіт вибудувані так, щоб кожна наступна фаза спиралася на перевірений результат попередньої: далі рухаємося лише тоді, коли метрики якості зафіксовані та відтворювані.
Це подовжує старт, зате знімає переробку моделі в момент, коли вона вже вбудована в торговий або ризик-контур.
- Аудит даних. Збираємо історію котирувань і обсягів, перевіряємо неперервність рядів, розриви на зупинках торгів і коректність закриття пропусків, окремо шукаємо витік майбутніх значень в історичних ознаках.
- Підготовка ознак. Із сирих рядів збираємо ознаки волатильності та ліквідності, приводимо їх до одного кроку за часом і рахуємо на ковзних вікнах — модель має бачити режим ринку, а не окрему свічку.
- Схема моделі. Вибираємо клас моделі під горизонт прогнозу та частоту даних, домовляємося про метрики помилки і про те, який результат вважаємо прийнятним на спокійному та на різкому ринку.
- Складання й навчання. Навчаємо на одному відрізку історії, налаштовуємо параметри на другому, а фінальну оцінку робимо на третьому — тому, якого модель не бачила жодного разу.
- Перевірка. Проганяємо прогноз на відкладеному періоді та на стрес-ділянках, порівнюємо з простим базовим прогнозом і дивимося, де модель стійко програє — такі сценарії йдуть у доопрацювання, а не в презентацію.
- Впровадження моделі. Обгортаємо розрахунок у сервіс, налаштовуємо розклад перерахунку, моніторинг розходження прогнозу й факту та відкат на попередню версію без зупинки роботи.
- Передача й навчання команди. Віддаємо код, конфігурації та розбір рішень, проводимо навчання ваших інженерів і аналітиків, щоб перенавчання й правки ознак ви робили самі.
Кожен етап закривається артефактом: звітом за даними, набором ознак, специфікацією, результатами перевірки, працюючим сервісом і документацією.
Жоден пункт не вважається зробленим «на словах» — у вас залишається відтворюваний результат і команда, яка розуміє, як його підтримувати.
Комплект передачі: код моделі, звіти, регламент перерахунку
Комплект збираємо так, щоб модель можна було перезапустити й перевірити без нас: від сирих даних до артефакту, за фіксованою командою запуску та на закріплених залежностях. Нижче — що саме залишається у вашої команди і в якому вигляді це застосовно в роботі.
- Код моделі — навчання й оцінка одним запуском, фіксовані зерна генератора, щоб повторний прогін на тих самих даних давав той самий результат.
- Конфігурація середовища — закріплені залежності, образ і змінні запуску: розгортається на вашому обладнанні, без «працює тільки в автора».
- Документація моделі — які ознаки на вході, який горизонт прогнозу, на якому вікні рахується помилка і де модель застосовувати не можна.
- Звіт за якістю — метрика помилки на відкладеному відрізку, порівняння з простою базовою оцінкою, розбивка за спокійним і волатильним ринком.
- Перевірки даних — правила на пропуски, викиди та розриви котирувань, журнал спрацьованих перевірок із зазначенням джерела й часу.
- Регламент перерахунку — за календарем або за зсувом вхідних даних, порядок перенавчання й приймання нової версії до її використання.
- Моніторинг розходжень — панель «прогноз проти факту», пороги оповіщень і порядок відкату на попередню версію моделі.
Кейс: як змінилася точність оцінки ризику на різких рухах
До: помилка розходилася на штормовому ринку
Модель навчалася на історії спокійних періодів, а пороги спрацювання задавалися абсолютною величиною відхилення.
На спокійному ринку помилка прогнозу трималася в межах 4-6%, і ризик-служба вважала оцінку адекватною; на різких рухах розкид помилки розходився до 30-40%, а частка пропущених аномалій сягала 38%. Рішення за лімітами ухвалювалися постфактум — коли рух уже відбувся.
Що змінили
Схему розбили на два компоненти: модель стохастичної волатильності для базового рівня та режимне перемикання, яке окремо навчається на періодах стиснення й розширення.
Пороги алертів прив’язали до квантилів розподілу залишків замість абсолютного відхилення, щоб сигнал не залежав від поточного масштабу ціни.
Калібрування звіряли з implied-оцінками Deribit: розходження модельної та ринкової очікуваної волатильності розбирали окремо, а не усереднювали.
Що стало
Частка пропущених аномалій знизилася з 38% до 9%. На штормовому ринку розкид помилки скоротився приблизно вдвічі — з 30-40% до 14-18%, і залишився керованим на подіях, коли ціна проходить кілька відсотків за хвилини.
На спокійному ринку точність не деградувала: помилка залишилася в межах 3-5%, тобто покращення не куплено ціною хибних спрацювань.
Прогнозний інтервал почав розширюватися за 15-40 хвилин до зростання спреду — такого випереджального сигналу раніше не було. Ліміти знижували заздалегідь, а не екстрено за фактом.
Чим відрізняється прогнозування волатильності від моніторингу цін
Моніторинг цін відповідає на питання «скільки актив коштує прямо зараз» і оновлюється за фактом угоди. Прогнозування волатильності відповідає на інше питання: наскільки широким буде розкид дохідності в наступному вікні — годині, добі, тижні.
Це не уточнення першого контуру, а окрема задача з іншими вхідними даними, іншою частотою перерахунку та іншою ціною помилки.
Моніторинг — це потік останніх угод і алерти за порогами, тобто реакція на те, що вже сталося.
Оцінка розкиду будується на випереджальних ознаках: стиснення діапазону перед імпульсом, перекіс заявок у склянці, сплеск примусових закриттів, стрибок ставок фінансування за безстроковими контрактами.
Окремий шар — неявна волатильність опціонів: на великій опціонній площадці на кшталт Deribit вона котирується напряму, тобто ринок сам платить за право зафіксувати майбутній розкид.
Звідси різниця в застосуванні. Індикатори ризику, побудовані на прогнозі розкиду, дають запас за часом: граничне плече знижується до імпульсу, а не після нього, розмір позиції перераховується заздалегідь, автоматичне хеджування вмикається на розширенні очікуваного розкиду.
Ліміти ризику, прив’язані лише до поточної ціни, спрацьовують у момент руху — коли рішення вже не можна ухвалити за прийнятною ціною.
На практиці контури ділять так: моніторинг цін ловить збої виконання та аномалії ліквідності, прогноз волатильності захищає від втрат на різкому розширенні розкиду.
Змішувати їх в один не можна — інакше пороги або запізнюються, або глушать нормальну роботу на спокійному ринку: модель, навчена на денних даних, не побачить внутрішньоденний сплеск, а годинні оцінки переоцінюють ризик на трендовій ділянці без відкатів.
Ми розводимо ці контури на рівні даних, горизонту та порогів, а не на рівні звітів, — нижче показуємо, як це влаштовано в нашій роботі.
Технічні сумніви: дані, перенавчання, підтримка
Перед стартом робіт технічна команда замовника ставить майже той самий набір питань: звідки беруться дані, як ми переконуємося, що модель не запам’ятала історію, що відбувається при зміні режиму ринку і хто відповідає за роботу моделі після передачі. Нижче — прямі відповіді, без обіцянок «прогноз завжди точний».
Ці питання ми закриваємо в проєктуванні, а не після запуску: від відповідей залежить схема збору даних, склад перевірок і те, які метрики якості потраплять у звіт. Якщо за якимось пунктом домовитися не вдається, це привід не починати, а не «доналаштувати по ходу».
Як ви боретеся з перенавчанням моделі?
Перевіряємо на послідовних часових відрізках: навчаємо на минулому, перевіряємо на наступному за ним періоді, який не брав участі ні в підборі налаштувань, ні у відборі ознак. Випадкове розбиття ряду тут не працює — воно підмішує майбутнє в навчання й дає завищені метрики.
Додатково порівнюємо результат із простим базовим прогнозом: якщо модель його не обходить стійко, у роботу вона не йде.
Що з якістю даних і пропусками?
Пропуски — норма, а не збій: майданчики йдуть на обслуговування, частина джерел віддає історію з розривами. Ми не заповнюємо їх середнім, а помічаємо, виносимо в окремий шар і фіксуємо у звіті із зазначенням джерела й періоду.
Якість даних перевіряємо за формальними правилами — дублі, викиди, розходження цін між джерелами, — і кожен набір проходить цю перевірку до навчання.
Як відстежуєте дрейф даних?
Дрейф — це зміна статистичних властивостей ряду: спокійний ринок і різкий перехід поводяться по-різному, і модель, налаштована на один режим, втрачає точність на іншому.
Ми тримаємо контроль розподілів вхідних показників і якості прогнозу, перераховуємо модель за розкладом або за спрацюванням порога. При виході за межі вага прогнозу автоматично знижується, щоб рішення не спиралося на застаріле налаштування.
Що входить у підтримку моделі?
Регламент перенавчання, моніторинг якості, оповіщення про деградацію, журнал запусків із відтворюваністю результатів і порядок відкату на попередню робочу версію. Окремо фіксуємо, хто і за яким сигналом запускає перенавчання.
Без цього модель живе до першої зміни ринку — тому підтримку описуємо до старту, а не як доповнення до здачі.
Обговоримо задачу: дані, доступи, план робіт
Перш ніж називати строки, потрібен склад даних і доступи до них — від цього залежить, які моделі прогнозування волатильності застосовні та скільки часу займе їхня перевірка на історії.
Нижче мінімальний набір, після якого ми повернемося з оцінкою та планом робіт, а не з уточнювальними питаннями.
- Інструменти й горизонт. За якими активами та парами будуємо прогноз, на якому часовому кроці, якої глибини історію віддаєте — свічки чи окремі угоди, чи потрібна склянка та дані строкового ринку.
- Склад даних. Вивантаження з вашого сховища або біржові архіви: структура записів, частота, відомі пропуски й розриви, як оброблялися зупинки торгів і делістинги.
- Доступи до даних. Ключі лише на читання, тестовий контур, архівне сховище; хто на вашій стороні видає та продовжує доступ, на кого зав’язані запити.
- Цільова метрика ризику. Що вважаємо прогнозом: волатильність на крок уперед, імовірність перевищення порога або момент спрацювання захисного правила. Від цього залежить спосіб перевірки якості.
- Режим використання. Звіт за розкладом, оповіщення або автоматичне управління позицією; допустима частка хибних спрацювань і потрібна затримка відгуку.
- Контур запуску та приймання. Де рахуємо, куди пишемо результат, як часто перераховуємо модель, хто приймає роботу і за якими числами звіряємо прогноз із фактом.
Після цього фіксуємо план робіт: підготовка рядів і ознак, відбір моделей, перевірка на історичних періодах, запуск і спостереження за розходженням прогнозу з фактом.
Опишіть задачу в цих межах — повернемося з оцінкою, строками та складом команди; старт робіт починається з узгодження метрики й даних, а не з налаштування середовища.
