Вещание рыночных данных

Вещание рыночных данных
NP RTS 2014
версия 0.1
11.04.2014
Вещание рыночных данных
Содержание
1. Краткий обзор торговой платформы ....................................................................................................... 3
1.1. Основной режим торгов ............................................................................................................. 3
1.1.1. Типы поручений .............................................................................................................. 3
1.1.2. Исполнение поручений .................................................................................................... 3
1.2. Шлюзы торговой платформы ....................................................................................................... 5
1.2.1. Торговый шлюз ............................................................................................................... 5
1.2.2. Просмотровый шлюз ........................................................................................................ 5
1.3. Логины ...................................................................................................................................... 5
2. Каналы рыночных данных ..................................................................................................................... 7
2.1. Описание каналов рыночных данных ........................................................................................... 7
2.2. Потоки ...................................................................................................................................... 7
2.2.1. Потоки срезов ................................................................................................................. 7
2.2.2. Потоки обновлений ......................................................................................................... 7
2.2.3. Последовательная обработка сообщений ........................................................................... 8
2.2.4. Дублирование потоков ..................................................................................................... 8
2.3. Сообщения в каналах ................................................................................................................. 8
2.3.1. OrderBook ....................................................................................................................... 8
2.3.2. Trades ............................................................................................................................. 8
2.3.3. BestPrices ........................................................................................................................ 8
2.3.4. Commons ........................................................................................................................ 8
3. Сообщения ......................................................................................................................................... 10
3.1. Сообщения FAST ....................................................................................................................... 10
3.2. Форматы cообщений ................................................................................................................ 10
2
Краткий обзор торговой платформы
1. Краткий обзор торговой платформы
Торговая платформа предназначена для совершения операций на финансовых рынках. К основным ее функциям
относятся:
1. прием поручений/заявок, направляемых на различные биржи;
2. маршрутизация поручений, отправка заявок на доступные торговые площадки;
3. регистрация сделок на обслуживаемых платформой биржах, а также обработка информации о сделках на
других биржах при условии наличия подключения к ним;
4. трансляции анонимной и неанонимной информации о торгах, а также дополнительной и справочной
информации;
5. контроль рисков участников клиринга по операциям с инструментами, зарегистрированными в платформе;
6. прочий функционал, связанный с предоставлением доступа к торгам на биржевом рынке.
При наличии подключения участника к нескольких биржам платформа обеспечивает возможность обработки
клиентских подключений на каждой из них.
Для корректного использования торгового шлюза клиенту необходим актуальный файл с описанием торговых
инструментов (подробнее см. документ Описание торговых инструментов).
1.1. Основной режим торгов
1.1.1. Типы поручений
Основной режим торгов подразумевает заключение анонимных сделок на различных торговых площадках.
В Основном режиме торгов клиентам доступны пять типов поручений, которые могут быть поданы в торговую
платформу путем отправки сообщения AddOrder. Тип поручения определяется сочетанием значений полей
в сообщении.
1. Рыночное — поручение с указанием объема и без указания цены, будет исполнено по любой доступной цене;
остаток удаляется.
2. Лимитное, активное до конца торгового дня — поручение с указанием объема и цены; остаток добавляется
в очередь заявок.
3. Fill or Kill (FOK) — поручение с указанием объема и цены, которое должно быть исполнено незамедлительно
в полном объеме либо отклонено.
4. Immediate or Cancel (IOC) — поручение с указанием объема и цены, которое должно быть исполнено
незамедлительно в полном или частичном объеме; остаток удаляется.
5. Айсберг — поручение с указанием объема и цены, объем которого состоит из видимой и скрытой частей.
В очередь заявок выставляется видимая часть. В случае если в результате матчинга видимая часть
исполнилась не полностью, то остаток в очереди заявок остается без изменений. В случае если видимая часть
была исполнена полностью, то на следующей итерации после матчинга видимая часть выставляется заново
полностью, скрытая часть при этом уменьшается на это значение.
Набор типов поручений, доступных в торговой платформе, может не совпадать с набором типов заявок,
доступных на торговой площадке.
1.1.2. Исполнение поручений
Клиентское поручения, поданное в торговую платформу, может быть исполнено на биржах, (1) к которым
подключен данный участник торгов и (2) на которых торгуется инструмент, указанный в поручении. В случае
3
Краткий обзор торговой платформы
если такая биржа одна, то весь объем поручения маршрутизируется на эту биржу в виде одной или нескольких
заявок. При наличии нескольких таких бирж, поручение будет исполнено по принципам «наилучшего
исполнения».
Для группы инструментов, зарегистрированных в торговой платформе, среди нескольких торговых площадок
определяется Основная биржа, характеризующаяся наиболее высокой ликвидностью. Статус Основной
площадки может влиять на выбор стратегии маршрутизации: по умолчанию часть поручения, которая не может
быть сведена с активными заявками в очереди, уходит на эту биржу.
Объем поручения может быть полностью или частично маршрутизирован на торговую площадку только в том
случае, если тип входящего поручения совпадает с одним из типов заявок на бирже. Однако при исполнении
по принципам «наилучшего исполнения» обработка некоторых типов поручения подразумевает возможное
изменение типа заявки по отношению к типу входящего поручения. В текущей версии торговой платформы
таким образом обрабатывается айсберг поручение (подробнее см. 1.1.2.3).
1.1.2.1. Наилучшее исполнение
Наилучшее исполнение (услуга Best Execution) доступно для поручений, (а) поданных с использованием логина,
имеющего доступ на нескольких торговых площадок, (б) по инструментам, торгуемым на нескольких биржах,
(в) с особым указанием маршрутизации (см. раздел ???).
В качестве рыночных данных, на основе которых осуществляется определение объема выставляемых на
торговые площадки заявок в целях обеспечения наилучшего исполнения, используется агрегированная очередь
заявок по каждому инструменту, которая строится объединением очередей заявок, получаемых участником с
разных рынков и доступных ему для использования.
1.1.2.2. Разделение поручения
Разделение входящего поручения на заявки и маршрутизация этих заявок зависит от типа клиентского
поручения.
Входящее поручение вида Fill Or Kill участвует в сведении только на одной бирже, более выгодной для
инициатора исходя из средневзвешенной цены; при равных показателях приоритет отдается бирже,
предоставляющей меньшее время отклика.
Входящие поручения других видов (лимитное, рыночное, IOC, айсберг) могут быть исполнены на нескольких
биржах одновременно. Последовательно для каждого ценового уровня, начиная с наиболее выгодного
инициатору, определяется объем входящей заявки, который может быть удовлетворен на доступных биржах.
В процессе разделения входящее поручение последовательно проходит ценовые уровни очереди заявок
до достижения необходимого объема встречных предложений. В случае если пройдены все доступные
ценовые уровни, а входящее поручение не исполнено целиком, остаток маршрутизируется на Основную
торговую площадку либо удаляется из системы в случае IOC. В первом случае остаток добавляется к объему,
отправляемому на Основную торговую площадку. После того как определены объемы, маршрутизируемые на
биржи, формируются заявки и передаются на торговые площадки.
1.1.2.3. Особенности обработки айсберг-поручений
Поручение типа айсберг, направленное на все торговые площадки (instrument.source_id=TRADSYS), будет
разделено на заявки согласно обычному алгоритму — в соответствии с актуальным состоянием очередей
заявок. Заявка, сформированная на биржу, на которой доступны айсберг-заявки, будет маршрутизирована туда
в виде айсберг-заявки, причем скрытый объем равен изначальному, если он не превышает объем заявки, либо
текущему объему заявки, если текущий объем меньше или равен изначальному скрытому объему. Заявка,
сформированная на биржу, на которой недоступны айсберг-заявки, будет маршрутизирована как заявка IOC, при
этом весь объем заявки будет скрытым. В отчетах о поручении будут указаны изначальные параметры, в отчетах
о заявках — новые.
4
Краткий обзор торговой платформы
1.2. Шлюзы торговой платформы
1.2.1. Торговый шлюз
Поключившись к торговому шлюзу, клиент может в соответствии с правами доступа логина, через который
осуществлено подключение, подавать поручения, запрашивать снятие и получать отчеты о поданных
поручениях.
Взаимодействие с торговым шлюзом осуществляется при помощи бинарного протокола торговой платформы
на двух уровнях — сессионном и прикладном. Сессионный уровень обеспечивает надежность и корректность
обмена сообщениями. Прикладной уровень позволяет клиенту осуществлять оправку транзакционных запросов
и получение отчетов от торговой системы.
1.2.2. Просмотровый шлюз
Просмотровый шлюз позволяет клиенту получать неанонимные рыночные данные в соответствии с правами
доступа логина.
Взаимодействие с торговым шлюзом осуществляется при помощи бинарного протокола торговой
платформы на двух уровнях — сессионном и прикладном. Сессионный уровень обеспечивает надежность
и корректность обмена сообщениями. На прикладном уровне просмотровый шлюз обеспечивает одностороннее
взаимодействие: шлюз направляет клиенту транзакционные отчеты согласно правам доступа логина, но клиент
не имеет возможности отправлять торговые сообщения.
1.3. Логины
Логин является учетной записью для доступа к торговому и/или просмотровому шлюзу торговой платформы и
обладает набором прав доступа, определенных при регистрации.
Таблица 1.1. Права доступа логина
Тип доступа
Описание
Обязательность
Участник торгов
Логин привязан к одному участнику обязательно
торгов
Торгово-клиринговый счет
Логин может быть привязан к
одному или нескольким торговоклиринговым счетам
необязательно
Коды клиентов участника торгов
Логин может быть привязан к
одному или нескольким кодам
клиентов
необязательно
Шлюзы
Логин может иметь доступ к
одному или обоим типам шлюзов:
обязателен по крайней мере один
1. Trade: торговый,
2. DropCopy: просмотровый
Получение неанонимных рыночных Логин может получать разный
данных
набор отчетов:
обязательно
1. CompleteLog: отчеты о
поручениях и заявках;
2. RestrictedLog: отчеты только о
поручениях.
Участник торгов, торгово-клиринговый счет и код клиента, присвоенные логину, определяют, во-первых, от чьего
имени логин может подавать поручения, в-вторых, какими поручениями логин может управлять (запрашивать
снятие и изменять параметры), а в-третьих, о каких поручениях логин будет получать отчеты.
5
Краткий обзор торговой платформы
Шлюз может транслировать клиенту либо отчеты о поручениях и заявках, либо отчеты только о поручениях.
В последнем случае клиент будет получать меньшее количество сообщений, однако не будет обладать
информацией о объемах заявок на конкретных торговых площадках.
При регистрации логину присваиваются маски IP-адресов, определяющие диапазон адресов, с которых данный
логин может подключиться к шлюзу торговой платформы.
Перед каждым подключением к шлюзу торговой платформы необходимо запросить предоставление адреса
посредством сервера входа (см. ???).
6
Каналы рыночных данных
2. Каналы рыночных данных
2.1. Описание каналов рыночных данных
Торговая платформа транслирует клиентам несколько каналов различных рыночных данных:
1. OrderBook — объединенная очередь заявок одной или нескольких торговых площадок, агрегированная по
ценовым уровням. Количество ценовых уровней 50
2. Trades — список сделок, заключенных на торговых площадках клиентами торговой системы в течение
текущего операционного дня
3. BestPrices — лучшие на цены в покупку и в продажу объединенной очереди заявок.
4. Commons — статистические рыночные параметры торговых площадок
Транслируемые каналы перечислены в документе Network Connectivity.
2.2. Потоки
Каналы OrderBook, BestPrices и Commons представляет собой два потока — срез и обновления. Канал Trades
включает в себя только поток обновлений; данные о предыдущих сделках могут быть получены при помощи
особого механизма (будет доступен в последующих версиях).
Срез представляет собой полное описание актуальных данных, например всю очередь заявок для OrderBook, и
передается с заданной периодичностью (с определенным перерывом между отправками). В потоке обновлений
новое сообщение формируется сразу при получении новых данных, например при совершении сделки для
Trades. Несколько обновлений могут быть включены в одно сообщение.
2.2.1. Потоки срезов
В потоке срезов транслируются срезы, содержащие полную информацию об актуальном состоянии
определенных показателей. Как правило, один срез содержится не в одном, а в нескольких последовательных
сообщениях. Срезы передаются в поток по мере формирования. В дальнейшем данная величина может
изменяться.
Срезы передаются сообщением MarketDataSnapshotFullRefresh[W]. Срез относится только к одному инструменту,
указанному в поле SecurityID[48]. Сами рыночные данные указаны в повторяющейся группе: значения поля
MDEntryType[269] и набор полей в группе зависят от канала.
2.2.2. Потоки обновлений
В сообщениях потока обновлений содержатся изменения — текущие инкрементальные изменения вида
(а) добавление, (б) изменение или (в) удаление. Инкрементальные обновления должны обрабатываться только
в прямом хронологическом порядке, которому соответствуют номера обновления RptSeq[83].
Обновления передаются сообщением MarketDataIncrementalRefresh[W]. Само обновление содержится в
повторяющейся группе: значения поля MDEntryType[269] и набор полей в группе зависят от канала. Одно
сообщение может включать в себя обновления, относящиеся к различным инструментам.
В случае отсутствия сообщений в потоке обновлений в течение установленного интервала сервер отправляет
сообщение Heartbeat[0]. Оно предназначено только для подтверждения наличия связи в канале. В случае
отсутствия сообщений в течение более чем двух тактовых интервалов, это обозначает либо задержки, либо
отсутствие связи в канале.
7
Каналы рыночных данных
2.2.3. Последовательная обработка сообщений
Всем сообщениям в потоках, в том числе Heartbeat[0], последовательно присваивается номер MsgSeqNum[34].
Каждое обновление обладает номером RptSeq[83]. В сообщении MarketDataSnapshotFullRefresh[W] указывается
номер последнего обновления, отправленного до формирования среза. Таким образом, для среза следует
использовать обновление, номер которого на единицу больше, чем указанный в этом срезе, и последующие.
Пропуск номера обновления свидетельствует о потере части данных.
Обработка сообщений FAST подразумевает получение сообщений и последовательную их обработку согласно
номеру сообщения и номеру обновления. В общем случае следует получить срез, в то же время записывая
сообщения с обновлениями. После получения полного среза нужно применить к нему обновления; затем
можно только использовать получаемые обновления и обращаться к срезу лишь при потере сообщений с
обновлениями.
2.2.4. Дублирование потоков
Каждый поток рыночных данных транслируется двумя идентичными UDP-потоками — А и В. По этим
потокам одновременно рассылаются идентичные сообщения (в том числе, с одними и теми же номерами
сообщения). Дублирование повышает надежность трансляции, значительно снижая вероятность потери пакетов.
Пользователю рекомендуется подключаться к обоим потокам. Так, если в потоке A после сообщения n–1 было
получено сообщение n+1, то сообщение n могло быть получено в потоке В. В случае если сообщение оказалось
потеряно в обоих потоках, необходимо ожидать получения следующего среза в соответствующем потоке.
2.3. Сообщения в каналах
2.3.1. OrderBook
В канале OrderBook транслируются объемы ценовых уровней: срез содержит 50 уровней (или менее);
обновления относятся также к 50 видимым ценовым уровням.
Значение поля MDEntryType[269] равно 0 для котировок в покупку и 1 для котировок в продажу. При этом цена
указана в MDEntryPx[270], а суммарный объем заявок на ценовом уровне — в MDEntrySize[271].
2.3.2. Trades
В канале обновлений Trades транслируются данные о только что заключенных сделках: при получении
от биржи информации о заключении одной или нескольких сделок формируется сообщение
MarketDataIncrementalRefresh[X], в котором каждая сделка представляет собой запись в потовряющейся группе.
Значение поля MDEntryType[269] всегда равно 2. При этом цена указана в поле MDEntryPx[270], объем — в
MDEntrySize[271], а поле MDEntryID[278] содержит идентификатор сделки, присвоенный биржей.
2.3.3. BestPrices
В канале BestPrices транслируются сообщения, содержащие ценовой уровень с лучшей ценой в покупку
(MDEntryType[269]=0), ценовой уровень с лучшей ценой в продажу (MDEntryType[269]=1) и последнюю сделку
(MDEntryType[269]=2). В поле MDEntryPx[270] указан ценовой уровень или цена сделки, а в MDEntrySize[271] —
суммарный объем заявок на ценовом уровне или объем сделки. Поле MDEntryTime[273] содержит время
последнего обновления ценового уровня или время заключения сделки.
2.3.4. Commons
Тип параметра указан в MDEntryType[269], набор заполняемых полей зависит от указанного типа (см. ниже
таблицу соответствий).
8
Каналы рыночных данных
Для потока обновления сообщение формируется при изменении одного или нескольких статистических
параметров. Срез транслируется с определенной периодичностью.
Таблица 2.1. Соответствие рыночных параметров и полей в сообщениях
Рыночный параметр
Значение
MDEntryType[269]
Заполняемое поле
Цена первой сделки за сессию
4
MDEntryPx[270]
Последняя сделка предыдущей сессии
5
MDEntryPx[270]
Сделка с максимальной ценой
7
MDEntryPx[270]
Сделка с минимальной ценой
8
MDEntryPx[270]
Текущая котировка
f
MDEntryPx[270]
Расчетная цена последнего основного клиринга
n
MDEntryPx[270]
Расчетная цена последнего клиринга
6
MDEntryPx[270]
Количество заявок в покупку
x
MDEntrySize[271]
Количество заявок в продажу
y
MDEntrySize[271]
Количество лотов в покупку
u
MDEntrySize[271]
Количество лотов в продажу
v
MDEntrySize[271]
Количество сделок (системных)
w
MDEntrySize[271]
Оборот в лотах (по системным сделкам)
B
MDEntrySize[271]
Оборот в единицах актива (по системным сделкам)
r
MDEntrySize[271]
Оборот в валюте (по системным сделкам)
s
MDEntrySize[271]
Количество сделок (всех)
t
MDEntrySize[271]
Оборот в лотах (весь)
o
MDEntrySize[271]
Оборот в единицах актива (весь)
p
MDEntrySize[271]
Оборот в валюте (весь)
q
MDEntrySize[271]
9
Сообщения
3. Сообщения
3.1. Сообщения FAST
Все сообщения, отправляемые в потоках рыночных данных, сформированы в соответствии с протоколом FIX и
закодированы по протоколу FAST. Шлюз использует протокол FIX версии 5 Service Pack 2 и протокол FAST версии
1.1. Версия протокола доступна на портале FIXProtocol.org: http://www.fixprotocol.org/fast.
Каждое FAST-сообщение предваряется 4-байтной преамбулой. Она содержит значение поля MsgSeqNum[34] в
некодированном виде и позволяет узнать номер полученного сообщения без декодирования.
Все поля в сообщении, кодируемом FAST, выстроены в строго определенном порядке. Поэтому указание на
номер тега отсутствует в самом сообщении. Формат сообщений, используемых в потоках, описан в шаблоне
template.xml.
Передаваемые сообщения FAST не содержат все значения, поскольку могут использоваться (а) константы,
описанные в шаблоне, (б) значение по умолчанию при отсутствии заданного значения, (в) предыдущее
значение, (г) изменение по отношению к предыдущему значению (дельта или инкремент). Набор предыдущих
значений сохраняется и представляет собой словарь. Словарь актуален для одного UDP-пакета (FASTсообщения).
Словарем называется кэш, в котором хранятся предыдущие значения, полученные системой. Содержимое
словаря сбрасывается в начале обработки каждого UDP-пакета. Так как в одном UDP-пакете отправляется только
одно FAST-сообщение, то дельта в такой реализации использоваться не будет.
3.2. Форматы cообщений
В этом разделе приведены таблицы, описывающие форматы сообщений.
Наличие поля
• R [required] — обязательное;
• N [nonrequired] — необязательное;
• C [conditionally required] — необходимое при некотором условии.
Типы данных
Bool — логический тип данных. Допустимые значения: Y и N.
Char — односимвольный тип данных. Допустимые значения — символы ASCII: латинские буквы цифры и
пунктуационные знаки. Не допустимы бинарный нуль и бинарная единица.
Int — целочисленный тип данных.
SeqNum — натуральное число для обозначения порядкового номера сообщения.
String — строковый тип данных. Строка может передаваться в любой кодировке; не допустимы бинарный нуль и
бинарная единица.
Timestamp — строковый тип данных для указания времени по Всемирному времени (UTC) в формате
YYYYMMDD-HH:MM:SS.sss
Таблица 3.1. Формат сообщения MarketDataIncrementalRefresh[X]
Тег
Поле
Тип
Наличие
Описание
8
BeginString
String
R
Начальная строка. Значение всегда FIXT.1.1
10
Сообщения
Тег
Поле
Тип
Наличие
Описание
9
BodyLength
int
R
Длина сообщения
35
MessageType
String
R
Тип сообщения. Значение всегда X
1128
ApplVerID
String
R
Версия сообщения. Значение всегда 1
49
SenderCompID
String
R
Идентификатор отправителя. Значение всегда BEX
34
MsgSeqNum
int
R
Номер сообшения
52
SendingTime
int
R
Время отправки сообщения
268
NoMDEntries
length
R
Количество записей в группе
48
> SecurityID
int
R
Идентификатор торгового инструмента
83
> RptSeq
int
R
Номер обновления инструмента.
Соответствует RptSeq[83] в сообщении
MarketDataFullSnapshotRefresh[W]
22
> SecurityIDSource
int
R
Идентификатор торговой площадки
279
>
MDUpdateAuction
int
R
Тип обновления. Значения:
269
> MDEntryType
int
R
Тип записи
270
> MDEntryPx
decimal
N
Цена
271
> MDEntrySize
int
N
Объем
272
> MDEntryDate
int
N
Дата обновления
273
> MDEntryTime
int
N
Время обновления
278
> MDEntryID
int
N
Идентификатор сделки
828
> TrdType
int
N
Тип сделки
• 0 (добавление);
• 1 (замена);
• 2 (удаление)
Таблица 3.2. Формат сообщения MarketDataSnapshotFullRefresh[W]
Тег
Поле
Тип
Наличие
Описание
8
BeginString
String
R
Начальная строка. Значение всегда FIXT.1.1
9
BodyLength
int
R
Длина сообщения
35
MessageType
String
R
Тип сообщения. Значение всегда W
1128
ApplVerID
String
R
Версия сообщения. Значение всегда 1
49
SenderCompID
String
R
Идентификатор отправителя. Значение всегда BEX
34
MsgSeqNum
int64
R
Номер сообшения
52
SendingTime
Timestamp
R
Время отправки сообщения
48
SecurityID
int
R
Идентификатор торгового инструмента
22
SecurityIDSource int
R
Идентификатор торговой площадки
83
RptSeq
int
R
Номер обновления инструмента.
Соответствует RptSeq[83] в сообщении
MarketDataIncrementalRefresh[X]
268
NoMDEntries
length
R
Количество записей в группе
269
> MDEntryType
int
R
Тип записи
270
> MDEntryPx
decimal
N
Цена
271
> MDEntrySize
int
N
Объем
11
Сообщения
Тег
Поле
Тип
Наличие
Описание
272
> MDEntryDate
int
N
Дата обновления
273
> MDEntryTime
int
N
Время обновления
278
> MDEntryID
int
N
Идентификатор сделки
828
> TrdType
int
N
Тип сделки
Таблица 3.3. Формат сообщения Heartbeat[0]
Тег
Поле
Тип
Наличие
Описание
8
BeginString
String
R
Начальная строка. Значение всегда FIXT.1.1
9
BodyLength
int
R
Длина сообщения
35
MessageType
String
R
Тип сообщения. Значение всегда 0
1128 ApplVerID
String
R
Версия сообщения. Значение всегда 1
49
SenderCompID
String
R
Идентификатор отправителя. Значение всегда BEX
34
MsgSeqNum
int64
R
Номер сообшения
52
SendingTime
Timestamp
R
Время отправки сообщения
12