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

 

Голубые фишки, или blue chips, давшие название формату моего биржевого контента, — это наиболее высоконадежные и ликвидные акции первого эшелона российского фондового рынка.

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

1. Высокая ликвидность – то есть возможность купить или продать большой объем со среднестатистическим (прогнозируемым) отклонением от текущей цены;

2. Плотная (повышенная) проторгованность/повторяемость ценовых диапазонов, небольшой спред между текущими ценами спроса и предложения;

3. Адекватная и взвешенная реакция на внешний фон;

4. Статистически-устойчивые и умеренные амплитуды/размахи ценовых колебаний на всех основных торговых периодах (таймфреймах);

5. Статистически-устойчивые высокие торговые объемы/обороты в каждом из основных таймфреймов;

6. Взаимные корреляции;

7. Прогнозируемая корпоративная отчетность;

8. Устойчивые выплаты дивидендов.

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

Месяц назад я написал пост Робот ContanGO! smart-lab.ru/blog/385513.php
В нём был изложен черновик торговой идеи. Между фьючерсом и акцией всегда есть разница в цене. Обычно фьючерс дороже акции. Это называется контанго. Контанго всё время меняется. Оно то больше, то меньше. С каждым днём контанго распадается и стремится к нулю. Контанго достигает нуля к дате экспирации.
Робот, выложенный в первом посте, был первым наброском. Он многое не учитывал. С тех пор он стал умнее, я полностью переписал код и обогатил его новыми аналитическими элементами.
1. Теперь роботу не нужно задавать код фьючерса. Он сам возьмёт новый список фьючерсов, когда до экспирации останется 5 дней.
2. Робот умеет учитывать то, что часть денег морозится во фьючерсах, заблокированная под ГО. Он уменьшает доходность на размер замороженных денег.
3. Робот учитывает комиссию биржи автоматически (ничего писать не нужно)
4. Робот учитывает комиссию брокера. Задаётся пользователем в файле ContanGO.lua
5. Робот вычитает из доходности налог НДФЛ 13%
6. Если вы знаете что делаете, вы можете вписать размер дивиденда по каждой акции. Вписав дивиденд, вы поднимете доходность до справедливого значения. Дивиденд считается с налогом 13%. После среза реестра дивиденд нужно обнулить

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

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

Другое дело муниципальные облигации (не путать с ОФЗ). Сейчас на ММВБ торгуется примерно 110 выпусков, эмитентами которых выступают практически все субъекты РФ. Если инвестор желает получать доходность на уровне банковских депозитов, то ему достаточно весь свой капитал «размазать» равномерно по всем выпускам, ликвидности для этого обычно хватает и в течение недели можно легко собрать даже очень крупный портфель.

Что же интересного в таком виде заработка?

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

Выплаты купонов происходят практически ежедневно — это бурлящий поток заработанных рублей!

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

В последнее время, Московская биржа на всех встречах и форумах призывает быстренько становиться маркет мейкерами на опционном рынке. Это зашло так далеко, что знакомые, далекие от биржи, начали спрашивать: «Как это?». Однако, на мой вопрос: «Покажите бизнес план» ни Илья Бутурлин ни прочие представители биржи, ни чего конкретного сказать не могли. Пришлось самому садиться и разбираться в этом вопросе. Возможно, где то, что то я не понял или пропустил, поэтому прошу уважаемое сообщество помочь мне. Указать на ошибки или сделать дополнение.

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

Затратная часть: Штат из трех человек. Директор, он же все остальное, включая уборку помещения с окладом «как повезет», ITшник друг директора, готовый терпеть пока «все получится». Приходящий бухгалтер. Либо жена друга, либо 30 тысяч в месяц. Подключение по Плазе 15 тысяч. Аренда помещения, ну это от города зависит. Можно и дома. Лучше, в Ленинской библиотеке, там можно через дорогу перейти и спросить, почему снова торги остановились. По кругу берем затрат 50 тысяч.

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

Вступление

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

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

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

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

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

На срочном рынке FOTRS у любого фьючерса есть три главных характеристики!

1. Гарантийное обеспечние (ГО) — это залог который берет биржа за еденицу контракта.

2. Шаг цены (тик) — это минимальное возможное изменение цены контракта. 

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

Вот параметры некоторых фьючерсных контрактов на текущий момент после дневного (пром) клиринга:

1. РТС: шаг-10 пунктов, стоимость шага-11,36660 рубля
2. Д/Р: шаг-1 пункт, стоимость шага-1 рубль
3. ММВБ: шаг-25 пунктов, стоимость 25 рублей
4. Брент: шаг-0,01 пункта, стоимость-5,68330 рублей

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

                При данном исследовании было потрачено немало труда, поэтому ссылка на автора при перепечатке обязательна. © Simix.
                Сразу скажу что расчёт ГО тема скользкая, т.к. представляет собой величину умозрительную — риск. Есть люди, которые прыгают с парашютом для развлечения, а я считаю что этот риск слишком велик чтобы прыгать без необходимости. То есть риск зависит от того, кто смотрит.  Если бы мы все знали реальные риски той или иной ситуации, то была бы не жизнь, а красота. Поэтому ровно такое же ГО как в QUIKе вы не получите никаким оффлайновым алгоритмом. Биржа имеет насчёт ГО свои взгляды, собственные поправочные коэффициенты и собственный модуль, который работает только с подключением к бирже.
Но посчитать ГО в оффлайне всё-таки можно.
Чтобы как-то ограничить и описать риск  количественно, биржа вводит ряд предположений и условий, а также приводит открытую методику которыми мы и воспользуемся:


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