Pull to refresh

Как не дать алгоритму продать банк

Reading time 6 min
Views 11K
Привет, Хабр! Наша команда в Москве занимается разработкой внутренней алгоритмической торговой платформы. Сегодня нам бы хотелось рассказать о механизмах, которые мы добавляем в нашу архитектуру для защиты от возможных сбоев.

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

Три года назад у всех была на слуху история о Knight Capital Group. В результате «успешного» обновления их системы они потеряли около 460 миллионов долларов из-за того, что их торговая система выставила и купила 397 миллионов акций разных компаний по нерыночным ценам.  Отчет о расследовании данного события должен, наверное, лежать на столе каждого COO любой финансовой компании — как напоминание, к чему может привести недостаточный уровень технического развития процессов в компании и отсутствия автоматических систем защиты.

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

В нашей платформе торговые стратегии (или, по-другому, торговые алгоритмы) запускаются в рамках некоторого контейнера. В контейнере находятся 'circuit breaker' компоненты, которые стоят на пути от торгового алгоритма к внешнему миру. Ближайшая аналогия из физического мира — это «плавкие предохранители». Основная цель этих 'circuit breaker' - принимать автоматическое решение об отключении стратегии в случае срабатывания правил, которые в них заложены. У них есть два состояния: «замкнутое» — проводят все сообщения между стратегией и внешним миром, и «разомкнутое» — когда они блокируют любые новые заявки (aka ордера) от стратегии на биржу. При этом они в любом состоянии всегда передают сообщения от биржи внутрь стратегии.


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

Контейнер, в котором запускается алгоритм, должен гарантировать, что стратегия не сможет обойти эту защиту. Можно еще добавить из практики, что разработкой стратегий и 'circuit breaker' компонентов должны заниматься разные команды.

Каждый 'circuit breaker' — это некое простое правило, которое должно ограничивать свободу действий контролируемой стратегии. Типичное правило может звучать так: «стратегия может послать не более 100 ордеров на рынок за все время». Как только стратегия попробует послать на рынок 101 ордер, 'circuit breaker' перейдет в разомкнутое состояние и перестанет передавать новые ордера от стратегии дальше на рынок.

Как только срабатывает любое правило, запускается следующая цепочка событий: а) стратегия получает сообщение о том, что 'circuit breaker' перешел в открытое состояние и она обязана завершить свою работу; б) удаляются все активные ордера с рынков, которые были поставлены этой стратегией; в) трейдер получает уведомление на свой торговый терминал об ошибке в алго-стратегии и ее принудительной остановке; г) такое же сообщение получает команда поддержки, которая должна незамедлительно начать расследование произошедшего.

Давайте посмотрим, какие, на наш взгляд, 'circuit breakers' должны присутствовать в любой торговой системе:

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

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

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

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

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

  • Too good to be true — иногда алгоритм может пытаться купить или продать инструмент по цене, которая ну слишком хороша, чтобы быть реальной. Обычно для реализации таких проверок у вас должен быть источник цен, которые вы примете за средние для торговли данного актива на рынке. В случае, если стратегия пытается купить/продать актив по ценам, которые выходят за рамки обозначенного вами коридора, это снова значит, что происходит что-то подозрительное и нужно остановить торговлю до момента, когда вы сможете однозначно сказать, чем это вызвано.

  • Fat fingers — данная проверка ограничивает размер ордера, который стратегия может выставить в одном распоряжении за один раз на рынок. Проверка скорее предназначена для защиты от трейдеров, если они запустят стратегию с какими-то очень большими распоряжениями на покупку или продажу активов.

  • Dead-man switch — любые алгоритмы запускаются трейдерами, которые и несут в конечном итоге ответственность за финансовый результат. Главное правило заключается в том, что за алгоритмом всегда должен наблюдать человек, следить за открытой позицией, финансовым результатом. Он принимает решение о том, что алгоритм работает в рамках заданной программы или что-то идет не так. Данная проверка призвана скорее бороться с человеческой небрежностью или забывчивостью, результатом которых могут стать большие финансовые потери для вашего банка. В нашем случае, если трейдер не совершает никаких активных действий на компьютере (нажатия клавиатуры, мыши) длительное время, выводится окошко с предупреждением. Если он не реагирует, то UI закрывает активные соединения с алго-контейнером. И алго-контейнер, уже видя, что сессия с UI закрылась, останавливает свои стратегии, которые были связанны с данной сессией (в алго-контейнере могут быть запущены стратегии от нескольких разных трейдеров).

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

Также важно еще раз отметить, что наличие 'circuit breaker' в вашей системе не гарантирует отсутствия проблем. Это только одна из линий обороны, которые вы должны построить внутри вашей торговой платформы. Ошибки могут прокрасться и внутрь алго-контейнера и 'circuit breaker' компонентов. О том, как мы боремся с техническими рисками данных возможных ошибок, мы расскажем в следующих статьях, если вас заинтересовала эта.
Tags:
Hubs:
+25
Comments 13
Comments Comments 13

Articles

Information

Website
dbtc-career.ru
Registered
Founded
2001
Employees
1,001–5,000 employees
Location
Россия