Коротко

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

Где остаётся человеческое решение

Системная торговля и дискреционный подход различаются тем, где и как формируется решение. CME Group описывает system-based trading как заранее заданную последовательность правил, а discretionary trading — как процесс, где решение зависит от текущего суждения человека (System-Based vs. Discretionary Trading). Это различие полезно, но оно не означает, что системный процесс существует без людей.

Человек обычно участвует в нескольких точках:

  1. выбирает вопрос и данные для исследования;
  2. задаёт правило, параметры и ограничения;
  3. решает, когда версия готова к проверке или запуску;
  4. определяет пороги мониторинга и порядок остановки;
  5. разбирает исключения, ошибки данных и расхождения исполнения.

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

Эмоции возникают до и после сигнала

Интуитивно кажется, что эмоциональный риск — это только желание войти или выйти во время движения цены. На практике он может появиться раньше: исследователь выбирает самый убедительный график, меняет параметры после неблагоприятного периода или расширяет исключение, чтобы не останавливать процесс.

Материалы CFA Institute о поведенческих и когнитивных искажениях рассматривают, как систематические ошибки суждения влияют на решения (The Behavioral Biases of Individuals). Перечень искажений не является диагнозом конкретного человека; он полезен как повод превратить неявное решение в проверяемый вопрос.

Полезно отдельно спросить:

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

Условный пример исключения

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

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

Как поддержать дисциплину правилами

Журнал решений

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

Заранее описанные исключения

Исключение должно иметь условие входа и условие завершения. Формулировка «при необычной ситуации» слишком расплывчата; лучше описать наблюдаемый признак и следующий шаг.

Разделение наблюдения и изменения

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

Что проверить самостоятельно

  1. Какие решения формализованы, а какие остаются ручными?
  2. Кто может изменить правило, параметр или порог остановки?
  3. Есть ли журнал ручных исключений и причин их применения?
  4. Что считается задержкой данных, ошибкой исполнения или инцидентом?
  5. Отделён ли мониторинг версии от её немедленной перенастройки?
  6. Как неблагоприятный период влияет на решение — по правилу или по впечатлению?
  7. Можно ли восстановить состояние процесса по журналу без устного объяснения?

Ограничения и границы вывода

Наличие журнала и правил не делает решения объективными автоматически. Поведенческие рамки помогают задавать вопросы, но не заменяют обучение, контроль и ответственность владельца процесса. Статья не утверждает, что автоматизация устраняет эмоции, и не оценивает конкретную систему ARM.

Итог

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