Начало здесь: smart-lab.ru/blog/474365.php

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

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

Основное отличие от стандартного метода оценки стоимости опционов является утверждение:

Цену опциона можно рассчитывать исходя из показателей волатильности, не привязанной в процентном отношении к цене базового актива. В моем случае волатильность измеряется пунктах индикатора ATR(Н1).

За исходные данные берется цена опциона на центральном страйке (стредл на центральном страйке). Получить ее можно опираясь на историческую волатильность (описано в 1 части), или просто взяв текущие значения из таблицы опционов, опираясь на ожидаемую волатильность.

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

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

Чтобы иметь меньше параметров, «избавимся» от дельты и от всяких рассуждений «что куда пойдет и на сколько процентов». Рассмотрим самую простую дельтанейтральную позицию  -стредл.

 Проданный стредл или купленный  это не важно. Будем пытаться его дельтанейтралить. Если не вдаваться в подробности формул, а выделить основное свойство такого действия, то результат будет зависеть от того расстояния, которое «набегает» нам цена базового актива. Тут появляется один важный момент: Расстояние пробегаемое базовым активом можно выразить через волатильность базового актива в процентах, но можно этого не делать. Можно использовать непосредственно «длину пробега» для оценки стоимости опциона.

 

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

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

Два свежих примера.
Допустим, мы купили (продали) стрэддл Ri на центральном страйке 3 месяца назад, затем рехеджили его с разными шагами (по БА). Тогда зависимость реализованной в результате волатильности от шага рехеджа выглядит так:


Мелкий шаг рехеджа «отбил» бы нам покупку стрэддла примерно по 19% IV, но шаг в 13000 пунктов реализовал бы уже IV около 40%.

Точно такой же пример, но со стрэддлом полуторамесячной давности дает следующую картинку:

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

Я не буду рассказывать, что такое опцион (ну, типа, «это контракт, дающий покупателю право, но не обязанность бла-бла-бла»), надеюсь все интересующиеся знают, или слышали, или могут в Вики посмотреть. Сразу покажу, как определяется его цена. Да, еще 2 замечания. Я говорил, что нам не понадобится математика уровня выше 9-го класса школы — извините, соврал. :) Но 11-классник уже справится. И второе: вы не научитесь торговать опционами по этим заметкам, придется читать книжки.

Представим очень простую (скажем прямо — примитивную) модель изменения цены акции. Каждый день цена акции может измениться только на 1 рубль, вверх или вниз. Вот так:

И мы хотим купить опцион колл с ценой исполнения (страйком) 100. Как понять, сколько нам платить продавцу, чтобы цена была «справедливой»?

1. Максимальная прибыль в этой модели (которая на картинке) — 6 рублей. Дороже 5.99 рублей покупать смысла точно нет.
2. За 0 рублей нам его тоже не продадут.

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

Вступление

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

Первая часть лежит тут… smart-lab.ru/blog/155810.php… думал частично переписать, но решил просто добавить...

 

            1 Основа торговли

            Трейдинг — это прогнозирование будущих цен и торговля этого прогноза с целью извлечения прибыли.

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

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

 

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

Продолжаем выкладывать фотографии с опционной конференции, которая прошла в Стрельне 6 июня!

Десерты на конференции — объедение!


Сергей Замолоцких и Григорий Фишман: 
 
Роман Вишневский (United Traders) и Владимир Твардовский (Финам)
 
Алексей Каленкович
 

Тимофей Мартынов о чем-то думает

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

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

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

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

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



Гном. Или как трейдер обанкротил банк.

Глава первая и вторая

Глава третья и четвертая

Глава пятая и шестая


Гном 2. Возвращение.

Глава первая

Глава вторая и третья

Глава четвертая и пятая

Глава шестая и седьмая

Глава восьмая и девятая 

Глава десятая, одиннадцатая и двенадцатая.



Просто про опционы.

Вместо предисловия

Глава первая

Глава вторая

Глава третья

Глава 3 1/2

Глава четвертая

Глава пятая

Глава 5 1/2

Глава шестая

Глава седьмая


Не окончена...
 


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


Глава первая

Глава вторая

Глава третья

Глава четвертая

Глава  4 1/2 и пятая

Глава шестая  

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


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