Один день из жизни Ri. Или введение в микроструктурный анализ. StockSharp

Один день из жизни Ri. Или введение в микроструктурный анализ

10.10.2013

vlad1024

Для большинства трейдеров свечные графики различного таймфрейма это и есть рынок, там скрывается все - и тренд и боковик и хитрый маркет мэйкер с глобальным кукловодом. Начнем с простых фактов, за одну сессию 2012.11.07 на фьючерсе Ri ядро биржи обработало 10 449 043 транзакций или примерно 12 000 транзакций в минуту, одна свечка самого "высоко частотного" минутного таймфрема скрывает за собой огромное количество более элементарных действий. Поэтому мы спустимся на самый низкий уровень того, что происходит на бирже и начнем оттуда.

Можно долго рассказывать про то как устроена биржа, про промежуточные сервера и другие части "транспортной" инфракстуры, какие задержки они вносят при путешествии заявки, но в конце пути любая заявка попадает в ядро биржие, где непосредственно происходит то ради чего все собственно и затевалось - сведение(matching). И на этом уровне, в смысле формата данных и производимых элементарных действий, FORTS мало чем отличается от той же CME или любой другой современной биржи. Входной поток состоит из заявко двух типов, на вставку(insert) и отмену(cancel). Бьете вы по рынку или выставляете заявку в глубь стакана - для ядра нет разницы, все это в конечном итоге преобразуется в заявку на вставку, которой присваивается свой уникальный идентификатор. Другой тип заявок - на отмену, позволяет убрать часть(или всю) предшествующей заявки на вставку. Ядро принимая на входе поток состоящий из заявок на вставку и отмену, создает поток сведенных сделок, каждая сведенная сделка связана с двумя заявками участвующих в сделке. Исходя из полученного потока, затем строятся стаканы, и тиковые данные(сведенные сделки), которые рассылаются пользователям(к примеру на RTS срезы стаканов строятся с периодичностью 30 миллисекунд), и лишь затем тики преобразуются в красивые свечки, отображаемые на экране. Поток данных содержащий заявки на вставку, отмену и сведенные сделки, на FORTS называется Full Order Log.

Рассмотрим более подробно формат данных Full Order Log. Возьмем для примера маленький, кусочек:

Код

 QUOTE  TYPE    TIMESTAMP      SESSION    ORDER_ID  STATUS ACTION PRICE  VOL  DEAL_ID DEAL_PRICE
['riz2',  1, 1352315357375000, 20121107, 9368447574, 101401, 1, 141870.0, 1,,]
['riz2', -1, 1352315357380000, 20121107, 9368447558, 100001, 0, 141900.0, 3,,]
['riz2', -1, 1352315357380000, 20121107, 9368447580, 101401, 1, 141890.0, 3,,]
['riz2', -1, 1352315357381000, 20121107, 9368447559, 100001, 0, 141890.0, 2,,]
['riz2', -1, 1352315357381000, 20121107, 9368447581, 101401, 1, 141880.0, 2,,]
['riz2',  1, 1352315357381000, 20121107, 9368447507, 100001, 0, 141840.0, 4,,]
['riz2',  1, 1352315357381000, 20121107, 9368447582, 101401, 1, 141860.0, 4,,]
['riz2',  1, 1352315357384000, 20121107, 9368447522, 100001, 0, 141850.0, 8,,]
['riz2',  1, 1352315357384000, 20121107, 9368447586, 101401, 1, 141860.0, 8,,] <- A
['riz2',  1, 1352315357386000, 20121107, 9368447255, 201401, 0, 141850.0, 2,,]
           .... 
['riz2', 1, 1352315358149000, 20121107, 9368447396,      1, 2, 141860.0, 2, 657525271, 141860.0]
['riz2', 1, 1352315358149000, 20121107, 9368447454,      1, 2, 141860.0, 2, 657525272, 141860.0]
['riz2', 1, 1352315358149000, 20121107, 9368447586,      1, 2, 141860.0, 1, 657525273, 141860.0] <- B
['riz2',-1, 1352315358149000, 20121107, 9368447766,    402, 1, 134840.0, 5, ,,] <- C
['riz2',-1, 1352315358149000, 20121107, 9368447766,      2, 2, 134840.0, 2, 657525271, 141860.0]
['riz2',-1, 1352315358149000, 20121107, 9368447766,      2, 2, 134840.0, 2, 657525272, 141860.0]
['riz2',-1, 1352315358149000, 20121107, 9368447766,   1002, 2, 134840.0, 1, 657525273, 141860.0] <- D
['riz2', 1, 1352315358189000, 20121107, 9368447761, 100001, 0, 141840.0, 4, ,,]
['riz2', 1, 1352315358189000, 20121107, 9368447770, 101401, 1, 141860.0, 4, ,,]

QUOTE - содержит название инструмента, TYPE - направление заявки (+1 - bid, -1 - ask), TIMESTAMP - временная метка в микросекундах, SESSION - идентификатор сессии, ORDER_ID - идентификатор заявки, STATUS - флаги заявки, ACTION - тип заявки (0 - отмена, 1 - вставка, 2 - сведенная сделка), PRICE - цена, VOL - объем заявки, DEAL_ID - идентификатор сделки, DEAL_PRICE - цена сделки.
На примере выше показан цикл жизни заявки, вставка заявки c идентификатором 9368447586 в поток (A), вставка встречно заявки (C), первая сторона сведенной сделки (B) и вторая сторона (D).

Теперь, немного разобравшись в формате данных, можно приступить к статистическому анализу. Всего за сессию было произведено 10 449 043 транзакций, из них 4 990 732 на вставку, и 4 362 829 на отмену, а сведено сделок - 1 095 482. То есть "в среднем по больнице" на каждую сделку приходилось 4 перестановки. Следующий вопрос, который возникает - каким образом данная активность распределена по объемам. Для этого посчитаем следующие факторы - количестов вставок и отмен для заданного объема, отношение отмененых заявок к выставленным, чем меньше это соотношение тем больше количество сделок сведено на каждую вставленную заявку, тогда умножив соотношение на количество вставленных заявок, мы получим количество проторгованных заявок для данного объема заявки. В результате получим следующую табличку, отсортированную по столбцу проторгованного объема(для анализа использовался python + scipy):

Код

   cancel_count  cancel_volume  insert_count  insert_volume     ratio    trade_volume  
        1176407              1       1452121              1  0.810130      275714  
         272998              5        327113              5  0.834568      270575  
        1257775              2       1369794              2  0.918222      224038  
          39698             10         55877             10  0.710453      161790  
         432361              4        470513              4  0.918914      152608  
         668395              3        718625              3  0.930103      150690  
          15002             20         20662             20  0.726067      113200  
           1455             50          3608             50  0.403271      107650  
            453            100          1404            100  0.322650       95100  
         201295              8        212359              8  0.947900       88512  
          21651             15         27185             15  0.796432       83010   
          99168              6        110608              6  0.896572       68640  
           1989             30          4107             30  0.484295       63540  
           4926             25          7438             25  0.662275       62800  
           1025            200          1310            200  0.782443       57000  
          37216             12         41715             12  0.892149       53988  
             68            500           172            500  0.395349       52000  
          17857              7         25274              7  0.706536       51919

cancel_volume, insert_volume - объем в заявке на вставку или отмену, cancel_count - количество отмен, insert_count - количество вставок, ratio - соотношение, trade_volume - оценка проторгованного объема в контрактах.

Как видно, объемы заявок на вставку, можно условно разделить на две группы, small-volume traders с диапазоном объема 1-10 - высокочастотные трейдеры и скальперы, и всех остальных, как видно во второй группе, значения проторгованного объема кучкуются вокруг "психологических" уровней заявок - 15, 20, 25, 30, 50, 100, 200, 500.

код на питоне
Продолжение следует...

Теги:

Спасибо:

Самунджян Артем

wkj

Mikhail Sukhov

Prival

< 1 2

Slepoy

Дата: 03.04.2014

Михаил Сухов

slepoy

[quote=Михаил Сухов;30179]В ОЛ этих данных нет.

Так нет. Это лог заявок. И цены там не бидов асков, а цены заявок и их исполнения.

Секунду. У нас недопонимание с терминологией. Что по вашему тогда аск и бид?
Аск- это лимитировананя заявка на продажу
Бид -это лимитирвоанная заявка по покупку.
Так же в стакане, на границе спреда присутвуют "лучший бид" и "лучший аск" - именно по ним вначале и бьют маркетом (на ФОРТСе имитация - лимитка с заведомо большой/меньешй ценой)
Все логично, даже сам автор статьи упоминает тоже самое "TYPE - направление заявки (+1 - bid, -1 - ask)"

Спасибо:

< 1 2

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