AI-управління ризиками портфеля: чому ручні правила не тримаються
Ручне управління ризиками тримається на регламенті та лімітах у таблицях: обмеження за інструментами, секторами й валютами живуть в окремих файлах, а зведена картина збирається раз на день — рідше, якщо хтось із команди зайнятий. Поки цифри сходяться в один звіт, склад позицій уже змінився.
Затримка реакції на ризик — це не про швидкість натискання кнопки, а про час від події до людини, яка має право діяти. Розрив між ціною, обсягом і кореляцією позицій виявляється постфактум, коли просадка портфеля вже вийшла за узгоджений коридор. На волатильному ринку такий розрив коштує кількох відсотків дохідності, які не повернути.
Людський фактор в оцінці ризику накопичується непомітно: втомлений аналітик пояснює рух тимчасовою волатильністю, а фіксація збитку потребує рішення, яке хочеться відкласти до ранку. Формально правила при цьому дотримані — ліміт перевірено за вчорашнім зрізом.
Окрема проблема — неузгодженість обмежень між собою: за одним інструментом ліміт вибрано повністю, а сукупне навантаження на портфель не перевіряється взагалі. Локально все в нормі, на рівні портфеля — перевантаження.
Автоматичний контур рахує ризик за кожною позицією в момент зміни, зводить кореляції та обсяг одночасно і спрацьовує раніше, ніж просадка стане незворотною. Розбираємо, як це закривається на практиці.
Що змінюється: швидкість реакції, глибина просадки, звітність
Раніше шлях від сигналу до дії займав години: аналітик вручну збирав позиції та котирування, звіряв їх із лімітами й ухвалював рішення ближче до закриття. Поки дані сходилися, ринок устигав відпрацювати рух, і обмеження втрат перетворювалося на фіксацію вже наявного збитку.
Система скорочує цей розрив: відхилення від порогу фіксується в момент появи, перевірка лімітів відбувається до виставлення заявки, а дія виконується автоматично або йде на підтвердження відповідальному.
Швидкість реакції на ризик перестає залежати від того, чи вільний цієї хвилини конкретний співробітник.
Зниження просадки дає не один стоп, а набір обмежень: за інструментом, за групою пов'язаних позицій і за портфелем загалом.
Коли показник підходить до межі, система зменшує обсяг, відкриває захисну позицію або виводить частину капіталу — глибина втрат обмежується заданим порогом, а не рішенням, ухваленим під тиском.
Прозорість рішень тримається на журналі: за кожним спрацюванням видно, який показник вийшов за межу, на яких даних, яка версія правила діяла і хто підтвердив дію.
Той самий журнал закриває звітність із ризиків — зрізи за період збираються автоматично, без ручної звірки, і перевіряльник бачить не лише результат, а й логіку.
Підсумок — управління ризиками портфеля стає відтворюваним: однакові умови призводять до однакових дій незалежно від зміни та поточного завантаження команди.
Три підходи до контролю ризику: правила, моделі, гібрид
Вибір між правилами та моделлю — не суперечка про складність, а питання про те, які рішення система ухвалює сама, а які віддає людині. Галузеві огляди, наприклад матеріали GARP, сходяться в одному: статистика без жорстких обмежувачів рідко виживає в експлуатації.
Декларативні правила описують ризик як набір перевірюваних умов: ліміт частки в інструменті або секторі, максимальна просадка, заборона нарощувати плече при падінні ліквідності. Спрацювання відтворюється й пояснюється інвесткомітету за хвилину. Але окремо позиції виглядають у нормі, а разом дають приховану концентрацію.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Декларативні правила | Прозорий мандат, угод небагато | Не бачать кореляцій, спрацьовують за фактом |
| Статистична модель ризику | Багато пов'язаних інструментів, є довга історія | Чутлива до зміни режиму ринку, потребує контролю дрейфу |
| Гібридний підхід | Портфель зростає, ціна помилки висока | Потрібно розмежувати права моделі та правил |
У гібриді правила працюють як жорсткі обмежувачі з правом зупинити угоду, а модель оцінює ризик і пропонує зниження за крок-два до порушення ліміту. Це зменшує частку хибних тривог, але не віддає критичні рішення статистиці.
Вибір задають дані та режим звітності: де потрібна пояснюваність і угод небагато — достатньо правил; де позицій сотні й вони рухаються разом, правила без моделі дають або хибні тривоги, або запізнілу реакцію.
Етапи впровадження: від аудиту даних до передачі регламенту
Порядок робіт майже не залежить від розміру портфеля — змінюються джерела даних і горизонт ризику. Ми йдемо від сирих рядів до робочого контуру, де в кожного сигналу є причина, а в кожного рішення — відповідальний. Нижче — послідовність, яку проєкт проходить повністю.
- Аудит даних. Дивимося, які ряди доступні, яка глибина історії, де пропуски та розбіжності між джерелами, чи коректно оброблено корпоративні події. На виході — перелік доопрацювань: що відновлюємо, що виключаємо з розрахунку.
- Схема системи. Визначаємо, які ризики рахуємо — ринковий, концентрацію, ліквідність — і які обмеження задаємо. Окремо фіксуємо, де рішення ухвалює людина, а де система лише сигналить.
- Налаштування правил. Задаємо пороги спрацювання, вікна оцінки, реакцію на зміну режиму ринку та поведінку за неповних даних. Кожне правило перевіряємо на стійкість, щоб воно не ламалося від одного викиду.
- Перевірка на історичних даних. Проганяємо контур на кількох періодах, включно зі стресовими, і зіставляємо сигнали з фактичними просадками. Рахуємо частку хибних спрацювань і затримку реакції — це головні числа приймання.
- Передача в експлуатацію. Віддаємо регламент: хто і що робить при спрацюванні, як оновлюються дані, коли переглядаються пороги. Додаємо моніторинг якості вхідних рядів, інакше тиха деградація даних уб'є всю логіку.
Що залишається в контурі замовника після здачі
Здача — це не показ робочої моделі, а передача всього, що потрібно для її експлуатації без нас. Увесь комплект лежить у вашому контурі, під вашими правами та з історією змін — модель бере ризики на себе, але не забирає контроль.
- Конфігурація правил — ліміти за класами активів і окремими інструментами, пороги спрацювання, вікна усереднення, списки винятків. Правляться без перезбирання, кожна зміна проходить перевірку й версіонується.
- Схеми інтеграції — звідки надходять позиції, котирування та довідники інструментів, з якою частотою оновлюються, як система поводиться при затримці або зникненні джерела. З контрактами обміну та обробкою розбіжностей.
- Політики доступу — ролі: хто дивиться звітність, хто змінює ліміти, хто адмініструє. Право на правку правил ризику видається окремо, кожна дія залишається в журналі з автором і часом.
- Документація — як рахується оцінка ризику, які дані на вході, які припущення закладено і де модель втрачає надійність. Окремий розділ: як читати сигнал і чого він не означає.
- Регламент супроводу — періодичність перегляду правил, порядок реакції на спрацювання, хто ухвалює рішення про зміну моделі та в які строки.
- Порядок відкату — як повернутися до попередньої версії правил і моделі, що при цьому відбувається з уже надісланими сигналами та відкритими позиціями.
Окремо передаємо журнал змін і карту залежностей: видно, що зламається при заміні джерела даних або правила. Такий комплект дає змогу вести систему своєю командою або віддати її іншому підряднику без відновлення контексту з нуля.
Кейс: просадка портфеля і час реакції до та після
Портфель на кілька десятків інструментів обслуговував ризик-контур, побудований навколо нічного перерахунку: кореляції та коваріаційна матриця рахувалися один раз на добу, а рішення про зниження позицій ухвалювалося вранці на загальному дзвінку.
Між сигналом і дією минало кілька годин, і в дні різких рухів цього вистачало, щоб просадка вийшла за узгоджену з інвесторами межу. Розбираємо, що змінилося після перебудови контуру.
Що змінили в ризик-контурі
Перевели розрахунок у потоковий режим: волатильність і кореляції перераховуються за ковзним вікном при кожному оновленні котирувань, порогові правила спрацьовують автоматично, а ризик-менеджер бачить не ранковий звіт, а чергу сигналів з обґрунтуванням і посиланням на розрахунок.
Версії моделей і наборів параметрів фіксуються в MLflow — будь-яке рішення відтворюване, а невдалу конфігурацію можна відкотити, не втрачаючи історію.
| Метрика | До | Після |
|---|---|---|
| Глибина просадки на різкому русі | 9-12% | 3-4% |
| Затримка від сигналу до рішення | 4-6 годин | 3-5 хвилин |
| Частка рішень, ухвалених вручну | 100% | ~15% |
| Періодичність перерахунку ризик-метрик | раз на добу | при кожному оновленні котирувань |
Ручними залишилися лише спірні випадки: розбіжність між ринковим сигналом і обмеженнями мандата, великі позиції та вихід з інструментів із низькою ліквідністю.
Решту закривають правила, і це принципово змінює навантаження на команду — ризик-менеджер розбирає одиниці ситуацій замість усього потоку.
Окремо відстежували хибні спрацювання: поріг волатильності підтягнули адаптивно, щоб контур не смикав портфель на звичайному внутрішньоденному шумі.
Частка відкатів після автоматичних рішень знизилася до поодиноких випадків за квартал, а кожне відхилення розбирається як розбіжність моделі, а не як помилка чергового.
Чим модель ризику відрізняється від набору ручних лімітів?
Ручний ліміт — детерміноване правило: частка одного емітента не вище заданої, експозиція на сектор — у межах порогу, перевищення блокує угоду. Логіка прозора, її легко пояснити раді директорів і перевірити аудитору.
Слабке місце одне: ліміт дивиться на позицію окремо й не бачить портфель загалом, коли кореляції сходяться до одиниці.
Модель ризику оцінює не окремий папір, а спільний розподіл дохідностей. Вона рахує волатильність портфеля, хвостові сценарії та внесок кожної позиції в загальний ризик — концентрація виявляється там, де за номінальними частками її не видно.
Звідси робоча схема: жорсткі обмеження на структуру залишаються детермінованими, їх обхід неприпустимий. Усередині цих меж модель перерозподіляє вагу між інструментами з урахуванням кореляцій і режиму ринку, а результат перевіряється стрес-сценаріями на історичних даних.
Щоб адаптивна оцінка не стала чорною скринькою, розрахунок має бути відтворюваним: фіксуються вхідні дані, версія моделі та внесок кожного фактора в підсумкову цифру.
Підхід із Базель III будується на тому самому принципі — жорсткі межі плюс внутрішня модель під постійним контролем.
Ми налаштовуємо обидва контури разом: ліміти як страховку від грубих помилок, модель — як інструмент тонкого налаштування. Межу між ними визначаємо за вашою структурою портфеля та горизонтом утримання.
Часті технічні сумніви перед стартом
Технічні сумніви зазвичай виринають не на етапі вибору моделі, а коли йдеться про дані та експлуатацію: що робити з дірками в історії, як зловити, що модель «поїхала», і чи не почне система видавати попередження щодня.
Нижче — розбір чотирьох вузлів, які визначають, чи працюватиме рішення через пів року після запуску.
У нас в обліковій системі різнорідні дані та ручні правки. Модель узагалі можна будувати?
Починаємо не з навчання, а з профілювання вивантаження: повнота за кожним інструментом і періодом, частота пропусків, розбіжності між джерелами цін, частка ручних коригувань.
За результатом — звіт про придатність даних і перелік позицій, які не потраплять у розрахунок, доки не з'являться достовірні ряди. Пропуски не заповнюємо «середнім за портфелем»: позначаємо ознаку як недоступну, інакше оцінка ризику стає тихо неправильною.
Як ви відстежуєте дрейф моделі та що відбувається, коли він настає?
Рахуємо розподіли вхідних ознак і якість прогнозів на відкладеному періоді — не лише на навчальному. Окремо дивимося стійкість на зміні режиму ринку: зростання волатильності, розрив кореляцій, обвал ліквідності.
При виході метрик за допустимий коридор запускається перенавчання на актуальному вікні, а нова версія спочатку працює в тіньовому режимі поруч із поточною — порівнюємо їхні оцінки на тих самих позиціях і перемикаємося, коли розбіжність пояснювана.
Як система вбудується в обліковий контур і не зламає його?
Перший контур — лише читання: забираємо позиції та угоди, нічого не пишемо назад. Завантаження ідемпотентне, повторний запуск не створює дублів, а розбіжність між нашими розрахунками та обліковими залишками розбирається окремим звітом звірки.
Запис рекомендацій назад — другий етап, окремим сервісом із журналом дій і можливістю вимкнути його однією настройкою.
Система не почне попереджати нас про кожну коливальність?
Поріг спрацювання калібруємо на історичних епізодах: проганяємо модель за минулими періодами й дивимося, скільки попереджень припадало на реальні просадки, а скільки — на шум. Далі вибудовуємо рівні: спостереження, увага, дія, — з різною частотою повідомлень.
У кожного спрацювання є пояснення: який показник вийшов за межу і наскільки. Якщо частка хибних сигналів зростає, регулятор чутливості змінюється без перенавчання всієї моделі.
Обговоримо задачу: що потрібно від вас і що далі
Щоб обговорити задачу предметно, не потрібен повний доступ до ваших систем. Достатньо вивантаження угод і позицій за доступний період, довідника інструментів і класів активів, чинних обмежень із ризику та кількох прикладів рішень, які ви ухвалювали вручну.
За цим набором уже видно структуру даних, якість історії та те, які перевірки можна побудувати відразу, а які потребують доопрацювання обліку.
Мінімум даних, із якого починається розбір:
- історія позицій і угод — її глибина та частота визначають, які моделі ризику застосовні;
- довідник інструментів, класів активів і валют;
- чинні ліміти, нормативи та правила ескалації разом із регламентами;
- опис джерел ринкових даних і порядку їх завантаження;
- приклади рішень щодо зниження ризику за минулі періоди — вони стають перевірним набором;
- обмеження за інфраструктурою: де зберігаються дані та хто має до них доступ.
Після розбору ми повертаємося з оцінкою та планом: що робимо в першу чергу, які вимоги до даних закриваємо на вашій стороні, як розподіляються строки впровадження і в який момент ви побачите перший робочий результат.
Якщо даних менше, ніж потрібно, скажемо про це прямо й запропонуємо, що зібрати в першу чергу. Опишіть задачу — повернемося з оцінкою та планом.







