Парсинг Funding Rate: API, скриптинг, арбитраж на криптобиржах

Парсинг funding rate: где расходятся данные бирж

Ставка финансирования perpetual — не общая для рынка величина, а результат локального расчёта каждой площадки. Окно усреднения и момент фиксации у бирж различаются: одни считают раз в 8 часов по средневзвешенной цене за окно, другие — раз в 4 или каждый час по снапшоту индекса. Единой выгрузки «ставка по рынку» не существует.

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

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

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

Что даёт налаженный сбор ставок финансирования

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

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

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

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

Способы сбора: опрос по расписанию, поток, срез по запросу

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

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

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

Как строится внедрение сбора: этапы инженерной работы

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

1. Аудит источников данных. Фиксируем перечень площадок и инструментов, доступную глубину истории, лимиты на частоту запросов и поведение площадки при обрыве связи. На выходе — карта источников: где ряды полные, а где придётся восстанавливать пропуски.

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

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

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

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

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

Что заказчик получает на руки: схемы, регламенты, мониторинг

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

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

Каждый пункт рассчитан на инженера, который откроет систему через полгода после передачи.

Кейс: расхождение ставок между площадками до и после

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

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

После: сборщик приводит ответы к единой временной шкале — метка в UTC, тип значения, идентификатор площадки. Логирование сбора уходит в отдельный журнал с кодом ответа, задержкой и объёмом данных: пропуск видно в момент появления, а не задним числом. Сверка данных по площадкам идёт по паре «контракт + окно», а не по времени получения ответа.

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

Funding rate вручную: что делать, если сбор уже налажен?

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

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

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

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

После периода сверки без необъяснимых расхождений ручной контур уходит в резерв, автоматический становится основным. История при этом остаётся непрерывной, а расчёты ни на день не останавливались.

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

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

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

Что делать с лимитами площадок на частоту запросов?

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

Можно ли восстановить историю ставок задним числом?

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

Что происходит после передачи — кто отвечает за сбор?

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

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

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

• Постановка задачи на сбор. Какой результат нужен: таблица истории ставок, онлайн-монитор, сигналы расхождения между площадками или расчёт доходности стратегии.
• Перечень площадок. Биржи и типы инструментов, по которым нужны ставки, с приоритетом — что подключаем первым.
• Текущий способ получения. Ручной экспорт, таблицы, готовые агрегаторы или свои скрипты — что переносим, а что переписываем.
• Требования к истории ставок. Глубина, шаг обновления, нужны ли рядом цена и объём, точность округления и правила обработки пропусков.
• Режим обновления данных. Раз в сутки для аналитики, раз в минуту для мониторинга расхождений или поток для реакции на аномалии.
• Целевые расчёты. Средняя ставка за период, накопленная доходность, отклонение от рынка, порог срабатывания сигнала.
• Куда отдавать данные. Выгрузка в файл, запись в базу, веб-панель, уведомления в мессенджер — формат фиксируем до старта.
• Доступы и ограничения. Ключи к биржам, лимиты по частоте запросов, требования к хранению и разграничению доступа.

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