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

Парсинг ставки фінансування: де розходяться дані бірж

Ставка фінансування perpetual — не загальна для ринку величина, а результат локального розрахунку кожного майданчика.

Вікно усереднення та момент фіксації у бірж розрізняються: одні рахують раз на 8 годин за середньозваженою ціною за вікно, інші — раз на 4 або щогодини за знімком індексу. Єдиного вивантаження «ставка по ринку» не існує.

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

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

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

Ліміти на частоту звернень теж неоднакові, тому збір даних з біржі за одним періодом іде з різною повнотою та потребує пауз між серіями запитів.

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

Що дає налагоджений збір ставок фінансування

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

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

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

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

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

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

Перевірки на відхилення від медіани та на узгодженість між джерелами відсікають такі записи до потрапляння в базу.

Способи збору: опитування за розкладом, потік, зріз за запитом

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

Опитування за розкладом — періодичні запити з фіксованим кроком; потоковий канал — постійне з'єднання, куди біржа сама віддає зміни ставки; зріз за запитом — разова вибірка під конкретну задачу, наприклад для звірки розрахунків.

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

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

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

Як будується впровадження збору: етапи інженерної роботи

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

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

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

3. Налаштування збору. Реалізуємо опитування за розкладом і потокові підписки, додаємо повторні спроби із затримкою, відсікання дублів і запис вихідних відповідей — щоб у разі збою перезібрати вітрину, а не втратити інтервал.

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

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

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

Що замовник отримує на руки: схеми, регламенти, моніторинг

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

Тому разом із робочим збирачем передаємо комплект артефактів, за яким систему можна супроводжувати й розвивати без нас.

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

Кожен пункт розрахований на інженера, який відкриє систему через пів року після передачі.

Кейс: розбіжність ставок між майданчиками до і після

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

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

Гірше були тихі пропуски: запит повертав помилку, скрипт писав порожнє значення, і помітити це вдавалося випадково.

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

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

Попутно знайшлися два майданчики з рваними лімітами запитів — для них збір перевели на окремий інтервал.

Ставка фінансування вручну: що робити, якщо збір уже налагоджено?

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

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

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

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

Далі — звірка старого й нового джерела в тіньовому режимі.

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

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

Поступове перемикання йде невеликими порціями: одна біржа, один інструмент, один розрахунковий інтервал за раз. У конфігурації є ознака активного джерела, тому відкат — це повернення прапорця, а не відновлення з бекапу.

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

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

Технічні сумніви перед стартом збору даних

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

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

Тому ми не беремо готові агрегатори, а пишемо збір із збереженням сирої відповіді та мітки часу — тоді будь-яку розбіжність між джерелами можна розібрати за першоджерелом, а не гадати, чий ряд вірний. Далі — коротко про те, що найчастіше запитують перед підписанням.

Що робити з лімітами майданчиків на частоту запитів?

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

За потреби розподіляємо навантаження за кількома потоками, щоб вікно не рвалося і ряд залишався безперервним.

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

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

Що відбувається після передачі — хто відповідає за збір?

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

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

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

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

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