Вступление

     Никогда не увлекался скоростным трейдингом. Всегда хватало терминала. Изучать этот протокол меня побудил набор вакансий. Надо отметить, что я неспешно перебираю хорошие вакансии на рынке. Частному трейдеру очень сложно развиваться в одиночку — психологически, эмоционально, физически. Создавать и развиваться постоянно хочется, поэтому принял решение вливаться в коллектив. За несколько месяцев, мне удалось провести несколько собеседований. На втором этапе я проваливался именно из за не знаний протокола.  Предметную область я примерно представлял. Ну что там сложного? Соединился с биржей по сокетам и начинай обмен сообщениями. Надо отметить, что в этой области есть уже готовые разработки в виде quickfix или готового API от StockSharp (правда платные). Но я принял решение разбираться с нуля, чтобы вникнуть в детали.

Технические аспекты протокола

     Итак. Любой протокол, какой бы он сложный не был, работает примерно одинаково. Мы создаем у себя соединение с сервером, устанавливаем некий туннель между нами и сервером, посредством которого будем обмениваться сообщениями. Протокол — это как раз и есть набор правил, по которым строятся сообщения нужного формата. Если говорить технически, то мы должны создать сокет соединение с сервером на указанный порт.
Сообщение в FIX, как и в любом другом протоколе, состоит из нескольких блоков:

• <Заголовок сообщения>
• <Сообщение>
• <Концовка сообщения>

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

• <Начало сообщения, версия протокола>
• <Длина (размер) сообщения>
• <Тип сообщения>
• <Идентификатор отправителя>
• <Идентификатор получателя>
• <Номер сообщения>
• <Время отправки>

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

• <Контрольная сумма сообщения>

     Сами данные заполняются достаточно легко. В виде: <тип поля> = <значение>. Например, <длина сообщения> = 78, то есть мы серверу говорим, что размер передаваемого нами сообщения составляет 78 байт. Стоит обратить внимание, что в протоколе FIX, типы полей кодируются в виде числовых значений. Например,  <длина сообщения> в протоколе передается как цифра 9. Исходя из выше сказанного, наш заголовок сообщения, выглядел бы следующим образом:

• 8=FIX.4.4 _____ начало сообщения, протокол версии 4.4
• 9=78 _____ размер сообщения 78 байт
• 35=A _____ тип сообщения А, что означает попытка на соединение с сервером
• 49=<ваш идентификатор выдается биржей>
• 56=FG _____ идентификатор получателя, раздел Forts на бирже
• 34=1 _____ первое сообщение
• 52=20160212-11:42:51.812 _____ время отправки сообщения

Организационные вопросы

1. Наша биржа дает тестовый контур для отработки своих алгоритмов по данному протоколу. Надо всего лишь написать запрос на доступ. Надо признать, тех служба работает отменно. Очень все быстро было организовано. Подробности http://moex.com/s442
2. Обязательно понадобится описание протокола для нашей биржи ftp://ftp.moex.com/pub/FIX/Spectra/test/docs/spectra_fixgate_ru.pdf
3. Чтобы вникнуть в тонкости передачи, мне очень помогла эта программа от биржи (позже я покажу как помогла) ftp://ftp.moex.com/pub/FIX/Spectra/Utils/fix_client.zip
4. Описание самого протокола от создателей (на английском). Мне помог сильно wiki. http://fixwiki.org/fixwiki/FIXwiki
5. Чтобы найти свои ошибки, мне приходилось перехватывать сообщения рабочего клиента биржи и сверять со своими. Для этого мне понадобился tcp/ip сниффер — программа перехвата сетевого трафика.
6. Разработку я веду на c#.

К бою. Немного теоретической практики

     На момент изучения протокола, я уверен, многие столкнуться со следующими вопросами:

• как именно считать длину сообщения
• как разделять между собой данные
• как считать контрольную сумму

     Если говорить образно. То, чтобы отправить сообщение на сервер, нам просто нужно сформировать нужную строку со всеми данными и отправить ее на биржу. Ну например:

8=FIX.4.4;9=78;35=A;49=FG;56=tgFhcfx901U05;34=1;52=20160212-11:42:51.812;98=0;108=3000;141=Y;10=047;

     Если быть внимательным, то мы увидим, что кол-во символов в строке у нас 100, а в заголовке сообщения мы передаем, что 78 (9 = 78). По правилам протокола FIX, длину сообщения нужно считать без учета концовки и первых двух полей заголовка. А именно:

     С длиной сообщения разобрались. Теперь про разделитель. Пока в моем скрине это ";". В документациях западных написано что это символ SOH. Чтобы однозначно ответить на этот вопрос, я запустил прилагаемого клиента биржи и сниффером стал перехватывать сообщения между клиентом и биржей. Кстати, программа ведет логи, и их общение выглядит так (зеленое — передача запроса на биржу, красное — ответ от биржи):

     Зачеркнул свой идентификатор, прошу понять правильно. Ну а перехват сообщения выглядит так:
     Зеленым я отметил именно разделители. Как вы уже видите, это просто в шестнадцатеричном виде код 01. То есть, в нашу строку в виде разделителей, нужно вставлять код 01. Также я отметил для себя последовательность полей в сообщении. Почему то в другом порядке у меня вызывало ошибки (возможно тут я не прав)
     Ну и контрольная сумма. Контрольная сумма считается над всем сообщением, за исключением концовки. То есть в расчет берется только заголовок и само сообщение. Для этого, мы переводим каждый символ в его Ascii код и вычисляем их сумму. Полученную сумму делим по модулю 256. Это и будет контрольной суммой сообщения. При этом, значение должно быть трехзначным. Если мы получаем 2 знака, то подставляем 0 слева (например, если контрольная сумма = 68, то должны передать значении 068).

К бою. Начало программирования

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

• класс для работы с заголовками
• класс для работы с сообщением подключения к серверу (onLogon)
• класс для работы с концовкой

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


     Как видим, первый метод строит нужную строку из полей. Обратите внимание, там присутствует наш разделитель в виде спец символа \u0001. Второй метод вычисляет размер заголовка (чтобы потом высчитывать размер сообщения). Надо обратить внимание, что при передачи времени, миллисекунды должны указываться в трехзначном формате (даже если миллисекунды = 52, то передаем 052). Следующие классы строятся по аналогии.
Класс создания сообщения на подключение (инициализация сессии)

Класс создания концовки сообщения


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

//Получаем ip сервера
IPAddress ipAddr = IPAddress.Parse(server);
IPEndPoint ipEndPoint = new IPEndPoint(ipAddr, port);
//Создаем заголовк
HeaderMessage msHeader = new HeaderMessage
{
BeginString = «FIX.4.4»,
MsgType = «A», //Тип сообщения на установку сессии
SenderCompID = "",
TargetCompID = «FG»,
MsgSeqNum = 1
};
//Создаем сообщение на подключение onLogon
LogonMessage msLogon = new LogonMessage
{
EncryptMethod = 0,
HeartBtInt = 3000,
ResetSeqNumFlag = true
};

//Вычисляем длину сообщения
msHeader.BodyLength = msHeader.GetHeaderSize() + msLogon.GetMessageSize();
//Создаем концовку сообщения
TrailerMessage msTrailer = new TrailerMessage(msHeader.ToString() + msLogon.ToString());

//Формируем полное готовое сообщение
string fullMessage = msHeader.ToString() + msLogon.ToString() + msTrailer.ToString();
Console.WriteLine(«Сообщение для отправки {0}»,fullMessage);

//Создаем сокет для подключения
sSender = new Socket(ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
//Подключаемся
sSender.Connect(ipEndPoint);
Console.WriteLine(«Сокет соединился с {0} », sSender.RemoteEndPoint.ToString());

byte[] msg = Encoding.UTF8.GetBytes(fullMessage);
//Отправляем сообщение
int bytesSent = sSender.Send(msg);
Console.WriteLine(«Отправил {0} байт», bytesSent.ToString());

//Получаем ответ от сервера
byte[] bytes = new byte[1024];
int bytesRec = 0;
bytesRec = sSender.Receive(bytes);
Console.WriteLine(«Ответ от сервера: {0}», Encoding.UTF8.GetString(bytes, 0, bytesRec));

Все таки приложу и в виде картинок. Так наглядней. Кликабельно.


В результате мы запросили у сервера подключение с нашим логином. И получили от него ответ.

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

Продолжение Изучаю FIX протокол с нуля. Рисуем и программируем дальше.

Всегда мечтал уметь программировать. Вот начал самостоятельно изучать Computer Science и Python Programming, имея сугубо финансово-экономический бэкграунд, но будучи гиком в душе.

Изучаю Python в контексте инструментария для применения в Data Science и далее в Machine Learning. Навыков программирования до этого не имел, если не считать работу со сложными связанными таблицами excel.

Начал с самого базового курса "Основы программирования на Python", книги Марка Лутца «Изучаем Python» и тренинга Python Essentials от Enthought, Inc. И официальные инструкции поглядываю: The Python Tutorial.

Также обучаюсь на курсах:

• массачусетского технологического института (MIT) MITx: 6.00.1x Introduction to Computer Science and Programming Using Python на 

( Читать дальше )

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

Моя философия трейдинга заключается в том, что деньги всегда должны быть под рукой. Фактически, это означает, что основной целью является плавная эквити. То есть всякие там психологии, дисциплины и крепкие фаберже с высиживанием просадок--это не мое. Кстати, плавная эквити может быть напрямую преобразована в доходность путем использования плечей--так что плавная эквити хороша также и с точки зрения доходности. Очень мощным средством повысить плавность эквити является одновременная работа многих систем. Почему так, с математической точки зрения описано здесь: http://utkin.2stocks.ru/?p=232 . Это значит, что нужно много идей, много реализаций одной и той же идеи. А значит, процесс генерации идей и систем фактически непрерывен.

( Читать дальше )

Знакомый показал такую среду www.quantopian.com/home
которая позволяет:

* закодировать и протестировать простейшие идеи на языке Python (один из самых популярных и простейших языков) прямо в браузере
* дает бесплатный доступ к данным за 13 лет (похоже в основном американский рынок?)
* обеспечивает среду для исследований (можно строить графики корреляций, спредов для парной торговли и т.п.)
* участвовать в конкурсе и получить деньги в управление

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

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

1. Наша экспирация позже их заморской экспирации. Отсюда первое извращение — их контракт прекратит свою жизнь сегодня в 19-30 по Лондону, а наш только в понедельник в вечерний клиринг. У вас осталось всего 6 часов на всё-про-всё, на движуху.

2. Второе извращение, вытекающее из первого — уже сегодня в вышеупомянутое время 19-30 по Лондону (22-30 по Москве) наш старый контракт полностью потеряет ценовой ориентир, т.к. их старый контракт будет остановлен.

3. Расчётная цена нашей экспирации равна значению биндекса (BINDEX, The ICE Brent Index). Эту хрень вы в стаканах не найдёте, значение публикуется в 12-00 по Лондону (в 15-00 по Москве) на следующий день, для нынешней экспиры это стало быть понедельник. Сейчас сайт выглядит так, в понедельник появится строчка

( Читать дальше )

 Строим портфель с максимальной доходностью и гладкой эквити!


( Читать дальше )

В пятницу случайно попал на одно мероприятие, где выступал молодой талантливый и очень интересный парень Ярослав. Я впервые встретил случай, чтобы супер-компетентный человек из индустрии алго и hft трейдинга совершенно свободно рассказывал о том, что он делает. К счастью, он согласился выступить и на конференции смартлаба, чему я несказанно рад! Что интересно, он торгует именно зарубежные рынки и даже никогда не торговал Россию.

Вот некоторые тезисы из того, что он сказал:

• все hft делают примерно одно и то же
• используют примерно 4 типа предикторов
• в торговле hft все просто, не надо ничего придумывать, все и так известно
• но при этом, если я вам расскажу всё, вы не сможете это повторить
• этот бизнес становится сложнее с каждым годом, конкуренция растет
• начать свой hft бизнес сейчас нереально, разве что только если сосредоточиться на низкочастотном трейдинге. Это доступно даже людям со средними способностями.
• знания ничего не значат, куда важнее каким обраом человек мыслит
• единственный шанс закрепиться в индустрии — это попасть junior quant'ом в алго-команду.
• научить торговать человека руками безумно сложно

HFT стратегии условно можно разделить на три:

• давление книги (book pressure) — анализ стакана по сути
• давление трейдов (trade pressure) — анализ истории всех сделок
• и относительное значение (trade pressure) — анализ корреляций

В общем, все детали на конфе смартлаба!

https://market.smart-lab.ru/confa/ 

Многие, кто не читал книгу Ларри «Долгосрочные секреты краткосрочной торговли» и не внимательно смотрел на картинку в предыдущем ларри-посте, задавали вопрос про то, как строится система по определению минимумов и максимумов. Специально для них, отдельным постом с примером.

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

• локальный максимум, это бар который имет два соседних с максимумами ниже
• локальный минимум, это бар который имет два соседних с минимумами выше

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

В этом случае получается:

• краткосрочный максимум, это локальный максимум который имеет два соседних ниже
• краткосрочный минимум, это локальный минимум который имеет два соседних выше

… и дальше по иерархии

( Читать дальше )

В своем прошлом посте я обещал раскрыть алгоритм robot_uralpro (25 место ЛЧИ 2010, HFT), но получил в личку много просьб от читателей смарт-лаба ( видимо тех, кто занимается алгоритмической торговлей) этого не делать. Аргументация, в общем, сводилась к тому, что народ у нас достаточно образованный и этим разоблачением алгоритма я могу наплодить армию конкурентов для  роботорговцев. И это правда -  например, когда в 2009 году начинал разработку стратегий, я вообще не знал ничего о том, как работают HFT, но, шаг за шагом, в условиях почти нулевой информации, удалось создать прибыльный алгоритм. Тем не менее, свои обещания надо выполнять, поэтому я принял решение, которое позволит трейдерам, серьезно интересующимся высокочастотной торговлей, получить обещанное, и даже больше, но в то же время значительно ограничит распространение: я предоставлю не только описание алгоритма, но и сам исходный код робота на C# с подробными комментариями точно в том виде, в котором он работал на ЛЧИ 2010, но все это — не бесплатно .  Далее причины, почему покупать это не нужно:

( Читать дальше )