Розрахунок бета-коефіцієнта криптоактиву: де ламається
Бета рахується за простою формулою: коваріація дохідностей активу й ринку, поділена на дисперсію ринку. Поки інструментів п'ять, розрахунок бета-коефіцієнта криптоактиву сходиться в таблиці вручну.
На сотні активів ручна оцінка ринкового ризику криптоактиву розвалюється одразу в кількох місцях, і кожне місце дає тихо неправильний результат замість явної помилки.
Перше джерело розбіжностей — розсинхрон джерел котирувань. Біржі дають різні ціни закриття, в одних пар торгівля триває цілодобово, в інших є перерви, і ряд, зшитий з різних стрічок, зміщує коваріацію на помітну частку.
Друге — розбіжні вікна спостереження: один розрахунок бере ковзний рік за денними свічками, інший квартал за годинними, і бети перестають бути порівнюваними між звітами.
Пропуски в цінових рядах добивають результат: делістинг пари, зупинка торгів, розрив ліквідності на вихідних.
Якщо дірку закрити нулем або протягнути останню ціну вперед, дисперсія занижується, і бета з'їжджає до нуля або до одиниці — актив у звіті виглядає безпечнішим, ніж він є насправді.
І головне — відтворюваність методики розрахунку. Без журналу змін неможливо відповісти, чому бета за минулий період відрізнялася від поточної: змінилося вікно, джерело або правило відсікання викидів.
Ризик-звіт, який не можна повторити, перестає бути опорою для рішень — на нього не спертися в суперечці з ризик-комітетом. Розбираємо, як це закривається.
Що змінюється після впровадження: ефект у вимірюваних величинах
Ефект вважаємо не за відчуттями, а за величинами, які знімаються із самої системи: час перерахунку, частка розбіжностей між звітами, закриті класи відмов, глибина історії та версіонування методики.
Підхід до оцінки ризику спираємо на галузеву практику — ринкову модель і RiskMetrics. Нижче п'ять результатів, які видно вже в першому звітному циклі.
- Швидкість перерахунку портфеля. Повний перерахунок бети за всіма позиціями замість нічного пакета триває хвилини, тому його запускають після кожного значущого руху ринку, а не раз на добу — розрахунок перестає бути вузьким місцем ризик-контуру.
- Розбіжності між звітами. Єдине джерело цін і одна методика на ризик-звіт, звіт перед клієнтом і облікову систему: залишкові відмінності пояснюються лише моментом знімка, а не логікою розрахунку.
- Усунені класи відмов. Зникають розрахунок на застарілому знімку цін, пропуск делістингу та зміни тікера, дублі угод при повторному завантаженні, ручна правка коефіцієнта без сліду в журналі.
- Глибина історичних даних. Вікно історії розширюється так, щоб коефіцієнт рахувався на кількох ринкових режимах, а не на одному тренді; під час оновлення старі зрізи не перетираються.
- Прозорість змін методики. Кожна правка вікна, ваг і джерела цін фіксується версією: видно, що змінилося, коли і на скільки зсунувся коефіцієнт.
Підходи до оцінки бети: регресія, вікна, факторні моделі
Бета — це коваріація дохідності активу з ринком, поділена на дисперсію ринку. Формула однакова в усіх підходах, а результат визначають три рішення: як рахуються дохідності, яке вікно береться і що робиться з аномальними точками.
На розрізненій ліквідності та різких перемиканнях режиму те саме вікно дає бету, що відрізняється кратно, — тому оцінку обирають під характер активу, а не за замовчуванням.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Регресійна оцінка бети на фіксованому вікні | Регулярна звітність, потрібна відтворюваність: той самий період дає те саме число | Один викид у котируванні помітно тягне коефіцієнт, на зміні режиму значення відстає |
| Ковзне вікно спостереження з вагами | Волатильність змінюється, важливіші свіжі спостереження | Значення «тремтить» від дня до дня, потрібне налаштування глибини вікна та затухання ваг |
| Багатофакторна модель ризику | Дохідність пояснюється не лише ринком: ставка, домінація, галузевий фактор | Потребує більше історії, фактори корелюють між собою, зростає ризик перенавчання |
| Оцінка за власним індексом ліквідності | Актив торгується на кількох майданчиках, ринок тонкий, еталонного індексу немає | Індекс потрібно будувати й підтримувати, історичних даних менше |
На практиці підходи не конкурують, а доповнюють один одного. Фіксоване вікно дає базу для звіту, ковзне показує напрям зсуву, багатофакторна модель пояснює розбіжність, а власний індекс ліквідності закриває активи, для яких зовнішній еталон працює погано.
Згладжування викидів вважаємо окремим обов'язковим кроком: без нього будь-яка з оцінок чутлива до однієї неправильної свічки. Розрахунок ведемо двома способами паралельно — розбіжність між ними слугує сигналом, що вікно або склад факторів вибрано неправильно.
Етапи впровадження: від аудиту даних до передачі в експлуатацію
Перш ніж рахувати бета-коефіцієнт, потрібно переконатися, що вхідні дані взагалі придатні для розрахунку. У криптоактивів котирування надходять із десятків бірж і різняться за торговими парами, глибиною ринку та мітками часу.
Пропуски, викиди на низьколіквідних майданчиках і розсинхрон годинників дають бети, які не відтворюються під час наступного перерахунку — а отже, на них не можна спиратися в оцінці ризику. Тому маршрут починається з аудиту даних, а не з формул.
- Аудит джерел даних. Перевіряємо повноту історії, частоту котирувань, частку пропусків і викидів за кожною біржею та парою; фіксуємо, які майданчики йдуть у розрахунок, а які залишаються лише довідковими.
- Схема потоків котирувань. Проєктуємо шлях даних до сховища: нормалізація міток часу до одного поясу, приведення пар до єдиного активу-знаменника, видалення дублів і порядок довантаження пропущених ділянок.
- Узгодження методики розрахунку. Обираємо базу порівняння — ринковий індекс або провідний актив, — вікно та крок перерахунку, спосіб обробки дохідностей; спірні місця проговорюємо до коду, а не після першого вивантаження.
- Налаштування перерахунку та зберігання. Розрахунок стає регулярним: вікна оновлюються за розкладом, результати версіонуються, попередні значення залишаються доступними для порівняння та відкату.
- Приймальні перевірки на історії. Проганяємо систему на історичних даних і звіряємо з еталонним розрахунком; розбіжність понад допуск розбираємо до передачі, а не після.
- Паралельний прогін. Нова система рахує поруч із поточним процесом на живому потоці, значення зіставляються, поки розбіжності не зійдуть у нуль.
- Передача в експлуатацію та навчання. Передаємо документацію з конфігурації, розбираємо типові інциденти й навчаємо команду замовника супроводжувати розрахунок самостійно.
Кожен етап закривається своїм артефактом — звітом, схемою або результатом звірки. Без нього далі не йдемо: так помилка в даних не перетворюється на помилку в моделі, яку потім шукають тижнями.
Що передаємо на руки: артефакти, схеми, регламенти
Після приймання у вашої команди залишається не «працюючий сервіс», а комплект, за яким розрахунок можна супроводжувати й розширювати без нас. Передаємо його поруч із кодом, щоб правка методики й правка реалізації йшли одним зміненням і не розходилися по різних документах.
- Опис методики розрахунку — вікно дохідностей, еталонний ринковий орієнтир, крок перерахунку, обробка пропусків у торгових даних і правила виключення низьколіквідних пар, із прикладами розбіжностей із наївною оцінкою.
- Схеми інтеграції джерел — які біржові потоки та історичні вивантаження використовуються, як зіставляються тікери й валютні пари, що відбувається при розбіжності цін між майданчиками та як відпрацьовує повторний запит при обриві.
- Політики доступу до даних — ролі, розділення ключів читання й запису, журнал звернень до історичних рядів, порядок видачі доступів аналітикам і правила зміни секретів.
- Регламент перерахунку та реакції на збої — розклад планового перерахунку, запуск позапланового при аномаліях, відновлення пропущених вікон, пороги оповіщень про розбіжність із попереднім значенням.
- Інструкції для аналітиків — як запустити розрахунок вручну, як прочитати службові метрики якості вхідних даних, як зафіксувати обґрунтоване коригування та зберегти історію змін.
- Набір тестових сценаріїв — еталонні ряди, перевірки на розривах і викидах, звірка з незалежним джерелом: після будь-якої правки видно, що розрахунок не поїхав.
- Карта залежностей і відкат — що зачіпає зміна джерела, як повернути попередню версію методики та які значення після цього потрібно перерахувати.
Кейс: перерахунок портфеля із доби у хвилини
Замовник — інвестиційна команда з портфелем криптоактивів у кілька десятків позицій: бета кожної монети до ринку була потрібна для лімітів ризику й регулярної звітності.
Перерахунок запускався раз на добу й займав майже стільки ж: котирування вивантажувалися вручну, вікна спостереження в різних аналітиків не збігалися, а активи з короткою історією оцінювалися «на око» — за одним-двома схожими інструментами.
Ціна такої схеми проявлялася в розбіжностях: два звіти за одним і тим самим портфелем давали оцінки, що відрізнялися на кілька відсоткових пунктів. Оспорити ліміт або пояснити інвестору цифру було нічим — під нею не стояв відтворюваний розрахунок.
Що зібрали
Єдину методику оцінки ризику: одне джерело котирувань (CoinGecko), фіксоване вікно спостереження, спільний ринковий орієнтир і явні правила відбору для активів із неповною історією.
Кожен показник у звіті тепер посилається на зріз даних, з якого він отриманий, — аж до конкретного часового ряду.
Що вийшло
Час перерахунку всього портфеля — хвилини замість доби, розбіжності між звітами впали до десятих часток відсоткового пункту. Однаковий вхід дає однаковий результат, тому кейс розрахунку бети відтворюється й перевіряється зовнішнім аудитором без розбору чужої логіки.
Що робити, якщо розрахунок уже зібрано на електронних таблицях
Формула бети переноситься швидко — ризик не в ній, а у втраті порівнюваності з минулими звітами.
Довжина вікна ретроспективи, спосіб заповнення пропусків, часовий пояс закриття свічок і джерело ціни зсувають показник на десяті частки, і накопичений ряд перестає читатися як одна безперервна історія.
Перенесення історичних розрахунків починаємо з еталона: проганяємо минулі періоди через новий контур і звіряємо результат за кожним активом і кожним вікном. Допуск розбіжності фіксуємо до початку робіт — тисячні частки, а не «приблизно збіглося».
Вихід за допуск означає, що розійшлася не математика, а налаштування середовища, і шукати потрібно саме його.
Ламаються під час перенесення зазвичай табличні звички навколо формули.
Протягнуті вниз діапазони захоплюють зайві рядки після додавання активу, правка однієї комірки живе поза історією змін і не відтворюється, остання ціна тягнеться вперед на дні без угод, а вихідні на різних майданчиках обробляються однаково.
Кожну таку ділянку потрібно відтворити явно або усвідомлено замінити — інакше розбіжність спливе вже у звіті перед інвестором.
Перемикання робимо поступовим: міграція з електронних таблиць іде паралельним контуром, і поки звірка старого й нового розрахунку не зійдеться, джерелом звітності залишається таблиця.
Міграцію ведемо групами — спочатку ліквідні активи із щільною історією, потім низьколіквідні, де пропуски та викиди дають найбільший розкид. Так звітність не зупиняється ні на день, а порівнюваність показників перевіряється на всьому перехідному періоді.
Технічні сумніви перед стартом: часті питання
Питання перед стартом розрахунку бета-коефіцієнта зазвичай не про формулу, а про якість вхідних даних. Саме вікно спостереження, повнота котирувань і стабільність джерела визначають результат — розбираємо те, що найчастіше спливає на етапі оцінки.
Яке вікно спостереження брати?
Коротке вікно ловить поточний режим ринку, але дає шумну оцінку; довге стійкіше, зате розмиває зміну режиму. Рахуємо бета на кількох вікнах одразу й віддаємо основний варіант разом із розкидом — видно, наскільки результат залежить від періоду.
Що відбувається на низьколіквідних криптоактивах?
За рідких угод дохідність у більшості точок нульова, і бета зміщується до нуля — актив виглядає менш ризикованим, ніж є. Переходимо на більший інтервал, відсікаємо дні без торгів і позначаємо оцінку як обмежено надійну.
Як бути з пропусками в котируваннях?
Видаляти пропущений день не можна: роз'їжджаються пари дохідностей активу й ринку, спотворюється коваріація. Вирівнюємо календар, відновлюємо ряд за фіксованим правилом і окремо перевіряємо, наскільки бета чутлива до цього правила.
Що якщо змінилося джерело даних?
Звіряємо обидва джерела на періоді перекриття й переходимо на спільній даті. Інакше на стику виникає хибний стрибок дохідності, коваріація ламається, і у звіті з'являється переоцінка ризику, якої на ринку не було.
Як переконатися, що розрахунок коректний?
Перевіряємо на інваріантах: бета ринку до самого себе дорівнює одиниці, зміна масштабу дохідності не змінює результат, синтетичний ряд із заздалегідь відомою бетою відтворюється.
Журнал вхідних даних — період, джерело, правила очищення — робить розрахунок відтворюваним у будь-який момент.
Обговоримо задачу й повернемося з оцінкою та планом робіт
Щоб оцінка була точною, а не приблизною, потрібні ввідні: бета-коефіцієнт криптоактиву рахується за рядом дохідностей, і результат залежить від складу кошика, джерела котирувань і вікна оцінки.
Чим конкретніші вихідні дані, тим щільніший план робіт — інакше закладаємо запас на розбір і уніфікацію рядів.
Достатньо надіслати п'ять пунктів:
- Склад активів і джерела котирувань: які монети входять у розрахунок, з яких майданчиків беремо ціни, що робити з низьколіквідними парами та розривами в історії.
- Поточна методика та її обмеження: як рахуєте зараз, яке вікно й частота, як обробляєте пропуски та викиди, що в результатах не влаштовує.
- Вимоги до частоти перерахунку: раз на добу, за появою нової свічки або на запит, чи потрібен перерахунок історії при зміні складу кошика.
- Споживачі звіту: хто й як використовує цифру — ризик-контроль, аналітика, торгові стратегії, — і в якому вигляді їм зручно її отримувати.
- Яким має бути результат: вивантаження у файл, програмний інтерфейс, панель із графіком, набір полів і глибина історії.
Далі обговорюємо задачу по суті: уточнюємо спірні місця, узгоджуємо модель даних і еталонний індекс, відносно якого рахуємо бету. Повертаємося з оцінкою та планом робіт — етапи, склад вихідних даних і артефактів, контрольні точки, де ви перевіряєте проміжний результат.
