Торговая автоматизация с учётом риска: gates, лимиты и сценарии отказа
Практический подход к автоматизации через failure modes, детерминированные gates, лимиты экспозиции, stale-data проверки и audit trail.
Торговая автоматизация с учётом риска начинается с неприятного предположения: стратегия может правильно угадать направление и всё равно потерять деньги, если окружающая система ошиблась во времени, ликвидности, размере позиции или состоянии счета.
Поэтому задача risk layer — не сделать стратегию абстрактно «безопасной», а определить явные условия, при которых автоматизация должна уменьшить размер, задержать, отклонить или полностью остановить действие.
Четыре разных вида риска
1. Рыночный риск
Цена способна двигаться дальше и быстрее, чем показывала история. Режимы меняются, корреляции ломаются, волатильность кластеризуется.
Полезные controls: лимиты экспозиции и концентрации, drawdown rules и sizing, учитывающий режим.
2. Риск ликвидности и исполнения
Сигнал может существовать, а торгуемой возможности уже не быть. Спред, глубина стакана, price impact, лимиты площадки и задержка превращают красивую теоретическую точку входа в плохое исполнение.
Каталог бирж и market pages дают публичный контекст, но фактические условия нужно проверять в момент решения.
3. Риск данных
Устаревшие свечи, пропуски book updates, ошибки символов, clock drift или деградация источника могут обесценить evidence стратегии.
Надёжная система должна уметь fail closed, когда обязательное evidence отсутствует, а не молча подставлять удобное значение.
4. Операционный риск
Коннектор может отключиться, счёт — отклонить действие, зависимость — деградировать, а deployment — запустить не ту версию стратегии.
Operational health должен быть частью decision boundary, а не только post-mortem мониторинга.
Модель последовательных gates
Один из способов строить автоматизацию — цепочка gates:
- Evidence gate — обязательные рыночные наблюдения есть и достаточно свежие.
- Strategy gate — условия Detector выполнены.
- Admission gate — Advisor детерминированно записывает
ADMITилиREJECT. - Execution/risk gate — Inspector получает актуальную truth, применяет sizing, exposure, drawdown и ограничения счёта и владеет governed execution lifecycle.
- Provider/venue evidence gate — Provider остаётся единственной broker/exchange границей и возвращает venue-confirmed evidence, позволяющее понять, было ли действие принято и исполнено.
Каждый gate должен останавливать workflow, не объявляя предыдущий этап «ошибочным». Для исследования это принципиально.
Почему отклонённые кандидаты нужно сохранять
Если rejected candidates исчезают, система не сможет ответить:
- находила ли стратегия полезные возможности, которые policy фильтровала слишком жёстко;
- какие убытки были предотвращены конкретным risk rule;
- отклоняла ли stale-data проверка хорошие с виду кандидаты;
- мешала ли исполнению площадка, а не стратегия.
Полный decision path позволяет измерять поведение risk policy отдельно.
Sizing должен идти после стратегического intent
Стратегия может сказать «условие интересно», не зная полного состояния счета и портфеля.
Inspector затем учитывает:
- максимальный размер позиции;
- текущую экспозицию по активу или группе;
- drawdown state;
- concentration limits;
- ограничения площадки и счета;
- risk budget конкретной стратегии.
Так portfolio и execution authority не приходится встраивать в каждый Detector. Inspector остаётся финальной execution/risk authority, а Provider — broker/exchange границей.
Отказ должен быть явным
Автоматизация должна заранее определять поведение, если:
- обязательные данные устарели;
- источник пропал;
- состояние счета не удаётся подтвердить;
- risk service недоступен;
- статус ордера неоднозначен;
- deployment неожиданно сменил конфигурацию стратегии.
«Продолжить с последним известным значением» иногда нормально для аналитики и часто опасно для исполнения.
Чеклист перед автоматизацией
- Какие входы обязательны и сколько времени они считаются свежими?
- Что приводит к hard reject, а что только уменьшает размер?
- Сохраняется ли причина каждого risk decision?
- Сверяется ли исполнение с подтверждённым площадкой order/fill state?
- Независимы ли risk limits от strategy code?
- Проверен ли сценарий деградации зависимостей?
- Может ли оператор остановить workflow без изменения стратегии?
Связанные страницы
Риск-контроли могут уменьшить конкретные failure modes, но не гарантируют прибыль, отсутствие убытков, проскальзывания или операционных ошибок.