Что такое алготрейдинг: от идеи до работающей системы

01Алготрейдинг начинается не с кода

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

Хорошую гипотезу можно описать простыми словами и перевести в однозначные правила. Если два разработчика реализуют её по-разному, спецификация ещё не готова.

• Что именно наблюдаем
• На каких инструментах и таймфреймах
• Как определяем вход и выход
• Когда система обязана остановиться

02Шесть слоёв торговой системы

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

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

• Данные → сигнал → риск → ордер → контроль → отчёт
• Каждый слой тестируется отдельно
• Критические события записываются в журнал

03Как проверять гипотезу

Исторический тест должен учитывать комиссии, проскальзывание и реальные правила биржи. Параметры нельзя подбирать на всей истории и затем называть результат независимым.

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

04От бэктеста к реальному рынку

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

Масштабировать объём имеет смысл только после того, как фактические сделки объяснимо совпадают с моделью.

05Нештатные режимы проектируют заранее

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

Особенно опасны неоднозначные ответы API. Если запрос завершился тайм-аутом, это ещё не значит, что ордер не был принят. Перед повторной отправкой система должна сверить открытые заявки и сделки по уникальному идентификатору.

• Потеря потока котировок останавливает новые входы
• Повторный запрос не создаёт дублирующий ордер
• Расхождение позиции вызывает предупреждение и сверку
• Ручная остановка не зависит от основного процесса

06Система требует рабочего регламента

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

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

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

07Данные определяют границы стратегии

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

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

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

08Каждый результат должен воспроизводиться

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

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

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

• Версия кода и конфигурации
• Снимок или контрольная сумма данных
• Отдельный отчёт по каждой проверке
• План отката до предыдущей версии