Введение

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

"Алготрейдер спит — торговля идет!" — любят говорить некоторые трейдеры. Но в реальности не все так просто. Как вы думаете с чего начинается алгоритмическая торговля? С подключения к бирже или написания алгоритма? Для профессионально участника трейдинг начинается с разработки риск-менеджмента.

Считается, что алготрейдинг значительно эффективнее классического трейдинга. Потому, что у роботов не бывает эмоциональных решений, они готовы работать 24/7, точно знают, когда покупать и когда продавать, совершают сделки со скоростью не доступной обычному человеку. Однако, в силу своих суперспособностей, они создают повышенный класс рисков.
Например, известный случай вошедший в историю как «Месть машин» принес убытки в $460 млн, или сломавшийся робот принес потери в размере $4.3 млн или сбои на Московской бирже приводящие к остановкам и убыткам для трейдеров и т.д. Достаточного одного такого инцидента и торговым счетам может быть нанесен непоправимый ущерб. Это особенно актуально, если торговля маржинальная, когда цена ошибки возрастает в несколько раз.

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

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

1. Архитектурные решения

Прежде чем перейти к классификации рисков немого расскажу о типовых решениях в торговой части алгоритмического тнейдинга.

От требований к скорости исполнения заявок торговые роботы строятся по-разному. Если это HFT (например, арбитраж или маркетмейкинг) чувствительный к задержкам, то стараются минимизировать путь заявки от алгоритма к бирже и счет в задержках идет на микросекунды. Как правило, такие алгоритмы имеют специфичную архитектуру и оптимизируются под конкретную стратегию. В этом случае риск-менеджмент интегрируется непосредственно в стратегию.

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

Торговые алгоритмы редко торгуются по одному. Как правило это целые семейства стратегий, которые собираются в портфели для диверсификации и стабилизации кривой Equity. При этом биржевые данные для торговых алгоритмов могут идти из различных источников, а заявки отправляться на различные биржи. В ядре торговой системы находятся движки, которые маршрутизируют и оптимизируют данные между алгоритмами и биржами (см. Рис.1). Обычно присутствуют и другие движки, например, для работы с историческими данными или бектестирования, но в целях упрощения я их не показываю.


Рис.1. Схема архитектурного решения для торгового сервера.

2. Общая классификация рисков

• 2.1. Инфраструктурные риски
• 2.2. Проблемы с подключением к бирже/брокеру
• 2.3. Проблемы в логике торговых стратегий

2.1. Инфраструктурные риски

Основная доля проблем в данном классе связана с торговыми серверами. Для алгоритмической торговли даже очень мощный ПК не подходит по множеству причин: ненадежное оборудование, нестабильное интернет-соединение, плохое электропитание и т.д.

Основные риски:

• полная/частичная потеря работоспособности сервера;
• аварийная перезагрузка операционной системы;
• физический отказ сервера.

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

2.1.1. Варианты решения

• Колокация на бирже. Идеальный и самый дорогой вариант. Как правило используется в высокодоходных HFT алгоритмах или в крупных компаниях, например, банках, где данная инфраструктура переиспользуется для других торговых решений.
• Аренда виртуальных/выделенных серверов. Если вы не большой хедж-фонд или частный трейдер, то наверняка используете именно этот вариант. Простое легко настраиваемое и масштабируемое решение. Всегда можно найти провайдера, подходящего по параметрам цена/качество.
• Своя серверная. В данном случае реализуется собственная серверная с надежным резервируемым подключением. Иногда это особенно актуально, если приходится работать с чувствительными к приватности данными или часть серверов используются для ресурсоемких задач оптимизации/машинного обучения, аренда которых выйдет в копеечку.

2.1.2. Правила подбора торговых серверов

• Надежный/стабильный провайдер. ЦОД с вашими серверами должен отвечать классу надежности TIER III с uptime не менее 99,98% с резервируемыми каналами связи. Провайдер не должен останавливать или перезагружать ваши сервера в случае проведения своих технических работ.
• Качество интернет соединения. Всегда тестируйте скорость, задержки и стабильность канала связи. Заявленные показатели не всегда соответствуют реальности.
• Запас мощности минимум 40-50% (ЦП, оперативная память, SSD) по сравнению с обычным режимом торговли. Как правило, на сильных движениях на рынке кратно увеличиваются нагрузки в потоках данных и алгоритмы начинают активно совершать сделки. В этот ответственный момент не должно быть никаких тормозов на ваших серверах.

2.2. Проблемы с подключением

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

Основные риски:

• разрывы соединения;
• высокие задержки;
• некорректные данные;
• частичная потеря данных.

2.2.1. Разрывы соединения

Информацию о разрыве соединения можно получить несколькими способами:

• API события в коннекторе — Connected, Disconnected.
• Используя алгоритмы проверки соединения типа Heartbeat, которые, как правило, присутствуют в API.
• Косвенным путем. По отсутствию данных в потоках данных.

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

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

2.2.2. Проблемы с данными

Для начала рассмотрим основные типы биржевых данных. В зависимости от типа коннектора и биржи эти данные не много разнятся, но в основном плюс-минус одинаковые.

Входящие изменения:

• Биржевые стаканы/ордербук
• Сделки
• Заявки
• Позиции
• Баланс

Исходящие данные:

• Заявки на регистрацию

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

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

WatchDogs отслеживают:

• частоту обновления данных в потоке;
• задержки по таймстемпу в данных и текущему времени;
• по факту наличия данных определяет наличие связи с биржей.

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

Для корректного расчета задержек, должна быть реализована независимая система точной синхронизации системного времени. Например, с серверами NTP.

2.2.3. Варианты решения

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

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

Порядок восстановления работы:

• восстановить подключение;
• загрузить потерянные данные;
• оповестить алгоритмы о восстановлении связи;
• передать в алгоритмы потерянные данные;
• переключить потоки в real time;
• торговая логика алгоритмов должна нормализовать свои позиции и перевыставить заявки.

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

2.3. Проблемы в логике торговых стратегий

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

2.3.1. Классификация проблем

1. Ошибки в заявках:
   • Отрицательные цена/объем;
   • Обратное направление;
   • Не верный тип и т.д.
2. Ошибки в API:
   • Не все поля заполнены в транзакции;
   • Используется устаревшая версия API;
   • Ошибки конвертации и т.д.
3. Нарушение спецификации инструментов:
   • Не верная точность цены и объема в заявке;
   • Не правильное значение лотов;
   • Нарушение минимального и максимального объема в заявке;
   • Цена вне «ценового коридора»;
   • Торги не доступными или не существующими инструментами.
4. Нарушение регламента торгов:
   • До начала и после завершения торговой сессии;
   • Во время клиринга;
   • В праздничные или выходные дни.
5. Девиантное поведение заявок:
   • Высокая частота выставления заявок;
   • Большое количество активных заявок.
6. Нарушение лимитов торговой стратегии:
   • По балансу денежных средств;
   • По позиции по инструментам;
   • Превышение максимального объема в одной заявке;
   • Превышение максимального суммарного объема в активных заявках по инструментам.
7. Нарушение лимитов торгового счета:
   • По общей позиции по инструментам;
   • По общему балансу денежных средств;
   • Большое количество заявок, не приводящих к сделкам.
8. Отсутствие обработки исключений в программном коде торговых стратегий

При этом одни ошибки могут породить другие. Например, остановка алгоритма из-за грубой ошибки приведет к нарушению позиции и как следствие нарушению лимитов.

2.3.2. Варианты решения

Решение данных проблем сводится к контролю заявок и лимитов торговых стратегий (см. раздел 3). При этом любое исключение в программном коде должно привести к немедленной остановке проблемного алгоритма и снятию всех его активных заявок.

3. Контроль заявок и лимитов торговых стратегий

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

Проверки можно разделить на два типа:
3.1. Базовая проверка заявок
3.2. Анализ и контроль лимитов

3.1. Базовая проверка заявок

Все исходящие заявки должны проверяться на:

• грубые ошибки;
• корректность и достаточность данных для API;
• соответствие спецификации торгуемых инструментов;
• соблюдение регламента торгов и т.д.

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

3.2. Контроль лимитов

Для контроля лимитов проверяется:
3.2.1. Изменение баланса и позиции до выставления заявки
3.2.2. Изменение текущего баланса и позиции
3.2.3. Цена и объем заявки
3.2.4. Поведение заявок

3.2.1. Анализ изменения баланса и позиции до выставления заявки

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

3.2.2. Анализ изменения текущего баланса и позиции

Формируются лимиты на изменение торгуемого объема и позиции по инструментам за периоды времени: 15 сек, 30 сек, 1 мин, 5 мин, 15 мин, 1 час, 1 день. Постоянный контроль изменений за периоды времени позволит увидеть девиацию в поведении и остановить торги, до того момента, когда отклонение станет критичным.

Бывает, что проблемы с алгоритмом проявляются не сразу. Он может начать «сливать» не спеша и не нарушая лимитов на коротком промежутке времени. Можно проснуться утром и обнаружить значительную просадку из-за одного не много «поломанного» алгоритма. Оно нам надо? Оно нам не надо.

3.2.3. Анализ цены и объема заявки

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

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

Если изменения превышают заданные лимиты, то заявки отклоняются до отправки на биржу.

3.2.4. Анализ поведения заявок

Здесь проверяется:

• количество заявок, не приводящих к сделкам;
• количество активных заявок;
• частота выставления заявок за периоды 1 сек, 3 сек, 5 сек, 15 сек, 30 сек, 1 мин.

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

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

Данные проверки осуществляются на нескольких уровнях:

1. На уровне коннектора. Защита коннектора «притормаживает» заявки, когда частота выставления подходит к максимальной. Это необходимо, чтобы не потерять доступ к бирже. Данные меры крайние, поэтому важно заранее правильно рассчитывать нагрузку на коннектор.

2. На уровне торговой стратегии. Если алгоритм превышает свой лимит по частоте выставления заявок, то он принудительно останавливается с ошибкой. При этом снимаются все ранее выставленные активные заявки.

4. Интеграция риск-менеджмента в архитектурное решение

Интеграцию риск-менеджмента можно условно разделить на две основные части (см. Рис.2):

• PRE-TRADE включает в себя базовый контроль заявок, контроль цены и объема заявки, контроль изменения баланса и позиции до выставления заявки, так же здесь анализируется поведение заявок.
• POST-TRADE включает в себя проверки на разрывы соединения и корректность маркет данных, осуществляется постоянный контроль изменений баланса и текущих позиций, здесь так же анализируется поведение заявок.

Рис. 2. Схема интеграции риск-менеджмента в архитектурное решение для торгового сервера.

5. Логирование и репортинг

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

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

Заключение

Обычно риск-менеджмент к торговым алгоритмам начинают «прикручивать» в последнюю очередь, когда уже случилось пару инцидентов и пришло понимание, что без него не обойтись.

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

Однако, если грамотно построить торговую систему и настроить риск-менеджмент, то можно спать спокойно и быть уверенным, что "Алготрейдер спит — торговля идет!"

Всем удачных торгов!