Ненулевая вероятность наличия ошибок в коде даже после самого тщательного тестирования и код ревью — это факт, с которым нужно смириться и принять как данность. Поэтому при разработке архитектуры всегда стоит закладывать механизмы защиты, которые позволят системе функционировать или завершиться без нанесения ущерба себе, когда она начнет себя вести не в соответствии с ожиданиями. Особенно это важно в финансовом секторе, где мы работаем.
Три года назад у всех была на слуху история о 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' компонентов. О том, как мы боремся с техническими рисками данных возможных ошибок, мы расскажем в следующих статьях, если вас заинтересовала эта.
Комментарии (10)
slava_k
06.06.2017 15:38+2Также было бы интересно прочитать про системы анализа финансового поведения/календаря определенного набора компаний (не обязательно одноотраслевых) и построения ТС на основе подобных данных. К примеру, периоды уплаты налогов, дивидендных расчетов и схемы влияния этого на курсы различных валют и иных активов.
rezdm
07.06.2017 13:43Во как! Когда-то ж я был в тех двух командах в Дойче, что писали алго. Интересно, что там осталось с тех времён, и вообще осталась ли «няня пушкина» до сих пор.
V_M
14.06.2017 09:28-2Извините за мой коммент, но лучше человека ( конечно, обладающего для этого качествами ) никакая программа в одиночку торговать не сможет. По скорости реакции, отсутствию некоторых человеческих чувств ( нерешительность, страх, утомляемость, трезвый расчёт, неоправданная самоуверенность) — да, но по остальным критериям — нет. Это как сделать автопилот на автомобиль. А биржа сродни нашим дорогам. На карте красивая дорога и известны её параметры и средняя загруженность, а в реальности дорога с ямами, канавами, нарушающими правила водителями, пробками, пешеходами и пр. Просчитать заранее все варианты возможных ситуаций на будущее просто невозможно. Тут уже нужен интеллект и опыт для принятия правильного решения «на ходу». Допускаю как вариант программа под контролем человека, но программа один на один с биржей — очень и очень большой риск. Ещё раз извиняюсь, это всё моё личное мнение.
rezdm
14.06.2017 10:15Скажите, Вы работали в области algorithmic trading?
V_M
14.06.2017 17:41-1Я не программист, сразу признаюсь в этом И ни как не хотел быть понятым как противник разработчиков алгоритмов ( программ ) для торговли или как их критик. Я высказал свой взгляд с позиции человека, торговавшего на свои реальные деньги на бирже. Вот когда начинаешь вплотную задумываться над подходом к себе и способам ведения торговли. И часто задумываешься, как она вообще устроена вся эта биржевая система, почему произошло именно это и так, а не по другому и что надо было делать. Начинаешь искать логические объяснения всему происходящему. Особенно тому, что прямо или косвенно влияет на твой торговый счёт. И бывает часто так, что логики в некоторых вещах ты просто не можешь найти. Согласитесь, в процессе разработки всегда приходится что-то спрашивать у трейдеров, торгующих вручную. Вот я и решил поделиться своим взглядом на торговлю и торговлю с помощью программ. Всем удачи!!!
rezdm
14.06.2017 21:26Ваш подход, человеческий, сильно отличается от алгоритмического. Ручная торговля, всебезусловно, также имеет место быть, только у неё цели совершенно иные. Человек вручную не перебъёт машину в том же HFT. В IB, полагаю, что с нонешним ML можно вполне и без человека обойтись вообще.
slava_k
Спасибо за статью.
Со многими ограничениями можно успешно справляться, если того требует торговая система (ТС). К примеру, ограничение на максимальное количество ордеров — успешно решается увеличением числа контрагентов при доступе к бирже и балансировкой активов/ордеров. Если ТС имеет хитрую внутриспредовую HFT-торговлю с анализом стакана и иных «побочных» факторов типа нереализованной волатильности — то ограничение на минимальное время обработки ордера (порядка 2-5 мс, к примеру) также можно нивелировать длительностью удержания ордера или же уровнем доступа к самой бирже, тут вопрос лишь в деньгах.
Я понимаю, что мои пожелания могут вообще не иметь интереса у большинства, но все же. На мой взгляд было бы интересно увидеть/прочесть про то, как проходит тестирование ТС, какой используется подход к обработке исходных данных, какие типы данных (кроме цены+первичные параметры) используются, по каким критериям все это фильтруется (ценовые спайки, too-good-to-be-true), как проводится стресс-тест ТС (smoke tests и прочие).
Как происходит мониторинг работы ТС, системы оповещений, уровни реакции, какие из них в основном имеет смысл закладывать сразу в ТС, а не внешние сервисы и пр. Как выглядит процесс ликвидации позиций в случае внешних факторов типа «завтра FED решит резко взвинтить ставку до 6-8%, надо выходить изо всего, что в рынке». Как происходит тестирование ТС при длительном отсутствии связи, либо при наличии кратковременной, когда можно что-то сделать. Если ТС специфичная HFT и работает большими объемами — как происходит анализ неполного покрытия объема заявок, какой анализ каких параметров рынка используется для поиска оптимального money management в нестандартных ситуациях. К примеру, если HFT ТС работает парными сделками на одном или нескольких инструментах (одна из них — хедж) — как происходит коррекция к нейтральности позиции, если ликвидность резко снижается/расширяются спреды, какие дополнительные хедж-инструменты из доступных можно задействовать в такой сложной ситуации? К примеру, если есть позиции в рынке по золоту в долларе, доступ к этому инструменту ограничивается, но сохраняется доступ к паре фунт-йена (хедж, основанный на существенной корреляции инструментов). Ну и совсем на десерт — что-то про статистический анализ сезонности и корреляций различных/необычных инструментов, и как можно на основе этого построить различные ТС.
Было бы здОрово хотя бы что-то по подобной тематике прочитать. Спасибо.
volnnik
Спасибо за массу идей для дальнейших статей )
Я не понял только вашу мысль о борьбе с ограничениями. Это не внешние ограничения от рынков, это наше собственные ограничения, которые мы специально задаем для каждой стратегии с целью её контроля.
В дальнейших статьях на эту тему мы планировали покрыть то, что относится к технологиям и разработке (бэктестинг, стресс-тесты, реализация контейнеров для стратегий, мониторинге).
slava_k
Пожалуйста.
> это наше собственные ограничения
Значит я просто неверно воспринял, нужно чаще отдыхать.