Разработка индикатора Open Interest для криптобирж под ключ

Разработка индикатора Open Interest: почему метрика расходится

Открытый интерес по одной монете на разных площадках не сходится с биржевыми значениями — причина в разной методике, а не в ошибке расчёта. Одна площадка считает только бессрочные контракты, другая добавляет фьючерсы с датой поставки, третья пересчитывает объём в базовый актив по текущей цене, а не по цене входа. Суммирование таких чисел даёт расхождение с интерфейсом биржи, и опираться на него в торговой логике нельзя.

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

Пропуски данных при волатильности — второй источник искажений. На резком движении потоковые каналы площадок отдают снимок с задержкой или рвут подписку. Если на разрыве подставить последнее известное число, индикатор рисует ровную линию и сигнал опаздывает; если ноль — появляется ложный сброс открытого интереса. Лечится это меткой достоверности: значение помечается как неподтверждённое, перекрывается следующим снимком и дозаполняется из истории.

Задержка уведомлений — обычно следствие периодического опроса и очереди повторов: сигнал должен срабатывать по факту изменения метрики, а не по таймеру. Дальше разбираем, как это закрывается при разработке индикатора Open Interest.

Что даёт собственный расчёт открытого интереса

Открытый интерес площадки считают по разным правилам: у CME Group это контракты с фиксированным номиналом, у криптобирж — объём в монетах, часть площадок округляет значение при публикации. Готовый график со стороны биржи отдаёт уже агрегированное число, поэтому расхождение между источниками нечем объяснить, а на резком движении цены оно маскирует реальную динамику позиций.

Собственный расчёт открытого интереса строится от первичных данных: забираем обновления по каждой площадке, приводим значение к общей базе и только потом агрегируем. Так получается единая метрика по площадкам — одна шкала, согласованные метки времени, одинаковый шаг публикации. Расхождение между источниками видно отдельным рядом, а не как ошибка на графике.

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

Что перестаёт ломаться:

• график не перерисовывается задним числом при смене источника;
• сравнение площадок остаётся корректным на любом интервале;
• всплески от каскадных ликвидаций видны и объяснимы;
• пропуск в потоке площадки помечается флагом качества.

Варианты расчёта: снимки, поток событий, гибридная схема

Собирать открытый интерес можно двумя разными способами: периодическим опросом площадки (снимки состояния) и подпиской на поток изменений, где каждое обновление приходит отдельным событием. Снимки дают ровный ряд без пропусков между точками, поток — минимальную задержку и полноту, но требует сверки со снимком, чтобы восстановить значение после обрыва связи.

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

Гибрид и оказывается рабочим: опорный снимок при старте и по расписанию задаёт базовое значение, поток изменений уточняет его между снимками, а расхождение сверх порога запускает пересборку участка ряда. Так индикатор переживает обрывы связи и смену состава инструментов без провалов.

Этапы внедрения: от разбора требований до передачи

Начинаем с разбора требований, а не с кода: от этого зависит, какие площадки и контракты попадут в расчёт, какая глубина истории нужна и как часто обновляется значение. Дальше фиксируем схему данных, договариваемся о формате выдачи и только потом собираем расчётное ядро. Каждый этап заканчивается артефактом, который можно проверить, — поэтому внедрение индикатора открытого интереса идёт предсказуемо, без сюрпризов на финале.

1. Разбор требований. Уточняем перечень бирж и инструментов, горизонт истории, частоту пересчёта и способ доставки значений — витрина, программный интерфейс или событийный поток. Итог — согласованное описание метрики.
2. Схема данных. Определяем источники, правила нормализации и обработку разрывов: пропуски сбора, смена контракта, выходные дни. Фиксируем, что считаем эталоном при расхождении.
3. Сборка расчётного ядра. Реализуем расчёт открытого интереса, агрегацию по инструментам и периодам, кэширование. Логика покрывается автотестами до первого запуска на боевых данных.
4. Проверка на исторических данных. Прогоняем расчёт на накопленной истории и сравниваем с независимым источником. Здесь вылавливаются ошибки округления, дубли и смещение часовых поясов.
5. Сверка с площадкой. Сопоставляем значения с данными биржи в контрольных точках, разбираем расхождения и документируем допустимые отклонения.
6. Приёмка расчёта. Передаём методику и тесты, открываем доступ к мониторингу, подтверждаем совпадение на согласованном наборе проверок.
7. Передача и обучение. Отдаём исходники, конфигурацию и инструкции по эксплуатации, разбираем типовые сбои и сопровождаем первый самостоятельный запуск.

Что остаётся в контуре заказчика после сдачи

После сдачи индикатора в контуре заказчика остаётся не только работающий расчёт, но и всё, что позволяет сопровождать его своими силами: обновлять, отлаживать и передавать новому инженеру. Ниже — перечень артефактов, которые мы фиксируем в приёмке.

• Схема данных. Какие поля приходят с биржевых потоков (открытый интерес, объёмы, метки времени), в каких единицах, с какой периодичностью и как разные площадки приводятся к одному виду.
• Конфигурации. Список источников, интервалы опроса, правила агрегации и пересчёта, пороги срабатывания — вынесены в отдельные файлы и правятся без пересборки.
• Документация по индикатору. Формулы расчёта, поведение при пропусках в потоке, разрывах сессий и смене контракта, реакция на запоздавшие данные.
• Регламенты обновления. Порядок подключения новой площадки или инструмента, выпуск изменений в расчёт и обязательные проверки перед выкаткой.
• Политики доступа к данным. Роли, ключи доступа, разделение прав на чтение и на изменение настроек, журнал действий.
• Оповещения о сбоях. Метрики и пороги, каналы уведомлений, последовательность действий дежурного при потере потока или расхождении значений.
• Эталонные наборы. Срезы исторических данных, на которых проверяется корректность расчёта после любого изменения.
• Инструкция по развёртыванию. Поднять сервис с нуля, перенести на другой контур, откатиться на предыдущую версию.

Каждый артефакт передаём с разбором на созвоне: инженер проходит по схеме, показывает, где менять настройки, и отвечает на вопросы команды заказчика.

Кейс: как расхождение с биржевыми значениями ушло

Заказчик — аналитическая команда, которая строит сигналы на открытом интересе фьючерсов. Индикатор собирал значения с нескольких площадок, но они расходились с биржевыми витринами до нескольких процентов: где-то терялись частичные сделки, где-то объём удваивался при переподключении к потоку. Каждое утро аналитик вручную сверял срезы по инструментам — на это уходило больше двух часов, и часть расхождений всплывала уже после открытия позиции.

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

Отдельно поставили автоматическую сверку с эталоном: раз в интервал индикатор сравнивает себя с публичными данными CoinGlass и формирует отчёт по отклонениям. Ручная работа сократилась примерно на 90% — аналитик смотрит только расхождения выше порога.

После переделки доля значений с расхождением больше 0.5% упала с 4% до 0.2%, а задержка обновления — с пяти минут до двух секунд. Аномалию в открытом интересе видно почти сразу, время реакции на резкий рост или сброс сократилось с часа до пары минут. Сбой сборщика теперь заметен по пропуску снимков, а не по убытку в позиции.

Чем расчётный индикатор отличается от биржевого значения?

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

Расчётный индикатор собирает показатель из нескольких источников: забираем публичные потоки сделок и позиций, приводим контракты к единому номиналу и складываем. Состав площадок задаём явно — топ по объёму или только те, где торгует клиент, как публичные агрегаторы вроде CoinGlass. Без фильтра ликвидаций каскад принудительных закрытий даёт всплеск, которого на рынке не было.

Основное расхождение — задержка обновления метрики: площадка отдаёт значение по расписанию, расчётный ряд пересчитывается по каждому событию и на резком движении опережает биржевой. Для сигналов это преимущество, для сверки с отчётом площадки — источник расхождений, который закладывают в допуски.

Источник выбирают под задачу: для отчёта — биржевое значение, для сигналов — расчётный индикатор, для контроля риска — гибрид. Состав площадок и правила обработки ликвидаций фиксируем в спецификации до старта работ.

Технические сомнения перед стартом работ

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

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

Как проверяется корректность расчёта?

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

Насколько трудоёмко добавить новую площадку?

Источник подключается отдельным адаптером к общему интерфейсу: описание контракта, нормализация полей, тесты на исторических данных. Новая площадка не затрагивает расчётное ядро, поэтому расширение идёт предсказуемо.

Что входит в передачу поддержки?

Схему данных, регламент дежурства и алертов, инструкции по типовым сбоям и разбор с вашей командой. При необходимости остаёмся на сопровождении — границу ответственности фиксируем заранее.

Обсудим задачу и вернёмся с оценкой и планом

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

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

Дальше делаем пробный расчёт: берём окно в несколько суток по одному-двум контрактам, считаем открытый интерес, сверяем с публикуемым значением площадки и показываем расхождение в процентах. После этого возвращаемся с оценкой и планом работ.

Что входит в ответ:

• перечень площадок и контрактов: что отдаёт каждая — снимки открытого интереса, лента сделок, глубина стакана;
• итог пробного расчёта — совпадение с публикуемым значением в пределах заданной точности или разбор причин расхождения;
• оценка и план работ по этапам: сбор данных, расчёт, отрисовка индикатора, оповещения, приёмка;
• схема доставки сигнала: виджет на странице, программный интерфейс или сообщения в мессенджер;
• требования к глубине истории и частоте пересчёта, чтобы индикатор не отставал от рынка;
• состав документации: формула расчёта, конфигурации, инструкция по развёртыванию.