Торговый робот: как написать, протестировать на бэктесте и запустить в прод

Что такое торговый робот и когда он реально нужен

Когда к нам приходят с задачей «сделать торгового робота», первое, что мы выясняем — а нужен ли он вообще. Потому что торговый робот — это не «умная программа, которая зарабатывает на бирже», а всего лишь исполнитель: код, который по формализованным правилам отправляет заявки на биржу через API. Никакой магии внутри нет. Есть условие «если цена пересекла X, купить объём Y», и есть HTTP-запрос к бирже, который это условие реализует.

У нас в практике робот оправдан там, где человек физически не справляется. Триггеров ровно три: высокая частота решений (десятки сигналов в час — руками не отследить), жёсткая дисциплина исполнения (правило «стоп всегда на 2%» человек нарушит на третьем убытке) и круглосуточный рынок крипты, который не закрывается на ночь и выходные. Если стратегия — «покупаю раз в месяц на просадке по фундаменталу», робот не нужен: вы потратите больше времени на код, чем сэкономите.

И ещё: робот — это не «бот-кнопка». Это связка из трёх частей. Логика сигнала, слой исполнения (отправка и трекинг ордеров) и инфраструктура (ключи, лимиты, логи, мониторинг). Ошибки в любой из трёх ломают торговлю одинаково больно — об этом ниже.

Где робот выигрывает у ручной торговли:

• 24/7 без усталости — криптобиржа не спит, а человеку нужен сон; робот держит позиции и реагирует на события в 3 часа ночи.
• Мгновенная реакция на событие — от тика цены до отправки ордера проходят миллисекунды, рука так не умеет.
• Отсутствие эмоций — нет страха «усредниться» и жадности «подождать ещё чуть-чуть»; правило есть правило.
• Масштабирование на несколько инструментов — один и тот же алгоритм крутится по десятку пар одновременно, человек так не сможет.

А теперь честно про то, где робот проигрывает. Редкие discretionary-решения — «вот эта новость меняет весь расклад, выходим» — машина не примет: у неё нет контекста. Нестандартные рыночные режимы — резкий гэп, остановка торгов, аномальный спред — ломают логику, написанную под «нормальный» рынок. И главное: стратегии без чётких правил входа/выхода в код не переносятся вообще. Если вы сами не можете записать условие на бумаге, робот его не «поймёт».

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

Как написать торгового робота: стек, API и первые подписанные запросы

Типичный сценарий: стратегия уже сформулирована на бумаге, но до первого живого ордера ещё далеко — потому что между «правила есть» и «робот торгует» лежит выбор стека и работа с подписью запросов. Именно здесь чаще всего теряются дни. Мы регулярно видим проекты, где человек уверенно пишет логику сигналов, а потом два вечера воюет с signature и -1022 Signature for this request is not valid.

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

Выбор стека: Python, PHP или чистый REST

Python + CCXT — самый быстрый старт. Библиотека даёт унифицированный API к десяткам бирж, и код на старте получается коротким и читаемым. Если вы пишете робота с нуля и не привязаны к существующей инфраструктуре — почти всегда начинаем отсюда.

PHP + CCXT имеет смысл, когда бэкенд уже живёт на PHP (типичный случай — Bitrix), и заводить отдельный Python-сервис ради пары вызовов не хочется. Библиотека поддерживает PHP наравне с Python, синтаксис отличается, логика та же. Минус — экосистема аналитики и бэктеста в PHP беднее, и тяжёлые вычисления придётся выносить.

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

Дальше покажем на Python — это самый короткий путь к первому подписанному запросу.

import os
import ccxt

exchange = ccxt.binance({
    "apiKey": os.environ["BINANCE_API_KEY"],
    "secret": os.environ["BINANCE_SECRET"],
    "options": {
        "defaultType": "spot",
    },
    "enableRateLimit": True,
})

try:
    balance = exchange.fetch_balance()
    usdt = balance["USDT"]["free"]
    print(f"Соединение установлено, свободно USDT: {usdt}")
except ccxt.AuthenticationError as e:
    print(f"Ключи не приняты биржей: {e}")
except ccxt.NetworkError as e:
    print(f"Сеть недоступна: {e}")

Подпись запроса: почему TRADE-эндпоинты не работают без signature

Запросы к Spot REST API Binance делятся по типу безопасности. Публичные (курсы, стакан, свечи) работают без ключей вообще. Запросы к аккаунту требуют API-Key в заголовке. А вот создание ордера относится к типу TRADE: мало передать ключ, нужно ещё доказать, что параметры не подменили по дороге.

Механика такая: все параметры запроса (включая timestamp) собираются в строку, к ней применяется HMAC-SHA256 с вашим secret, результат кладётся в параметр signature. Биржа повторяет вычисление у себя и сверяет. Если хотя бы один параметр изменился или timestamp ушёл за окно recvWindow — запрос отклоняется.

Если подпись не передать вовсе, придёт ошибка вроде -2014 API-key format invalid или -1022 Signature for this request is not valid — в зависимости от того, что именно отсутствует. Ордер, разумеется, не создастся.

Хорошая новость: CCXT делает подпись под капотом. Вы передаёте параметры метода, а библиотека сама добавляет timestamp, считает signature и собирает финальный запрос. Поэтому в коде ниже вы не увидите ни строчки про HMAC. Если же вы работаете с чистым REST, всю эту логику придётся реализовать самому — и вот тут начинаются те самые два вечера.

Торговый робот для Binance: типы ордеров и параметры ответа

Многие думают, что торговый робот для Binance — это «нажал кнопку купить, дождался профита». На деле Spot API даёт семь типов ордеров, и выбор между ними определяет, как бот поведёт себя в волатильности. MARKET сработает мгновенно по любой цене и проскользнёт на тонком стакане. LIMIT встанет в очередь, и не факт, что исполнится. STOP_LOSS и STOP_LOSS_LIMIT — это две разные стратегии выхода из позиции: первый стреляет рыночным ордером при пробое стопа, второй выставляет лимитник и может остаться неисполненным, если цена пролетела мимо. TAKE_PROFIT и TAKE_PROFIT_LIMIT — зеркальная пара для фиксации прибыли. А LIMIT_MAKER устроен иначе: биржа отклонит его, если он снимется как тейкер.

В проектах, где мы собираем ботов под конкретную стратегию, именно на этом слое чаще всего ломается логика. Трейдер на бумаге описал «стоп на минус 2%», а разработчик поставил STOP_LOSS_LIMIT. В момент резкого движения лимитник не исполнился. Тип ордера — не деталь реализации, а часть стратегии, и её стоит согласовывать до первой строки кода.

Отдельно стоит разобраться с параметром newOrderRespType. Он определяет, что именно биржа вернёт в ответ на создание ордера. Значение ACK отдаёт только orderId и базовые поля: робот знает, что ордер принят, но не знает, исполнен ли он. RESULT добавляет статус исполнения и заполненный объём. FULL возвращает полный объект, включая массив fills с ценой и количеством каждой сделки.

Для бота, который сразу пересчитывает позицию и среднюю цену входа, FULL экономит один запрос к бирже. Без него придётся отдельно дёргать GET /api/v3/myTrades или GET /api/v3/order — лишний round-trip и лишний риск разойтись в состоянии. Если робот только выставляет ордера и не ведёт учёт филов, хватит RESULT. ACK имеет смысл там, где ответ не важен: например, при массовой отмене или в сценариях, где статус вы всё равно тянете отдельным стримом.

from binance.client import Client

client = Client(api_key="...", api_secret="...")

order = client.create_order(
    symbol="BTCUSDT",
    side=Client.SIDE_SELL,
    type=Client.ORDER_TYPE_STOP_LOSS_LIMIT,
    timeInForce=Client.TIME_IN_FORCE_GTC,
    quantity=0.001,
    price="58000.00",
    stopPrice="58500.00",
    newOrderRespType="FULL",
)

print(order["status"], order["orderId"])
for fill in order.get("fills", []):
    # замените на вашу логику учёта позиции
    print(fill["price"], fill["qty"], fill["commission"])

Бэктест стратегии: как прогнать правила по истории и не обмануть себя

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

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

Backtrader и Cerebro: как собрать движок бэктеста

Для прогона на Python мы обычно берём Backtrader — зрелая библиотека, где данные, стратегия и анализаторы живут в одном объекте. По опыту сообщества это самый предсказуемый вариант для крипты и акций: движок сам ведёт учёт позиций, считает комиссии и equity curve, вам остаётся описать правила.

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

Данные берём через CCXT — он тянет исторические свечи с Binance и ещё сотни бирж в одном формате. Дальше — сборка движка.

Что делает Cerebro и почему дефолтный баланс надо переопределять

Движок Cerebro (создаётся как bt.Cerebro()) — центральный компонент Backtrader. Он объединяет три вещи: данные (data feeds), стратегию и анализаторы, которые считают метрики по итогу прогона. Вы добавляете источники, регистрируете стратегию, запускаете cerebro.run() — и на выходе получаете результат прогона.

Ключевой момент, на котором спотыкаются почти все: встроенный брокер по умолчанию стартует с балансом 10 000 единиц. Если не переопределить это явно, вы протестируете стратегию на абстрактном депозите, а не на своём. Для крипты с плечом и комиссией 0.1% разница в размере позиции меняет всю картину — вплоть до знака доходности.

Поэтому cash, комиссию и размер позиции задаём руками. Что ещё стоит подкрутить под свой проект: setcommission — под реальную ставку биржи, set_slippage_perc — под проскальзывание, addanalyzer — чтобы сразу получить Sharpe и максимальную просадку, а не считать их вручную.

import backtrader as bt

cerebro = bt.Cerebro()

# Явно задаём депозит вместо дефолтных 10 000
cerebro.broker.setcash(1000.0)

# Комиссия биржи: 0.1% за сделку — замените на свою ставку
cerebro.broker.setcommission(commission=0.001)

# Проскальзывание: 0.05% — реалистичнее, чем нулевое
cerebro.broker.set_slippage_perc(0.0005)

# Данные: исторические свечи, загруженные через CCXT в pandas DataFrame
data = bt.feeds.PandasData(dataname=df_ohlcv)
cerebro.adddata(data)

# Регистрируем стратегию с параметрами
cerebro.addstrategy(MyStrategy, fast_period=12, slow_period=26)

# Анализаторы: просадка и Sharpe считаются автоматически
cerebro.addanalyzer(bt.analyzers.DrawDown, _name="dd")
cerebro.addanalyzer(bt.analyzers.SharpeRatio, _name="sharpe")

results = cerebro.run()
strategy = results[0]
print("Max drawdown:", strategy.analyzers.dd.get_analysis()["max"]["drawdown"])

StrategySkipError: как корректно прервать прогон изнутри стратегии

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

Жизненный цикл стратегии в Backtrader может быть прерван с помощью исключения StrategySkipError. Согласно документации, оно вызывается во время инициализации (__init__), чтобы движок Cerebro пропустил текущий экземпляр стратегии при прогоне. Это особенно актуально при оптимизации параметров: если комбинация настроек не подходит для конкретного инструмента, стратегия исключается из расчетов еще на этапе «рождения».

Три классические ошибки, из-за которых бэктест врёт

• Look-ahead bias — стратегия использует данные будущих свечей: например, принимает решение на закрытии бара, но «видит» его high и low до того, как они сформировались. На истории это даёт нереальный профит.
• Survivorship bias — тестируете только на тикерах, которые дожили до сегодня. Делистингованные монеты и обанкротившиеся акции выпадают из выборки, и стратегия выглядит устойчивее, чем есть.
• Переоптимизация параметров — подбираете fast_period и slow_period на одном отрезке, пока кривая не станет красивой. На новых данных такая стратегия разваливается.

Алготрейдинг-бот: от бэктеста к paper trading

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

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

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

Что проверяет paper trading, чего не видит бэктест

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

Четыре класса проблем, которые вылезают только в paper trading:

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

Именно на этом этапе становится видно, справляется ли робот с состоянием «ордер отправлен, но ещё не подтверждён» — а это, по нашему опыту, источник половины багов в проде.

Метрики, по которым мы решаем идти в прод

Paper trading без критериев выхода — это бесконечное наблюдение. Мы фиксируем матрицу метрик заранее и смотрим на неё, а не на «вроде неплохо торгует». Пороги у каждого проекта свои, но логика оценки общая: сравниваем поведение в paper с тем, что обещал бэктест, и смотрим на инфраструктурные показатели, а не только на PnL.

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

Самые частые ошибки при запуске робота в продакшн

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

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

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

Поэтому состояние надо регулярно сверять с биржей через fetch_orders и fetch_my_trades. Биржа здесь источник истины, ваш робот только зеркало. При старте, после каждого рестарта и раз в N минут робот запрашивает у биржи открытые и закрытые ордера, историю сделок и пересобирает локальную картину позиций. Если данные разошлись, приоритет у биржи, локальную базу перезаписываем.

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

Как мы делаем алготрейдинг под ключ: от идеи до мониторинга

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

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

Ниже — шесть этапов, через которые проходит у нас каждый проект.

1. Формализовать правила входа и выхода на бумаге — до единого условия, без «ну тут по ситуации».
2. Прогнать стратегию на исторических данных в Backtrader и посмотреть просадку, а не только доходность.
3. Запустить на paper trading: тот же код, но ордера уходят в песочницу.
4. Вывести на реальный счёт с минимальным размером позиции и ограниченным депозитом.
5. Настроить мониторинг, метрики и алерты — чтобы о сбое узнавать из уведомления, а не из истории сделок.
6. Масштабировать депозит постепенно, по мере накопления статистики на живых сделках.

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

Вокруг самого робота мы ставим инфраструктуру, без которой продакшн превращается в рулетку: логирование каждой заявки и ответа биржи, метрики по просадке и числу сделок, kill-switch для аварийной остановки и отдельный сервер с ограниченным доступом. Не тот, где живёт сайт или рабочая машина разработчика. API-ключи настраиваем с привязкой к IP сервера, чтобы утечка ключа не открывала доступ откуда угодно.

Читайте также: Бизнес-процессы в Битрикс24: создание, запуск и автоматизация через дизайнер и REST API, ИИ-ассистент для бизнеса: как мы внедряем нейросетевых помощников в Bitrix и 1С.

Подробнее об услуге: алготрейдинг.