Мы смотрели на кучу распределения и думали, как из нее сетку ордеров построить.  Для этого нам надо построить функцию. Это такой график. Есть три способа его построить. Первый описан здесь http://mathprofi.ru/funkcia_raspredeleniya_dsv.html. Второй я описывал в своих топиках и выкладывал экселовские файлы. Мы будем использовать самый гениальный, третий способ. Так как мы уже договорились и поняли, что все распределение учтено улыбками, то мы можем взять любую опционную программу и построить график. Я воспользуюсь smart-lab.ru/blog/388853.php  от FateevVV (за что ему отдельное спасибо)

 
Для этого надо записать на ЦС две позиции, проданный колл и проданный пут по 100 штук и выбрать на графике «Дельта». По горизонтальной оси у нас цена БА. А по вертикали как раз то, что мы искали. Так видно, при цене 110000 у нас сработает 20й sell limit. Что тут главное, что надо заметить. Если взять интервал 2500 пунктов от текущей 112500 то ставится 30 ордеров. А между 105000 и 102500 только 10 ордеров. От 107500 до 105000 будет 20 ордеров. Думаю, вас в школе учили про абсциссы и ординаты. Что тут еще интересно. Я не буду загаживать топик скриншотами, просто поверьте или скачайте программу, прикрутите к Квику и проверьте. При изменении волатильности, времени, улыбки, дельта тоже будет меняться. За десять дней до экспирации от 112500 до 110000 потребуется 60 ордеров в сетке. А между 105000 и 102500 только два.

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

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

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

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

Профиль волатильности. Есть такой зверь и он не может не есть. Что бы его поймать, мы вернемся к нашей стратегии лимитных заявок. Если вы видели гениальный биржевой график (а они все гениальные, потому что простые), то должны были заметить, что там цена ходит не просто вверх вниз, но и еще направо (на лево не ходит). Это должно было натолкнуть вас на мысль, что в торговле и торговой системе должно присутствовать время. Вход в рынок и выход из него должен происходить с учетом того, сколько времени вы там будите. Когда вы интересуетесь свой зарплатой или зарплатой соседа, вам важно как часто такая зарплата платится. В нашей ТС мы смотрим на стодневную свечу. Это значит, что торгуем мы сто дней и рассчитываем свою зарплату за 100 дней. И если с этим ни кто спорить не будет, вернемся к распределению случайностей. Помните, мы брали сто свечей и строили колокол. Но вот проходит 50 дней, мы откидываем 50 свечей и наш колокол становиться уже. И если наша сигма за сто дней была 10% (отклонение от цены БА +-)  то через 50 дней (остается еще 50 дней) наша сигма уже 7,5%, а через 99 дней она будет 1%. Допустим, по нашей ТС с лимитками мы определились работать в рамках одной сигмы. Сто дней 10% делим на 100 ордеров, шаг сетки у нас 0,1%. Проходит 50 дней и шаг сетки 0,75%, а на 99 день 0,01%. Но, если ставить отложки через каждые 100 рублей это куда не шло. А вот через каждый рубель, тут уже очко жим жим. Нам такой скальпинг не нужен. Если цена пройдет больше процента в день? Без отката. И как говорилось выше про очко, а оно не железное, его надо укрепить. Например, вставить бронзовую втулку.  И естественной бронзовой втулкой является сетка поширше или пошерее. Но тем самым мы расширяем наш колокол распределения и увеличиваем нашу IV. И тут возникает такой эффект, как горизонтальная волатильность.

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

Наиболее отдаренные Гении уже поняли, в чем заключается торговля в спреде. Цена в стодневной свече заполняется однодневными, часовыми, минутными. Цена ходит вверх вниз, а мы лимитки выставляем. В начали стратегии мы можем предполагать или прогнозировать какой будет следующая 100 дневная свеча. Для этого нам надо понимать историческую волатильнось HV. Если вы посмотрите на график, хотя что я говорю, у вас график на правом мониторе, в телефоне, в планшете, только что не сниться, то должны заметить, что свечи примерно одинаковые. (смотрите дневные). И если они начинают меняться по величине, то можно заметить некоторые тенденции. Еще лучше, если вы поставите индикатор, измеряющий волатильность или ATR какой ни будь. И так как волатильнось параметр медленный, то вполне прогнозируемый. Другими словами, величину следующей свечки можно угадывать.

Этот наш прогноз может не совпасть с реальностью. Свечка оказалась меньше, тогда нам плюс, потому что в этой стратегии мы продаем волатильность. Свечка оказалась больше, тогда нам может не хватить ГО. Мы будем закрывать убыточные позиции (на сленге опционщиков это называется роллированием). Но наша статистика одной сигмы в 68%, что свеча будет меньше или такой же. Ну а кому этого мало возьмите 2 сигмы. В общем, ни чего тут сложного нет, это обычная стратегия маркет мейкара по поддержанию двухсторонних котировок. И она рабочая. (не взирая на комиссии). Ну и там существуют методы управления позицией. Волатильность меняется от малых ТФ к большим. Вы можете менять спред, добавлять ГО.

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

Что бы картину сложить, надо кое что понять. Я снова про волатильность. Что она представляет из себя, с точки зрения науки. Вот перед вами график. Дневной в 100 свечей. Давайте возьмем и снимем с него все свечи или бары. Положим их на стол (свечи) и перемешаем. Теперь нам надо взять штангельциркуль и измерить все эти свечки. Можно в сантиметрах и найти среднюю величину. Допустим 2 см. Теперь смотрим 2 см для БА это сколько в % и переводим в проценты.

Опытный Гений может просто прищуриться и прикинуть величину свечек на графике и назвать волатильность в годовых. Нам же надо, пока, понять, почему мы берем свечи, а не движение цены, уровни, стохастики и машки. И для этого мы, все таки перейдем к процентам и закономерностям.

Итак. Вола у нас измеряется в годовых. И если мы говорим про годовую волу, то это величина годовой свечи. То есть мы берем цену открытия и умножаем на 30% (условная волатильность для примера) = величина свечи в деньгах относительно цены открытия. Но нас интересует не один раз в год поторговать. Может быть, я удивлю. Но, зная какая у нас годовая свеча, можно с определенной точностью вычислить часовую и даже минутную. И наоборот, имея часовые свечи, можно вычислить какой будет годовая свеча. Для этого надо правильно перевести годовую свечу в часовую. И переводится это через корень из времени из Пьяного Матроса Алберта Энштейна. Я не раз об этом писал, не буду повторяться.

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

В самый разгар периода выхода отчетностей российских эмитентов, хочу предоставить Вам к прочтению статью, в которой выделяются основные отличия отчетности РСБУ от МСФО, в чем же их принципиальное отличие, и почему инвесторы отдают предпочтение именно этим стандартам. 

Цели

В первую очередь эти два стандарта различаются по целям предоставления информации. Отчетность по МСФО больше используется инвесторами и кредиторами для принятия инвестиционных решений. Тогда как РСБУ предназначен для предоставления информации контролирующим и налоговым органам.

Форма и содержание

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

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

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


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

Я пишу финансовые чипсы (novice_chips) для новичков, они пользуются вниманием, более сложный материал я излагаю в fin_chips (более 100 штук), торговые приемы и нюансы, к которым можно прийти за 3-5 лет торговли.

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

 

ПРАКТИЧЕСКИЕ НЮАНСЫ ТОРГОВЛИ:
ИЗМЕНЕНИЕ СУММАРНОГО СПРОСА И ПРЕДЛОЖЕНИЯ КАК  ПОДСКАЗКА О НАПРАВЛЕНИИ БУДУЩЕГО ДВИЖЕНИЯ И СМЕНЫ ТЕНДЕНЦИИ.

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

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

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

Вступление

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