Разработка системы forward-тестирования (paper trading)

Paper trading: где симуляция расходится с реальной торговлей

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

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

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

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

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

Форвард-тестирование (paper trading) прогоняет стратегию на живом потоке рыночных данных, но заявки уходят не на биржу, а в эмулятор исполнения. Тестовый контур подключается к тому же торговому API, что и боевой: на Binance и других площадках набор методов совпадает, поэтому расхождение между прогоном и реальным счётом даёт логика гипотезы, а не разница инфраструктуры.

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

Эффекты, которые видно в отчёте

• Время проверки гипотезы — дни вместо недель, прогон идёт непрерывно.
• Доля воспроизводимых сделок — выше 95% при фиксированном снапшоте стакана и повторе запуска.
• Простой тестового контура — минуты на перезапуск вместо часов ручной сборки стенда.
• Предсказуемость просадки — расчётная и фактическая кривые сходятся, лимиты риска задаются заранее.
• Классы отказов — закрываются на тестовом контуре, а не на реальном счёте.

Состояние до и после

Форматы paper trading: история, живой поток, теневой режим

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

Как выбирать режим под тип стратегии

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

Как устроен теневой прогон параллельно с рабочим контуром

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

Этапы внедрения системы тестирования: от аудита до передачи

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

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

Критерии приёмки

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

Запуск без остановки рабочего контура

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

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

Стенд для paper trading сдаём не «как есть», а комплектом, по которому ваша команда запускает и проверяет его без нашего участия. В передачу входят конфигурации, схемы, правила доступа и регламенты — ниже перечень артефактов.

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

Как передаём знания команде

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

Кейс: сократили разрыв между тестом и реальными сделками

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

Модель исполнения сделок и учёт задержек

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

Сравнивали три метрики: расхождение цены входа упало с трети случаев до 4%, разрыв по средней доходности между стендом и живым счётом сократился с 40% до 6%, суточный прогон истории ускорился вчетверо.

Перенос настроек стенда в рабочий контур

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

Чем форвард-тестирование отличается от проверки на истории

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

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

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

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

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

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

Перед стартом проекта заказчики приносят один и тот же набор инженерных сомнений: не окажется ли модель исполнения в paper trading слишком «тепличной», хватит ли исторических данных и не начнёт ли симулятор мешать боевому контуру. Короткие ответы ниже обычно снимают эти вопросы до обсуждения оценок и плана.

Какие требования к историческим данным?

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

Что делать с редкими инструментами?

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

Симулятор нагрузит рабочий торговый контур?

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

Что меняется в системе после передачи?

Отдаём конфигурацию, правила сопоставления заявок, документацию по расширению и набор сценариев для регрессии. Новый инструмент или поле в модели исполнения добавляются правкой конфигурации, без переписывания ядра.

Обсудим задачу тестирования ваших стратегий

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

• Описание стратегий: логика входа и выхода, используемые индикаторы и таймфреймы, как сигналы считаются сейчас — вручную, в таблицах или уже кодом.
• Источники данных: площадки и инструменты, требуемая глубина истории, нужен ли поток котировок в реальном времени и с какой частотой обновления.
• Схема контуров: сколько окружений нужно — прогон на истории, paper trading на живом потоке, сверка с реальной торговлей — и как они связаны между собой.
• Требования к отчётности: какие метрики считать (доходность, просадка, доля прибыльных сделок), в каком виде отдавать — панель мониторинга, выгрузка в таблицу, регулярный отчёт.
• Ограничения: сроки, доступы к площадкам и данным, правила разграничения прав, системы, в которые нужно встроиться.
• Текущие наработки: что уже есть и должно сохраниться, а что можно заменить без потери логики.

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