Розробка індикатора Open Interest: чому метрика розходиться
Відкритий інтерес за однією монетою на різних майданчиках не збігається з біржовими значеннями — причина в різній методиці, а не в помилці розрахунку.
Один майданчик рахує лише безстрокові контракти, інший додає ф'ючерси з датою поставки, третій перераховує обсяг у базовий актив за поточною ціною, а не за ціною входу.
Підсумовування таких чисел дає розходження з інтерфейсом біржі, і спиратися на нього в торговій логіці не можна.
Агрегація відкритого інтересу починається з приведення майданчиків до спільної бази: розмір контракту, множник, момент фіксації за часом сервера майданчика. Окремо вирішується доля інструментів, що торгуються в кількох розрахункових одиницях, — інакше одна монета рахується двічі. Ми зберігаємо знімок та історію правок, щоб значення можна було перерахувати заднім числом.
Пропуски даних при волатильності — друге джерело викривлень. На різкому русі потокові канали майданчиків віддають знімок із затримкою або рвуть підписку.
Якщо на розриві підставити останнє відоме число, індикатор малює рівну лінію і сигнал запізнюється; якщо нуль — з'являється хибне скидання відкритого інтересу.
Лікується це міткою достовірності: значення позначається як непідтверджене, перекривається наступним знімком і дозаповнюється з історії.
Затримка сповіщень — зазвичай наслідок періодичного опитування та черги повторів: сигнал має спрацьовувати за фактом зміни метрики, а не за таймером. Далі розбираємо, як це закривається під час розробки індикатора Open Interest.
Що дає власний розрахунок відкритого інтересу
Відкритий інтерес майданчика рахують за різними правилами: у CME Group це контракти з фіксованим номіналом, у криптобірж — обсяг у монетах, частина майданчиків округлює значення при публікації.
Готовий графік з боку біржі віддає вже агреговане число, тому розходження між джерелами нема чим пояснити, а на різкому русі ціни воно маскує реальну динаміку позицій.
Власний розрахунок відкритого інтересу будується від первинних даних: забираємо оновлення по кожному майданчику, приводимо значення до спільної бази і лише потім агрегуємо. Так виходить єдина метрика по майданчиках — одна шкала, узгоджені мітки часу, однаковий крок публікації. Розходження між джерелами видно окремим рядом, а не як помилка на графіку.
Стійкість до ліквідацій закладається на рівні обробки. Каскад закриттів приходить пачкою оновлень, частина — із затримкою або повтором: потік буферизується, дублі відсікаються за ідентифікатором запису, пропущений інтервал дозапитується з історії.
Контроль якості даних іде паралельно — значення звіряється з незалежним джерелом, і при розходженні вище порогу спрацьовує сигнал, а не тихе згладжування.
Що перестає ламатися:
- графік не перемальовується заднім числом при зміні джерела;
- порівняння майданчиків залишається коректним на будь-якому інтервалі;
- сплески від каскадних ліквідацій видно і вони пояснювані;
- пропуск у потоці майданчика позначається флагом якості.
Варіанти розрахунку: знімки, потік подій, гібридна схема
Збирати відкритий інтерес можна двома різними способами: періодичним опитуванням майданчика (знімки стану) і підпискою на потік змін, де кожне оновлення приходить окремою подією.
Знімки дають рівний ряд без пропусків між точками, потік — мінімальну затримку й повноту, але потребує звірки зі знімком, щоб відновити значення після обриву зв'язку.
Що вибрати, вирішують чутливість споживача до затримки і те, як часто змінюється склад інструментів на майданчику. Нижче — чесне порівняння: де кожен варіант ламається і що доводиться добудовувати.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Знімки стану майданчика | Ретроспектива, розрахунок за історією, майданчики із закритим потоком подій | Точність обмежена кроком опитування, сплески між точками губляться |
| Потік змін | Сигнали й оповіщення, де важлива затримка | Обрив зв'язку дає провал у ряді, потрібен дозбір історії та звірка значення |
| Гібридна схема розрахунку | Робочий індикатор з довгою історією та живим оновленням | Дорожче в підтримці: два джерела, логіка звірки та розв'язання розходжень |
Гібрид і виявляється робочим: опорний знімок на старті та за розкладом задає базове значення, потік змін уточнює його між знімками, а розходження понад поріг запускає перезбирання ділянки ряду. Так індикатор переживає обриви зв'язку та зміну складу інструментів без провалів.
Етапи впровадження: від розбору вимог до передачі
Починаємо з розбору вимог, а не з коду: від цього залежить, які майданчики й контракти потраплять у розрахунок, яка глибина історії потрібна і як часто оновлюється значення. Далі фіксуємо схему даних, домовляємося про формат видачі і лише потім збираємо розрахункове ядро.
Кожен етап завершується артефактом, який можна перевірити, — тому впровадження індикатора відкритого інтересу йде передбачувано, без сюрпризів на фіналі.
- Розбір вимог. Уточнюємо перелік бірж та інструментів, горизонт історії, частоту перерахунку й спосіб доставки значень — вітрина, програмний інтерфейс або подієвий потік. Підсумок — узгоджений опис метрики.
- Схема даних. Визначаємо джерела, правила нормалізації та обробку розривів: пропуски збору, зміна контракту, вихідні дні. Фіксуємо, що вважаємо еталоном при розходженні.
- Складання розрахункового ядра. Реалізуємо розрахунок відкритого інтересу, агрегацію за інструментами та періодами, кешування. Логіка покривається автотестами до першого запуску на бойових даних.
- Перевірка на історичних даних. Проганяємо розрахунок на накопиченій історії та порівнюємо з незалежним джерелом. Тут виловлюються помилки округлення, дублі та зсув часових поясів.
- Звірка з майданчиком. Зіставляємо значення з даними біржі в контрольних точках, розбираємо розходження та документуємо допустимі відхилення.
- Приймання розрахунку. Передаємо методику й тести, відкриваємо доступ до моніторингу, підтверджуємо збіг на узгодженому наборі перевірок.
- Передача та навчання. Віддаємо вихідники, конфігурацію та інструкції з експлуатації, розбираємо типові збої та супроводжуємо перший самостійний запуск.
Що залишається в контурі замовника після здачі
Після здачі індикатора в контурі замовника залишається не лише робочий розрахунок, а й усе, що дозволяє супроводжувати його власними силами: оновлювати, налагоджувати та передавати новому інженеру. Нижче — перелік артефактів, які ми фіксуємо на прийманні.
- Схема даних. Які поля приходять із біржових потоків (відкритий інтерес, обсяги, мітки часу), в яких одиницях, з якою періодичністю і як різні майданчики приводяться до одного вигляду.
- Конфігурації. Список джерел, інтервали опитування, правила агрегації та перерахунку, пороги спрацювання — винесені в окремі файли й правляться без перезбирання.
- Документація з індикатора. Формули розрахунку, поведінка при пропусках у потоці, розривах сесій та зміні контракту, реакція на запізнілі дані.
- Регламенти оновлення. Порядок підключення нового майданчика або інструмента, випуск змін у розрахунок та обов'язкові перевірки перед викаткою.
- Політики доступу до даних. Ролі, ключі доступу, розділення прав на читання й на зміну налаштувань, журнал дій.
- Оповіщення про збої. Метрики та пороги, канали сповіщень, послідовність дій чергового при втраті потоку або розходженні значень.
- Еталонні набори. Зрізи історичних даних, на яких перевіряється коректність розрахунку після будь-якої зміни.
- Інструкція з розгортання. Підняти сервіс з нуля, перенести на інший контур, відкотитися на попередню версію.
Кожен артефакт передаємо з розбором на дзвінку: інженер проходить за схемою, показує, де міняти налаштування, і відповідає на запитання команди замовника.
Кейс: як розходження з біржовими значеннями зникло
Замовник — аналітична команда, яка будує сигнали на відкритому інтересі ф'ючерсів. Індикатор збирав значення з кількох майданчиків, але вони розходилися з біржовими вітринами до кількох відсотків: десь губилися часткові угоди, десь обсяг подвоювався при перепідключенні до потоку.
Щоранку аналітик вручну звіряв зрізи за інструментами — на це йшло понад дві години, і частина розходжень випливала вже після відкриття позиції.
Що змінили: збір переїхав на потік подій майданчика замість періодичного опитування, додалися дедуплікація за ідентифікатором угоди та зберігання знімків стану.
Агрегат тепер перераховується незалежно за сирими даними — якщо він розходиться з вітриною, значення позначається і йде в чергу на розбір, а не в сигнал.
Окремо поставили автоматичну звірку з еталоном: раз на інтервал індикатор порівнює себе з публічними даними CoinGlass і формує звіт за відхиленнями. Ручна робота скоротилася приблизно на 90% — аналітик дивиться лише розходження вище порогу.
Після переробки частка значень із розходженням понад 0.5% упала з 4% до 0.2%, а затримка оновлення — з п'яти хвилин до двох секунд. Аномалію у відкритому інтересі видно майже одразу, час реакції на різке зростання або скидання скоротився з години до пари хвилин. Збій збирача тепер помітний за пропуском знімків, а не за збитком у позиції.
Чим розрахунковий індикатор відрізняється від біржового значення?
Біржове значення відкритого інтересу майданчик рахує сам: він бачить усі позиції за своїми контрактами й оновлює метрику на закритті свічки або черговому зрізі. Точність метрики максимальна, але описує вона один майданчик, а ліквідації потрапляють у публічний потік із затримкою.
Розрахунковий індикатор збирає показник з кількох джерел: забираємо публічні потоки угод і позицій, приводимо контракти до єдиного номіналу й додаємо. Склад майданчиків задаємо явно — топ за обсягом або лише ті, де торгує клієнт, як публічні агрегатори на кшталт CoinGlass. Без фільтра ліквідацій каскад примусових закриттів дає сплеск, якого на ринку не було.
Основне розходження — затримка оновлення метрики: майданчик віддає значення за розкладом, розрахунковий ряд перераховується за кожною подією і на різкому русі випереджає біржовий.
Для сигналів це перевага, для звірки зі звітом майданчика — джерело розходжень, яке закладають у допуски.
| Джерело | Коли підходить | Обмеження |
|---|---|---|
| Біржове значення | Робота в межах одного майданчика, звірка з його звітами | Не бачить ринок цілком, затримка публікації, різна методика майданчиків |
| Розрахунковий індикатор | Зведена аналітика та сигнали за кількома майданчиками | Залежить від доступності потоків, потрібні нормалізація та фільтр ліквідацій |
| Гібрид | Контроль ризику: важливі і охоплення, і точність | Складніше в підтримці, потрібен контроль розходження джерел |
Джерело вибирають під задачу: для звіту — біржове значення, для сигналів — розрахунковий індикатор, для контролю ризику — гібрид. Склад майданчиків і правила обробки ліквідацій фіксуємо в специфікації до старту робіт.
Технічні сумніви перед стартом робіт
Перед стартом замовники перевіряють не формулу агрегації, а стійкість потоку даних і ціну подальшого розширення. Нижче — питання, які найчастіше порушують на технічних зустрічах, і наші відповіді.
Індикатор збирає відкритий інтерес з кількох джерел: потокових каналів майданчиків і резервного опитування за розкладом. Кожне джерело пише в окреме сховище з міткою часу, а розрахунковий шар зводить дані в єдиний ряд — збій одного майданчика не викривляє загальну картину.
Що відбувається при розриві з'єднання з біржею?
Канал перепіднімається автоматично з наростаючою паузою, а пропущений інтервал закривається резервним опитуванням за минулі хвилини. Місце розриву позначається окремою ознакою, щоб аналітика не прийняла діру за нульовий інтерес.
Як перевіряється коректність розрахунку?
Щогодини агреговане значення звіряється з еталонною відповіддю майданчика, розходження вище порогу піднімає оповіщення. Окремо контролюємо повноту рядів: частка пропущених інтервалів і час до відновлення видні на одному дашборді.
Наскільки трудомістко додати новий майданчик?
Джерело підключається окремим адаптером до спільного інтерфейсу: опис контракту, нормалізація полів, тести на історичних даних. Новий майданчик не зачіпає розрахункове ядро, тому розширення йде передбачувано.
Що входить у передачу підтримки?
Схему даних, регламент чергування та алертів, інструкції з типових збоїв і розбір із вашою командою. За потреби залишаємося на супроводі — межу відповідальності фіксуємо заздалегідь.
Обговоримо задачу та повернемося з оцінкою і планом
Обговорення задачі починаємо з предметної частини: які майданчики й типи контрактів у фокусі — безстрокові ф'ючерси, квартальні, опціони, — чи потрібне розбиття за біржами або зведений індекс, за який період потрібна історія і як часто індикатор має оновлюватися.
Від замовника достатньо сценарію: як сигнал використовується в рішенні й яке розходження з публікованим значенням майданчика вважається неприпустимим.
Паралельно запитуємо доступи до даних майданчиків: публічні потоки, історію через програмний інтерфейс, де є — тестовий контур із ключами лише на читання.
Це ще до оцінки показує, чи вистачає глибини угод і знімків відкритого інтересу для розрахунку, чи джерело доведеться збирати через агрегатор.
Далі робимо пробний розрахунок: беремо вікно в кілька діб за одним-двома контрактами, рахуємо відкритий інтерес, звіряємо з публікованим значенням майданчика й показуємо розходження у відсотках. Після цього повертаємося з оцінкою та планом робіт.
Що входить у відповідь:
- перелік майданчиків і контрактів: що віддає кожен — знімки відкритого інтересу, стрічку угод, глибину стакана;
- підсумок пробного розрахунку — збіг із публікованим значенням у межах заданої точності або розбір причин розходження;
- оцінка та план робіт за етапами: збір даних, розрахунок, відрисовка індикатора, оповіщення, приймання;
- схема доставки сигналу: віджет на сторінці, програмний інтерфейс або повідомлення в месенджер;
- вимоги до глибини історії та частоти перерахунку, щоб індикатор не відставав від ринку;
- склад документації: формула розрахунку, конфігурації, інструкція з розгортання.
