Разработка системы бэктестинга с учётом funding rate

Бэктестинг funding rate: где стратегия ломается на истории

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

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

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

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

Что даёт учёт ставки финансирования в расчёте доходности

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

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

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

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

Способы моделирования ставки: сравнение подходов

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

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

Этапы сборки системы бэктестинга под вашу стратегию

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

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

Что передаём на руки: артефакты и регламенты

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

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

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

Кейс: как сократили расхождение теста и реальной торговли

До: расхождение 18% между тестом и счётом

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

После: 4% и сохранённый результат при смене режима

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

Расхождение сократилось с 18% до 4% за месяц, пропущенных начислений — с 6 из 90 окон до нуля. В стресс-сценарии со сменой знака ставки просадка выросла не более чем на пятую часть, стратегия осталась в плюсе. Решение об увеличении плеча теперь принимается по результатам теста, а не по интуиции.

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

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

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

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

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

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

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

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

Насколько результат совпадёт с реальной торговлей?

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

Что делать, если биржа изменила правила расчёта ставки?

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

Как быстро прогоняется многолетняя история?

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

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

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

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

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