Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 8
Сложно как все... Толи дело МТ или cTrader, кнопку нажал и все
Да, MetaTrader действительно снимает с разработчика значительную часть этой работы. Там уже есть терминал, готовая модель ордеров, сделок и позиций, торговые события и связь с сервером брокера. Поэтому советник под MT обычно пишется заметно проще, чем отдельное приложение через брокерский API.
Но я бы не говорил, что этих проблем там вообще нет. Даже в MT5 один торговый запрос порождает цепочку транзакций, их порядок не гарантирован, возможны частичные исполнения, а ручные операции пользователя приходят советнику через те же торговые события.
Просто MetaTrader предоставляет готовую инфраструктуру, внутри которой всё это можно обрабатывать. При прямой интеграции с T-Invest API, а особенно с Interactive Brokers, значительную часть инфраструктуры приходится строить самостоятельно.
Я в статье отталкиваюсь именно от максимального уровня ответственности, с которым сталкивался в проектах под IB. Там есть клиенты со счетами в десятки миллионов долларов, и подход «обработаем нормальный сценарий, а остальное маловероятно» уже не работает. При таких суммах приходится проектировать не только момент отправки заявки, но и потерю связи, частичное исполнение, ручное изменение портфеля, перезапуск приложения и восстановление после неопределённого состояния.
Поэтому статья не столько про недостатки T-Invest или преимущества конкретной платформы, сколько про требования к самостоятельной торговой системе, когда терминал не делает половину работы за разработчика.
По опыту запиливания похожей системы для крипторынка, всё перечисленное — стейт-машина заявок, чужие позиции, сверка после рестарта, протухшие данные — подтверждаю как обязательный фундамент.
Про «самую неприятную ситуацию» (брокер принял, ответ потерялся). Есть вторая гонка того же класса: отмена против исполнения. Отмена не считается успешной, пока не подтверждена, и если в окне гонки пришло исполнение — побеждает исполнение. Без явной семантики «fill wins» легко получить «отменённую» позицию, которая на самом деле открылась.
Поделюсь тем, где началась следующая граница надежности:
1. Главный сдвиг мышления: перечислять не отказы, а допущения. Любой список сценариев («API не ответил», «частичное исполнение») неполон — следующий сбой будет не из списка. Вместо этого перечисляем допущения, на которых стоит корректность системы: «наблюдаемая цена отражает реальность», «ордер размещается за ограниченное время», «цена исполнения близка к наблюдаемой», «внутреннее состояние равно брокерскому», «единица учёта стабильна» — и на каждое нужен монитор. Будущее tail-событие проявится как нарушение их подмножества.
2. Отказы частичны. Криптокрах 10 октября 2025 показал: отмена работала, размещение — нет, данные шли, но глубина стакана испарилась на 98%. «API доступен/недоступен» — слишком грубая модель; полезно вести здоровье по каналам (размещение / отмена / маркет-дата / аккаунт) раздельно.
3. Охранять выход, а не убыток. Стоп по просадке смотрит назад — и в фазе испарившейся ликвидности стреляет в пустой стакан. Форвардная метрика «закрывается ли портфель прямо сейчас в пределах X% слиппеджа» велит сокращаться, пока стакан еще жив.
4. Для проектирования защитного слоя полезно задавать архитектурный вопрос - «какая общая причина отключит и слой, и то, что он защищает?». Отсюда рождаются решения вида сторожевой контур на отдельном хосте/маршруте/ключе, который умеет только сокращать и отменять и срабатывает при «робот мёртв ∧ позиции открыты ∧ биржа жива».
5. Биржевые SL/TP как страховка не работают — взводить их когда канал размещения уже деградировал бессмысленно, а постоянный взвод заранее показывает рынку вашу точку боли. Отсутствие гарантий их выполнения - постоянный источник грустных мемов)
Спасибо, очень сильный комментарий.
Гонку между отменой и исполнением действительно нужно явно формализовать правилом fill wins: отмена относится только к неисполненному остатку, а любое пришедшее исполнение обязано обновить позицию. cancel_requested нельзя считать финальным состоянием.
Особенно забираю идею мониторить не перечень известных аварий, а допущения, на которых держится корректность системы. Список конкретных сбоев всегда будет неполным, а нарушение допущения можно обнаружить независимо от его причины.
Раздельное здоровье каналов тоже намного точнее общего флага «API доступен»: маркет-данные могут поступать, пока размещение уже не работает, либо отмена работает отдельно от новых заявок.
Метрика возможности закрыть портфель прямо сейчас в пределах допустимого проскальзывания действительно сильнее обычного контроля просадки. Стоп смотрит на уже полученный убыток, но ничего не говорит о том, существует ли ещё нормальный выход.
И по биржевым SL/TP согласен: проблема не в том, что стоп превратится в обычную заявку, а в том, что при исчезнувшей ликвидности эта заявка может исполниться с чудовищным проскальзыванием, частично или не исполниться вообще. Стоп фиксирует намерение выйти, но не гарантирует сам выход.
Идея отдельного сторожевого контура, который умеет только отменять заявки и сокращать риск, тоже очень сильная. Особенно с проверкой общей причины отказа основной системы и её защиты.
Спасибо, это уже следующий уровень архитектуры. Если не секрет, при расчёте возможности выхода вы используете текущую глубину стакана как есть или дополнительно стрессуете её исчезновением части объёма?
Этот слой на стадии проектирования, в бою механики попроще (просадка + здоровье фида), так что делюсь замыслом, а не проверенной практикой.
Статический стресс-множитель («допустим, испарится половина объёма») отбросили — его не откалибровать: любой заранее выбранный коэффициент либо слишком мягок для реального хвоста, либо парализует нормальную торговлю. Вместо этого хотим стрессовать измеренной скоростью деградации: не «а что если объём исчезнет», а «объём исчезает вот с такой скоростью, экстраполяция на горизонт выхода даёт вот столько». Сужающаяся дверь важнее уже узкой. Плюс помнить, что собственный выход тоже ест стакан.
Кстати, полез посмотреть T-Invest API — понравился флаг is_consistent в стриме стакана: API сам сознаётся в деградации канала доставки, готовый вход для мониторинга допущений. Еще, в крипте дверь на выход сужает ликвидность, а на фонде её может штатно захлопнуть сама биржа — планка, дискретный аукцион, приостановка торгов. Получаем дополнительный слой рисков.
Мысль отказаться от статического стресс-множителя в пользу измеренной скорости деградации выглядит намного здравее. Любой коэффициент вроде «считаем, что исчезнет половина стакана» действительно берётся почти с потолка: в спокойном рынке он будет душить торговлю, а в настоящем хвостовом событии всё равно окажется недостаточным.
Формулировка «сужающаяся дверь важнее уже узкой» здесь попадает точно в цель. Получается, оценивать нужно не только текущую стоимость выхода, но и скорость исчезновения доступного объёма на горизонте, за который позицию реально можно закрыть. Плюс учитывать, что собственная заявка сама съест часть наблюдаемой глубины.
Интересно, как вы планируете выбирать сам горизонт выхода: фиксировать его отдельно для каждого инструмента или рассчитывать динамически из размера позиции, текущей глубины и допустимой доли участия в рынке? И как будете защищаться от нелинейного обвала, когда скорость исчезновения объёма резко ускоряется?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Торговый робот: что нужно для автономной работы с реальными деньгами