Tорговые роботы. Full Orders Log.
Atom
13.03.2012


Здравствуйте. В этой статье мы расскажем Вам, что такое Full orders log, как он выглядит, для чего используется, и какую интересную информацию можно в нем увидеть. Начнем с определения и общих понятий и свойств. После этого поговорим о том, как можно использовать ордер лог для создания торговых роботов.
Full orders log (в статье будем использовать сокращение FOL) — это список всех заявок с полной информацией по каждой заявке. Еще его называют анонимным ордер логом (анонимная рыночная информация), т.к. из всей информации о заявке в нем не доступен только номер счета клиента, пославшую эту заявку. Как вы понимаете, эта информация конфиденциальна. Ордер лог, это самый глубокий и детальный уровень информации, который доступен трейдеру.

Полный список полей таблицы orders_log


Поле Тип Описание

replID i8 Служебное поле подсистемы репликации

replRev i8 Служебное поле подсистемы репликации

replAct i8 Служебное поле подсистемы репликации

id_ord i8 Номер заявки

sess_id i4 Идентификатор торговой сессии

client_code c7 Код клиента

moment t Время изменения состояния заявки

status i4 Статус заявки

action i1 Действие с заявкой

isin_id i4 Уникальный числовой идентификатор инструмента

dir i1 Направление

price d16.5 Цена

amount i4 Количество в операции

amount_rest i4 Оставшееся количество в заявке

comment c20 Комментарий трейдера

hedge i1 Признак хеджевой заявки

trust i1 Признак заявки доверительного управления

ext_id i4 Внешний номер

login_from c20 Логин пользователя, поставившего заявку

broker_to c7 Код FORTS фирмы-адресата внесистемной заявки

broker_to_rts c7 Код RTS фирмы-адресата внесистемной заявки

date_exp t Дата истечения заявки

id_ord1 i8 Номер первой заявки

broker_from_rts c7 Код РТС клиента — владельца заявки

id_deal i8 Идентификатор сделки по данной записи журнала заявок

deal_price d16.5 Цена заключенной сделки

local_stamp t Локальное время пользователя


Онлайн данные по full_orders_log можно получать через шлюз Plaza2. До 17 февраля 2012 года по Plaza2 была доступна информация только по рынку ФОРТС, с 17 февраля Биржа ММВБ – РТС начала трансляцию анонимной рыночной информации по Валютному рынку и Фондовому рынку в секторе Основной рынок.
Таким образом, через шлюз Plaza II будет доступна информация по следующим рынкам:

  • Cрочный рынок FORTS

  • Фондовый рынок в Секторе рынка Standard

  • Валютный рынок в режиме РТС Money

  • Фондовый рынок в Секторе Основной рынок


Сохранять ордер лог, обрабатывать и создавать торговых роботов на его основе, вы можете с помощью библиотеки StockSharp. 11 марта StockSharp был сертифицирован биржей РТС для работы с Plaza II.

Файл с сохраненными данными FOL выглядит примерно следующим образом. Вид из FAR'a.
Tорговые роботы. Full Orders Log Рис.1
роботы

Формат данных может немного различаться, зависит от настроек программы, через которую вы его получаете, которая может трансформировать данные, для приведения их к более удобному виду. Например, в изначальном варианте инструменты обозначаются с помощью isin_id i4 Уникальный числовой идентификатор инструмента (8й столбец на картинке) Помимо ордер лога, по шлюзу Plaza2 передается и другая информация, среди которой fut_sess_contents, где мы можем посмотреть соответствие числовых идентификаторов названию контактов. Например, isin_id = 242176 будет соответствовать контракту RIH2. Таким образом, мы можем преобразовывать вид данных. В этой статье Вы столкнетесь с картинками, где они будут немного различаться.

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

Symbol – название инструмента = isin_id

Type – покупка/продажа = dir

ID - уникальный номер заявки = id_ord

Moment - время изменения состояния заявки = moment

Volume – количество лотов = amount

Price – цены по которой выставляли заявку = price

Action Действие с заявкой - выставление 1/удаление 0 /сделка 2 = action

ID_Deal - уникальный номер сделки = id_deal

Price_Deal – цена по которой прошла сделка = deal_price

В отформатированном виде ордер лог будет выглядеть примерно так.
Tорговые роботы. Full Orders Log Рис.2
роботы2

Как хранить и обрабатывать FOL

На данный момент (2012 год), файл с ордер логом с данными по всем инструментам срочного рынка весит порядка 4-5 гигабайт за один торговый день. По инструменту RTSi, порядка 1 гигабайта за один день. В одном дне RTSi содержится порядка 8-10 млн строк, из них сделок 600-800 тысяч строк.
1 гигабайт или 9млн строк за день, довольно внушительный объем данных. Поэтому появляется вопрос, как лучше работать с таким объемом данных? По сути, оредр лог представляет собой базу данных, поэтому для его обработки и хранения можно использовать программы для создания и хранения БД. С помощью языка SQL мы можем обрабатывать данные, выводить нужные нам информация и производить расчеты. SQL проще чем C#, т.к. имеет узкую специализацию, поэтому его легче освоить, но использовать его для других целей проблематично. Писать робота нужно на C#, для вспомогательных целей при работе с ордер логом использовать SQL.

Торговые роботы на основе ордер лога.

Как уже было сказано, создавать торговых роботов на основе ордер лог можно с помощью stocksharp.
Plaza2 + FOL дают высокую скорость и все необходимые данные для создания и работы высокочастотных роботов. Тут и добавить больше нечего, бери да делай. Если же говорить о тестировании высокочастотных роботов на истории, то нам необходимы стаканы и все сделки. И стаканы и сделки можно сохранять отдельно от FOL через другие каналы. Но, стаканы и сделки не синхронизированы, т.е. мы можем получить такую ситуацию, когда те или другие данные пришли с запаздыванием, в итоге сделка будет относиться к стакану, который был несколькими секундами ранее или позднее. Например, при стакане с офером на 160 600 проходит сделка на покупку 160 700. Ордер лог может избавить нас от такой проблемы, с его помощью можно получить синхронизированный со сделками стакан.
Еще такой момент по тестированию. Если вы захотите ознакомиться с FOL, вы можете скачать месяц бесплатной истории на сайте РТС. На Рис.2 как раз пример исторических данных с сайта РТС. Там вы можете увидеть момент времени, когда заявка пришла в систему, но! Когда заявка пришла к вам на компьютер, там не показано. Нам же, для формирования стаканов, нужно знать какими пачками и в какое время мы получали данные. Поэтому, когда мы сохраняем информацию на домашних компьютерах, дополнительно появляется метка времени, когда заявки дошли до нас.

Tорговые роботы. Full Orders Log Рис. 3
Добавлена метка с временем получения данных на компьютер
роботы3

На сайте РТС, история ордер лога за один год по всем инструментам стоит 5000$. Если вам интересно это направление, стоит задуматься о сохранении истории уже с сегодняшнего дня, чтобы потом не тратить деньги на покупку.

Манипулирование биржевым стаканом: Торговые роботы или …?

Понимание рыночного механизма потока заявок может дать нам ответ на многие вопросы, правда после которых, может появиться еще больше количество вопросов. В сети лежит ролик “Манипулирование ценой в биржевом стакане”. В ролике показано, как трейдер выставляет заявку на покупку по цене лучшего офера в стакане. Как только он нажимает на ОК, оффер исчезает из стакана. Инсайдер (трейдер-блогер) объясняет такое поведение действиями торговых роботов.
Цитата: “Вы же наверняка часто видели, как кидая заявку на продажу по рынку, цена уходит назад и Ваша заявка удовлетворяется по цене ниже пунктов на 50, чем та цена, которую Вы видели секунду назад и цена сразу же возвращается назад на 50 пунктов вверх.

Они видят благодаря РТС все Ваши манипуляции с заявкой и используют свои быстрые каналы связи с серверами биржи, чтобы откусить чуток от Вашего ордера.”
С точки зрения ордер лога, такого быть не может и торговые роботы не могут реагировать на такую заявку. Среагировать на поступившую заявку, мы можем после того, как к нам пришли данные из плазы. Это самый быстрый, легально возможный способ. Данные, пришедшие из плазы, это уже история, свершившееся событие. Значит, если мы кинули заявку по цене офера, то она обязана исполниться. Или, этот офер должен быть снят до того момента, когда наша заявка на покупку пришла в систему. Единственное объяснение, которое приходит мне в голову такое: брокер делает искусственную задержку и передает информацию о том, что идет заявка. После этого робот брокера отзывает свою заявку или делает другие нужные действия, после чего заявку клиента посылают на рынок. Достаточно задержать заявку на полсекунды, чтобы проводить такие махинации, что естественно незаконно. В законе о проф. участниках указанно, что в случае конфликта интересов брокера и клиента, брокер обязан отдавать приоритет клиенту. Так это происходит в действительности или нет, мы не знаем.



Ордер лог представляется интересным инструментом для анализа рыночной ситуации. Огромное количество интересных возможностей, о которых мы не сказали или даже не знаем. Если у вас есть вопросы, или нужна помощь по ордер логу, можете написать на почту info@stocksharp.com.

StockSharp Торговые роботы


1 2 3  >
CyTrade

Фотография
Дата: 29.03.2012
Ответить


а можно ли где нить надыбать реплику этого потока за пару тройку дней? помимо того что есть фтп ртсе.
Спасибо:

Alexander

Фотография
Дата: 29.03.2012
Ответить


CyTrade Перейти
а можно ли где нить надыбать реплику этого потока за пару тройку дней? помимо того что есть фтп ртсе.


тут есть
Спасибо:

Rinas Andrey

Фотография
Дата: 30.03.2012
Ответить


А Open Interest в FOL тоже доступен?

И по поводу хранения данных: а что если в бинарных файлах эту информацию хранить? Конечно, будут свои замарочки с обработкой данных для анализа, но размер занимаемого дискового пространства должен значительно уменьшиться. Нужно просто придумать формат, наподобие:
4 байта: isin_id
1 байт: Type – покупка/продажа
8 байт: MOMENT
4 байта:ID
1 байт ACTION
8 байт: PRICE(но можно и 4 байта выделить)
4 байта: Volume
4 байта: ID_DEAL
4 байта: PRICE_DEAL

Итого на одну запись 38 байт. Размер файла при 10 млн строк будет 360 мегабайт.
(Тут еще можно isin_id убрать, если разделять файлы по инструментам)
Спасибо:

Mikhail Sukhov

Фотография
Дата: 30.03.2012
Ответить


Rinas Andrey Перейти
И по поводу хранения данных: а что если в бинарных файлах эту информацию хранить?


Гидра и так хранит его в бинарном виде. За день получается около 10 мб по РИ.
Спасибо:

Rinas Andrey

Фотография
Дата: 30.03.2012
Ответить


Mikhail Sukhov Перейти
Rinas Andrey Перейти
И по поводу хранения данных: а что если в бинарных файлах эту информацию хранить?


Гидра и так хранит его в бинарном виде. За день получается около 10 мб по РИ.


А где можно посмотреть формат этих файлов? (В некоторых случаях, лично мне, например, удобнее работать напрямую с файлами)

..наверное немного не в той теме вопрос задал
Спасибо:

Mikhail Sukhov

Фотография
Дата: 30.03.2012
Ответить


Rinas Andrey Перейти
А где можно посмотреть формат этих файлов? (В некоторых случаях, лично мне, например, удобнее работать напрямую с файлами)


Так работайте с файлами. Хранилище у нас имеет свое АПИ. Собственно, с ним Гидра как раз и работает, а не напрямую в файлы.
Спасибо: Rinas Andrey

Rinas Andrey

Фотография
Дата: 01.04.2012
Ответить


Спасибо, а что на счет OI? Есть ли об этом информация в FOL?

UPD: еще один вопрос появился. По login_from c20 получается мы можем все заявки разделить по-пользователям?
Спасибо:

StockSharp

Фотография
Дата: 02.04.2012
Ответить


Rinas Andrey Перейти
Спасибо, а что на счет OI? Есть ли об этом информация в FOL?

UPD: еще один вопрос появился. По login_from c20 получается мы можем все заявки разделить по-пользователям?


IO нет, также как и стохастика с болинджером [biggrin]

все заявки разделить по-пользователям? - Ордер лог анонимный
Спасибо:

Rinas Andrey

Фотография
Дата: 02.04.2012
Ответить


Alexey Gorbunov Перейти

Хм, а стохастик с болинджером при чем тут? [smile]



Не транслируется [biggrin]

Просто сколько я слушаю людей, использующих IO, ни разу не услышал ни одной конкретной технологии.
Что, кстати, не говорит, что такой технологии нет )

Надеюсь никого не обидел [biggrin]
Спасибо:

Mikhail

Фотография
Дата: 12.04.2012
Ответить


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

Выглядит это примерно так:

Цитата:

#SYMBOL,SYSTEM,TYPE,MOMENT,ID,ACTION,PRICE,VOLUME,ID_DEAL,PRICE_DEAL
...
RIM1,F,S,20110601103159033,4002175729,1,188660.00000,3,, #1
...
RIM1,F,S,20110601103159110,4002175771,1,188660.00000,2,, #2
...
RIM1,F,S,20110601103159200,4002175729,2,188660.00000,1,327752213,188660.00000 #3
...
RIM1,F,S,20110601103159200,4002175729,2,188660.00000,2,327752214,188660.00000 #4
RIM1,F,B,20110601103159200,4002175814,1,188660.00000,9,, #5
RIM1,F,B,20110601103159200,4002175814,2,188660.00000,2,327752214,188660.00000 #6
RIM1,F,B,20110601103159200,4002175814,0,188660.00000,7,, #7
...
RIM1,F,S,20110601103159260,4002175771,0,188660.00000,2,, #8


Я интерпретировал это следующим образом.
#1 - добавлена sell-заявка №...5729 объемом 3 контракта;
#2 - добавлена sell-заявка №...5771 объемом 2 контракта;
#3 - по заявке №...5729 произошла сделка объемом 1 контракт, в заявке осталось 2 контракта;
#5 - добавлена buy-заявка №...5814 объемом 9 контрактов;
#4,6 - по заявкам №...5814 и №...5729 произошла сделка объемом 2 контракта, заявка №...5729 исполнена полностью, в заявке №...5814 осталось 7 контрактов;
#7 - заявка №...5814 объемом 7 контрактов снята;
#8 - заявка №...5771 объемом 2 контракта снята.

На мысли о мистическом вмешательстве наводят два момента:

1. Сообщения о появлении заявки №...5814 в системе и ее снятии (#5 и #7) имеют одинаковую отметку времени. При этом в промежутке (#6) по этой заявке совершается сделка.

2. Хотя между заявками №...5814 и №...5729 совершается сделка (#6), не происходит сделки между заявками №...5814 и №...5771, при этом условия по цене одинаковы.

После общения на форуме РТС, оказалось, что мистическое вмешательство отменяется.

Судя по всему, заявка №...5814 является "встречной" (aka "immediate or cancel"), чем и объясняется поведение системы. Печально то, что в файле отсутствует поле status, по которому можно было бы узнать тип заявки. К тому же, описание "встречных" заявок в документации по Плазе весьма загадочное само по себе. Например там не указывается, что по такой заявке выполняется максимум 1 сделка.

Теперь вот думаю, как отлавливать такие заявки по файлу. При работе с "живым" ордер логом таких проблем быть не должно, так как можно прочесть поле status.
Спасибо:
1 2 3  >

Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
clippy