«Алгоритмическая торговля» может означать что угодно — от таблицы, проверяющей правило, до программного обеспечения, которое маршрутизирует ордера и сверяет исполнения. Само название не говорит, что именно работает. Прежде чем оценивать бота или создавать прототип, проследите, что происходит между наблюдением за рынком и подтверждённой позицией.
Отделите исследование от исполнения ордеров
Начните со спецификации исследования: рынок и инструмент, источник данных, таймфрейм, входные данные, доступные на каждом решении, условия входа и выхода, правило определения размера позиции, допущения о затратах, эталон и условие, при котором тест был бы неинформативным. Версионируйте спецификацию и набор данных. Бэктест должен оставлять журнал, который может проверить другой человек, включая сигналы, которые в рамках модели не стали исполнениями.
Затем различайте три операционных состояния:
| Состояние | Что оно может установить | Что оно не устанавливает |
|---|---|---|
| Историческая симуляция | Как заявленные правила ведут себя на выбранных исторических данных и допущениях об исполнении | Что данные полны или что будущие результаты будут похожи на выборку |
| Демо-наблюдение | Как процесс фиксирует гипотетические решения за период наблюдения | Что ордера могут достичь площадки или получить смоделированное исполнение |
| Живой путь ордера | Что показывают аутентифицированные подтверждения площадки, исполнения, комиссии и записи счёта | Что у стратегии есть устойчивое преимущество или что она подходит конкретному человеку |
Успешный тест программного обеспечения охватывает только то поведение, которое он проверил. Он не проверяет биржевой счёт, разрешение API, продакшен-хранилище секретов или фактический ордер.
Спроектируйте границу контроля до стратегии
Если система может отправлять реальные ордера, рассматривайте её рабочий путь как отдельную инженерную задачу. Проверяйте актуальность данных и идентичность инструмента, прежде чем использовать сигнал. Применяйте лимиты на максимальный ордер, экспозицию и убыток до отправки запроса. Сохраняйте уникальный идентификатор решения и клиентский идентификатор ордера до передачи, если площадка это поддерживает. Этот идентификатор помогает запросить и сверить неопределённый запрос; он не делает дублирующие отправки безопасными на всех площадках. После ответа сверяйте состояние ордера и позиции с записями площадки; успешный HTTP-запрос — не то же самое, что исполнение.
Определите, что система делает, когда какая-либо часть неопределённа. Устаревшая цена, некорректное количество, отклонённый ордер, частичное исполнение, потеря соединения или неизвестная позиция должны останавливать принятие нового риска до повторной проверки состояния. У аварийного выключателя должен быть чётко протестированный эффект, ответственный и процедура восстановления. Сам стоп-ордер не гарантирует цену исполнения и не предотвращает ликвидацию по правилам площадки.
Руководство SEC по Правилу 15c3-5 описывает средства контроля рыночного доступа для охваченных брокеров-дилеров на рынках ценных бумаг США, включая предторговые пороги и регулярный пересмотр. Это правило не является общим чек-листом, навязанным каждому розничному криптоскрипту, и не является утверждением о криптозаконодательстве в каждой юрисдикции. Его ограниченная сфера — полезный пример того, как можно назначать и документировать средства контроля рыночного доступа; любой, кто создаёт или эксплуатирует систему, должен отдельно определить правила, которые действительно к нему применяются.
Разберите сбой, а не только успешный сценарий
Представьте, что процесс стратегии отправляет ордер, и сеть отключается по тайм-ауту до прихода ответа. Запрос мог достичь механизма сопоставления, даже если клиент не видит ответа. Документация Binance по Spot REST явно помечает один тайм-аут и некоторые серверные ошибки как «статус исполнения неизвестен» и советует проверять пользовательский поток или запрашивать статус ордера. Hyperliquid документирует клиентские идентификаторы ордеров и запрос статуса ордера по ID ордера или клиентскому ID. Это инструменты конкретных площадок, а не универсальная гарантия ровно одного исполнения; используйте текущий контракт площадки и не отправляйте второй ордер просто потому, что первый ответ был потерян. См. руководство Binance по Spot REST API, эндпоинт биржи Hyperliquid и запрос статуса ордера Hyperliquid.
Используйте небольшой протокол сверки и фиксируйте доказательства, стоящие за каждым изменением состояния:
| Ситуация | Проверка по данным площадки | Операционное решение |
|---|---|---|
| Запрос завершается тайм-аутом или возвращает неоднозначную серверную ошибку | Запросите, используя исходный клиентский ID, где это поддерживается; проверьте статус ордера и исполнения | Оставьте решение неразрешённым; не повторяйте как новый ордер, пока экспозиция неизвестна |
| Ордер исполнен частично или отмена в ожидании | Просуммируйте отдельные исполнения, комиссии и оставшееся открытое количество; затем перепроверьте после отмены | Определяйте размер следующего действия от сверенной экспозиции, а не от запрошенного количества |
| Процесс или приватный поток переподключается | Обновите открытые ордера, позиции и недавние исполнения; возобновляйте обработку событий только после согласования состояния | Приостановите новый риск, если разрыв не удаётся сверить |
| Площадка возвращает ответ об ограничении частоты запросов | Следуйте инструкции этой площадки по задержке и проверьте текущее состояние ордеров и счёта | Прекратите быстрые повторы; повторные запросы могут продлить сбой |
Например, руководство Binance по Spot REST говорит, что ответ 429 означает превышение лимита частоты запросов, требует от клиента сделать паузу и предупреждает, что продолжение нарушений может привести к блокировке IP. Это поведение Binance Spot, а не обещание, что другой API использует те же коды. Документация биржи Hyperliquid определяет собственные варианты времени жизни ордера: ALO отменяет ордер, а не немедленно забирает ликвидность, тогда как IOC отменяет неисполненный остаток. Эти правила влияют на исход ордеров, поэтому один и тот же замысел стратегии может оставить разный инвентарь при разных инструкциях площадки. Документируйте точную площадку, продукт, версию API и флаги ордеров, использованные в репетиции.
Прежде чем считать контроллер исполнения готовым к любому развёртыванию, намеренно проработайте эти сбои в среде, отличной от продакшена. Внедрите устаревшую котировку, потерянный ответ после принятия, частичное исполнение во время отмены, разрыв приватного потока и ответ об ограничении частоты запросов. Для каждого случая убедитесь, что система не увеличивает экспозицию из неизвестного состояния и не теряет учёт оставшегося количества, а оператор может остановить, проверить и возобновить её на основе зафиксированных доказательств. Одна лишь демо-сессия по успешному сценарию не проверяет восстановление.
Для фьючерса или инструмента с плечом граница контроля также соприкасается с риском счёта: консультативное уведомление CFTC о фьючерсах на виртуальные валюты отмечает, что плечо может усиливать убытки и приводить к дополнительной марже или закрытию позиции в рассматриваемом им фьючерсном контексте.
Фактическая граница SuperQuant
SuperQuant предоставляет локальный движок исторических исследований и рабочий процесс ручной демо-практики на синтетических встроенных историях. Он не отправляет биржевые ордера и не подключается к торговому счёту пользователя. Не описывайте его как автоторгового бота. Чтобы изучить исследовательскую сторону, начните с примера следования за трендом, пройдите рабочий процесс бэктеста и сравните дискреционную и систематическую торговлю. Это руководство по архитектуре, а не совет по живому исполнению или рекомендация стратегии.