История создания одного HFT-робота

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

История эта началась осенью 2010 года. Разработкой торговых стратегий я занимаюсь давно, но в основном на таймфреймах выше 15 минут. Про высокочастотный трейдинг (high frequency trading, HFT) много слышал, но сам не пробовал. И вот, изучая результаты участников конкурса ЛЧИ 2010, в голове появилась крамольная мысль – они смогли и у меня получится.
Вообще про конкурс биржи РТС надо сказать отдельно. Это превосходный рекламный трюк! Согласно закону больших чисел из 1 322 участников даже по чистой случайности должны найтись несколько роботов, которые покажут ошеломляющую доходность (привет, Н. Талебу), не говоря уже про действительно хорошие наработки. И время то какое выбрано – осень, пора высокой волатильности. Тот факт, что 63% участников по итогам оказались ниже стартовой отметки, остается за кадром.

Технологии
Итак, не испытывая особых иллюзий, а любопытства ради, взялся за дело. Для начала надо было определиться с платформой для написания робота. Программы технического анализа, наподобие Omega Research, для этих целей не годились в силу больших задержек получения данных и исполнения приказов. В то же время, покупать доступ к шлюзу и выделенный сервер, на первом этапе не хотелось. Поэтому в качестве торговой платформы были выбраны следующие программы: торговый терминал QUIK плюс собственная программа на C#. QUIK зарекомендовал себя стабильной работой и наличием открытого API (application program interface) для подачи заявок. На языке C# остановился в силу предубежденья, что программы на С-языках родные Windows и работают быстрее. Хотя первоочередное значение, конечно же, имеет качество алгоритма, я не язык реализации.
Данные из программы QUIK было решено выводить по ODBC в базу данных MySQL – бесплатную СУБД со всем необходимым функционалом. И сразу ответ тем, кто успел подумать, что DDE в сто раз круче – в данной конфигурации робота, преимущество которые дает прямой вывод данных в память – несущественно. Итак, схема будущего робота изображена на рисунке 1.
 
Рисунок 1 Схема взаимодействия робота с программами
Торговый терминал QUIK получает от биржи поток с котировками. В частности нас будет интересовать последняя сделка. Далее он транслирует эти данные с минимальной задержкой в базу данных MySQL. Робот с интервалом 100 миллисекунд (10 раз в секунду) забирает из базы данных новые тики и анализирует их. В случае необходимости подает приказы на покупку либо продажу в QUIK и отслеживает факт исполнения заявок. Все просто и надежно.
Алгоритм робота
Алгоритм робота – это самая главная часть. Хотя для HFT-робота не меньшую роль играет и способ исполнение заявок. Известно, что на рынках присутствует следующая закономерность – чем выше таймфрем, тем выше персистентность («трендовость») последовательности цен, то есть за ростом цены, скорее всего, будет следовать рост, за  падением – падение цены. Верно и обратно, на более мелких разрешениях графиков будет преобладать антиперсистентность изменения цен – подъем и спад будут чередоваться. В частности, большую часть времени инструмент будет находиться в интервале между лучшей ценой покупки (бидом) и лучшей ценой продажи (аском). Поэтому логично предположить, что высокочастотные роботы по своей сути должны быть контртрендовые – покупать при падении и продавать на росте. Самый примитивный HFT-робот, который «пылесосит» спред, – это алгоритм одновременного выставления двух заявок  покупки и продаж фьючерс на индекс РТС с разницей в 10 пунктов внутри спреда. Такой алгоритм имеет крайне низкую эффективность, так как во-первых, 10 пунктов – это примерная стоимость комиссионных для такой сделки, во-вторых, любое движение против уже открытой позиции приносит счету убыток в несколько раз больше 10 пунктов.
Инструментом для торговли был выбран фьючерс на индекс РТС – самый популярный и, пожалуй, единственный кандидат на нашем рынке для этой цели. В качестве исходной информации для анализа взяли поток тиков (сделок). В спокойный день количество тиков по фьючерсу на РТС составляет более полумиллиона.
В качестве тестового алгоритма решено было взять следующую стратегию. Ждем формирования локального максимума\минимума цены. Если цена падает от максимума на Y пунктов – покупаем, выросла от текущего минимума на Х пунктов – закрываем позицию, X <= Y – параметры системы. Стоплосс в размере 150 пунктов.
Предварительное тестирование системы на тиковых данных нарисовало в воображении лазурный берег, яхту и много чего. Финансовый результат «Грааля» по итогу дня колебался от 15 000 до 20 000 пунктов фьючерса РТС при комиссии биржи 2 руб./контракт и комиссии брокера 0.5 руб./контракт. Количество сделок около 3 000 штук в день, что соответствует в среднем одной сделке раз в 15 секунд. Но поскольку весь мой прошлый опыт на рынке говорил о том, что легких денег на бирже не бывает, осталось всего ничего — запрограммировать бота и убедиться в этом.

Автор: Юрий Кондратенко
Полная версия http://robostroy.ru/community/Article.aspx?id=254

P.S. Статья написана для конкурса, если понравилась, не поленитесь поставить плюсик автору на первоисточнике