Биржи зеркалят объёмы друг у друга и реальный стакан в итоге существенно отличается от видимого, но а вообще надо торговать лимитниками, так стресс переходит из разряда - откуда такая цена в почему меня опять не исполнили )
Мысль отказаться от статического стресс-множителя в пользу измеренной скорости деградации выглядит намного здравее. Любой коэффициент вроде «считаем, что исчезнет половина стакана» действительно берётся почти с потолка: в спокойном рынке он будет душить торговлю, а в настоящем хвостовом событии всё равно окажется недостаточным.
Формулировка «сужающаяся дверь важнее уже узкой» здесь попадает точно в цель. Получается, оценивать нужно не только текущую стоимость выхода, но и скорость исчезновения доступного объёма на горизонте, за который позицию реально можно закрыть. Плюс учитывать, что собственная заявка сама съест часть наблюдаемой глубины.
Интересно, как вы планируете выбирать сам горизонт выхода: фиксировать его отдельно для каждого инструмента или рассчитывать динамически из размера позиции, текущей глубины и допустимой доли участия в рынке? И как будете защищаться от нелинейного обвала, когда скорость исчезновения объёма резко ускоряется?
Гонку между отменой и исполнением действительно нужно явно формализовать правилом fill wins: отмена относится только к неисполненному остатку, а любое пришедшее исполнение обязано обновить позицию. cancel_requestedнельзя считать финальным состоянием.
Особенно забираю идею мониторить не перечень известных аварий, а допущения, на которых держится корректность системы. Список конкретных сбоев всегда будет неполным, а нарушение допущения можно обнаружить независимо от его причины.
Раздельное здоровье каналов тоже намного точнее общего флага «API доступен»: маркет-данные могут поступать, пока размещение уже не работает, либо отмена работает отдельно от новых заявок.
Метрика возможности закрыть портфель прямо сейчас в пределах допустимого проскальзывания действительно сильнее обычного контроля просадки. Стоп смотрит на уже полученный убыток, но ничего не говорит о том, существует ли ещё нормальный выход.
И по биржевым SL/TP согласен: проблема не в том, что стоп превратится в обычную заявку, а в том, что при исчезнувшей ликвидности эта заявка может исполниться с чудовищным проскальзыванием, частично или не исполниться вообще. Стоп фиксирует намерение выйти, но не гарантирует сам выход.
Идея отдельного сторожевого контура, который умеет только отменять заявки и сокращать риск, тоже очень сильная. Особенно с проверкой общей причины отказа основной системы и её защиты.
Спасибо, это уже следующий уровень архитектуры. Если не секрет, при расчёте возможности выхода вы используете текущую глубину стакана как есть или дополнительно стрессуете её исчезновением части объёма?
Я здесь не выбирал брокера: робот делался под конкретного клиента Т-Банка. Почему он использует Т-Инвестиции — уже его решение. Скальпинг и арбитраж в этом проекте не применялись, поэтому их регламент отдельно не проверял.
Да, MetaTrader действительно снимает с разработчика значительную часть этой работы. Там уже есть терминал, готовая модель ордеров, сделок и позиций, торговые события и связь с сервером брокера. Поэтому советник под MT обычно пишется заметно проще, чем отдельное приложение через брокерский API.
Но я бы не говорил, что этих проблем там вообще нет. Даже в MT5 один торговый запрос порождает цепочку транзакций, их порядок не гарантирован, возможны частичные исполнения, а ручные операции пользователя приходят советнику через те же торговые события.
Просто MetaTrader предоставляет готовую инфраструктуру, внутри которой всё это можно обрабатывать. При прямой интеграции с T-Invest API, а особенно с Interactive Brokers, значительную часть инфраструктуры приходится строить самостоятельно.
Я в статье отталкиваюсь именно от максимального уровня ответственности, с которым сталкивался в проектах под IB. Там есть клиенты со счетами в десятки миллионов долларов, и подход «обработаем нормальный сценарий, а остальное маловероятно» уже не работает. При таких суммах приходится проектировать не только момент отправки заявки, но и потерю связи, частичное исполнение, ручное изменение портфеля, перезапуск приложения и восстановление после неопределённого состояния.
Поэтому статья не столько про недостатки T-Invest или преимущества конкретной платформы, сколько про требования к самостоятельной торговой системе, когда терминал не делает половину работы за разработчика.
Спасибо, теперь ваша мысль понятнее. MBO я как раз не критикую. Я отделяю ценность более подробных данных от ценности конкретного торгового сигнала. Возможность восстановить жизненный цикл отдельных заявок, очередь и полную отображаемую книгу действительно даёт существенно больше информации, чем агрегированный стакан.
Но с формулировкой про 18–35% «обмана» у меня возникает главный вопрос: что именно считается обманом?
Если речь просто о заявках, которые были быстро отменены или переставлены, этого недостаточно. Заявку могут снять из-за изменения цены, риска, очереди, частичного исполнения или появления новой информации. В публичном потоке видны действия, но не намерение участника в момент размещения заявки.
Поэтому я бы не делил события сразу на «честные» и «обманные». Скорее выделял бы наблюдаемые классы поведения:
— короткоживущая ликвидность; — борьба за положение в очереди; — многократное снятие и восстановление объёма; — асимметричные крупные заявки; — отмена после исполнения заявки на противоположной стороне; — повторяющиеся spoof-like последовательности.
А уже затем проверял бы, дают ли эти признаки дополнительную прогнозную ценность. Иначе есть риск сначала назвать треть рынка обманом, а потом построить алгоритм, который хорошо распознаёт наше собственное определение обмана, но ничего не зарабатывает.
Самостоятельное восстановление книги мне интересно как отдельный исследовательский слой. Но там сначала нужно доказать корректность самого replay: последовательность сообщений, восстановление после пропусков, add/modify/cancel/execute, частичные исполнения, смены сессий и сверка итогового состояния. Ошибка в одном событии дальше искажает всю книгу.
Для нашей текущей задачи я бы проверял MBO не как замену поиску исторических паттернов, а как дополнительный набор микроструктурных признаков. Базовая версия работает без них, затем добавляется order-flow-слой и сравнивается результат на последовательных OOS-участках после издержек.
Поэтому направление принимаю. Но особенно интересно, как именно у вас получены эти 18–35%. Это доля отменённых заявок, определённая последовательность событий, отмена после сделки на противоположной стороне или собственная классификация? И о каком конкретно рынке и фиде идёт речь?
В части симуляции сделок мы, по сути, говорим об одном и том же. После сигнала система должна перейти из состояния поиска входа в состояние управления позицией, дождаться выхода и посчитать результат с учётом комиссии, спреда, проскальзывания и фактической логики исполнения.
Но это не устраняет проблему перекрывающихся кандидатов. Если тридцать соседних исторических окон относятся к одному рыночному эпизоду и участвуют в построении прогноза как тридцать независимых голосов, ложная уверенность возникает ещё до входа. Торговый автомат, разрешающий только одну позицию, задним числом независимыми их не сделает. Поэтому сначала разрежается выборка кандидатов, а уже затем тестируется полный цикл входа и выхода.
Карту результатов по параметрам я тоже считаю полезной. Но выбирать на том же датасете участок с максимальной прибылью и говорить «вот она» — как раз опасная часть. Чем больше сочетаний перебрано, тем выше шанс найти красивый исторический выброс.
Поэтому меня интересует не вершина прибыли, а широкий устойчивый участок, где результат не разваливается от небольшого изменения параметров. После выбора параметры фиксируются и проверяются на следующих, не участвовавших в подборе данных. Иначе многомерный график получится красивым, но описывать он будет преимущественно прошлое.
Перебирать параметры по одному тоже недостаточно: так теряются их взаимодействия. Полный многомерный перебор взаимодействия видит, но резко увеличивает проблему множественного тестирования. Здесь бесплатного решения нет.
По тикам согласен частично. Для моделирования исполнения, очереди заявок и микроструктурных признаков тиковые данные и полноценный стакан действительно полезны. Но для прогноза, построенного на участках длительностью десятки минут, переход к каждому отдельному событию не является автоматическим улучшением: вместе с информацией резко растут шум, объём данных и сложность проверки.
И отдельно уточню: что именно вы называете Level-3 — Market by Order с жизненным циклом отдельных заявок и положением в очереди или конкретный брокерский формат глубины стакана? Если речь о MBO, то это интересный отдельный слой для модели исполнения и order-flow-признаков. Но он всё равно должен доказать дополнительную ценность вне выборки и после издержек.
Любопытно, а можно сразу ссылку на этот конструктор? Я вот к примеру продаю на авито время от времени, что то из ненужного, но ни разу ни какого конструктора не видел. Отсюда вопрос - почему этот конструктор не попадается на глаза?
Непонятно в чём обмен. Я захожу в банк вижу предложенный банком курс. Я меняю. Это банк предложил такие условия. Я не взламывал сайт и не делал ничего плохого. Но однозначно глупо было после этих операция оставлять деньги на счёте. Сначала их надо вывести, а потом уже можно и судиться.
Не хочу приземлять автора раньше времени, но ии в трейдинге это вообще не главное. Помощник да, но не более.
Биржи зеркалят объёмы друг у друга и реальный стакан в итоге существенно отличается от видимого, но а вообще надо торговать лимитниками, так стресс переходит из разряда - откуда такая цена в почему меня опять не исполнили )
Мысль отказаться от статического стресс-множителя в пользу измеренной скорости деградации выглядит намного здравее. Любой коэффициент вроде «считаем, что исчезнет половина стакана» действительно берётся почти с потолка: в спокойном рынке он будет душить торговлю, а в настоящем хвостовом событии всё равно окажется недостаточным.
Формулировка «сужающаяся дверь важнее уже узкой» здесь попадает точно в цель. Получается, оценивать нужно не только текущую стоимость выхода, но и скорость исчезновения доступного объёма на горизонте, за который позицию реально можно закрыть. Плюс учитывать, что собственная заявка сама съест часть наблюдаемой глубины.
Интересно, как вы планируете выбирать сам горизонт выхода: фиксировать его отдельно для каждого инструмента или рассчитывать динамически из размера позиции, текущей глубины и допустимой доли участия в рынке? И как будете защищаться от нелинейного обвала, когда скорость исчезновения объёма резко ускоряется?
Спасибо, очень сильный комментарий.
Гонку между отменой и исполнением действительно нужно явно формализовать правилом fill wins: отмена относится только к неисполненному остатку, а любое пришедшее исполнение обязано обновить позицию. cancel_requested
Особенно забираю идею мониторить не перечень известных аварий, а допущения, на которых держится корректность системы. Список конкретных сбоев всегда будет неполным, а нарушение допущения можно обнаружить независимо от его причины.
Раздельное здоровье каналов тоже намного точнее общего флага «API доступен»: маркет-данные могут поступать, пока размещение уже не работает, либо отмена работает отдельно от новых заявок.
Метрика возможности закрыть портфель прямо сейчас в пределах допустимого проскальзывания действительно сильнее обычного контроля просадки. Стоп смотрит на уже полученный убыток, но ничего не говорит о том, существует ли ещё нормальный выход.
И по биржевым SL/TP согласен: проблема не в том, что стоп превратится в обычную заявку, а в том, что при исчезнувшей ликвидности эта заявка может исполниться с чудовищным проскальзыванием, частично или не исполниться вообще. Стоп фиксирует намерение выйти, но не гарантирует сам выход.
Идея отдельного сторожевого контура, который умеет только отменять заявки и сокращать риск, тоже очень сильная. Особенно с проверкой общей причины отказа основной системы и её защиты.
Спасибо, это уже следующий уровень архитектуры. Если не секрет, при расчёте возможности выхода вы используете текущую глубину стакана как есть или дополнительно стрессуете её исчезновением части объёма?
Я здесь не выбирал брокера: робот делался под конкретного клиента Т-Банка. Почему он использует Т-Инвестиции — уже его решение. Скальпинг и арбитраж в этом проекте не применялись, поэтому их регламент отдельно не проверял.
Да, MetaTrader действительно снимает с разработчика значительную часть этой работы. Там уже есть терминал, готовая модель ордеров, сделок и позиций, торговые события и связь с сервером брокера. Поэтому советник под MT обычно пишется заметно проще, чем отдельное приложение через брокерский API.
Но я бы не говорил, что этих проблем там вообще нет. Даже в MT5 один торговый запрос порождает цепочку транзакций, их порядок не гарантирован, возможны частичные исполнения, а ручные операции пользователя приходят советнику через те же торговые события.
Просто MetaTrader предоставляет готовую инфраструктуру, внутри которой всё это можно обрабатывать. При прямой интеграции с T-Invest API, а особенно с Interactive Brokers, значительную часть инфраструктуры приходится строить самостоятельно.
Я в статье отталкиваюсь именно от максимального уровня ответственности, с которым сталкивался в проектах под IB. Там есть клиенты со счетами в десятки миллионов долларов, и подход «обработаем нормальный сценарий, а остальное маловероятно» уже не работает. При таких суммах приходится проектировать не только момент отправки заявки, но и потерю связи, частичное исполнение, ручное изменение портфеля, перезапуск приложения и восстановление после неопределённого состояния.
Поэтому статья не столько про недостатки T-Invest или преимущества конкретной платформы, сколько про требования к самостоятельной торговой системе, когда терминал не делает половину работы за разработчика.
Спасибо, теперь ваша мысль понятнее. MBO я как раз не критикую. Я отделяю ценность более подробных данных от ценности конкретного торгового сигнала. Возможность восстановить жизненный цикл отдельных заявок, очередь и полную отображаемую книгу действительно даёт существенно больше информации, чем агрегированный стакан.
Но с формулировкой про 18–35% «обмана» у меня возникает главный вопрос: что именно считается обманом?
Если речь просто о заявках, которые были быстро отменены или переставлены, этого недостаточно. Заявку могут снять из-за изменения цены, риска, очереди, частичного исполнения или появления новой информации. В публичном потоке видны действия, но не намерение участника в момент размещения заявки.
Поэтому я бы не делил события сразу на «честные» и «обманные». Скорее выделял бы наблюдаемые классы поведения:
— короткоживущая ликвидность;
— борьба за положение в очереди;
— многократное снятие и восстановление объёма;
— асимметричные крупные заявки;
— отмена после исполнения заявки на противоположной стороне;
— повторяющиеся spoof-like последовательности.
А уже затем проверял бы, дают ли эти признаки дополнительную прогнозную ценность. Иначе есть риск сначала назвать треть рынка обманом, а потом построить алгоритм, который хорошо распознаёт наше собственное определение обмана, но ничего не зарабатывает.
Самостоятельное восстановление книги мне интересно как отдельный исследовательский слой. Но там сначала нужно доказать корректность самого replay: последовательность сообщений, восстановление после пропусков, add/modify/cancel/execute, частичные исполнения, смены сессий и сверка итогового состояния. Ошибка в одном событии дальше искажает всю книгу.
Для нашей текущей задачи я бы проверял MBO не как замену поиску исторических паттернов, а как дополнительный набор микроструктурных признаков. Базовая версия работает без них, затем добавляется order-flow-слой и сравнивается результат на последовательных OOS-участках после издержек.
Поэтому направление принимаю. Но особенно интересно, как именно у вас получены эти 18–35%. Это доля отменённых заявок, определённая последовательность событий, отмена после сделки на противоположной стороне или собственная классификация? И о каком конкретно рынке и фиде идёт речь?
В части симуляции сделок мы, по сути, говорим об одном и том же. После сигнала система должна перейти из состояния поиска входа в состояние управления позицией, дождаться выхода и посчитать результат с учётом комиссии, спреда, проскальзывания и фактической логики исполнения.
Но это не устраняет проблему перекрывающихся кандидатов. Если тридцать соседних исторических окон относятся к одному рыночному эпизоду и участвуют в построении прогноза как тридцать независимых голосов, ложная уверенность возникает ещё до входа. Торговый автомат, разрешающий только одну позицию, задним числом независимыми их не сделает. Поэтому сначала разрежается выборка кандидатов, а уже затем тестируется полный цикл входа и выхода.
Карту результатов по параметрам я тоже считаю полезной. Но выбирать на том же датасете участок с максимальной прибылью и говорить «вот она» — как раз опасная часть. Чем больше сочетаний перебрано, тем выше шанс найти красивый исторический выброс.
Поэтому меня интересует не вершина прибыли, а широкий устойчивый участок, где результат не разваливается от небольшого изменения параметров. После выбора параметры фиксируются и проверяются на следующих, не участвовавших в подборе данных. Иначе многомерный график получится красивым, но описывать он будет преимущественно прошлое.
Перебирать параметры по одному тоже недостаточно: так теряются их взаимодействия. Полный многомерный перебор взаимодействия видит, но резко увеличивает проблему множественного тестирования. Здесь бесплатного решения нет.
По тикам согласен частично. Для моделирования исполнения, очереди заявок и микроструктурных признаков тиковые данные и полноценный стакан действительно полезны. Но для прогноза, построенного на участках длительностью десятки минут, переход к каждому отдельному событию не является автоматическим улучшением: вместе с информацией резко растут шум, объём данных и сложность проверки.
И отдельно уточню: что именно вы называете Level-3 — Market by Order с жизненным циклом отдельных заявок и положением в очереди или конкретный брокерский формат глубины стакана? Если речь о MBO, то это интересный отдельный слой для модели исполнения и order-flow-признаков. Но он всё равно должен доказать дополнительную ценность вне выборки и после издержек.
За развёрнутый комментарий спасибо.
вот до сих пор поражаюсь зачем этот вим? Давайте и на перфокартах ещё что-то делать. Хардкор же, круто.
Ушёл с firefox потому что неоднократно возникали проблемы во время оплаты покупок в интернете - некорректно отображались платёжные формы.
Любопытно, а можно сразу ссылку на этот конструктор? Я вот к примеру продаю на авито время от времени, что то из ненужного, но ни разу ни какого конструктора не видел. Отсюда вопрос - почему этот конструктор не попадается на глаза?
Именно сейчас и надо ими заниматься
Непонятно в чём обмен. Я захожу в банк вижу предложенный банком курс. Я меняю. Это банк предложил такие условия. Я не взламывал сайт и не делал ничего плохого. Но однозначно глупо было после этих операция оставлять деньги на счёте. Сначала их надо вывести, а потом уже можно и судиться.