Посчитал на R спред между акциями Google и Apple с учётом соотношения (hedge ratio). И нанёс среднюю линию с двумя среднеквадратичными отклонениями сверху и снизу. Красота. 



Делается на R это очень просто, код ниже. 

require(quantmod)
> startT <- «2015-01-01»
> endT <- «2016-01-01»
> rangeT <- paste(startT, "::", endT, sep="")
> symbols <- c(«AAPL», «GOOG»)
> getSymbols(symbols)
[1] «AAPL» «GOOG»
> tGOOG <- GOOG[,6][rangeT]
> pdtGOOG <- diff(tGOOG)[-1]
> tAAPL <- AAPL[,6][rangeT]
> pdtAAPL <- diff(tAAPL)[-1]
> model <- lm(pdtAAPL ~ pdtGOOG)
> hr <- as.numeric(model$coefficients[1])
> spreadT <- tAAPL — hr * tGOOG
> meanT <- as.numeric(mean(spreadT, na.rm=TRUE))
> sdT <- as.numeric(sd(spreadT, na.rm=TRUE))
> par(mfrow = c(2,1))
> hist(spreadT, col=«blue», breaks = 100, main = «Spread Histogram (AAPL vs GOOG)»)
> plot(spreadT, main=«AAPL vs GOOG spread (in-sample period)»)
> abline(h = meanT, col = «red», lwd = 2)
> abline(h = meanT + 1 * sdT, col = «blue», lwd = 2)
> abline(h = meanT — 1 * sdT, col = «blue», lwd = 2)

Здесь: 

meanT — среднее
sdT — среднекв. отклонение
spreadT — спред
par — график с двумя секциями
plot — график
hist — гистограмма
abline — линия поверх графика
model — линейная зависимость модель, МНК
quantmod — библиотека для получения исторических данных
rangeT — временной диапазон

Хотите попросить сделать количественный анализ чего-нибудь? Пишите в личку или в комментариях.

Все мы знаем, на уровне здравого смысла, что опционы это круто. Особенно бинарные.
По заявлениям сектантов, познавший их внутреннюю нелинейную сущность уже никогда не станет прежним не вернется торговать линейными инструментами. Впрочем, по их словам, опционы — это добро и свет не только для избранных — любой дремучий аксакал торгующий по тренду уже сейчас может воспользоваться их благодатью.
Убедитесь сами — берем месячный RI OTM Call со страйком на расстоянии 10000 от текущей цены стоимостью ~500. Если фьюч делает +2500, опцион стоит уже ~1000 (профит +500). Если фьюч делает -2500, опцион стоит 250 (убыток -250). Можно и продолжить! В пределе, что бы цена ни вытворяла, наш убыток ограничен 500-ми, а профит вообще неограничен!.. правда опцион теряет в стоимости приметно 25 пунктов в день, но подобная фигня ведь никого не остановит, нэ?

Пытаемся придерживать раскатившуюся губу и думаем — как лучше воспользоваться этой благодатью в наших корыстных целях...
Самое простое(имхо) — взять замшелого трендового робота и заменить в нем покупку фьюча на покупку ОТМ опциона.
Теперь нужно прикинуть, какой страйк лучше покупать… ATM медленнее распадается, но обладает меньшим эффектом усиления плеча… дальние OTM наоборот — плечо усиливают хорошо, но распадаются быстрее.

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

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

Проверка Банка России, которая прошла в Консервативном коммерческом банке (ККБ), являющимся расчетным банком Webmoney, привела к проблемам у владельцев WMR.

Люди массово жалуются, что операции по пополнению привязанных карт и счетов недоступны, деньги вывести не получается. Юрики же не могут не только вывести, но и внести деньги.

Вот, что говорит пресс-служба.

По физикам:

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

По юрикам:

"Система WebMoney и ее сервисы функционируют в обычном режиме. 
По результатам плановой проверки Центробанк выдал ККБ, одному из расчетных банков в РФ, рекомендации по совершенствованию работы с инструментами WebMoney. 

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

Начало положено тут 
Продолжил тут
Затем тут

Обсуждения

     Сегодня будет без введения. Мои первые публикации вызвали небольшие обсуждения, как в комментариях, так и в личных беседах. Если классифицировать, то можно подвести некие итоги:

• занимаюсь ерундой, до меня уже давно все создано. Прежде чем, что либо начать, конечно же я изучаю положение дел. Я прекрасно изучил, что уже есть конкретные разработки. Но я уже говорил, что я готовлюсь к хорошим вакансиям и хочу знать досконально протокол. Человек я щепетильный, мне важно знать каждую мелочь. Другого метода изучения я не придумал. 
• мой код не оптимален. Хоть я и не услышал конкретные доводы, но все же склонен к такой мысли. Код только строится и конечно будет еще дорабатываться.
• выбрал не ту платформу. Тут самое интересное. Были интересные беседы. Но надо заметить. Я не отвечаю на позывы типа: «си ерунда, бери  то-то». Я считаю это не профессиональным. Но все же интересные моменты были. Итог:
    — Для скоростного трейдинга желательно уходить на Linux. Основной довод — несовершенство windows многозадачности. Лишним доказательством будет являться набор постоянных вакансий на рынке, где требуются именно Linux программисты. Также вы должны заметить, какое внимание Linux оказывается на будущей конференции алготрейдеров (27 февраля).
  — Желательное использование Си и Java. Ничего пока не могу сказать. Но стоит заметить, как и в беседах было подчеркнуто, так и в вакансиях на рынке, западные компании требуют именно java программисты. 
• в любом случае, направление движения изучения вырисовывается, за что, спасибо собеседникам
• в личных беседах я увидел заинтересованности в изучении протокола. Думаю статьи и дальше будут полезны. Литературы доступной с разжевыванием мало. А интерес смотрю есть.
• получил несколько предложений поработать вместе. Оказывается СЛ читают интересные люди. Это радует.

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

Начало положено тут
Продолжение тут

Вступление

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

Теоретически аспекты. Разложим немного по полочкам.

     Все сообщения протокола можно разложить на несколько тем. Я начну с первой группы:

1. Сообщения для поддержания связи.

• Logon; Тип=A; Сообщение для инициализации сессии. Грубо говоря для подключения к серверу
• Logout; Тип=5; Сообщение для завершения сессии. Сообщаем серверу о прекращении связи
• Hearbeat; Тип=0; Сообщение для поддержания связи. 
• Request; Тип=1; Сообщение для поддержания связи. Запрос второй стороны, жива ли первая
• Reject; Тип=3; Сообщение об ошибке. Получаем его, если мы не правильно оформили свое сообщение
• Resend Request; Тип=2; Повторный запрос сообщений, в случае утери. Задается интервал номеров сообщений.
• Sequence Reset; Тип=4; Используется для сброса номеров сообщений. 

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

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

Всем привет.

Решил выложить в открытый доступ базу данных тиков с CME, которая накапливалась за последние годы, и обновляется по итогу дня.

FTP доступ: 

85.25.211.62
login: smartlab
pass: smartlabpass

Ссылки на торрент: http://ge.tt/1Ql8j3Y2

№2: app.box.com/s/h0dhmkif0fhnvlpzdp8ma89c1ysv876t

Формат данных:

seconds (int32) — кол-во секунд с начала суток по Чикаго.
milliseconds (int32)
price (int32)
volume (int32)
bestBidPrice (sbyte) — расстояние в тиках между price и реальной ценой BidPrice
bestAskPrice (sbyte) - расстояние в тиках между price и реальной ценой AskPrice
bestBidSize (int32) — доступно с июня 2015
bestAskSize (int32) - доступно с июня 2015

Ниже код для чтения бинарных файлов (На C#).

Создаем класс Tick:

1. public class Tick
2. {
3. public DateTime Time { get; set; }
4. public int Price { get; set; }
5. public int Volume { get; set; }
6. public int BidPrice { get; set; }
7. public int AskPrice { get; set; }

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

Вступление

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

Представляю вашему вниманию библиотеку для работы с Quik из C#/F#/.NET — QuikSharp.

Последняя неделя показала, что мне нельзя торговать руками на такой волатильности, и заставила задуматься о более серьезном подходе к автоматизации. В итоге — пока нет доступа к Plaza, Fix и другим нормальным API — я набросал эту библиотеку.

Главная идея библиотеки — всё, что написано в руководстве к Луа работает из .NET без изменений интерфейса. Quik и Lua — недружественная территория по сравнению с .NET, хочется свести их использование к абсолютному минимуму.

Реализован и протестирован механизм обмена данными на основе TCP sockets. Ping/Pong roundtrip с Квиком занимает 190 микросекунд на моем компьютере. Также реализованы сервисные функции и несколько функций обратного вызова.

Установить библиотеку в свой .NET проект можно из NuGet. В проекте будет создана папка lua, из которой нужно запускать в Квике скрипт QuikSharp.lua.

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

Начало тут — http://smart-lab.ru/blog/130108.php
 
Грааль №5: Опционная система «Зиг заг удачи !!!»
 

 
На рынке регулярно случаются страшные обвалы и головокружительные взлеты индекса. Многие пытаются на этом заработать. Но не у многих это получается.
Как практически решить данную задачу?
Во-первых, сигналом для работы не должен быть общепринятый индикатор – RSI, ADX,  MACD, уровни Фиббоначи, и прочее;
Во-вторых, лучше использовать нелинейный инструмент – опцион, т.к. при использовании опционов для гораздо больше состояний рынка при котором будет прибыль, а также в случае ошибки в направлении – размер убытка значительно ниже размера прибыли, в этом и есть плюс нелинейности.
 
 
Сигнал для входа.

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