Разработка paper trading: где ломается тестирование
Проверка стратегии без риска на живом счёте выглядит честной, но статистику так не собрать, а цена ошибки равна деньгам. Чтобы набрать значимую выборку сделок, нужны месяцы — за это время рынок успевает сменить режим, и то, что уверенно работало на тренде, ломается в боковике. Самодельный скрипт на истории считает быстрее, но обычно закрывает сделки по цене свечи: без стакана, комиссий, проскальзывания и задержки отклика.
Отсюда разрыв между ровной кривой в отчёте и минусом на реальных сделках. Причины предсказуемые: частичное исполнение крупных заявок, резкие просадки на тонкой ликвидности, пропуски и дырки в исторических данных, подгонка параметров под прошлые периоды. Ошибка в доли процента на сделку при сотнях сделок съедает результат целиком, а заложенная в модель ликвидность оказывается в разы выше реальной.
Разработка paper trading закрывает это не «демо-режимом», а полноценным учебным торговым контуром. Симулятор биржевой торговли повторяет механику исполнения, комиссии, лимиты и отказы заявок — стратегия проверяется по тем же правилам, что и в бою, но без риска для капитала. Разбираем, из чего состоит такой контур и какие проверки отделяют рабочую стратегию от красивой кривой.
Что даёт симулятор трейдера: эффект в цифрах
Эффект симулятора измеряется не удобством интерфейса, а тремя числами: сколько времени занимает прогон одной стратегии, какая доля отказов отсекается до боевого контура и насколько дешевле ошибка в песочнице, чем на реальном счёте. Ниже — как эти метрики выглядят на практике.
Скорость задаёт модель исполнения: она проигрывает исторические сделки и стакан в ускоренном режиме, а не в реальном времени. Месяц рыночных данных стратегия проходит за минуты, поэтому перебор сотен комбинаций параметров укладывается в одну ночь вместо недель ручного наблюдения. Заодно видно поведение на редких участках — резких разрывах цены и тонком стакане, где большинство стратегий и рассыпается.
Класс отказов, который закрывается до продакшена, — интеграционный, а не аналитический. Симулятор воспроизводит отказ по шагу цены и лимитам, частичное исполнение, проскальзывание, разрыв соединения и повторную отправку ордера после переподключения. Именно эти сценарии чаще всего ломают боевой запуск: логика сигнала верна, а ордер не доходит или дублируется.
Второй эффект — доля инцидентов, которые не доезжают до реального счёта. Ошибки в обработке отказов, округлении объёма и задержках ответа вылавливаются в песочнице, где цена ошибки — минуты прогона, а не открытая позиция и ручной разбор. Исторические данные для прогонов берём из публичных источников, например CoinGecko, и храним локально: прогоны не упираются в лимиты внешнего сервиса.
Режимы исполнения сделок и способы подключения
Точность симулятора задают два независимых решения: источник рыночных данных и режим исполнения заявок. Их выбирают порознь — можно подавать живой поток котировок в собственный матчинг или воспроизводить записанную ленту сделок через тестовый контур биржи. Каждый вариант даёт свой класс точности и свою нагрузку на контур.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Собственный матчинг по записанной ленте | Повторяемые прогоны, разбор спорных сценариев, обучение | Реалистичность ограничена моментом записи: события, которых в ленте не было, не воспроизводятся |
| Живой поток котировок с локальным исполнением | Показ логики на актуальном рынке, редкие ручные запуски | Прогон не воспроизводится — следующий запуск даст другой результат |
| Прямое подключение к тестовому контуру биржи | Проверка правил, лимитов, форматов заявок и отказов | Разреженная ликвидность, периодические сбросы состояния, ограничения на частоту запросов |
| Живой поток плюс модель исполнения | Основной режим для торговых стратегий | Требует калибровки очереди и проскальзывания под конкретный инструмент |
На практике рабочий вариант — четвёртый: данные идут живым потоком, исполнение считает локальная модель с очередью и проскальзыванием, а весь вход и выход пишется в журнал. Тогда прогон воспроизводится по журналу, а не по удаче, и нагрузку можно поднять до десятков заявок в секунду без деградации отклика.
Отдельно проговариваем ограничения симуляции: влияние вашей крупной заявки на рынок, задержки сети в пиковые моменты и разрывы ликвидности не воспроизводит ни один режим. До старта фиксируем, какие сценарии считаем достоверными, а где результат показывает только порядок величин.
Как мы строим симулятор: этапы инженерной работы
Порядок работ подчинён одному требованию: учебный контур должен повторять поведение боевого, но не иметь доступа к реальным средствам. Поэтому начинаем не с кода, а с инвентаризации того, что уже есть у команды, — так этапы внедрения симулятора не превращаются в переписывание торговых процессов с нуля.
- Разбор текущего стенда. Смотрим, чем команда пользуется сегодня: аналитика, риск-контроль, журналы сделок. Фиксируем, какие данные по инструментам уже есть, а какие придётся подгружать.
- Схема потоков заявок. Согласуем путь заявки от интерфейса до книги заявок и обратно: постановка, проверка лимитов, исполнение по котировке, запись в историю сделок.
- Сборка контура. Поднимаем виртуальный счёт, изолированное хранилище и собственную книгу заявок. Боевые счета и ключи доступа в контур не попадают — это проверяется отдельно.
- Сценарии торговли. Наполняем стенд типовыми ситуациями команды: серия убыточных сделок, резкий разворот рынка, частичное исполнение, обрыв связи в момент открытия позиции.
- Нагрузочная проверка контура. Прогоняем поток в объёме выше обычного дня и смотрим, на каком числе активных счетов растёт задержка обработки заявок и начинают теряться события.
- Проверка на сценариях отказа. Гасим источник котировок, перезапускаем расчётный модуль, отзываем доступ. Контур должен восстанавливать состояние счёта без ручной сверки.
- Передача в эксплуатацию. Отдаём команде стенд, регламенты и разбор прошлых инцидентов, обучаем работе с симулятором и назначаем ответственных за обновление сценариев.
Дальше контур живёт как отдельный сервис: новые сценарии и инструменты вносим по регламенту, а не правками в рабочей ветке.
Что остаётся у вас: конфигурации, схемы, регламенты
Мы передаём не «работающий сервис», а контур симуляции, который ваша команда может развивать и сопровождать сама. Всё, что фиксирует логику торговли, доступы и тестовые данные, остаётся в репозитории и в документации по симулятору — с версиями, а не в переписке.
Ниже — что именно остаётся у вас на выходе и зачем каждый артефакт нужен в ежедневной работе.
- Рабочие конфигурации всех сред — правило расчёта маржи, комиссии и лимиты по инструментам, с пояснением, какой параметр за что отвечает и как менять его без риска для расчётов.
- Схемы потоков — путь заявки от интерфейса до пересчёта позиции, места хранения состояния портфеля и точки стыка сервисов.
- Политики доступа и роли — кто видит виртуальный контур, кто допущен к административным операциям, как выдаются и отзываются ключи.
- Тестовые профили пользователей — аккаунты с разными ролями, балансами и историями сделок для регрессии, проверки лимитов и демонстраций.
- Регламенты эксплуатации — порядок выпуска изменений, откат к предыдущей сборке, действия при расхождении расчётов, подъём окружения с нуля.
- Передача контура команде — разбор архитектуры с вашими инженерами, после которого правки выпускаются без нас.
На передаче мы не отдаём папку файлов, а показываем, где что менять и как проверить результат.
Кейс: торговый симулятор под нагрузкой до и после
Исходное состояние: расчётный контур симулятора жил в том же процессе, что и приём заявок, а состояние книги заявок менялось без журнала. На пиковой нагрузке — несколько тысяч заявок в минуту — расчёты сделок расходились с эталоном, доля расхождений доходила до 3–4% от общего числа операций. Каждое расхождение разбирали вручную: инженер поднимал логи, сопоставлял историю заявок и повторял расчёт, чтобы понять, где разошлись цены и объёмы.
Что перестроили
Расчёт вынесли в отдельный контур с идемпотентной обработкой, а поток событий начали писать в PostgreSQL с журналом до и после каждой операции. Появился детерминированный пересчёт: по снимку книги заявок и журналу событий сделку можно воспроизвести один в один, не поднимая рабочий процесс. Симулятор перестал быть «чёрным ящиком» — состояние на любой момент восстанавливается из данных.
Метрики до и после
- Время отклика на пике: было — очередь росла, отклик уходил в секунды; стало — предсказуемое время на том же профиле нагрузки.
- Доля расхождений в расчётах сделок: с 3–4% до десятых долей процента.
- Ручные проверки стратегий: с десятков разборов в неделю до единичных, и те — по заранее помеченным сценариям.
- Восстановление после сбоя: вместо повторного прогона сессии — продолжение с последней записанной операции.
Кейс внедрения симулятора дал главное: стратегии теперь прогоняются пакетно по историческим данным и сравниваются между версиями, а расхождения ловят проверки, а не дежурный инженер.
Чем симулятор отличается от демо-счёта брокера?
Разница в том, кто исполняет сделку. На демо-счёте брокера ордер уходит во внутренний контур посредника: он сам решает, какой спред показать, как смоделировать проскальзывание и с какой задержкой вернуть ответ. Логику исполнения нельзя ни прочитать, ни изменить, ни зафиксировать для повторного прогона.
Симулятор — это собственный торговый контур: своё сопоставление заявок, своя книга, свои правила маржи, комиссий и принудительного закрытия позиций. Модель исполнения задаётся явно — тип ордера, глубина стакана, частичное заполнение, поведение при разрыве ликвидности. Один и тот же сценарий можно прогнать завтра и получить идентичный результат.
Независимость от посредника — не абстракция. Демо-режим могут урезать по инструментам, ограничить плечо или отключить вместе с торговым интерфейсом; доступные пары меняются решением площадки. Свой контур не завязан на чужие релизы и доступы, которые выдаёт третья сторона.
Практический критерий простой. Если задача — показать интерфейс и обучить базовым действиям, встроенный paper trading в TradingView её закрывает. Если нужна управляемая среда с контролем логики исполнения, воспроизводимыми сценариями и собственной отчётностью — модель рынка, риск-модуль и аналитика проектируются под ваш продукт.
Технические сомнения: частые вопросы по симулятору
Симулятор — не песочница ради демонстрации, а стенд, где проверяют логику стратегий и поведение сервисов до выхода на реальный рынок. Ниже — сомнения, которые чаще всего поднимают инженеры, и ответы по существу.
Насколько точно моделируется исполнение заявок?
Модель наполняет заявку по уровням стакана, а не по средней цене, поэтому проскальзывание и частичные исполнения видны на любом объёме. Комиссии, задержка ответа и лимиты позиции задаются в конфигурации контура, а результат сверяется с фактическими сделками.
Как симулятор связывается с учётной системой?
Обмен идёт через программный интерфейс и события о сделках: балансы, позиции и история операций попадают в учётный контур без ручного переноса. Если учётная система уже есть, пишем адаптер под её модель данных, а не заводим вторую параллельную бухгалтерию.
Безопасен ли тестовый контур для работы с реальными данными?
Контур изолирован от боевого: отдельные ключи доступа с ограниченными правами, свой реестр настроек и запрет на вывод средств. Историю сделок обезличиваем, поэтому стратегию проверяют на структуре реальных данных, не открывая доступ к живому счёту.
Можно ли поддержать несколько сценариев и переиспользовать наработки?
Сценарий — это набор правил исполнения, комиссий и рыночных условий, который подключается к ядру симуляции как конфигурация. Ядро, отчётность и панель наблюдения остаются общими, поэтому новый рынок или новый тип заявок добавляется без переписывания существующих модулей.
Обсудим задачу: что нужно для старта разработки
Оценка симулятора бумажной торговли зависит не от числа экранов, а от того, насколько точно описан контур исполнения сделок. Чем раньше мы получим вводные, тем меньше допущений заложим в план и тем меньше правок всплывёт на приёмке. Ниже — что стоит собрать к старту разработки симулятора.
- Текущий стек: серверная часть, база данных, клиентские приложения — и что из этого переиспользуем, а что пишем заново.
- Сценарии сделок: спот, маржа, лимитные и рыночные заявки, стопы, частичное исполнение, отмена.
- Источники котировок: биржевые потоки или агрегатор, нужная глубина истории и допустимая задержка.
- Порядок расчёта виртуального баланса: комиссии, спред, плечо, реферальные начисления, блокировка средств под заявку.
- Роли пользователей: трейдер, наставник, администратор, наблюдатель — и что каждая из них видит на экране.
- Отчётность и метрики: история сделок, выгрузки, сводки по доходности учебного счёта.
- Ограничения: правила площадок, разграничение доступов, требования к хранению персональных данных.
Часть вводных обычно ещё не сформулирована — это нормально: разберём вместе и зафиксируем допущения прямо в документе, чтобы они не превратились в скрытый рост объёма. По итогам обсуждения задачи вернёмся с планом работ по контуру: состав этапов, их порядок, что запускаем первым и на каких данных проверяем корректность расчётов.
