Чому стрес-тестування портфеля ламається на даних
Стрес-тестування портфеля починається не зі сценарію, а з якості даних про позиції. Вивантаження з майданчиків надходить різними шляхами: частина — через програмний інтерфейс, частина — вручну з кабінету, частина — з таблиці, яку хтось веде паралельно.
Позиції за деривативами, позиками та заблокованими коштами при цьому осідають не в тому контурі, де рахується ризик, і в модель потрапляє урізана картина. Достатньо однієї неврахованої ноги — і підсумкова експозиція занижена, хоча всі розрахунки формально зійшлися.
Друга точка відмови — припущення про незалежність активів. Кореляційну матрицю рахують на спокійному вікні історії, де інструменти справді поводяться по-різному; у момент шоку прихована кореляція проявляється, зв'язки сходяться до одиниці, і диверсифікація перестає працювати.
Актив, який у звіті виглядав захисним, падає разом з іншими, а розрахунок при цьому показує комфортний запас міцності.
Третє — неліквідність, якої в моделі просто немає. На спокійному ринку прослизання непомітне, а в момент каскадних ліквідацій книга заявок порожніє, і ціна виконання відрізняється від тієї, що стоїть в оцінці, у рази.
Ліміт втрат, розрахований за котируванням, виявляється нездійсненним: закрити позицію потрібного розміру за цією ціною неможливо.
Загалом ручні вивантаження й розбіжності дають систематичну недооцінку ризику: розрахункова просадка нижче фактичної, ліміти спрацьовують із запізненням, а рішення про хедж ухвалюється за цифрами, які вже не описують реальність. Нижче розбираємо, як закриваємо кожен із цих розривів.
Вимірювані ефекти: час, точність, усунений клас відмов
Час підготовки оцінки ризику: хвилини замість днів
Прогін сценаріїв іде за історичними рядами та за згенерованими шоками, тому оцінка ризику готується за хвилини після того, як портфель змінився.
Раніше на ту саму роботу йшли дні ручного звіряння: позиції вивантажувалися з майданчиків окремо, ціни зводилися вручну, і будь-яке оновлення портфеля знецінювало розрахунок.
CoinGecko використовується як джерело нормалізованих рядів, а кореляції між активами рахуються спільно — інакше диверсифікація виглядає захистом, якого немає.
Точність оцінки просадки: покриття всіх позицій
Просадка рахується за повним набором інструментів, включно з низьколіквідними позиціями, стейкінгом і заблокованими коштами, а не лише за основними монетами.
Для тонких ринків модель враховує прослизання та глибину книги заявок: під час шоку вихід із позиції коштує дорожче, ніж показує остання угода. Це прибирає звичну помилку, коли розрахункова просадка в рази розходиться з фактичною під час виконання.
Єдині ліміти на всі майданчики та знятий клас відмов
Правила лімітів описуються один раз і застосовуються до всіх майданчиків і рахунків, тому розбіжність між ними видно на етапі розрахунку, а не після.
Знято цілий клас відмов, пов'язаний із запізнілою реакцією на рух ринку: сценарії виконуються за розписом і при виході волатильності за поріг, а сигнал іде в моніторинг до того, як обмеження порушено.
Режими прогону сценаріїв: порівняння підходів
Режими прогону не замінюють один одного — вони відповідають на різні питання: відтворюваність звіту, пошук межі стійкості, перевірка ланцюжка подій.
Вибір режиму визначає, що ви отримаєте на виході: оцінку просадки або відповідь, за якого руху ринку портфель перестає тримати ліміти.
Методику звіряємо з рекомендаціями IOSCO щодо стрес-тестування фондів — склад сценаріїв, періодичність, документування припущень. На практиці режими комбінують: історичні шоки дають базу для порівняння, зворотний розрахунок — межі, випадкові траєкторії — розподіл результатів.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Прогін на історичних шоках | Потрібна відтворюваність і спільна база для порівняння звітів | Минулі обвали не описують нові класи ризику |
| Заданий ринковий шок | Перевірка під конкретну гіпотезу: просадка базового активу, стрибок волатильності | Підсумок залежить від вибору глибини та моменту шоку |
| Зворотний розрахунок від ліміту | Потрібно дізнатися, за якого руху ринку ліміт ризику порушується | Дає межу, але не ймовірність події |
| Випадкові траєкторії ринку | Оцінка розподілу результатів і хвостових втрат | Потребує калібрування моделі та великої кількості прогонів |
| Каскад сценаріїв | Перевірка ланцюжка: ціна → волатильність → ліквідність → маржа | Довше рахувати й складніше налаштовувати |
Окремі прогони не бачать, як один збій тягне за собою наступний, тому каскад збирають поверх інших режимів. Він показує, де прослизання під час виконання перетворюється на маржин-кол по позикових позиціях — і що саме в такому ланцюжку рветься першим.
Як ми будуємо стрес-тестування портфеля: етапи робіт
Стрес-тестування починається не з коду, а з інвентаризації даних і правил розрахунку. Якщо котирування та склад портфеля розходяться між системами, прогін видає гарні, але марні числа. Тому спочатку джерела й логіка, розрахунки — після.
-
Аудит джерел даних. Зводимо котирування, угоди, залишки та довідники інструментів, перевіряємо частоту оновлення, пропуски й розбіжності між майданчиками. На виході — карта джерел з еталоном за кожним показником.
-
Схема розрахунку та лімітів. Фіксуємо склад портфеля на момент зрізу, правила перерахунку позицій і валюту звіту. Окремо прописуємо ліміти за інструментом, класом активів і концентрацією — і що вважається їх порушенням.
-
Налаштування прогонів. Реалізуємо розрахунковий модуль, задаємо параметри запуску й логуємо кожен крок: від зрізу портфеля до підсумкового збитку за позиціями.
-
Перевірка на відомих шоках. Проганяємо сценарії, які ринок уже пережив, і звіряємо результат із фактом. Розбіжність вище порогу означає помилку в даних або формулі, а не особливість моделі.
Заодно проходимо граничні випадки — порожній портфель, одна позиція, відсутність ціни за частиною паперів.
-
Узгодження набору сценаріїв. Виносимо ризик-комітету перелік шоків — обвал ліквідності, розрив кореляцій, різке зростання ставки — з амплітудою кожного. Комітет затверджує обов'язковий набір і періодичність перегляду.
-
Передача регламенту команді. Віддаємо документ: обов'язкові сценарії, критичні пороги, порядок запуску та читання звіту, правило оновлення сценаріїв у разі зміни ринку.
Етап здано, коли ваші аналітики проганяють стрес-тест самі: регламент, який не відтворюється без автора, ми переданим не вважаємо.
Артефакти проєкту: конфігурації, схеми, регламенти
Підсумок проєкту — не лише робочий стенд, а й комплект, з яким команда замовника працює далі сама: додає сценарії, розбирає звіти, змінює пороги без звернення до нас. Нижче — що передається після завершення робіт.
- Конфігурації прогонів. Сценарії стрес-тестування портфеля — обвал ліквідності, розходження прив'язки стейблкоїна, каскад примусових закриттів — описані декларативно: горизонт, крок, склад активів. Новий сценарій додається правкою файлу, без доопрацювання коду.
- Схеми потоків даних. Шлях від джерел котирувань і даних блокчейну до розрахункового ядра та звіту, з точками відмови й описаною поведінкою при зникненні джерела.
- Політики доступу та ролі. Аналітик, ризик-менеджер і адміністратор розділені за правами: правка конфігурацій, запуск прогонів, перегляд складу портфелів. Дії журналюються — видно, хто і коли змінював параметри.
- Регламент реагування на ліміти. Пороги, за яких прогін зупиняється, порядок ескалації, шаблони повідомлень і формат фіксації інциденту.
- Посібник для аналітиків. Як зібрати сценарій, прочитати звіт, які метрики вважати пороговими й де найчастіше помиляються з інтерпретацією.
- Каталог метрик і еталонні прогони — база порівняння для кожного нового результату.
- Інструкція з розгортання та відновлення — як підняти стенд з нуля й відкотитися на попередній набір конфігурацій.
На прийманні запускаємо прогін за переданою документацією силами вашої команди: результат має відтворюватися без нашої участі.
Кейс: метрики до і після впровадження контуру ризику
Портфель замовника — спотові залишки на кількох біржах, похідні з плечем, заставне кредитування та стейкінг. Стрес-тестування портфеля велося вручну, і ризик-зведення з'являлося із затримкою — уже після того, як ринок пішов проти позиції.
Початкова схема та її слабкі місця
Аналітик вивантажував залишки, зводив їх у таблицю та вручну звіряв з лімітами за інструментами й контрагентами. У покриття потрапляли лише спотові позиції: похідні, застава й нарахований дохід залишалися поза межами, тому реальна позиція за активом була вищою за розрахункову. Ліміти перевірялися наступного дня — перевищення фіксувалося, коли угода вже відбулася.
Що змінили і що вийшло
Зібрали єдиний контур ризику: одне джерело позицій за всіма рахунками та мережами, перерахунок за розписом і за тригером при різкому русі, матриця сценаріїв — обвал ринку на 30–40% за сесію, розрив ліквідності, втрата прив'язки стейблкоїна, каскад примусових закриттів.
Сценарії рахуємо через очікуваний дефіцит портфеля, за логікою Базельського комітету з банківського нагляду, а не через одне відхилення ціни. Ранні попередження поставили на підході до 80% ліміту — спрацьовують до порушення, а не після.
| Показник | До | Після |
|---|---|---|
| Строк підготовки зведення з ризиків | два робочих дні ручного складання | 15–20 хвилин автоматичного розрахунку |
| Частка покритих позицій | 45–60% | 98% |
| Пропущені попередження про перевищення лімітів | 7 за квартал | жодного |
| Ранні попередження, що надійшли до порушення | 3 із 10 | 9 із 10 |
Чим відрізняється сценарний аналіз від зворотного тестування?
Методи відповідають на різні питання: сценарний аналіз іде від причини, зворотне тестування від ліміту — від наслідку. Один показує, що буде з портфелем за заданого шоку, другий — які умови проб'ють допустимий збиток.
У сценарному аналізі на вході — явні шоки: падіння великого активу на задану частку, втрата прив'язки стейблкоїном, стрибок волатильності, зростання ставки фінансування.
На виході — переоцінка портфеля, просадка за кожною ногою, момент вимоги довнести забезпечення та його залишок.
Зворотне тестування розвертає логіку: на вході допустимий збиток і горизонт утримання, на виході — комбінації умов, які пробивають ліміт, із частотою та глибиною перевищення.
Прогін за історичними вікнами та згенерованими траєкторіями показує, як часто межа порушувалася б знову, а не лише «було один раз».
Вибір методу під задачу простий: сценарний — перевірити конкретний ризик і обґрунтувати його; зворотний — відкалібрувати ліміт, розмір позиції та поріг автоматичного скорочення.
У системі стрес-тестування обидва режими працюють разом: зворотний прогін знаходить межу, сценарний пояснює, що за нею відбувається.
Технічні сумніви: дані, ліквідність, позабіржові позиції
Перед прийманням замовник перевіряє місця, де стрес-тест портфеля зазвичай ламається: неповні дані про позиції, позабіржові та заставні інструменти, застарілі сценарії й підтримка після здачі.
Дані про позиції неповні — що робити?
Звіряємо залишки з виписками та локалізуємо розбіжності до конкретної угоди. Пропуски відновлюємо за історією операцій, а невідновлювані позначаємо як оцінку та показуємо діапазоном.
Як ураховуються позабіржові позиції?
Ведемо окремий реєстр підтверджень і договорів: обсяг, ціна входу, умови виходу. Такі позиції рахуємо зі знижкою на ліквідність і подовженим строком закриття, а не як біржовий актив.
Що із заставними інструментами?
Застава — це зв'язка «забезпечення та зобов'язання»: у разі падіння ціни зростає вимога за маржею. Сценарій проходимо каскадом — від просадки забезпечення до порогу й примусового закриття.
Як часто переглядати сценарії?
Перегляд прив'язаний до подій, а не до календаря: нова структура портфеля, новий інструмент, зміна режиму ринку. Параметри калібруємо за свіжими даними, щоб сценарії не застарівали разом із ринком.
Чи зможемо вести систему самі?
Так. Сценарії зберігаються окремо від коду, до них іде опис і регламент перегляду. Ваш аналітик додає та править сценарії без релізу, а ми залишаємося на зв'язку для доопрацювань.
Обговоримо задачу: з чого почати контур оцінки ризику
Щоб оцінка контуру стрес-тестування портфеля спиралася на вашу реальність, а не на середні припущення, потрібні ввідні. Чим точніші вихідні, тим менше невідомих у плані робіт і реалістичніші строки.
- Склад портфеля: класи активів, майданчики, частки та ліміти за кожним напрямом.
- Джерела даних: архіви угод, котирування, інтерфейси бірж — що доступно, з якою глибиною історії та частотою.
- Значущі сценарії: обвал ліквідності, каскад ліквідацій, розходження цін між майданчиками, відмова контрагента.
- Правила управління ризиком: ліміти, пороги маржі, умови зупинки торгів, хто ухвалює рішення про зниження позиції.
- Контур виконання: де рахуються метрики, які системи вже є і до чого потрібно підключитися.
- Вимоги до звітності: хто дивиться результати, у якому вигляді, чи потрібне вивантаження у внутрішні системи.
- Обмеження: регуляторні, за доступами та за вікном навантажувальних прогонів на продуктивному середовищі.
За підсумками розбору повертаємося з оцінкою трудомісткості за етапами, планом робіт із порядком, точками контролю та складом артефактів, що передаються — від специфікації сценаріїв і моделі портфеля до конфігурацій і регламенту повторних прогонів.
Працюємо ітераціями: після кожного етапу — демонстрація проміжного результату й уточнення плану. Опишіть задачу у вільній формі — складом портфеля та найболючішим сценарієм; цього достатньо, щоб повернутися з оцінкою та планом.
