Розробка системи Monte Carlo симуляції портфеля

Монте-Карло симуляція портфеля: де ламається оцінка ризику

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

Монте-Карло симуляція портфеля замінює одне число розподілом результатів, але тримається на вхідних припущеннях: як описана волатильність активів, чи враховані кореляції між інструментами, чи змінюється матриця зв'язків у стресових режимах.

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

Другий розрив — ручні припущення. Ставки, горизонти й правила ребалансування часто задані «за досвідом» і ніде не перевірені.

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

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

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

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

Що дає впровадження: вимірювані ефекти для оцінки ризику

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

Декларативний опис генератора Monte Carlo знімає цей етап — новий набір сценаріїв збирається в рази швидше, а не за дні.

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

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

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

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

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

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

Підходи до моделювання портфеля: порівняння режимів

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

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

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

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

Етапи розробки: від аудиту даних до передачі в експлуатацію

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

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

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

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

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

   Генератор запускаємо з фіксованим зерном: результат відтворюваний, а інженерна зміна видно окремо від випадкового розкиду.

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

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

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

Що передаємо на руки: моделі, конфігурації, регламенти

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

Тому передаємо не лише код, а й повний контур відтворюваності — від опису моделі до регламенту перерахунку.

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

Кейс: як змінилася оцінка ризику після впровадження

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

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

Сценарії готували 15 робочих днів, а підсумок залежав від того, хто збирав вивантаження: розходження в 95-му квантилі втрат між підрозділами доходили до 12 пунктів, і ще тиждень ішов на звірку.

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

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

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

Чим сценарний аналіз відрізняється від стрес-тестування?

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

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

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

Стрес дає точкову відповідь: на якому кроці спрацьовують примусові закриття і чи залишається капітал додатним.

Розрізняються й припущення про зв'язки між активами. У сценарному аналізі залежності відтворюються статистичною моделлю — і в хвості вони підсилюються, що майже не видно на спокійних даних.

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

Звідси й вибір методу. Питання «де ламається портфель і який запас міцності потрібен» закриває стрес-тестування; питання «скільки капіталу тримати і як часто порушується ліміт» — розподіл із прогонів.

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

Технічні сумніви: дані, точність, відтворюваність

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

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

Це точковий прогноз чи діапазон?

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

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

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

Як вбудувати розрахунок у звітність і оновлювати модель?

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

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

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

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

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