Как сервисы автоматизации трейдинга вводят вас в заблуждение: правда о миллисекундах

12, 50, 100 или 200 миллисекунд звучат убедительно. Но что именно измеряют сервисы торговой автоматизации: обработку входящего webhook или время до реально подтверждённой позиции на торговом счёте?

Индустрия автоматизации трейдинга выработала особую одержимость миллисекундами. Почти каждый коннектор, webhook-мост или платформа автоматической торговли пытается впечатлить трейдера какой-нибудь цифрой: 12 миллисекунд, 50 миллисекунд, 100 миллисекунд, 200 миллисекунд. Эти цифры выглядят точными и техническими, именно поэтому они так хорошо работают в рекламе. Трейдер видит такое число и естественным образом предполагает, что речь идёт о времени, необходимом для превращения сигнала в открытую позицию на реальном торговом счёте.

Однако в большинстве случаев эта цифра означает совсем не это.

Сам показатель может быть настоящим. Сервис действительно может обработать входящее сообщение за 100 миллисекунд, передать команду советнику за 50 миллисекунд или отправить API-запрос через 200 миллисекунд после получения webhook. Обман начинается тогда, когда один отдельный этап гораздо более длинного процесса подаётся таким образом, чтобы пользователь принял его за полное сквозное исполнение сделки.

Где начинается и заканчивается сделка

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

До того как коннектор вообще что-либо получит, торговая платформа должна сформировать сигнал, создать алерт, поместить webhook в свою систему доставки и передать его по сети. В конкретном случае TradingView мы неоднократно наблюдали разницу примерно в одну полную секунду между временной меткой, связанной с алертом, и временной меткой, зафиксированной в момент фактического поступления webhook в коннектор. Эта задержка замечена не только нами: трейдеры и разработчики публично обсуждали такое же поведение, в том числе на Reddit. Она не всегда составляет ровно одну секунду, поскольку сетевые условия и собственный механизм доставки TradingView меняются, но сам внешний этап существует, и честно игнорировать его нельзя.

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

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

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

Полученный webhook — ещё не сделка

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

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

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

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

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

Отправленный ордер — ещё не открытая позиция

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

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

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

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

Что именно можно честно измерять

В измерении внутреннего времени обработки нет ничего плохого. Инженерам необходимо понимать, сколько занимает каждый отдельный этап, и AlgoWay также измеряет такие показатели. Проблема начинается тогда, когда внутренняя инженерная метрика размещается на рекламной странице под формулировкой вроде «исполнение за 100 миллисекунд», хотя секундомер остановился ещё до того, как брокер вообще что-либо исполнил.

Полезное утверждение о производительности должно чётко определять, где начинается измерение и где оно заканчивается. Формулировка «интервал между получением webhook нашим сервером и отправкой API-запроса обычно составляет 200 миллисекунд» понятна и имеет технический смысл. Она не обещает больше, чем фактически измеряется. Заявление «исполнение сделки за 200 миллисекунд», когда на самом деле речь идёт только об обработке алерта, создаёт совершенно другое впечатление.

Лабораторные миллисекунды и реальные условия

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

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

Реальные пользователи работают с разными брокерами, разными платформами, различными названиями инструментов, несколькими счетами, одновременными сигналами, изменяющимися позициями, нестабильными соединениями, волатильными рынками, частичным закрытием, защитными ордерами и ограничениями конкретных платформ. В таких условиях один рекорд, показывающий операцию за 12 миллисекунд, говорит очень мало. Он не показывает, сколько операций заняли две секунды, сколько потребовали шесть секунд, сколько пришлось повторить, сколько были исполнены частично и сколько завершились неудачей.

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

Ограничения внешних платформ

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

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

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

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

Можно отправить сырой материал на биржу за миллисекунды. Но не всегда можно за миллисекунды превратить его в корректную и подтверждённую позицию.

Почему AlgoWay не публикует одну универсальную цифру

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

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

Ошибки пользователя и ответственность автоматизации

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

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

Эта работа расходует драгоценные миллисекунды. Иногда она требует нескольких секунд. Мы считаем это время потраченным правильно.

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

Это не интеллектуальная автоматизация. Это уход от ответственности, замаскированный под скорость.

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

Что считать настоящим исполнением

Скорость важна в трейдинге, но скорость без понимания, проверки, подтверждения и ответственности не является преимуществом. Неверный ордер, доставленный за 100 миллисекунд, остаётся неверным ордером. Некорректный запрос, мгновенно отклонённый брокером, не становится успешной операцией. Быстро отправленная, но так и не подтверждённая инструкция не является исполнением.

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

Когда компания рекламирует 12 миллисекунд, 100 миллисекунд или 200 миллисекунд, к этой цифре следует относиться внимательно. Главный вопрос заключается не в том, выдумано ли само измерение, а в том, описывает ли оно весь процесс или только один выгодный фрагмент. Без чётко определённой начальной точки, чётко определённой конечной точки и подтверждения того, что операция завершилась реальной позицией, а не просто отправленным запросом, рекламируемая задержка не является всей правдой.

Это лишь тщательно отполированный кусок правды, представленный так, будто ничего другого не существует.

---

Версия материала на английском: «How Trade Automation Tools Mislead You: The Truth About Milliseconds»