Розробка AI-системи управління ризиками інвестиційного портфеля

Просадка зростає швидше, ніж устигає відреагувати ручний контроль лімітів. Ми розробляємо AI-систему управління ризиками портфеля під ключ: від підготовки даних до передачі регламенту вашій команді. Скорочуємо час реакції на ринкові зміни й утримуємо глибину просадки в заданих межах.
Часті запитання

AI-управління ризиками портфеля: чому ручні правила не тримаються

Ручне управління ризиками тримається на регламенті та лімітах у таблицях: обмеження за інструментами, секторами й валютами живуть в окремих файлах, а зведена картина збирається раз на день — рідше, якщо хтось із команди зайнятий. Поки цифри сходяться в один звіт, склад позицій уже змінився.

Затримка реакції на ризик — це не про швидкість натискання кнопки, а про час від події до людини, яка має право діяти. Розрив між ціною, обсягом і кореляцією позицій виявляється постфактум, коли просадка портфеля вже вийшла за узгоджений коридор. На волатильному ринку такий розрив коштує кількох відсотків дохідності, які не повернути.

Людський фактор в оцінці ризику накопичується непомітно: втомлений аналітик пояснює рух тимчасовою волатильністю, а фіксація збитку потребує рішення, яке хочеться відкласти до ранку. Формально правила при цьому дотримані — ліміт перевірено за вчорашнім зрізом.

Окрема проблема — неузгодженість обмежень між собою: за одним інструментом ліміт вибрано повністю, а сукупне навантаження на портфель не перевіряється взагалі. Локально все в нормі, на рівні портфеля — перевантаження.

Автоматичний контур рахує ризик за кожною позицією в момент зміни, зводить кореляції та обсяг одночасно і спрацьовує раніше, ніж просадка стане незворотною. Розбираємо, як це закривається на практиці.

Що змінюється: швидкість реакції, глибина просадки, звітність

Раніше шлях від сигналу до дії займав години: аналітик вручну збирав позиції та котирування, звіряв їх із лімітами й ухвалював рішення ближче до закриття. Поки дані сходилися, ринок устигав відпрацювати рух, і обмеження втрат перетворювалося на фіксацію вже наявного збитку.

Система скорочує цей розрив: відхилення від порогу фіксується в момент появи, перевірка лімітів відбувається до виставлення заявки, а дія виконується автоматично або йде на підтвердження відповідальному.

Швидкість реакції на ризик перестає залежати від того, чи вільний цієї хвилини конкретний співробітник.

Зниження просадки дає не один стоп, а набір обмежень: за інструментом, за групою пов'язаних позицій і за портфелем загалом.

Коли показник підходить до межі, система зменшує обсяг, відкриває захисну позицію або виводить частину капіталу — глибина втрат обмежується заданим порогом, а не рішенням, ухваленим під тиском.

Прозорість рішень тримається на журналі: за кожним спрацюванням видно, який показник вийшов за межу, на яких даних, яка версія правила діяла і хто підтвердив дію.

Той самий журнал закриває звітність із ризиків — зрізи за період збираються автоматично, без ручної звірки, і перевіряльник бачить не лише результат, а й логіку.

Підсумок — управління ризиками портфеля стає відтворюваним: однакові умови призводять до однакових дій незалежно від зміни та поточного завантаження команди.

Три підходи до контролю ризику: правила, моделі, гібрид

Вибір між правилами та моделлю — не суперечка про складність, а питання про те, які рішення система ухвалює сама, а які віддає людині. Галузеві огляди, наприклад матеріали GARP, сходяться в одному: статистика без жорстких обмежувачів рідко виживає в експлуатації.

Декларативні правила описують ризик як набір перевірюваних умов: ліміт частки в інструменті або секторі, максимальна просадка, заборона нарощувати плече при падінні ліквідності. Спрацювання відтворюється й пояснюється інвесткомітету за хвилину. Але окремо позиції виглядають у нормі, а разом дають приховану концентрацію.

Підхід Коли підходить Обмеження
Декларативні правила Прозорий мандат, угод небагато Не бачать кореляцій, спрацьовують за фактом
Статистична модель ризику Багато пов'язаних інструментів, є довга історія Чутлива до зміни режиму ринку, потребує контролю дрейфу
Гібридний підхід Портфель зростає, ціна помилки висока Потрібно розмежувати права моделі та правил

У гібриді правила працюють як жорсткі обмежувачі з правом зупинити угоду, а модель оцінює ризик і пропонує зниження за крок-два до порушення ліміту. Це зменшує частку хибних тривог, але не віддає критичні рішення статистиці.

Вибір задають дані та режим звітності: де потрібна пояснюваність і угод небагато — достатньо правил; де позицій сотні й вони рухаються разом, правила без моделі дають або хибні тривоги, або запізнілу реакцію.

Етапи впровадження: від аудиту даних до передачі регламенту

Порядок робіт майже не залежить від розміру портфеля — змінюються джерела даних і горизонт ризику. Ми йдемо від сирих рядів до робочого контуру, де в кожного сигналу є причина, а в кожного рішення — відповідальний. Нижче — послідовність, яку проєкт проходить повністю.

  1. Аудит даних. Дивимося, які ряди доступні, яка глибина історії, де пропуски та розбіжності між джерелами, чи коректно оброблено корпоративні події. На виході — перелік доопрацювань: що відновлюємо, що виключаємо з розрахунку.
  2. Схема системи. Визначаємо, які ризики рахуємо — ринковий, концентрацію, ліквідність — і які обмеження задаємо. Окремо фіксуємо, де рішення ухвалює людина, а де система лише сигналить.
  3. Налаштування правил. Задаємо пороги спрацювання, вікна оцінки, реакцію на зміну режиму ринку та поведінку за неповних даних. Кожне правило перевіряємо на стійкість, щоб воно не ламалося від одного викиду.
  4. Перевірка на історичних даних. Проганяємо контур на кількох періодах, включно зі стресовими, і зіставляємо сигнали з фактичними просадками. Рахуємо частку хибних спрацювань і затримку реакції — це головні числа приймання.
  5. Передача в експлуатацію. Віддаємо регламент: хто і що робить при спрацюванні, як оновлюються дані, коли переглядаються пороги. Додаємо моніторинг якості вхідних рядів, інакше тиха деградація даних уб'є всю логіку.

Що залишається в контурі замовника після здачі

Здача — це не показ робочої моделі, а передача всього, що потрібно для її експлуатації без нас. Увесь комплект лежить у вашому контурі, під вашими правами та з історією змін — модель бере ризики на себе, але не забирає контроль.

  • Конфігурація правил — ліміти за класами активів і окремими інструментами, пороги спрацювання, вікна усереднення, списки винятків. Правляться без перезбирання, кожна зміна проходить перевірку й версіонується.
  • Схеми інтеграції — звідки надходять позиції, котирування та довідники інструментів, з якою частотою оновлюються, як система поводиться при затримці або зникненні джерела. З контрактами обміну та обробкою розбіжностей.
  • Політики доступу — ролі: хто дивиться звітність, хто змінює ліміти, хто адмініструє. Право на правку правил ризику видається окремо, кожна дія залишається в журналі з автором і часом.
  • Документація — як рахується оцінка ризику, які дані на вході, які припущення закладено і де модель втрачає надійність. Окремий розділ: як читати сигнал і чого він не означає.
  • Регламент супроводу — періодичність перегляду правил, порядок реакції на спрацювання, хто ухвалює рішення про зміну моделі та в які строки.
  • Порядок відкату — як повернутися до попередньої версії правил і моделі, що при цьому відбувається з уже надісланими сигналами та відкритими позиціями.

Окремо передаємо журнал змін і карту залежностей: видно, що зламається при заміні джерела даних або правила. Такий комплект дає змогу вести систему своєю командою або віддати її іншому підряднику без відновлення контексту з нуля.

Кейс: просадка портфеля і час реакції до та після

Портфель на кілька десятків інструментів обслуговував ризик-контур, побудований навколо нічного перерахунку: кореляції та коваріаційна матриця рахувалися один раз на добу, а рішення про зниження позицій ухвалювалося вранці на загальному дзвінку.

Між сигналом і дією минало кілька годин, і в дні різких рухів цього вистачало, щоб просадка вийшла за узгоджену з інвесторами межу. Розбираємо, що змінилося після перебудови контуру.

Що змінили в ризик-контурі

Перевели розрахунок у потоковий режим: волатильність і кореляції перераховуються за ковзним вікном при кожному оновленні котирувань, порогові правила спрацьовують автоматично, а ризик-менеджер бачить не ранковий звіт, а чергу сигналів з обґрунтуванням і посиланням на розрахунок.

Версії моделей і наборів параметрів фіксуються в MLflow — будь-яке рішення відтворюване, а невдалу конфігурацію можна відкотити, не втрачаючи історію.

Метрика До Після
Глибина просадки на різкому русі 9-12% 3-4%
Затримка від сигналу до рішення 4-6 годин 3-5 хвилин
Частка рішень, ухвалених вручну 100% ~15%
Періодичність перерахунку ризик-метрик раз на добу при кожному оновленні котирувань

Ручними залишилися лише спірні випадки: розбіжність між ринковим сигналом і обмеженнями мандата, великі позиції та вихід з інструментів із низькою ліквідністю.

Решту закривають правила, і це принципово змінює навантаження на команду — ризик-менеджер розбирає одиниці ситуацій замість усього потоку.

Окремо відстежували хибні спрацювання: поріг волатильності підтягнули адаптивно, щоб контур не смикав портфель на звичайному внутрішньоденному шумі.

Частка відкатів після автоматичних рішень знизилася до поодиноких випадків за квартал, а кожне відхилення розбирається як розбіжність моделі, а не як помилка чергового.

Чим модель ризику відрізняється від набору ручних лімітів?

Ручний ліміт — детерміноване правило: частка одного емітента не вище заданої, експозиція на сектор — у межах порогу, перевищення блокує угоду. Логіка прозора, її легко пояснити раді директорів і перевірити аудитору.

Слабке місце одне: ліміт дивиться на позицію окремо й не бачить портфель загалом, коли кореляції сходяться до одиниці.

Модель ризику оцінює не окремий папір, а спільний розподіл дохідностей. Вона рахує волатильність портфеля, хвостові сценарії та внесок кожної позиції в загальний ризик — концентрація виявляється там, де за номінальними частками її не видно.

Звідси робоча схема: жорсткі обмеження на структуру залишаються детермінованими, їх обхід неприпустимий. Усередині цих меж модель перерозподіляє вагу між інструментами з урахуванням кореляцій і режиму ринку, а результат перевіряється стрес-сценаріями на історичних даних.

Щоб адаптивна оцінка не стала чорною скринькою, розрахунок має бути відтворюваним: фіксуються вхідні дані, версія моделі та внесок кожного фактора в підсумкову цифру.

Підхід із Базель III будується на тому самому принципі — жорсткі межі плюс внутрішня модель під постійним контролем.

Ми налаштовуємо обидва контури разом: ліміти як страховку від грубих помилок, модель — як інструмент тонкого налаштування. Межу між ними визначаємо за вашою структурою портфеля та горизонтом утримання.

Часті технічні сумніви перед стартом

Технічні сумніви зазвичай виринають не на етапі вибору моделі, а коли йдеться про дані та експлуатацію: що робити з дірками в історії, як зловити, що модель «поїхала», і чи не почне система видавати попередження щодня.

Нижче — розбір чотирьох вузлів, які визначають, чи працюватиме рішення через пів року після запуску.

У нас в обліковій системі різнорідні дані та ручні правки. Модель узагалі можна будувати?

Починаємо не з навчання, а з профілювання вивантаження: повнота за кожним інструментом і періодом, частота пропусків, розбіжності між джерелами цін, частка ручних коригувань.

За результатом — звіт про придатність даних і перелік позицій, які не потраплять у розрахунок, доки не з'являться достовірні ряди. Пропуски не заповнюємо «середнім за портфелем»: позначаємо ознаку як недоступну, інакше оцінка ризику стає тихо неправильною.

Як ви відстежуєте дрейф моделі та що відбувається, коли він настає?

Рахуємо розподіли вхідних ознак і якість прогнозів на відкладеному періоді — не лише на навчальному. Окремо дивимося стійкість на зміні режиму ринку: зростання волатильності, розрив кореляцій, обвал ліквідності.

При виході метрик за допустимий коридор запускається перенавчання на актуальному вікні, а нова версія спочатку працює в тіньовому режимі поруч із поточною — порівнюємо їхні оцінки на тих самих позиціях і перемикаємося, коли розбіжність пояснювана.

Як система вбудується в обліковий контур і не зламає його?

Перший контур — лише читання: забираємо позиції та угоди, нічого не пишемо назад. Завантаження ідемпотентне, повторний запуск не створює дублів, а розбіжність між нашими розрахунками та обліковими залишками розбирається окремим звітом звірки.

Запис рекомендацій назад — другий етап, окремим сервісом із журналом дій і можливістю вимкнути його однією настройкою.

Система не почне попереджати нас про кожну коливальність?

Поріг спрацювання калібруємо на історичних епізодах: проганяємо модель за минулими періодами й дивимося, скільки попереджень припадало на реальні просадки, а скільки — на шум. Далі вибудовуємо рівні: спостереження, увага, дія, — з різною частотою повідомлень.

У кожного спрацювання є пояснення: який показник вийшов за межу і наскільки. Якщо частка хибних сигналів зростає, регулятор чутливості змінюється без перенавчання всієї моделі.

Обговоримо задачу: що потрібно від вас і що далі

Щоб обговорити задачу предметно, не потрібен повний доступ до ваших систем. Достатньо вивантаження угод і позицій за доступний період, довідника інструментів і класів активів, чинних обмежень із ризику та кількох прикладів рішень, які ви ухвалювали вручну.

За цим набором уже видно структуру даних, якість історії та те, які перевірки можна побудувати відразу, а які потребують доопрацювання обліку.

Мінімум даних, із якого починається розбір:

  • історія позицій і угод — її глибина та частота визначають, які моделі ризику застосовні;
  • довідник інструментів, класів активів і валют;
  • чинні ліміти, нормативи та правила ескалації разом із регламентами;
  • опис джерел ринкових даних і порядку їх завантаження;
  • приклади рішень щодо зниження ризику за минулі періоди — вони стають перевірним набором;
  • обмеження за інфраструктурою: де зберігаються дані та хто має до них доступ.

Після розбору ми повертаємося з оцінкою та планом: що робимо в першу чергу, які вимоги до даних закриваємо на вашій стороні, як розподіляються строки впровадження і в який момент ви побачите перший робочий результат.

Якщо даних менше, ніж потрібно, скажемо про це прямо й запропонуємо, що зібрати в першу чергу. Опишіть задачу — повернемося з оцінкою та планом.

Напрямки AI-розробки

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1543
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1394
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1374
  • Розробка логотипу компанії B2B Advance
    Розробка логотипу компанії B2B Advance
    816
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1142