Вступление

     Никогда не увлекался скоростным трейдингом. Всегда хватало терминала. Изучать этот протокол меня побудил набор вакансий. Надо отметить, что я неспешно перебираю хорошие вакансии на рынке. Частному трейдеру очень сложно развиваться в одиночку — психологически, эмоционально, физически. Создавать и развиваться постоянно хочется, поэтому принял решение вливаться в коллектив. За несколько месяцев, мне удалось провести несколько собеседований. На втором этапе я проваливался именно из за не знаний протокола.  Предметную область я примерно представлял. Ну что там сложного? Соединился с биржей по сокетам и начинай обмен сообщениями. Надо отметить, что в этой области есть уже готовые разработки в виде 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 протокол с нуля. Рисуем и программируем дальше.

1. С деньгами не так хорошо, как без них плохо.
2. Адам — первый счастливчик, потому что не имел тёщи.
3. Если проблему можно решить за деньги, это не проблема, это расходы.
4. Бог дал человеку два уха и один рот, чтобы он больше слушал и меньше говорил.
5. Да убережет тебя Бог от дурных женщин, от хороших спасайся сам!
6. Вошло вино — вышла тайна.
7. Бог не может быть везде одновременно — поэтому он создал матерей.
8. Не будь сладок — иначе тебя съедят. Не будь горек — иначе тебя выплюнут.
9. Бойся козла спереди, коня — сзади, дурака — со всех сторон.
10. Гость и рыба через три дня начинают попахивать.


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

На вид стандартный кластерный график, если не считать двух строк красной и зелёной. На мой взгляд если реализовать этот “индикатор” то можно существенно облегчить понимание рынка.

Что они означают: Какое кол-во контрактов было открыто/закрыто при исполнение сделки либо в аск, либо в бид.

Детально: допустим инициатор покупки кидает купить 500 контрактов по рынку, идентифицировать его можно уже давно открывает он или закрывает позицию через “умные ленты”, но когда проходит за минуту или за пять минут большое кол-во сделок “интересными” сайзами, то  понимание кто что делал через “умную ленту” очень тяжело, так как картина замылена и спроецировать на график что делали сайзы от 500 контрактов практически не реально.

А ЭТОТ ИНДИКАТОР СМОЖЕТ ПОКАЗАТЬ КОГДА,  ГДЕ, КТО ЧТО ДЕЛАЛ!!!

Можно придумать массу фильтров, где просто как на ладони будет видна картина происходящего.

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

А если он сделает дело? По крайней мере в части данного обсуждения Саакашвили прав.

Второе выступление: «Улыбка волатильности. Мифы и реальность». Лекция Владимира Твардовского, Ай Ти Инвест

Всем привет. 

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

    Идея — анализировать не цену инструмента, а таблицу всех сделок. Получаем ОПЕРЕЖАЮЩИЙ ИНДИКАТОР.
 
Рассмотрим таблицу всех сделок для RIZ4

 

Непрерывно суммируем количество всех новых сделок — если сделка КУПЛЯ — то прибавляем, если ПРОДАЖА — то вычитаем.
В итоге получаем график дельты. И его отличие от графика цены в том, что он более сглажен, и двигается он с небольшим опережением к графику цены, что позволяет наложив на него простой индикатор тренда всегда предсказывать движения цены заранее.

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

       3 года я торговал на домашнем компе под Тслабом. Комп домашний на i7, 2 винта по тетрабайту упакованы в аппаратный рейд, бесперебойник на три часа, винда7.
 
       Все было ОК. Использовал бесплатный АммиАдмин для удаленного доступа. Уезжал два-три раза в год по месяцу в отпуска, все было ок. Два-три раза в день зайдешь удаленно на домашний комп, посмотришь все ли в порядке. Проблемы были но где то раз в 20-30 дней на несколько часов. Обычно подвисал смартком — делал удаленную перезагрузку компа, и все начинало работать снова. Крайне редко не работала служба аммиадмина час-два.
 
       Только в последние три месяца стал пользоваться крайне удобной фичей тслаба для удаленной торговли — называется менеджер уведомлений. Вообщем настраиваешь этот менеджер уведомлений и нужные системные сообщения идут на емайл. Например скрипт пересчитан, смартком отвалился, связь потеряна с сервером брокера и прочие нужные сообщения. Сейчас если все в порядке, раз в 15 мин мне приходит письмо что все ок скрипт пересчитан. На мобиле у меня стоит майл ру агент. Смотрю в мобилу, когда хочу посмотреть все ли в порядке с сервером. Крайне удобно.
 


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

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

Краткая и лаконичная суть теории Блэка и Шоулса изложена здесь: http://anatoly-utkin.livejournal.com/2835.html . Ничего сложного в ней нет, это просто теория эффективного рынка в применении к опционам, не более. В настоящей заметке я хотел бы привести некоторые быстрые расчетные методы для работы с формулой Блэка-Шоулса, позволяющие быстро находить цены опционов и IV.


Итак, формула Блэка-Шоулса имеет вид: C=KN(d1)-SN(d2)  ( Wikipedia ). Первое, что тут есть из нетривиального--это функция N(x)--функция нормального распределения. В трейдерской тусовке модно аппроксимировать N(x) полиномом, однако мне это режет глаз, поскольку при этом не выполнено экспоненциальное стремление N(x) к единице на плюс бесконечности и к нулю на минус бесконечности. Поэтому такая метода мне абсолютно не нравится.


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

 
Не спится. Обратный календарь.
 
Актуальные опционные стратегии
 
Зарабатываем на временном распаде со страховкой
 
Движение улыбки волатильности
 
Что такое рыночная улыбка волатильности?
 
Об оценке будущей волатильности
 
Улыбка волатильности
 
Как считать время до экспирации?
 
Многомерная торговля


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

Какие дни использовать в расчетах — календарные или рабочие? В пользу первого метода говорит тот факт, что биржа считает время как точное время до экспирации. Этот метод прост и понятен. В пользу второго метода свидетельствуют провалы волатильности перед выходными и праздниками.
 
Иногда используется третий метод – учет выходных и праздничных дней с некоторым весом (периодом времени). Возможно, этот способ наиболее правильный, ведь на выходных в мире часто происходят события, влияющие на рынок. Но возникает вопрос: как вычислить вес нерабочих дней? Если в данные выходные ожидается конкретное событие, оценить его можно по влиянию на рынок во время аналогичных событий в прошлом. Такой подход требует внимательного исследования влияния конкретных событий, и дальше его рассматривать не будем. Далее будем искать вес «средних» выходных без учета событий в эти дни.
 
Чтобы найти вес периода времени, можно сравнить волатильность базового актива в этот периода с волатильностью этого актива в стандартный период времени. Волатильность измерим через HV: стандартное отклонение (выборочное СКО) логарифмов отношений цены актива.


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