И снова всем добрый день! Ко мне за последнее время поступило много вопросов — сколько времени уходит на то, чтобы вернуть часть полученного убытка по операциям с ценными бумагами и финансовыми инструментами срочных сделок.

Срок для возврата денег (сальдирования убытков) составляет всего четыре месяца. В этот срок включается:

1. Срок для проведения проверки документов (декларации 3-НДФЛ, справок от брокера) составляет три месяца.

2. Срок для возврата налога после проведенной проверки — один месяц. Но тут надо помнить, что вместе с пакетом документов для получения налогового вычета по НДФЛ надо обязательно написать и сдать заявление на возврат налога. В этом заявлении вы пишите сумму налога к возврату, ваши реквизиты счета. Если такое заявление не поступит налоговикам, вам деньги не вернут.

Приведу такой пример: вы 14 марта подали декларацию 3-НДФЛ на возврат налога, дата заявления на возврат денег тоже идет от 14 марта. Так вот, до 14 июля вам (если с документами все хорошо и декларация составлена верно) вернут денежные средства.

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

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

Продолжаю серию статей. Начало тут http://smart-lab.ru/blog/310895.php

Итак, у нас имеется история в виде набора упорядоченных по времени тиков, но используем мы только данные цены. Перед началом проведем подготовку данных (как я называю «упаковку тиков»). Например, есть исторический отрезок со следующими данными (окончание сессии от 12.02.2016 по ESH16):

Как мы видим множество соседних тиков, имеют одинаковое значение цены, что создает «избыточность данных». Если мы оставим только те последовательные тики, цена которых отличается от предыдущего, то количество данных ощутимо сократиться:

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

Итак, данные подготовлены и можно приступить к «описанию и поиску простейших паттернов» (этот блок служит для ввода в курс дела, а не отражает практический способ). Например, имеется некоторый паттерн, представленный на следующем рисунке:

Паттерн выделен оранжевым цветом. Какая особенность алгоритма необходима для его выявления? Это то, что он должен искать паттерн при поступлении каждой порции данных. Паттерн может начаться с любого тика, и закончится на любом. Т.е. поиск в данном случае будет представлять «трафарет»:

Подставляемый для каждого тика в последовательности, и при совпадении с которым паттерн считается «опознанным» (Т.е. трафарет как-бы скользящий).

Представленный пример достаточно сильно утрирован, в реальности трафарет не столь «жёсткий» и возможно бы включал в себя и следующие представления:

P.P.S

Формирование следующих статей цикла будет производиться по мере наличия времени и желания ;)

Всем успехов в торговле! 

Вступление

Технические аспекты протокола

• <Заголовок сообщения>
• <Сообщение>
• <Концовка сообщения>

• <Начало сообщения, версия протокола>
• <Длина (размер) сообщения>
• <Тип сообщения>
• <Идентификатор отправителя>
• <Идентификатор получателя>
• <Номер сообщения>
• <Время отправки>

• <Контрольная сумма сообщения>

• 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, длину сообщения нужно считать без учета концовки и первых двух полей заголовка. А именно:

К бою. Начало программирования

• класс для работы с заголовками
• класс для работы с сообщением подключения к серверу (onLogon)
• класс для работы с концовкой

//Получаем 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));

Торговые правила