Разработка AI-трейдинг-бота для товарного рынка commodities

Почему AI-трейдинг-бот даёт сбои на товарных рынках

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

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

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

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

Что даёт управляемая автоматизация товарной торговли

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

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

Единый риск-контроль по портфелю считает совокупную позицию, а не каждый инструмент отдельно. Лимит по группе связанных контрактов, требования по марже и максимальная просадка за сессию проверяются перед каждой заявкой; при исчерпании лимита стратегия переходит в режим только закрытия.

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

Источник котировок сверяем с биржевым: данные по товарным контрактам CME Group подтягиваются в той же схеме, что и внутренние справочники, поэтому расхождение видно сразу, а не обнаруживается при пересчёте позиций.

Режимы работы торговых алгоритмов: что выбрать

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

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

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

Как мы внедряем торговый контур: этапы работ

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

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

Артефакты внедрения: регламенты, схемы и доступы

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

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

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

Кейс: торговый контур на портфеле товарных активов

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

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

Что изменилось в метриках

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

Чем AI-трейдинг-бот отличается от советника-сигнальщика

Разница начинается там, где заканчивается сигнал. Советник-сигнальщик анализирует рынок и предлагает сделку: направление, ориентир входа, защитный ордер. Дальше решает человек — отправить заявку или пропустить. Зона ответственности алгоритма здесь заканчивается.

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

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

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

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

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

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

Как задаются лимиты риска на сделку и на день?

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

Можно ли обновить стратегию без остановки торговли?

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

Как контур стыкуется с действующей учётной системой?

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

Обсудим вашу задачу по автоматизации торговли

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

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

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