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

Чому кореляційний аналіз криптовалют дає хибні сигнали

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

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

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

Усередині одного режиму активи рухаються зі зв'язком 0,6–0,8, при зміні режиму він падає до 0,2, а іноді змінює знак — актив, який «страхував» решту, починає тягнути портфель вниз разом з ними.

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

Зворотна крайність — помилка на коротких вікнах. Якщо рахувати зв'язок за десятками останніх точок, оцінка стає настільки шумною, що ширина довірчого інтервалу порівнянна з самим коефіцієнтом: 0,7 і −0,1 формально нерозрізненні.

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

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

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

Що дає безперервний аналіз зв'язків замість разових вивантажень

Разова вивантаження дає зріз на момент запуску: зв'язки між активами перераховані, звіт зданий.

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

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

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

Режими розрахунку зв'язків: вікно, ваги, повна історія

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

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

Як вибираємо довжину вікна

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

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

Етапи впровадження: аудит джерел, схема, налаштування, передача

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

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

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

Артефакти постачання: схеми конвеєра, регламенти, документація

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

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

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

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

Кейс: перерахунок зв'язків у реальному часі замість ручних таблиць

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

На сорока з лишком інструментах повний перерахунок займав 3–4 години, і на момент готовності частина зв'язків уже встигала перебудуватися.

Як було

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

Що стало

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

• затримка зв'язку з ринком: години → секунди;
• ручні перерахунки: щоденна зміна → нуль;
• охоплення: 40+ пар, дві шкали вікна, історія по всіх;
• оповіщення: за фактом розбору → автоматично при розриві зв'язку.

За перший місяць з'ясувалося, що близько третини «стійких» на довгому вікні пар розпадалися на короткому — такі розходження раніше просто не потрапляли в таблицю. Аналітик перестав бути оператором вивантажень і зайнявся розбором сигналів, а не заповненням комірок.

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

Що робити, якщо зв'язки між активами ламаються на зміні режиму?

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

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

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

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

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

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

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

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

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

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

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

Як вибрати довжину вікна?

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

Що робити при лістингу нового інструмента?

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

Затримки котирувань ламають розрахунок?

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

Обговоримо задачу: які дані є і що вважаємо першим

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

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

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