Содержание
Дата | Изменения |
---|---|
08.07.2024 | Внесённые изменения:
|
12.04.2024 | Внесённые изменения:
|
18.03.2024 | Внесённые изменения:
|
01.12.2023 | Внесённые изменения:
|
04.09.2023 | Внесённые изменения:
|
02.06.2023 | Внесённые изменения:
|
27.03.2023 | Внесённые изменения:
|
09.11.2022 | Внесённые изменения:
|
15.09.2022 | Внесённые изменения:
|
17.05.2022 | Внесённые изменения:
|
05.04.2022 | Внесённые изменения:
|
20.10.2021 | Внесённые изменения:
|
23.07.2021 | Внесённые изменения:
|
14.05.2021 | Внесённые изменения:
|
25.02.2021 | Внесённые изменения:
|
12.01.2021 | Внесённые изменения:
|
19.10.2020 | Внесённые изменения:
|
17.08.2020 | Внесённые изменения:
|
19.06.2020 | Внесённые изменения:
|
15.01.2020 | Внесённые изменения:
|
10.12.2019 | Внесённые изменения:
|
12.09.2019 | Внесённые изменения:
|
31.08.2019 | Внесённые изменения:
|
20.06.2019 | Внесённые изменения:
|
14.01.2019 | Внесённые изменения:
|
05.12.2018 | Внесённые изменения:
|
26.09.2018 | Добавлен новый код ошибки 4208. |
25.09.2018 | Добавлен раздел "3.3.7. Клиентские SMA-логины (спонсируемый доступ)". |
03.08.2018 | Из таблицы orders потока FORTS_ORDBOOK_REPL удалено поле aspref. |
01.08.2018 | Из потока FORTS_INFO_REP удалены таблицы sma_master, sma_pre_trade_check. |
31.07.2018 | В поток FORTS_INFO_REPL добавлена таблица option_series_params. |
30.07.2018 | Из таблицы opt_vcb потока FORTS_OPTINFO_REPL удалено поле coeff_out. |
27.07.2018 | Внесённые изменения:
|
26.07.2018 | Добавлен новый код ошибки 4220. |
26.07.2018 | Внесённые изменения:
|
18.07.2018 | Добавлены команды SetSmaPreTradeCheck, DelSmaPreTradeCheck, UserKillSwitch. |
25.06.2018 | Добавлены новые коды ошибок (76, 4167, 4200 - 4207). |
21.06.2018 | Добавлен раздел "3.3.6. Потоки, получаемые логинами разных подтипов". |
19.06.2018 | У команды FutChangeClientMoney удалены неиспользуемые поля limit_pledge и coeff_liquidity. |
21.05.2018 | В таблицу diler потока FORTS_FUTINFO_REPL добавлено поле signs. |
11.04.2018 | В сообщениях OptChangeExpiration, FutTransferClientPosition, OptTransferClientPosition изменены тип сообщения и тип поля amount. |
30.03.2018 | В таблицу part_sa потока FORTS_PART_REPL добавлено поле money_old. |
22.03.2018 | Внесённые изменения:
|
28.02.2018 | Из потока FORTS_FORECASTIM_REPL удалена таблица part_forecast. |
26.02.2018 | Внесённые изменения:
|
21.02.2018 | Добавлены новые коды ошибок: 4148, 4149. Изменено описание кодов ошибок: 4127, 4138 |
20.02.2018 | Внесённые изменения:
|
31.01.2018 | Внесённые изменения:
|
26.12.2017 | Внесённые изменения:
|
21.12.2017 | Добавлены новые коды ошибок (4160 - 4166). |
16.11.2017 | Изменено описание параметра code_vcb метода FutDelUserOrders. |
25.10.2017 | Внесённые изменения:
|
24.10.2017 | Внесённые изменения:
|
28.08.2017 | В сообщениях OptChangeExpiration, FutTransferClientPosition, OptTransferClientPosition изменены тип сообщения и тип поля amount. |
23.06.2017 | Удалён поток RTS_INDEXLOG_REPL. |
02.06.2017 | Внесенные изменения:
|
18.05.2017 | Внесенные изменения:
|
15.05.2017 | Внесенные изменения:
|
05.05.2017 | Внесенные изменения:
|
24.03.2017 | Внесенные изменения:
|
28.12.2016 | Внесенные изменения:
|
21.12.2016 | В соответствии с политикой декомиссии программного обеспечения с 5 декабря 2016 прекращена поддержка API P2ClientGate и библиотек Plaza-2 версий младше или равных 198. Это изменение отменяет и обратную совместимость: шлюзы с библиотеками версий младше или равными 198, а также написанные с использованием API P2ClientGate, не смогут продолжать свою работу. |
30.08.2016 | Изменён список синхроевентов в таблице sys_events в потоках FORTS_PART_REPL, FORTS_CLR_REPL, FORTS_INFO_REPL. |
18.05.2016 | Внесенные изменения:
|
14.10.2015 | Добавлено описание CODHeartbeat. |
14.10.2015 | В таблицу fut_sess_contents добавлено 2 новых поля: pctyield_coeff и pctyield_total. |
12.08.2015 | Добавлены новые коды ошибок (200 - 208). |
23.01.2015 | В "Описание торгового шлюза" добавлен раздел "Обработка нештатных ситуаций". |
22.01.2015 | Добавлен раздел "Автоматическое снятие заявок при отключении пользователя от торгов". |
16.12.2014 | Отредактирован список кодов ошибок. |
29.09.2014 | Добавлена расшифровка таблицы prohibition потока FUTINFO. |
18.08.2014 | Добавлены коды ошибок ASTS. |
24.07.2014 | В таблицах fut_MM_info и opt_MM_info потока FORTS_MM_REPL теперь транслируются обязательства маркет-мейкеров с детализацией до семизначного клиентского кода. Форматы сообщений-транзакций FutTransferClientPosition и OptTransferClientPosition теперь идентичны. Из потока FORTS_FUTINFO_REPL удалена таблица fut_ts_cons. |
17.07.2014 | Из таблицы ORDERS потока FORTS_ORDBOOK_REPL удалено поле client_code |
25.04.2014 | В поток FORTS_MM_REPL добавлена новая таблица mm_agreement: Таблица с номерами и типами договоров на оказание маркет-мейкерских услуг. |
15.04.2014 | Добавлены новые команды:
|
14.01.2014 | Добавлены новые поля:
в таблицы fut_MM_info, opt_MM_info потока FORTS_MM_REPL |
31.05.2013 | Добавлено новое поле:
в таблицу clr_rate потока FORTS_CLR_REPL |
18.04.2013 | Добавлен анонимный поток orderbook:
Добавлено поле:
в таблицу money_clearing потока FORTS_CLR_REPL Удален поток FORTS_CLMONEY_REPL |
12.04.2013 | Добавлено новое поле:
в таблицу fut_sess_contents потока FORTS_FUTINFO_REPL |
10.04.2013 | Добавлено новое поле:
в таблицу opt_sess_contents потока FORTS_OPTINFO_REPL |
26.03.2013 | Добавлено новое поле:
в таблицы fut_vcb и opt_vcb потоков FORTS_FUTINFO_REPL и FORTS_OPTINFO_REPL Добавлен поток репликации:
Добавлена новая таблица:
в поток FORTS_FUTINFO_REPL |
27.11.2012 | Изменение описания таблицы user_deal. |
01.11.2012 | Добавлено описание двух событий для таблицы sys_events. |
30.10.2012 | Обновление документации:
|
22.10.2012 | Обновление документации:
|
10.02.12 | Обновления документации:
|
09.02.2012 | Добавлено новое поле:
в таблицы:
потоков:
|
24.01.2012 | В таблицу orders потоков:
добавлены следующие поля:
|
23.01.2012 | Добавлена таблица событий sys_events в потоки:
|
17.01.2012 | В таблицу fut_vcb потока FORTS_FUTINFO_REPL добавлено поле exch_pay_spot_repo, содержащее биржевой сбор по Репо |
12.01.2012 | Добавлен поток репликации:
|
02.11.2011 | Добавлены новые поля:
в таблицы:
|
25.11.2011 | Добавлен раздел "Использование тестовых примеров". |
7.11.2011 | Ревизия документа. Доработаны разделы "Введение" и "Описание торгового шлюза". Добавлен раздел "Краткий обзор системы SPECTRA". |
20.10.2011 | Добавлены следующие поля:
Добавлена таблица событий sys_events в потоки:
|
4.10.2011 | Добавлены потоки репликации:
Изменены номера команд торговых операций для поддержки возможности мониторинга времен полной обработки, включая канал до пользователя. |
14.09.2011 | Исправлены ошибки в значениях по умолчанию некоторых команд: Если параметр является строковым - его значение по умолчанию берется в кавычки |
15.04.2011 | Добавлены следующие поля:
Изменения в системе команды:
|
28.03.2011 | В таблицу multileag_deal потока FORTS_FUTTRADE_REPL добавлено поле buyback_amount, содержащее сумму обратного выкупа для сделок Репо |
24.03.2011 | Добавлен поток RTS_INDEXLOG_REPL, транслирующий историю изменения индексов РТС |
01.02.2011 | Для команды FutChangeClientVcb изменён тип параметра code_vcb с c4 на c25. Новый формат команды имеет код сообщения 33. Код ответного сообщения для команды не изменился. В документацию добавлен справочник кодов возврата команд. |
27.01.2011 | Исправлена ошибка в документации - параметр check_limit команд OptAddOrder и OptMoveOrder был описан некорректно. Правильные значения параметра: 0 - не выполнять проверку, 1 - выполнять проверку. |
24.12.2010 | Исправлен ряд ошибок в именовании полей команд, а также значения по умолчанию некоторых команд:
. |
26.11.2010 | Изменен формат агрегированных стаканов - убрано поле price2. Теперь поле price принимает различный смысл в зависимости от значения признака 0x1000 инструмента (поле signs таблицы fut_sess_contents потока FORTS_FUTINFO_REPL): в случае установки признака поле price содержит ставку, иначе - своп-цену. |
15.10.2010 | Новые признаки инструмента (поле signs таблицы fut_sess_contents потока FORTS_FUTINFO_REPL):
Новое значение признака составных инструментов multileg_type (таблицы fut_sess_contents потока FORTS_FUTINFO_REPL. Для свопов RTS Money принимает значение 2. Новое поле в стаканах агрегированных котировок - price2. Используется для свопов - в данное поле записывается своп-цена. |
14.09.2010 | В потоки FORTS_FUTCOMMON_REPL и FORTS_OPTCOMMON_REPL добавлены значения цен открытия и закрытия (поля open_price и close_price). В поток RTS_INDEX_REPL добавлены значения капитализации и объёма для индексов (поля cap и volume). |
07.07.2010 | В таблицу с информацией о сессии session потока FORTS_FUTINFO_REPL добавлена информация об интервале переноса позиций (поля pos_transfer_begin и pos_transfer_end) Добавлены таблицы:
|
15.06.2010 | Исправлена ошибка в описании команды FutAddMultiLegOrder: тип параметра isin_id изменён c25->i4 |
В таблице delivery_report потока FORTS_FUTINFO_REPL поля oblig_uni и fulfil_uni типа i4 заменены на поля oblig_qty и fulfil_qty типа i8. | |
31.05.2010 | В таблицы fut_sess_contents и fut_instruments потока FORTS_FUTINFO_REPL добавлено поле step_price_curr. В потоки FORTS_FUTCOMMON_REPL и FORTS_OPTCOMMON_REPL в таблицу common добавлены поля для совокупного спроса и предложения: orders_sell_qty, orders_sell_amount, orders_buy_qty, orders_buy_amount. |
17.05.2010 | Добавлена информация о параметрах инструментов:
Добавлена информация о стоимости шага цены инструмента в вечерний клиринг – поле step_price_clr таблицы fut_sess_contents потока FORTS_FUTINFO_REPL, а также в пром. клиринг – поле step_price_interclr той же таблицы. |
19.04.2010 | Изменены типы многих полей, в частности:
Таблица money_clearing перенесена из потока FORTS_FUTINFO_REPL в поток FORTS_CLMONEY_REPL. Переименованы:
Добавлены:
Удалены:
|
16.03.2010 | Изменен описание команды FutAddRepo: • вместо параметра swap_price, теперь используется параметр repo_rate |
24.02.2010 | Добавлено:
|
18.01.2010 |
|
15.01.2010 |
|
25.11.2009 | Исправлен ряд ошибок в описании команд |
03.11.2009 | Добавлена поддержка задания кодов брокеров при отправке сообщений |
30.10.2009 | Добавлены команды управления лимитами клиентов |
10.08.2009 | Добавлены справочники инструментов по опционам |
15.07.2009 | Добавлено описание справочных потоков репликации |
17.06.2009 | Добавлено описание команд управления заявками для фьючерсов и опционов |
27.03.2009 | Добавлено описание потоков репликации ‘common’ |
20.03.2009 | Первая версия документа |
Целью документа является освещение всего комплекса информации, необходимой пользователям при проектировании и разработке программного обеспечения для доступа на срочный рынок с использованием ПО PLAZA II шлюз (SPECTRA). В документе рассматриваются следующие вопросы:
Общий обзор системы SPECTRA — торговые инструменты, участники торгов, торговые операции, управление рисками и лимитирование операций и т.п.
Состав, установка и настройка ПО PLAZA II шлюз. Приводится описание действий пользователя по установке и настройке ПО, требований к аппаратной и программной инфраструктурам, а также даются общие рекомендации по использованию программного обеспечения.
Состав транслируемой информации. Приводится описание потоков репликации и транслируемых таблиц.
Перечень управляющих команд.
Справочные данные.
Данный документ предназначен для бизнес-аналитиков, системных архитекторов и программистов, участвующих в проектировании и разработке программного обеспечения для доступа на срочный рынок с использованием ПО PLAZA II шлюз.
В рамках настоящего документа используются следующие сокращения:
Термин | Определение |
---|---|
ASTS ФР | Торгово-клиринговая система фондового рынка |
COD | Сервис "Cancel On Disconnect" |
SMA | Сервис "Sponsored Market Access" |
БА | Базовый актив |
БФ | Брокерская фирма |
ВМ | Вариационная маржа |
ВПТС | Внешнее программное техническое средство |
ГО | Гарантийное обеспечение |
ММ | Маркет-мейкер |
НКД | Накопленный купонный доход |
НКЦ | Национальный Клиринговый Центр |
ОБФ | Обособленная Брокерская фирма |
ПО | Программное Обеспечение |
РФ | Расчетная фирма |
СУР | Система управления рисками |
ТКС | Торгово-клиринговый счёт |
ТС | Торговая система |
УК | Участник клиринга |
УТ | Участник торгов |
ЦБ | Ценная бумага |
Субъекты (участники) торгов это:
Участники клиринга (Расчетные фирмы)
Участники торгов (Брокерские фирмы)
Клиенты участников торгов и участников клиринга
Обычно участник торгов и участник клиринга - это одно и то же лицо, он заключает сделки и является стороной по заключенным сделкам, ниже речь пойдет именно о таких участниках, однако, начиная с версии SPECTRA 6.2 на срочном рынке реализован проект по разделению статусов участников торгов и участников клиринга, где функции участников могут быть выделены в явном виде. Более подробно о разделении статусов участников можно ознакомиться в разделе 2.7. Разделение статусов участников торгов и участников клиринга. Обращаем внимание, что реализованный SPECTRA 6.2 проект по разделению статусов участников торгов и участников клиринга никоим образом не затрагивает существующих участников торгов, для них порядок организации торгов остается прежним.
Расчетные фирмы — это организации, непосредственно несущие ответственность и покрывающие риски своих клиентов и субброкеров.
Расчетные фирмы имеют возможности:
Совершать сделки от своего имени и за свой счет.
Совершать сделки от своего имени и за счет обслуживаемых клиентов.
Вести расчеты с НКЦ напрямую.
Обслуживать клиентов, в том числе и брокерские фирмы.
Контролировать работу клиентов и брокерских фирм в ходе торгов.
Расчетные фирмы несут обязательства:
Членство в Секции срочного рынка.
Взнос в Гарантийный фонд.
Гарантийное обеспечение собственных сделок и сделок своих клиентов.
В отличие от расчетных фирм, брокерские фирмы не рассчитываются по операциям напрямую с биржей, а рассчитываются со своей расчетной фирмой, для брокеров нет требований по наличию лицензий и по внесению средств в Гарантийный фонд.
Брокерские фирмы имеют возможности:
Совершать сделки за свой счет.
Совершать сделки за счет обслуживаемых клиентов.
Выставлять заявки в Торговой системе с клиентского терминала.
Контролировать работу своих клиентов в ходе торгов.
Брокерские фирмы несут обязательства:
Гарантийное обеспечение собственных сделок и сделок своих клиентов.
Любое юридическое и физическое лицо может принимать участие в торгах на рынке фьючерсов и опционов SPECTRA в качестве клиента. Для этого необходимо заключить договор на торговое обслуживание с брокерской фирмой или непосредственно с расчетной фирмой. Важным атрибутом клиента служит ИНН или номер паспорта.
Участники торгов в системе кодируются с помощью семисимвольной строки вида:XXYYZZZ, где
XX — код расчетной фирмы
YY — код брокерской фирмы
ZZZ — код клиента
Код брокерской фирмы 00 предназначен для отражения состояния самой расчетной фирмы.
Код Клиента 000 предназначен для отражения состояния брокерской фирмы.
Пример 2.
Q1DU000 – код для представления состояния денежных средств субброкера DU расчетной фирмы Q1
Список расчетных и брокерских фирм доступен в таблице dealer потока FORTS_REFDATA_REPL. Список клиентов доступен в таблице investor потока FORTS_REFDATA_REPL. Раскрытие информации о клиентах и брокерах ограничено правами пользователя, запрашивающего информацию.
Кроме того, в различных потоках и таблицах есть ссылки на семисимвольные коды участников или на четырехсимвольные коды брокеров.
Пользователь или логин в системе может быть привязан к разным уровням иерархии участников:
Логин расчетной фирмы. Имеет возможность просматривать информацию и (при наличии транзакционных прав) совершать торговые операции от имени любого брокера или клиента данной расчетной фирмы, а также вызывать операции для установки различных лимитов, как для клиентов, так и для субброкеров.
Логин брокерской фирмы. Имеет возможность просматривать информацию и совершать торговые операции от имени всех клиентов брокера внутри расчетной фирмы, а также устанавливать лимиты клиентам этого брокера.
Логин клиента. Имеет возможность совершать торговые операции от имени конкретного клиента внутри брокерской фирмы и просматривать информацию по этому клиенту.
В схеме сообщений-команд (см. раздел Описание команд) есть поле 'broker_code'. Приложение, использующее логин уровня расчетной фирмы, обязано при отправке сообщения заполнять это поле четырехсимвольным кодом брокера SPECTRA. Приложения, использующие логины уровня брокера или клиента, заполнять это поле не обязаны.
Инструменты в системе SPECTRA имеют иерархическую структуру. Далее приведено описание инструментов, начиная с корневого уровня иерархии.
Базовый актив представляет собой сущность, к которой привязывается конкретный контракт — акцию, которую необходимо будет передать или получить для инструментов фондовой секции, товар — для инструментов товарной секции или индекс/курс валюты/индикатор для расчетных фьючерсов. Базовый актив содержит атрибуты, общие для всех инструментов, привязанных к нему, а именно:
Наименование торговой секции.
Разнообразные ставки комиссий.
Тип поставки по контрактам (подробнее – см. раздел, Поставка активов и экспирация опционов):
поставка собственно актива;
расчетный тип — по итогам обращения перечисляются только денежные средства в размере разницы между стоимостью открытия позиции и расчетной ценой актива.
Валюта для расчета стоимости шага цены. В настоящий момент может принимать значения:
RUR — стоимость шага цены указывается в рублях и, как правило, не меняется в течение всего срока действия контракта.
USR — стоимость шага цены указывается в рублях, с пересчетом по курсу доллара, рассчитываемого по методике Московской Биржи: http://moex.com/n6126
Стоимость шага цены изменяется два раза в день — при клиринге и при промежуточном клиринге.
Форма торгов — с залогом или без. При торговле с залогом часть депозита под позицию можно вносить путем передачи НКЦ в залог акций и других ценных бумаг из утвержденного списка.
Базовый актив НЕ ЯВЛЯЕТСЯ ТОРГОВЫМ инструментом.
Информация о базовых активах содержится в таблице fut_vcb потока FORTS_REFDATA_REPL.
Фьючерсные контракты — основной тип торговых инструментов в системе SPECTRA.
Фьючерсы привязаны к конкретному базовому активу. Каждый фьючерс имеет уникальные атрибуты срочности (даты поставки), лота, шага цены и стоимости шага цены.
Даты поставки фьючерсов в торговой системе назначаются с трехмесячным (квартальные фьючерсы) или месячным (месячные фьючерсы) интервалом. Для каждого базового актива может быть создано несколько торгуемых фьючерсов с разными датами исполнения.
Фьючерсы с разными датами исполнения на один и тот же актив могут входить в так называемый межмесячный или календарный спред. В этом случае, при расчете рисков учитывается корреляция цен на такие фьючерсы между собой и гарантийное обеспечение под позицию, состоящую из нескольких фьючерсов, входящих в спред может быть затребовано меньше, чем сумма обеспечений под каждую отдельную позицию.
Фьючерсы котируются в пунктах цены. Цена в рублях за контракт вычисляется как:
, где
PricePoints — цена в пунктах;
step_price — стоимость минимального шага цены;
min_step — минимальный шаг цены в пунктах.
Для фьючерсов с валютой стоимости шага USR, заполняются еще три дополнительных поля:
Стоимость шага цены в исходной валюте (т.е. в долларах США);
Стоимость шага цены в рублях, зафиксированная для промежуточного клиринга;
Стоимость шага цены в рублях, зафиксированная для клиринга.
Каждый торговый инструмент при появлении в системе недоступен для торгов в ближайшие дополнительные торговые сессии (вечернюю и утреннюю), и начинает быть доступным для торгов только в основную торговую сессию (подробнее о торговых сессиях см. раздел Расписание торгов и клиринга). О доступности инструмента для торговли в основную или дополнительные торговые сессии можно узнать из поля signs (признаки) таблицы fut_sess_contents.
Информация о фьючерсах содержится в трех таблицах торгового интерфейса:
Поток FORTS_REFDATA_REPL, таблица fut_sess_contents — основная таблица. Содержит список контрактов, назначенных в торги в данной торговой сессии.
Поток FORTS_REFDATA_REPL, таблица fut_instruments — содержит урезанную информацию обо всех фьючерсных контрактах в торговой системе, в том числе неторгуемых.
Поток FORTS_INFO_REPL, таблица futures_params — содержит информацию о фьючерсах в формате, необходимом для загрузки ее в клиентский модуль расчета рисков (SpectraIM).
В ТС SPECTRA существуют фьючерсы, которые по своему поведению несколько отличаются от обычных - это однодневные фьючерсные контракты с автопролонгацией. Близкими аналогами таких контрактов на рынке могут служить CFD (Contract For Difference) или NDF (Non-Deliverable Forward).
Базисными активами однодневных фьючерсов являются курсы иностранных валют по отношению к российскому рублю, фондовые индексы, рассчитываемые ПАО Московская Биржа, товары (драгоценные металлы) и акции российских эмитентов.
Основные особенности таких инструментов:
У однодневного фьючерса нет даты исполнения ("вечный" фьючерс). Технически же последняя дата торгов будет установлена далеко в будущем.
Расчетные цены формируются на основании рыночных данных с Валютного и Фондового рынков Московской биржи.
Вариационная маржа вечернего клиринга определяется с учетом дополнительной составляющей: ставки фондирования при отклонении цены контракта от цены БА больше заданного на контракте уровня (SwapRate). Значение ставки публикуется в шлюзе в таблице fut_sess_settl потока FORTS_CLR_REPL в поле swap_rate.
Для индикативной вариационной маржи ставка фондирования рассчитывается отдельно и публикуется в шлюзе в таблице common потока FORTS_COMMON_REPL в поле swap_rate.
Для вечных фьючерсов на фондовый индекс или акцию вариационная маржа вечернего клиринга рассчитывается с учетом дивидендной поправки, которая компенсирует изменение значения индекса или стоимости акции, вызванное дивидендными отсечками. Дивидендная поправка учитывается в день закрытия реестра по позиции на предыдущий вечерний клиринг и по сделкам в вечернюю сессию, по сделкам в течение утренней и основной сессий поправка не учитывается. Если день закрытия реестра приходится на неторговый день, то поправка учитывается в ближайший торговый день, предшествующий дню закрытия реестра. Значение поправки публикуется в шлюзе в таблице fut_sess_settl потока FORTS_CLR_REPL в поле index_div.
Формулы и детальное описание можно найти в спецификациях контрактов.
В справочнике торгуемых инструментов однодневные фьючерсы помечаются специальным признаком (бит 0x4000 в поле signs таблицы fut_sess_contents потока FORTS_REFDATA_REPL).
Еще одним типом производных финансовых инструментов в системе SPECTRA являются опционы. В отличие от фьючерсов опцион означает не обязанность, а право на покупку (продажу) базового актива, которое может быть реализовано или нет.
Различают колл и пут опционы. Опцион колл (опцион на покупку) – контракт, предоставляющий держателю (покупателю) опциона право купить базовый актив в указанный срок в будущем по фиксированной цене – цене исполнения опциона (страйк). Опцион пут (опцион на продажу) – контракт, предоставляющий держателю (покупателю) опциона право продать базовый актив в указанный срок в будущем по фиксированной цене – цене исполнения опциона (страйк). В качестве базового актива для опционов могут служить активы фондового и валютного рынков (акции, индексы, валюта и т.п.), а так же срочные фьючерсные контракты.
Опционы могут быть маржируемого типа, с уплатой вариационной маржи между участниками торгов на основании расчетной цены, определяемой дважды в торговую сессию, и премиального типа, с уплатой премии подписчику опциона в момент совершения сделки (в ближайший клиринг).
По способу исполнения опционы подразделяются на европейские и американские. Европейские опционы можно исполнить только в день истечения срока действия опциона (дату экспирации). Американские опционы отличаются тем, что держатель может реализовать свое право на продажу/покупку базового актива в любой момент, не дожидаясь наступления даты истечения опциона.
Опционы могут быть поставочными и расчетными. Поставочный опцион предусматривает физическую поставку. Расчетный опцион не предполагает поставки, а предусматривает перерасчет прибыли/убытков между участниками в виде начисления и списания денежных средств.
В настоящий момент в системе SPECTRA поддерживаются американские маржируемые поставочные опционы на фьючерсы и европейские премиальные расчетные опционы на спот-активы (акции, индексы, валюту и т.п.) и фьючерсы.
Опционы также как и фьючерсы имеют разные даты исполнения, но в отличие от фьючерсов существуют недельные опционы, с исполнением в середине ближайшей недели и в ВК пятницы (опционы на акции американских компаний).
Для опционов в торги назначается некоторое подмножество страйков, которое лежит в окрестности текущей расчетной цены базового актива, к которому привязан опцион, поэтому список опционов, назначенных в торги, в общем случае каждый день может быть разным.
Информация об опционах содержится в следующих таблицах торгового интерфейса:
Поток FORTS_REFDATA_REPL, таблица opt_sess_contents — основная таблица. Содержит список контрактов, назначенных в торги в данной торговой сессии.
Поток FORTS_REFDATA_REPL, таблица opt_vcb — содержит справочник базовых контрактов для опционов.
Поток FORTS_REFDATA_REPL, таблица sess_option_series — содержит список опционных серий.
Поток FORTS_INFO_REPL, таблица options_params — содержит информацию об опционах в формате, необходимом для загрузки ее в клиентский модуль расчета рисков (SpectraIM).
Поток FORTS_INFO_REPL, таблица option_series_params — содержит параметры опционных серий.
Торговая система SPECTRA поддерживает составные инструменты — инструменты, которые состоят из нескольких взаимосвязанных частей (атомарных инструментов), что позволяет реализовывать широко используемую стратегию торговли на рынке, когда при выполнении сделки по связке у клиента появляются позиции по двум или более инструментам. В настоящий момент в виде составных инструментов реализованы календарные спреды на фьючерсы.
Список имеющихся в системе составных инструментов можно получить из таблицы fut_sess_contents потока FORTS_REFDATA_REPL, проверяя поле multileg_type. Записи, со значением этого поля не равным 0, описывают составные инструменты.
Для получения составных частей инструмента следует пользоваться таблицей multileg_dict потока FORTS_REFDATA_REPL, в которой для каждого составного инструмента существует две или более записей, описывающей отдельные части такого инструмента (Рис. 1). Записи таблицы multileg_dict ссылаются обратно в fut_sess_contents, т.к. составные части инструментов являются обычными инструментами торговой системы. Для каждой составной части также указывается коэффициент, на который умножается объём исходной заявки для получения объёма заявки по составной части. Знак этого коэффициента указывает на направление заявки по составляющей — положительное значение означает, что составляющая будет направлена в ту же сторону, что и заявка по составному инструменту, отрицательное — в противоположную сторону.
В системе SPECTRA инструмент имеет четыре идентификатора:
Поле isin_id — уникальный числовой идентификатор инструмента в системе.
Поле isin — символьный идентификатор инструмента.
Поле short_isin — короткий символьный код инструмента для информационных систем.
Поле name — длинное "человекочитаемое" наименование инструмента.
Пример 3. Фьючерс на индекс РТС с исполнением в декабре 2010 года:
isin_id=
isin = RTS-12.10
short_isin = RIZ0
name = Фьючерсный контракт на индекс РТС с исполнением 15 декабря 2010 г.
Значение isin_id — первичный уникальный идентификатор инструмента в системе. Во всех структурах данных, содержащих ссылку на инструмент, используется именно это значение.
Поле isin — основной символьный код контракта. Именно этот код указывается в команде на постановку заявки. Гарантируется уникальность и неизменность во времени значения isin.
Поле short_isin — альтернативный символьный код контракта. Было введено для упрощения работы с данными SPECTRA мировым информагентствам.
Заявка - это приказ участника торгов в торговую систему на совершение сделки покупки или продажи инструмента по определённой цене. Заявка может быть адресной или безадресной.
Безадресные заявки - это обычный вид заявок, которые встают в очередь и видны всем пользователям, они обязательно участвуют в аукционе и сводятся со встречными заявками. Если у заявки есть контрпредложение с ценой лучшей или равной цене заявки, то такие заявки сводятся в сделку с ценой равной цене заявки в контрпредложении. Часть заявки, которая не свелась в сделку остается в виде заявки, с меньшим количеством инструмента.
Заявки бывают котировочные (Day), встречные (Immediate-or-Cancel), заявки Fill-or-Kill и заявки Book-or-Cancel. Котировочная заявка (Day) остается в очереди независимо от того, свелась ли она частично, или не свелась совсем. Встречная заявка (IOC), если она не свелась в сделку, удаляется из системы после проведения аукциона. При частичном сведении встречной заявки, несведенная ее часть также удаляется. Заявки Fill-or-Kill (FOK) - это встречные заявки, которые предполагают только полное исполнение (сведение в сделку). Заявка Book-or-Cancel (BOC) - это разновидность котировочной заявки, которая при выставлении либо целиком встает в стакан, либо отклоняется системой. Такая заявка может быть только пассивной стороной в сделке (Maker).
С точки зрения времени жизни заявки подразделяются на обычные и многодневные (Good-till-Date). У обычных заявок дата истечения заявки не задана, такие заявки (неисполненные) "живут" до конца текущей торговой сессии. Для многодневных заявок указывается дата истечения (диапазон дат - до года). Такие заявки автоматически перевыставляются в следующую торговую сессию, получая при этом новый номер и ссылку на номер самой первой выставленной заявки. При перевыставлении делаются проверки на наличие инструмента, клиента, достаточности средств. Заявки с истекшей датой автоматически снимаются после завершения вечерней сессии (если она есть в этот день).
Для нужд разработчиков в заявках предусмотрены два дополнительных атрибута:
поле comment - строка в 20 символов;
поле ext_id - четырехбайтовое число, куда предполагается вставлять идентификатор заявки в пользовательской системе.
Примечание: Уникальность значений дополнительных атрибутов заявки торговой системой SPECTRA не анализируется.
Информация о заявках содержится в таблицах orders_log потоков FORTS_TRADE_REPL и FORTS_ORDLOG_REPL.
Таблица orders_log - это история изменений заявок, на каждое изменение заявки добавляется отдельная запись. В таблице orders_log потока FORTS_TRADE_REPL содержится информация только по "своим" заявкам. Под своими заявками здесь понимается:
Для логина клиента - это заявки только этого клиента.
Для логина БФ или РФ - это все заявки клиентов этой БФ или РФ.
Данные по своим заявкам раскрываются полностью, включая служебные и пользовательские поля.
При желании пользователь может подписаться на получение таблицы orders_log потока FORTS_ORDLOG_REPL, в этом случае он будет получать всю историю изменений по всем заявкам в системе в анонимном виде.
Возможны следующие операции над заявками:
Добавление заявки.
Удаление заявки (по коду заявки в системе SPECTRA).
Передвижка заявки (операция MoveOrder). Передвижка заявки реализована как пара операций - удаление старой заявки и добавление новой заявки (с новым номером). Соответственно пользователю в ответном сообщении на операцию MoveOrder всегда возвращается номер новой заявки. Операции MoveOrder в таблице orders_log всегда соответствует как минимум две записи - удаление и добавление.
Одной операцией MoveOrder можно одновременно передвинуть две заявки (полезно для маркет-мейкеров), для этого в методе MoveOrder предусмотрен набор параметров (order_id1, order_id2) для двух заявок. При этом сам метод является универсальным - если двигается одна заявка, заполняются параметры только для order_id1.
Массовое удаление своих заявок по заданным пользователем условиям. В качестве условий могут быть заданы:
Направление операции - покупка, продажа.
Тип заявки - адресная, безадресная.
Код клиента.
Код базового актива.
ext_id - идентификатор заявки в пользовательской системе.
Код инструмента.
Группа инструментов - фьючерсы, опционы, составные инструменты.
Адресная заявка - это заявка, адресованная конкретному пользователю. По сравнению с безадресными эти заявки имеют некоторые ограничения в возможности управления заявками и в выборе контрагента:
Выставление адресной заявки возможно только от логина брокерской фирмы. При выставлении адресной заявки в качестве контрагента можно указать только брокерскую фирму.
Для определения контрагента в заявке указывается код РТС компании-контрагента (поле broker_to). Не все брокерские фирмы имеют такой код, соответственно, этим фирмам нельзя выставить адресную заявку.
Для адресных заявок невозможна операция MoveOrder. Можно только вручную удалить и выставить новую заявку.
В адресных заявках нельзя указывать дату истечения заявки, т.е. они не могут быть многодневными (GTD).
Адресные заявки сводятся в сделку при условии точного совпадения в них значения поля match_ref (см. описание поля в разделе Метод AddOrder - Добавление заявок ). Возможно частичное сведение адресных заявок.
В данном режиме участники выставляют адресные заявки с обязательным заполнением поля match_ref и указанием в поле broker_to кода НКЦ (код фирмы с флагом dealer.status 0x10000 – НКЦ). В поле match_ref задается уникальная последовательность символов, о которой стороны сделки отдельно (вне торговой системы) договариваются, что она будет использоваться в их заявках. Сведение заявок в сделки осуществляется по совпадению значений поля match_ref в заявках. Совпадение значения поля match_ref является подтверждением согласия контрагентов на совершение сделки на условиях, указанных в сделке. В режиме "Адресный режим с мэтчингом по уникальному коду" контрагент скрыт на всех этапах заключения и обработки сделки (заявка, мэтчинг, сделка, отчеты).
В остальном адресные заявки в таком режиме торгов имеют те же ограничения, что и обычные адресные заявки. Для отличия таких заявок от обычных адресных у них в дополнение к признаку Address (0x4000000) выставляется флаг NegotiatedMatchByRef (0x80000000).
Сделки в торговой системе заключаются после постановки заявок в случае, если цена в заявке одного направления по инструменту удовлетворяет цене заявки другого направления по тому же инструменту. Ценой сделки считается цена заявки, выставленной раньше. Сделки бывают адресные и безадресные. Многие атрибуты сделок эквивалентны атрибутам заявок. Сделки не изменяются и не удаляются из системы.
Информация о собственных сделках содержится в таблицах user_deal и user_multileg_deal потока FORTS_TRADE_REPL. Данные в таблицах представлены в отфильтрованном виде: пользователь видит приватную информацию только по своей части сделки (покупателя или продавца). Если пользователем является БФ или РФ и сделка совершена ее клиентами, то пользователь видит приватную информацию по обеим частям сделки. Информация обо всех сделках в системе раздается всем пользователям в таблицах deal и multileg_deal потока FORTS_DEALS_REPL. Данные в таблицах представлены в анонимном виде.
Помимо чисто торговых сделок в таблицах сделок содержатся дополнительные записи, которые в юридическом смысле сделками не являются, но отражают некоторые операции в системе, меняющие позиции участника. Данные сделки называются техническими. Отличить торговые сделки от технических можно по значению полей xstatus_sell и xstatus_buy таблиц user_deal и user_multileg_deal потока FORTS_TRADE_REPL или по признаку nosystem в таблицах deal и multileg_deal потока FORTS_DEALS_REPL (подробнее - см. раздел Признаки, выставляемые у заявок и сделок).
Кросс-сделка - сделка на основании заявок, поданных с одного и того же клиентского раздела, либо поданных с разных разделов с одинаковым ИНН. По умолчанию совершение кросс-сделок запрещено, заявка, наткнувшаяся на кросс-сделку, отклоняется системой. Допускается в индивидуальном порядке разрешение кросс-сделок для адресных заявок. Также в системе предусмотрена возможность, чтобы при кросс-сделке вместо отклонения вновь поступившей заявки (она же активная), снималась пассивная заявка, на которую она наткнулась.
Для определения логики обработки кросс-сделок в системе предусмотрено два флага:
"Разрешить кросс-сделки" - Разрешает кросс-сделки для адресных заявок. Чтобы кросс-сделка прошла данный флаг должен быть выставлен у обоих сторон сделки. В безадресном режиме совершение кросс-сделок запрещено всегда.
"Снять пассивную заявку при кросс-сделке" - Разрешает при кросс-сделке вместо отклонения вновь поступившей (она же активная) заявки снимать пассивную, на которую она наткнулась. Снятие пассивной заявки подразумевает продолжение сведения активной заявки в рамках транзакции. Если в процессе сведения транзакция не может завершиться успешно, то снятые пассивные заявки восстанавливаются.
Указанные флаги выставляются на уровне семизначного клиентского раздела на основании заявления участника. Выставленные флаги транслируются в шлюзе в поле xstatus таблицы investor потока FORTS_REFDATA_REPL.
Ниже в таблице приведены сценарии поведения безадресных заявок, приводящих к кросс-сделкам, для различных типов заявок и значений флага "Снять пассивную заявку при кросс-сделке":
Тип активной заявки | Флаг у клиентского раздела - автора пассивной заявки | Сценарии |
---|---|---|
Котировочная заявка (Day) | "Снять пассивную заявку при кросс-сделке"=НЕТ | Пассивная: Остается в стакане. Активная: В процессе сведения доходит до заявки с таким же ИНН, затем откатывается обратно по всем предварительно сведенным заявкам. |
"Снять пассивную заявку при кросс-сделке"=ДА | Пассивная: Снимается. Активная: В процессе сведения доходит до пассивной с тем же ИНН, инициирует снятие пассивной, продолжает сведение далее в стакане или остается как котировочная в стакане.Если далее в транзакции сведение активной заявки не может завершиться успешно (например, по причине встречи с еще одной кроссовой заявкой, по которой нет разрешения снимать ее), то все заявки, включая кроссовую пассивную, восстанавливаются. | |
Встречная заявка (IOC) | "Снять пассивную заявку при кросс-сделке"=НЕТ | Пассивная: Остается в стакане. Активная: В процессе сведения доходит до заявки с таким же ИНН, затем остаток снимается. |
"Снять пассивную заявку при кросс-сделке"=ДА | Пассивная: Снимается только в том случае, если активная может свестись хотя бы один раз со следующей в очереди после кроссовой. Активная: В рамках одной транзакции доходит до пассивной с тем же ИНН, инициирует предварительное снятие пассивной, затем продолжает сведение со следующими заявками в очереди из стакана.Если после снятия пассивной, в рамках данной транзакции, не произошло ни одного сведения, то остаток активной IOC снимается, а пассивная восстанавливается. | |
Заявка Fill-or-Kill (FOK) | "Снять пассивную заявку при кросс-сделке"=НЕТ | Пассивная: Остается в стакане. Активная: В процессе сведения доходит до заявки с таким же ИНН, затем откатывается обратно по всем предварительно сведенным заявкам. |
"Снять пассивную заявку при кросс-сделке"=ДА | Пассивная: Снимается только в том случае если активная может свестись полностью. Активная: В рамках одной транзакции доходит до пассивной с тем же ИНН, инициирует предварительное снятие пассивной, продолжает сведение далее в стакане.Если полный объем не собран по активной, то все предварительно сведенные и снятые пассивные заявки восстанавливаются обратно в стакан. |
Для адресных заявок логика обработки ситуаций с кросс-сделками аналогична. Если кросс-сделки не разрешены (нет признака "Разрешить кросс-сделки" у кого-либо из контрагентов), то в зависимости от значения признака "Снять пассивную заявку при кросс-сделке" у контрагента - автора пассивной заявки (НЕТ/ДА), отклоняется активная заявка либо снимается пассивная.
В случае синтетического матчинга, два стакана с заявками анализируются независимо – т.е. могут быть сняты как одна так и две пассивные заявки. Если для обеих пассивных заявок снятие не разрешено ("Снять пассивную заявку при кросс-сделке"=НЕТ), то отклоняется активная заявка, иначе снимаются (независимо) пассивные заявки, для которых снятие разрешено ("Снять пассивную заявку при кросс-сделке"=ДА).
У снятых пассивных кросс-заявок в поле xstatus выставляется отличительный признак DueToCrossCancel (0x2000).
Торговая система SPECTRA поддерживает составные инструменты (связки) - инструменты, которые состоят из нескольких взаимосвязанных частей (атомарных инструментов), что позволяет реализовывать широко используемую стратегию торговли на рынке, когда при выполнении сделки по связке у клиента появляются позиции по двум или более инструментам. В настоящий момент в виде составных инструментов реализованы календарные спреды на фьючерсы.
Основные особенности торговли связками:
Порядок сортировки цен в стаканах может быть различным (прямой или обратный).
При выставлении заявки по связке у клиента возникают обязательства по двум или более атомарным инструментам, следовательно, расчет обеспечения под такую позицию будет производиться соответствующим образом.
Для связок невозможна операция передвижки заявок.
Айсберг-заявка - это разновидность котировочной заявки, у которой определенная часть объема скрыта от рынка (т.е. в стакане), чтобы минимизировать влияние на рыночную цену крупных относительно рынка заявок. Айсберг-заявки появляются в стакане порциями (видимая часть). Когда видимая часть заявки полностью сводится в сделки, тогда "всплывает" очередная порция. Так может повторяться до тех пор, пока вся скрытая часть заявки не будет исчерпана.
Основные особенности айсберг-заявок:
Айсберг-заявки могут быть только безадресными. С точки зрения времени жизни айсберг-заявки могут быть обычными и многодневными. По типам айсберг-заявки делятся на котировочные (Day) и заявки Book-or-Cancel.
При добавлении айсберг-заявки в ней дополнительно указываются параметры для расчета размера всплывающей части. Всплывающая часть состоит из постоянной составляющей (disclose_const_amount) и случайным образом рассчитываемой надбавки. Значение надбавки - это случайная величина с равномерным распределением из диапазона [-Round(disclose_const_amount * variance_amount/100, 0); Round(disclose_const_amount * variance_amount/100, 0)], где variance_amount - амплитуда отклонения от объема постоянной части. Соответственно, при добавлении айсберг-заявки в ней указываются два параметра:
disclose_const_amount - объем постоянной всплывающей части. Данный параметр не может быть больше объема всего айсберга, и меньше некого минимального значения, определяемого в зависимости от базового актива и типа инструмента (значения публикуются на сайте биржи).
variance_amount - величина случайного отклонения объема всплывающей части айсберг-заявки (опционально). Значение параметра также ограничено снизу нулем, сверху - числом, публикуемым на сайте. По умолчанию параметр не задан.
Все указываемые параметры могут принимать только целые и положительны значения.
Гарантийное обеспечение при добавлении заявки блокируется под весь объем айсберг-заявки.
При изменении выставленной айсберг-заявки меняться может только цена, объем не доступен для изменения.
При удалении или изменении айсберг-заявки удаляется или меняется вся айсберг-заявка целиком, включая видимую часть.
В таблицах своих заявок и сделок айсберг-заявки и сделки по ним в полях xstatus и xstatus_sell / xstatus_buy помечаются специальным признаком "Iceberg" (0x800000000000).
Айсберг образует два представления заявки: публичное - это видимая часть айсберг-заявки, и приватное - вся айсберг-заявка целиком, включая видимую часть. Соответственно, в таблицах своих заявок и сделок предусмотрены два набора полей (ID заявки, количество в операции, остаток, действие и др.):
Публичные данные транслируются в полях с префиксом "public_":
Таблицы orders_log и multileg_orders_log:
public_order_id - Номер видимой части айсберг-заявки.
public_amount - Количество контрактов в операции c видимой частью айсберг-заявки.
public_amount_rest - Оставшееся количество контрактов в видимой части айсберг-заявки.
public_action - Действие с видимой частью айсберг-заявки.
Таблицы user_deal и user_multileg_deal:
public_order_id_buy - Номер видимой части айсберг-заявки покупателя.
public_order_id_sell - Номер видимой части айсберг-заявки продавца.
Приватные данные транслируются в полях с префиксом "private_":
Таблицы orders_log и multileg_orders_log:
private_order_id - Идентификационный номер всей айсберг-заявки.
private_amount - Количество контрактов в операции со всей айсберг-заявкой.
private_amount_rest - Оставшееся количество контрактов во всей айсберг-заявке.
private_action - Действие в отношении всей айсберг-заявки.
Таблицы user_deal и user_multileg_deal:
private_order_id_buy - Идентификатор всей айсберг-заявки покупателя.
private_order_id_sell - Идентификатор всей айсберг-заявки продавца.
Ниже приведен пример записи в потоке выставления и матчинга айсберг-заявки с amount=1000 и видимой частью, равной 100 (без фильтрации):
public_ order_id | public_ amount | public_ amount_ rest | public_ action | price | moment | dir | client_ code | private_ order_id | private_ amount | private_ amount_ rest | private_ action | comment |
---|---|---|---|---|---|---|---|---|---|---|---|---|
101 | 100 | 100 | 1 | 312 | 2019-01-11 11:55:58 | 1 | OD01123 | 101 | 1000 | 1000 | 1 | Add Iceberg |
102 | 1 | 1 | 1 | 312 | 2019-01-11 14:56:58 | 1 | PJ99888 | 102 | 1 | 1 | 1 | Add standard Order |
103 | 250 | 250 | 1 | 310 | 2019-01-11 16:58:58 | 2 | FS01020 | 103 | 250 | 250 | 1 | Add standard Order |
101 | 100 | 0 | 2 | 312 | 2019-01-11 16:58:58 | 1 | OD01123 | 101 | 100 | 900 | 2 | Match Iceberg |
103 | 100 | 150 | 2 | 310 | 2019-01-11 16:58:58 | 2 | FS01020 | 103 | 100 | 150 | 2 | Match standard Order |
102 | 1 | 0 | 2 | 312 | 2019-01-11 16:58:58 | 1 | PJ99888 | 102 | 1 | 0 | 2 | Match standard Order |
103 | 1 | 149 | 2 | 310 | 2019-01-11 16:58:58 | 2 | FS01020 | 103 | 1 | 149 | 2 | Match standard Order |
104 | 100 | 100 | 1 | 312 | 2019-01-11 16:58:58 | 1 | OD01123 | 101 | 100 | 900 | 3 | Pop-up Iceberg |
104 | 100 | 0 | 2 | 312 | 2019-01-11 16:58:58 | 1 | OD01123 | 101 | 100 | 800 | 2 | Match Iceberg |
103 | 100 | 49 | 2 | 310 | 2019-01-11 16:58:58 | 2 | FS01020 | 103 | 100 | 49 | 2 | Match standard Order |
105 | 100 | 100 | 1 | 312 | 2019-01-11 16:58:58 | 1 | OD01123 | 101 | 100 | 800 | 3 | Pop-up Iceberg |
105 | 49 | 51 | 2 | 312 | 2019-01-11 16:58:58 | 1 | OD01123 | 101 | 49 | 751 | 2 | Match Iceberg |
103 | 49 | 0 | 2 | 310 | 2019-01-11 16:58:58 | 2 | FS01020 | 103 | 49 | 0 | 2 | Match standard Order |
105 | 51 | 0 | 0 | 312 | 2019-01-11 17:00:58 | 1 | OD01123 | 101 | 751 | 0 | 0 | Cancel Iceberg |
Пояснения к таблице:
Клиент OD01123 выставляет айсберг-заявку объемом 1000 и видимой частью 100. В систему добавляется заявка (private_action=1) с идентификатором private_order_id=101, объемом айсберга private_amount=1000 и видимой частью public_amount=100.
Далее клиенты PJ99888 и FS01020 последовательно добавляют в систему свои обычные заявки, причем заявка клиента FS01020 - это заявка встречного направления, удовлетворяющая по цене двум предыдущим заявкам.
Происходит сведение видимой части айсберга (private_action=2) с заявкой встречного направления клиента FS01020, размер оставшегося айсберга private_amount_rest=900.
Далее сводятся обычные заявки клиентов PJ99888 и FS01020.
Всплывает следующая порция айсберг-заявки (private_action=3), которая тут же сводится (private_action=2) с оставшейся частью заявки клиента FS01020, размер оставшегося айсберга private_amount_rest=800.
Всплытие очередной порции айсберга (private_action=3) и сведение ее с остатками заявки клиента FS01020, размер оставшегося айсберга private_amount_rest=751.
Далее клиент OD01123 снял айсберг.
Обратите внимание, что при всплытии очередной порции айсберга, его видимая часть имеет номер (public_order_id), отличный от идентификатора самой айсберг-заявки (private_order_id).
Для обычных заявок приватные и публичные поля заполняются одинаковыми значениями и содержат привычные ID, количество в операции, остаток и код операции по заявке. Иллюстрация заполнения полей для примера, приведенного выше:
public_ order_id | public_ amount | public_ amount_ rest | public_ action | id_ord | xamount | xamount_ rest | action | private_ order_id | private_ amount | private_ amount_ rest | private_ action | comment |
---|---|---|---|---|---|---|---|---|---|---|---|---|
101 | 100 | 100 | 1 | 101 | 1000 | 1000 | 1 | 101 | 1000 | 1000 | 1 | Add Iceberg |
102 | 1 | 1 | 1 | 102 | 1 | 1 | 1 | 102 | 1 | 1 | 1 | Add Order |
103 | 250 | 250 | 1 | 103 | 250 | 250 | 1 | 103 | 250 | 250 | 1 | Add Order |
101 | 100 | 0 | 2 | 101 | 100 | 900 | 2 | 101 | 100 | 900 | 2 | Match Iceberg |
103 | 100 | 150 | 2 | 103 | 100 | 150 | 2 | 103 | 100 | 150 | 2 | Match Order |
102 | 1 | 0 | 2 | 102 | 1 | 0 | 2 | 102 | 1 | 0 | 2 | Match Order |
103 | 1 | 149 | 2 | 103 | 1 | 149 | 2 | 103 | 1 | 149 | 2 | Match Order |
104 | 100 | 100 | 1 | 101 | 100 | 900 | 3 | 101 | 100 | 900 | 3 | Pop-up Iceberg |
104 | 100 | 0 | 2 | 101 | 100 | 800 | 2 | 101 | 100 | 800 | 2 | Match Iceberg |
103 | 100 | 49 | 2 | 103 | 100 | 49 | 2 | 103 | 100 | 49 | 2 | Match Order |
105 | 100 | 100 | 1 | 101 | 100 | 800 | 3 | 101 | 100 | 800 | 3 | Pop-up Iceberg |
105 | 49 | 51 | 2 | 101 | 49 | 751 | 2 | 101 | 49 | 751 | 2 | Match Iceberg |
103 | 49 | 0 | 2 | 103 | 49 | 0 | 2 | 103 | 49 | 0 | 2 | Match Order |
105 | 51 | 0 | 0 | 101 | 751 | 0 | 0 | 101 | 751 | 0 | 0 | Cancel Iceberg |
В анонимных потоках заявок и сделок присутствуют только публичные поля, там всегда только видимая часть айсбергов.
Возможны следующие операции над айсберг-заявками
Добавление заявки (команда IcebergAddOrder).
Удаление заявки (команда IcebergDelOrder). Команда может отрабатывать как по public_order_id, так и по private_order_id.
Изменение заявки (команда IcebergMoveOrder). Команда может отрабатывать как по public_order_id, так и по private_order_id.
Внимание! Команды IcebergMoveOrder и IcebergDelOrder по public_order_id будут работать только, если видимая часть с таким номером еще есть в системе (не была сведена), в противном случае будет возвращена ошибка об отсутствии заявки с таким номером. Потому рекомендуем работать с айсберг-заявками по private_order_id.
При выставлении айсберг-заявки у нее идентификатор видимой части (public_order_id) и всей айсберг-заявки (private_order_id) совпадает. При всплытии новой части ей присваивается новый идентификатор (public_order_id), идентификатор всей айсберг-заявки не меняется. При изменении айсберг-заявки (move) у нее выставляется новый private_order_id.
Для многодневных (GTD) айсберг-заявок при перевыставлении в вечерний клиринг выставляется новая айсберг-заявка с новым private_order_id, у которой в качестве исходной заявки (поле id_ord1) указывается private_order_id самой первой айсберг-заявки.
Пример изменения идентификаторов заявки при операциях над айсберг-заявкой:
Операция | public_order_id | public_action | private_order_id | private_action | id_ord1 |
---|---|---|---|---|---|
Добавление | 100 | 1 | 100 | 1 | |
Сведение в сделку | 100 | 2 | 100 | 2 | |
Всплытие новой части | 105 | 1 | 100 | 3 | |
Перевыставление в ВК | 1106 | 1 | 1106 | 1 | 100 |
Передвижка (move) | 1106 | 0 | 1106 | 0 | 100 |
1200 | 1 | 1200 | 1 |
Пояснения к таблице:
Добавление - добавляется айсберг-заявка (private_action=1) с идентификатором private_order_id=100 и номером видимой части public_order_id=100.
Сведение в сделку - сведение видимой части айсберга (private_action=2) с заявкой встречного направления.
Всплытие новой части - при всплытии новой части (private_action=3) ей присваивается новый идентификатор public_order_id=105, идентификатор всей айсберг-заявки не меняется.
Перевыставление в ВК - при перевыставлении в вечерний клиринг выставляется новая айсберг-заявка (private_action=1) с новым private_order_id=1106, у которой в качестве исходной заявки (поле id_ord1=100) указывается private_order_id самой первой айсберг-заявки.
Передвижка (move) - при передвижке айсберг-заявки происходит удаление старой заявки (private_action=0) и добавление новой (private_action=1) с новым private_order_id=1200.
Значения "public_action":
0 - Заявка удалена
1 - Заявка добавлена
2 - Заявка сведена в сделку
Значения "private_action":
0 - Заявка удалена
1 - Заявка добавлена
2 - Заявка сведена в сделку
3 - Всплытие новой видимой части
В разрезе поставки фьючерсы бывают трех типов:
Расчетные фьючерсы (фьючерсы на индикаторы) — по итогам обращения перечисляются только денежные средства в размере разницы между стоимостью открытия позиции и текущей расчётной ценой актива. Поставка оформляется технической сделкой закрытия позиции, которая в таблице сделок помечается специальным признаком в полях xstatus_sell и xstatus_buy (подробнее — см. раздел Признаки, выставляемые у заявок и сделок).
Товарные фьючерсы (фьючерсы на реальные активы) — по итогам обращения перечисляются собственно активы и денежные средства. Поставка оформляется технической сделкой закрытия позиции, которая в таблице сделок помечается специальным признаком в полях xstatus_sell и xstatus_buy.
Фьючерсы на акции — при поставке позиция по фьючерсу превращается в позицию на рынке T+ в секторе "Основной рынок" Московской биржи. Поставка оформляется технической сделкой закрытия позиции на срочном рынке и сделкой открытия позиции на рынке T+. Сделка закрытия позиции на срочном рынке в таблице сделок помечается специальным признаком в полях xstatus_sell и xstatus_buy. Сделка открытия позиции на рынке T+ создаётся в системе ASTS фондового рынка. Более подробно см. подраздел "Реализация поставки фьючерсных контрактов срочного рынка на фондовом рынке (режим Т+2)".
Исполнение всех поставочных фьючерсных контрактов производится путём автоматического заключения сделок Т+2 в секторе "Основной рынок" Московской биржи (Торгово-клиринговая система ASTS).
В Клиринговой системе SPECTRA за каждой брокерской фирмой, которая желает проводить поставку, по заявлению Участника, закрепляется код фирмы и торгово-клиринговый счёт (далее – ТКС), зарегистрированные в Торгово-клиринговой системе фондового рынка (далее – ASTS ФР), с указанием которого должны быть заключены сделки Т+2 в целях исполнения обязательств по фьючерсным контрактам. За клиентским разделом регистра учета позиций может быть закреплён отдельный ТКС и код клиента, зарегистрированного в ASTS ФР.
Заранее по заявлению Участника регистрируются в SPECTRA три ТКС ФР (т.н. "любимые" ТКС): один для учета собственных обязательств, один для учета обязательств клиентов, один для учета обязательств ДУ. "Любимые" ТКС прикрепляются к БФ соответствующего типа по умолчанию.
Сделки Т+2 заключаются в ASTS ФР на отдельном режиме торгов (SPEQ) с кодом расчётов Y2. Сделка заключается между НКЦ и участником торгов фондового рынка. Никакого дополнительного подтверждения от участника торгов фондового рынка не требуется.
В случае, если сделка Т+2 не может быть заключена по причине отсутствия или неверных реквизитов привязки к фирме и ТКС, Участником до 15:00 МСК текущего дня должен быть закреплён за соответствующей брокерской фирмой действующий ТКС ФР. Если до 15:00 МСК Участник не закрепляет действующий ТКС, то в 15:00 МСК сделки Т+2 будут заключены с указанием "любимого" ТКС соответствующего типа (собственный, клиентский, ДУ). Если сделки Т+2 не могут быть заключены с указанием "любимого" ТКС (он также не указан или указан неверно), то обязательства участника клиринга по поставке по фьючерсу на акции в части позиций данной БФ считаются невыполненными, и взимается штраф в размере ГО по неисполненным фьючерсам.
После заключения сделок поставки по акциям в системе фондового рынка, в случае достаточности обеспечения под совокупную позицию на рынке T+2, фьючерсная позиция в системе SPECTRA закрывается, и обеспечение под эту позицию освобождается. В случае недостаточности обеспечения под совокупную позицию на рынке T+2, фьючерсная позиция и обеспечение под неё остаются заблокированными в системе SPECTRA до момента исполнения маржинального требования на рынке T+2.
После исполнения фьючерсов на акции технические сделки закрытия позиций по фьючерсам на акции транслируются в таблице сделок. Для этих сделок в полях xstatus_sell и xstatus_buy будут выставлены значения "Сделка исполнения фьючерса" (подробнее — см. раздел Признаки, выставляемые у заявок и сделок). Технические сделки, закрывающие фьючерсную позицию, будут также отображаться в отчётах срочного рынка f04.csv и fut_deal.csv в день их формирования.
Более подробную информацию по механизму реализации поставки вы можете найти на сайте – http://moex.com/s1262
В настоящий момент система SPECTRA поддерживает американские поставочные опционы на фьючерсы и европейские расчетные опционы на спот-активы (акции, индексы, валюту и т.п.) и фьючерсы.
При экспирации опциона позиция по опциону превращается в позицию по фьючерсу с ценой, равной страйку экспирируемого опциона. Экспирация опционов осуществляется в клиринговую сессию. Технически экспирация оформляется сделкой закрытия позиции по опциону и сделкой открытия позиции по фьючерсу, которые в таблице сделок помечаются специальным признаком в полях xstatus_sell и xstatus_buy (подробнее см. раздел Признаки, выставляемые у заявок и сделок).
Экспирация опционов возможна в двух режимах:
Досрочная, выполняемая по запросу участника. Покупатель может в любой момент предъявить продавцу требование об исполнении опциона, послав с систему поручение об экспирации (подробнее см. раздел Метод OptChangeExpiration — Поручения на экспирацию опционов). Поручения на экспирацию собираются в течение всей торговой сессии, но исполняются два раза в день — в промежуточный клиринг и в вечерний клиринг.
Автоматическая, в день завершения обращения опциона. В последний день обращения опционы, находящиеся "в деньгах" (коллы, страйк которых строго меньше расчетной цены фьючерса, и путы, страйк которых строго больше расчетной цены фьючерса), экспирируются автоматически.
Для опционов "на деньгах" (коллы и путы, страйк которых строго равен цене исполнения фьючерса) автоматическое исполнение осуществляется для половины открытой опционной позиции с данным страйком. Если величина открытой позиции является нечётным числом, то при расчёте величины исполняемой позиции для коллов применяется округление вверх (0.5=1), для путов – округление вниз (0.5=0).
Автоматическая экспирация может осуществляться как в промежуточный, так и в вечерний клиринг (задается на уровне опционной серии).
В торговой системе есть возможность отказаться от автоматической экспирации – для этого в шлюзовой команде OptChangeExpiration в поле amount необходимо ввести количество контрактов, экспирация которых нежелательна, как отрицательное (со знаком минус).
Для опционов, которые являются европейскими и расчетными, предусмотрена только автоматическая экспирация. В последний день обращения исполняются только опционы, находящиеся "в деньгах". Соответственно, поручения на исполнение/отказ от исполнения системой не принимаются.
Существующий алгоритм расчета обеспечения перед экспирацией может создавать резкий скачок обеспечения у клиентов. Для более гибкого управления алгоритмом в торговой системе вводятся дополнительные параметры, которые позволят брокеру самостоятельно задавать алгоритм расчета обеспечения при экспирации по его клиентам.
Параметры сценария экспирации:
exp_clearings_bf - данный параметр устанавливается НКЦ на весь рынок и определяет (для опционной серии) количество клиринговых сессий перед экспирацией, в течении которых по брокерской фирме начнется блокироваться обеспечение, посчитанное для всей брокероской фирмы по модели экспирации. До даты экспирации минус (exp_clearings_bf/2), применяется модель волатильности. Новое значение параметра применяется только в вечернюю или промежуточную клиринговую сессию.
exp_clearings_sa - определяет количество клиринговых сессий перед экспирацией, в которых будет применен сценарий экспирации для расчетного кода. Устанавливается и изменяется НКЦ на весь рынок. Применяется только в вечернюю или промежуточную клиринговую сессию.
exp_weight - вес риск-профиля с учетом сценариев экспирации.
exp_weight (client): Может меняться брокерской фирмой путем подачи неторговой шлюзовой транзакции OptChangeRiskParametersNextSession по каждому клиенту, применяется в ближайшую клиринговую сессию.
exp_weight (broker): Может устанавливаться расчетной фирмой через документооборот с биржей и командой ChangeBFParametersNextSession. В таком случае параметр exp_weight (broker) применяется для расчета гарантийного обеспечения брокера, у которого включен режим маржирования нетто.
exp_weight_client_default: Может устанавливаться расчетной фирмой через документооборот с биржей и командой ChangeBFClientDefaultParametersNextSession. В таком случае параметр exp_weight_client_default применяется на всех клиентов брокера, у которых не установлен exp_weight (client), то есть работает для таких клиентов как значение по умолчанию.
В случае, если участник не подал соответствующие распоряжения на установку веса риск-профиля, ко всем его клиентам будут применены параметры, установленные по умолчанию НКЦ.
exp_clearings_cc - определяет количество клиринговых сессий перед экспирацией, в которых будет применен вес риск-профиля exp_weight для клиентов БФ. Устанавливается и изменяется НКЦ на весь рынок. Применяется только в вечернюю или промежуточную клиринговую сессию.
num_clr_2delivery (broker) - параметр, который устанавливает брокерская фирма путем подачи неторговой шлюзовой транзакции ChangeBFParametersNextSession. Означает количество клиринговых сессий перед экспирацией, в которых будет применен вес риск-профиля exp_weight (broker) для расчета гарантийного обеспечения брокера в случае выбора режима маржирования нетто. Имеет приоритетное значение над предустановленным НКЦ параметром exp_clearings_bf, в случае, если num_clr_2delivery (broker) меньше exp_clearings_bf.
num_clr_2delivery_client_default - может устанавливаться расчетной фирмой через документооборот с биржей и командой ChangeBFClientDefaultParametersNextSession. В таком случае параметр num_clr_2delivery_client_default применяется для всех клиентов брокера, у которых не установлен num_clr_2delivery, то есть работает для таких клиентов как значение по умолчанию.
Прекращение обязательств по вечным фьючерсам (ВФ) может осуществляться по требованию одной из сторон путем подачи поручения на исполнение. Вечный фьючерс исполняется в ближайший по сроку исполнения обычный фьючерс на тот же самый спот-актив. Поручения на исполнение вечного фьючерса могут подаваться в течение всей торговой сессии за три торговых дня до последнего дня обращения фьючерса, в который исполняется ВФ. Подача поручений производится с помощь шлюзовой команды FuturesExecutionRequest. Поданные в торговую систему поручения транслируются в шлюзе в таблице fut_exec_orders потока FORTS_REFDATA_REPL.
В вечернюю клиринговую сессию дня подачи поручений производится исполнение, которое состоит из сведения встречных поручений на исполнение и, в случае наличия неудовлетворенных поручений на исполнение и открытых позиций с противоположной направленностью на рынке, процедуры их принудительного удовлетворения.
При исполнении позиция по вечному фьючерсу превращается в позицию по обычному фьючерсу, что технически оформляется сделкой закрытия позиции в вечном фьючерсе и сделкой открытия позиции в обычном фьючерсе, которые в таблице сделок помечаются специальными признаками в полях xstatus_sell и xstatus_buy:
PerpetualFuturesExecutionVoluntary (0x10000000000000) - сделка вследствие добровольного выхода из вечного фьючерса (на основании поданной заявки);
PerpetualFuturesExecutionForced (0x400000000000000) - сделка вследствие принудительного выхода из вечного фьючерса (реализация неудовлетворённого спроса);
PerpetualFuturesExecution (0x800000000000000) - сделка в связанном инструменте вследствие выхода из вечного фьючерса.
Сервис TAS (Trade at Settlement) - это возможность купить или продать фьючерсный контракт по будущей расчетной цене текущего торгового дня, определяемой в вечерний клиринг, плюс некий спред, который участник готов заплатить/уступить дополнительно от расчетной цены контракта. Именно спред является соглашением контрагентов в сделке и указывается в заявке TAS в качестве цены. Технически TAS в торговой системе реализован как обычный фьючерсный контракт с указанием спреда TAS в качестве цены в заявке (TAS-фьючерс), базисным активом (БА-фьючерсом) которого служит искомый фьючерсный контракт (фьючерс на фьючерс). Совершая сделку по заявке с указанием спреда TAS, участник получает позицию по TAS-фьючерсу.
Расчет сделки по заявке с указанием спреда TAS осуществляется в вечернюю клиринговую сессию. В результате позиция по TAS-фьючерсу превращается в позицию по БА-фьючерсу, что технически оформляется технической сделкой закрытия позиции в TAS-фьючерсе по цене 0 и сделкой открытия позиции в БА-фьючерсе по расчетной цене БА-фьючерса. Сделки в таблице сделок помечаются специальным признаком в полях xstatus_sell и xstatus_buy (бит 0x10000 (TASSettlement) - Расчет сделки по заявке с указанием спреда TAS).
Признаки, выставляемые у заявок и сделок:
Наименование признака | Битовая маска | Описание |
---|---|---|
Типы рыночных заявок | ||
Auction | 0x1 | Котировочная заявка (Day). |
Opposite | 0x2 | Встречная заявка (IOC). |
FOK | 0x80000 | Заявка Fill-or-Kill (FOK). |
BOC | 0x1000000000000000 | Заявка Book-or-Cancel (BOC). |
Типы клиринговых сделок | ||
NonQuote | 0x4 | Признак заявки/сделки, которая не участвует в расчете котировок. Признак выставляется в адресных заявках и сделках, технических сделках, клиринговых сделках, сделках по ногам мультилегов и сделках RFS. |
Exec | 0x20 | Сделка, возникшая в результате исполнения опциона. Флаг ставится для опционных сделок и для фьючерсных сделок, которые появились в результате экспирации опционов. |
Expiration | 0x80 | Истечение времени жизни инструмента, фьючерса или опциона. |
DUFlow | 0x800 | Сделка переноса ДУ между РФ. |
TASSettlement | 0x10000 | Расчет сделки по заявке с указанием спреда TAS. (В текущей версии недоступно) |
OptionLapse | 0x800000 | Сделка истечения опциона. |
ClearingTrade | 0x2000000 | Техническая клиринговая сделка, сформированная вне торгов. Выставляется у всех клиринговых сделок. |
FuturesExecution | 0x40000000 | Сделка исполнения фьючерса. |
CollateralInstrument | 0x400000000 | Сделка по коллатеральному инструменту. |
PerpetualFuturesExecutionVoluntary | 0x10000000000000 | Техническая сделка вследствие добровольного выхода из вечного фьючерса (на основании поданного поручения). |
PerpetualFuturesExecutionForced | 0x400000000000000 | Техническая сделка вследствие принудительного выхода из вечного фьючерса (реализация неудовлетворённого спроса). |
PerpetualFuturesExecution | 0x800000000000000 | Техническая сделка в связанном инструменте вследствие выхода из вечного фьючерса. |
Адресные заявки и сделки | ||
TransferClientPosition | 0x8 | Признак переноса позиций между БФ. |
Address | 0x4000000 | Признак адресной заявки, адресной сделки, сделки RFS или заявки, формируемой по результатам проверки котировок RFS. |
NegotiatedMatchByRef | 0x80000000 | Признак заявки или сделки, сформированной в режиме "Адресный с мэтчингом по уникальному коду". |
TransferSource | 0x200000000 | Признак источника переноса позиций между БФ. |
Операции над связками | ||
REPOBack | 0x4000 | Признак операции над второй ногой связки. |
Strategy | 0x8000000 | Признак заявки или сделки по связке. Ставится у операций над ногами связки. |
Другое | ||
DontCheckMoney | 0x10 | Не проверять обеспечение по клиентскому уровню. |
ExternalUseEveningExecution | 0x100 | Признак заявки или сделки в вечернюю сессию. |
DontCheckLimits | 0x200 | Не проверять лимиты по опционам. |
Charge | 0x400 | Конец логической транзакции. Флаг ставится ядром на заявки, чтобы по ордер логу можно было получить число (и границы) транзакций, то есть последовательности заявок, порожденных одной транзакцией. |
LastRec | 0x1000 | Признак последней записи в транзакции матчинга. |
DueToCrossCancel | 0x2000 | Признак снятия пассивной заявки при кросс-сделке. |
MoveOperation | 0x100000 | Признак передвижки заявки. |
DeleteOperation | 0x200000 | Признак одиночного удаления заявки. |
BulkDeleteOperation | 0x400000 | Признак группового удаления заявок. |
OppositeOrderTailDeleteDueToCrossTrade | 0x20000000 | Признак удаления остатка IOC-заявки по причине кросс-сделки. |
CODBulkDeleteOperation | 0x100000000 | Признак операции удаления заявки сервисом Cancel On Disconnect. |
FineOperation | 0x1000000000 | Проставляется при снятии заявки в результате штрафа в RFS. |
UKSBulkDeleteOperation | 0x2000000000 | Признак снятия заявок по команде UserKillSwitch |
NCCRequest | 0x4000000000 | Признак того, что операция является следствием подачи поручения НКЦ |
NCCBulkDeleteOperation | 0x8000000000 | Признак снятия заявок по команде DelOrdersByBFLimit |
LiqNettingRF | 0x10000000000 | Признак заявки или сделки, сформированной в процессе ликвидационного неттинга. |
ActiveSide | 0x20000000000 | Активная сторона в сделке. Заявка, приведшая к сделке при добавлении в стакан. |
PassiveSide | 0x40000000000 | Пассивная сторона в сделке. Заявка из стакана, участвующая в сделке. |
Synthetic | 0x200000000000 | Признак синтетической заявки и стороны сделки, соответствующей этой синтетической заявке. |
RFSOrder | 0x400000000000 | Заявка из системы RFS. |
Iceberg | 0x800000000000 | Признак айсберг-заявки, сделки по айсберг-заявке. |
OperatorInputSA | 0x1000000000000 | Признак заявки или сделки, сформированной при блокировке по Расчетному коду. |
DontFineRF | 0x80000000000000 | Признак невзимания штрафа за сделки урегулирования. |
MorningSession | 0x100000000000000 | Признак того, что сделка совершена в утреннюю торговую сессию. |
SyntheticPassive | 0x200000000000000 | Признак пассивной синтетической заявки. |
DuringDiscreteAuction | 0x4000000000000000 | Признак заявки или сделки в аукционе открытия. |
Для отличия адресных сделок от сделок, формируемых по результатам проверки котировок RFS, следует проверять не только бит Address, но и признак RFSOrder. В заявках и сделках, заключенных в результате сведения котировок из системы RFS, бит RFSOrder поднят, тогда как в адресных сделках этот бит снят.
Для удобства работы бэк-офисов информация в PLAZA II шлюзах и отчетах синхронизирована. Для этого в отчетах f04_XXYY.csv, f04clXXYYZZZ.csv, o04_XXYY.csv, o04clXXYYZZZ.csv используются поля signs_buy и signs_sell. Эти поля построены на основе битовой маски в PLAZA II.
Биты ExternalUseEveningExecution и MorningSession транслируются только в отчетах.
Начиная с версии 7.9, следующие признаки заявок и сделок, не использующиеся в настоящее время, будут переопределены и использованы для других целей:
SpotTransfer (0x8000);
REPO (0x20000);
IQSOrder (0x800000000).
Типы сделок, формируемые при исполнении и истечении фьючерсов и опционов, перечислены в следующей таблице:
Тип операции | Сделка закрытия позиции | Сделка открытия позиции | Дата и время, когда сделки появятся в отчете и шлюзе |
---|---|---|---|
Исполнение поставочного фьючерса |
| Нет | Утром в день исполнения |
Исполнение расчетного фьючерса |
| Нет | Вечером в день исполнения фьючерса |
Исполнение поставочного опциона |
|
| Сделки исполнения опционов генерируются:
В зависимости от времени подачи заявки на исполнение опциона (генерация в ближайшем клиринге) |
Исполнение расчетного опциона |
| Нет | Сделки исполнения опционов генерируются:
|
Истечение опциона |
| Нет | Вечером в день исполнения фьючерса |
Перенос позиции ОБФ |
|
| Вечером |
Добровольный выход из вечного фьючерса (на основании поданного поручения) |
|
| Вечером в день подачи поручения на исполнение |
Принудительный выход из вечного фьючерса (реализация неудовлетворённого спроса) |
|
| Вечером в день подачи поручения на исполнение |
Расчет сделки по заявке с указанием спреда TAS (В текущей версии недоступно) |
|
| Вечером в день исполнения TAS-фьючерса |
Торговые сделки отражаются следующим образом:
Операции в ходе торгов | Информация по операциям |
---|---|
Сделка по фьючерсу на акции на основании адресной заявки |
|
Сделка по фьючерсу на акции на основании безадресной заявки |
|
Сделка по опциону на фьючерсы на акции на основании адресной заявки |
|
Сделка по опциону на фьючерсы на акции на основании безадресной заявки |
|
Сделка по переносу позиций |
|
Техническая сделка на основании 1 части адресной парной заявки |
|
Техническая сделка на основании 2 части адресной парной заявки |
|
Техническая сделка на основании 1 части безадресной парной заявки |
|
Техническая сделка на основании 2 части безадресной парной заявки |
|
Сделка по фьючерсу на акции на основании сделки в RFS |
|
Сделка по опциону на фьючерсы на акции на основании сделки в RFS |
|
Техническая сделка по 1 части парной заявки на основании сделки в RFS |
|
Техническая сделка по 2 части парной заявки на основании сделки в RFS |
|
Торги в системе SPECTRA осуществляются в рамках торговой сессии. Торговая сессия в системе не связана с календарными сутками и включает в себя:
Вечернюю дополнительную торговую сессию — для реальных торгов длится с 19.05 до 23.50 по московскому времени.
Утреннюю дополнительную торговую сессию — для реальных торгов длится с 9.00 до 10.00 следующих календарных суток.
Основную торговую сессию — для реальных торгов длится с 10.00 до 18.50.
В пределах одной торговой сессии обращаются одни и те же торговые инструменты и применяются одни и те же параметры для расчета обеспечения. В промежутках между торговыми сессиями производится ряд важнейших для системы SPECTRA операций, таких как клиринг, истечение срока действия контрактов, генерация и рассылка отчетов и т.п.
Внутри основной торговой сессии существует перерыв, который в реальной системе SPECTRA длится с 14.00 до 14.05 по московскому времени, в течение которого проходит промежуточная клиринговая сессия (промежуточный клиринг). Промежуточная клиринговая сессия нужна для того, чтобы зафиксировать в середине дня новые расчетные цены по инструментам и перечислить вариационную маржу (премию) между участниками клиринга.
В промежуточный клиринг изменяются:
Расчетные цены инструментов, по которым были торговые операции в период вечерних/утренних торгов и первой половины дневных торгов. Старые и новые расчетные цены отображаются в специальных полях таблиц fut_sess_contents и opt_sess_contents потока FORTS_REFDATA_REPL.
Свободные средства клиентов после расчета и перечисления вариационной маржи (премии). Перечисленная вариационная маржа (премия) отображается в специальных полях таблиц part и part_sa потока FORTS_PART_REPL.
В промежуточный клиринг не изменяются:
Размер лимитов по инструментам.
Состав торговых инструментов. Удаление старых инструментов и добавление новых осуществляется в основную клиринговую сессию.
Основной клиринг проводится по окончании торговой сессии в период с 18.50 до 19.05 московского времени. В процессе клиринга выполняется:
Расчет и фиксация расчетных цен инструментов по итогам всей торговой сессии
Расчет и перечисление вариационной маржи (премии) между участниками.
Удаление торговых инструментов, с истекшим сроком обращения, и добавление новых торговых инструментов.
Обновление информации о клиентах, брокерских и расчетных фирмах путем удаления старой информации и закачки новых данных из клиринга.
После основного клиринга производится генерация и рассылка отчетов по итогам текущей торговой сессии.
При назначении новой торговой сессии данные из справочных таблиц, в которых существует привязка к номеру сессии закачиваются вновь из клиринга с указанием нового номера торговой сессии. В справочные таблицы, в которых нет привязки к номеру сессии, присылается набор изменений, то есть добавляются новые записи, появившиеся для новой торговой сессии, и удаляются записи для объектов, которых не должно быть в новой торговой сессии. Справочные таблицы — это таблицы, приходящие в потоке FORTS_REFDATA_REPL. Итогом всех этих изменений является добавление в таблицу session записи с новым номером сессии.
При смене торговой сессии информация о средствах, лимитах и позициях клиентов обновляется в режиме применения обновлений, то есть меняются только те записи, в которых во время клиринга реально произошли изменения (потоки FORTS_PART_REPL и FORTS_POS_REPL).
Основная торговая информация (потоки FORTS_TRADE_REPL, FORTS_ORDLOG_REPL и FORTS_DEALS_REPL) сохраняется, т.е. до ночи текущего дня в репликации доступны заявки и сделки, сделанные до 19.05 в текущую торговую сессию.
При смене торговой сессии происходит автоматическое перевыставление многодневных заявок, дата истечения которых еще не наступила, путем удаления старой заявки и добавления новой (с новым номером). Учитывая, что в реплику в таблицу orders_log информация об этом не предается, клиентская система должна быть устроена следующим образом. При обнаружении нового номера торговой сессии в таблице session, клиентская система должна "забыть" обо всех заявках, которые у нее сохранились в памяти до этого, и "слушать" реплику на предмет появления новых заявок, с указанием нового номера торговой сессии.
При смене торговой сессии происходит удаление торговых инструментов, с истекшим сроком обращения, и добавление новых торговых инструментов. Существует правило — новыми инструментами нельзя торговать в вечернюю и утреннюю торговые сессии, при этом данные инструменты присутствуют в системе, информация по ним приходит в реплике. В таблицах fut_sess_contents и opt_sess_contents такие инструменты помечены специальным признаком.
На границе торговых сессий потоки репликации могут быть штатным образом закрыты и переоткрыты заново серверами торговой системы, при этом по некоторым потокам может прийти уведомление о смене номера жизни схемы.
В настоящий момент, без смены номера жизни могут переоткрываться следующие потоки:
Поток с общими рыночными данными FORTS_COMMON_REPL.
Поток с текущими значениями волатильности FORTS_VOLAT_REPL.
Поток с текущими значениями вариационной маржи (премии) FORTS_VM_REPL.
Потоки, которые не переоткрываются:
Поток со справочной информацией FORTS_REFDATA_REPL.
Поток с торговой информацией FORTS_TRADE_REPL.
Поток со срезами стаканов FORTS_USERORDERBOOK_REPL.
Потоки агрегированных стаканов.
Потоки FORTS_PART_REPL, FORTS_POS_REPL, FORTS_INFO_REPL
Поток биржевых индексов RTS_INDEX_REPL.
Поток FORTS_CLR_REPL.
Если для разрабатываемой системы критично иметь возможность отмечать совокупное консистентное состояние всех данных в торговой системе на некоторые «важные» моменты времени, то такая система должна использовать механизм синхрособытий. Для синхронизации доступны следующие состояния торговой системы:
Данные для новой торговой сессии закачены и рассчитаны (~18:54-18:55, Московского времени)
Начало промежуточного клиринга (14:00, Московского времени)
Денежные средства после промклиринга перерассчитаны (~14:01:30, Московского времени)
Все расчетные процедуры в промклиринге закончены (~14:02, Московского времени)
Начало основного клиринга (18:50, Московского времени)
Данные после основного клиринга перерассчитаны (~18:54, Московского времени)
Раздвижка лимитов закончена (в течение торгов)
Начало приема заявок в аукцион открытия (~8.50, Московского времени)
Окончание приема заявок в аукцион открытия (~8.59, Московского времени)
Для уведомления внешних систем о наступлении определенного состояния торговой системы, в потоках репликации транслируется таблица sys_events следующего формата:
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
event_id | i8 | Уникальный идентификатор события |
sess_id | i4 | Номер сессии |
event_type | i4 | Тип события |
message | c64 | Описание события |
Таблица транслируется в следующих потоках репликации:
Правила синхронизации данных следующие - при наступлении глобального события в торговой системе, после генерации всех данных по этому событию всеми подсистемами торговой системы, в таблицы sys_events вставляется запись с одним и тем же event_id, с event_type, соответствующим типу события:
1 (session_data_ready) - закончена загрузка данных из клиринговой системы в торговую перед началом новой торговой сессии; события данного типа транслируются во всех потоках, где есть таблица sys_events, кроме потока FORTS_CLR_REPL
2 (intraday_clearing_finished) - все расчетные процедуры в промклиринге закончены; события данного типа транслируются во всех потоках, где есть таблица sys_events, кроме потока FORTS_CLR_REPL
3 (clearing_data_ready) - готовы данные после основного клиринга; события данного типа транслируются только в потоке FORTS_CLR_REPL
4 (intraday_clearing_started) - начало промклиринга; события данного типа транслируются во всех потоках, где есть таблица sys_events, кроме потока FORTS_CLR_REPL
5 (clearing_started) - начало основного клиринга; события данного типа транслируются во всех потоках, где есть таблица sys_events, кроме потока FORTS_CLR_REPL
6 (extension_of_limits_finished) - раздвижка лимитов закончена; события данного типа транслируются во всех потоках, где есть таблица sys_events, кроме потока FORTS_CLR_REPL
8 (broker_recalc_finished) - денежные средства после промклиринга пересчитаны; события данного типа транслируются во всех потоках, где есть таблица sys_events, кроме потока FORTS_CLR_REPL
23 (discrete_auction_add_order_started) - начало приема заявок в аукцион открытия; события данного типа транслируются в потоках FORTS_TRADE_REPL, FORTS_ORDLOG_REPL, FORTS_DEALS_REPL и FORTS_REFDATA_REPL
24 (discrete_auction_add_order_finished) - окончание приема заявок в аукцион открытия; события данного типа транслируются в потоках FORTS_TRADE_REPL, FORTS_ORDLOG_REPL, FORTS_DEALS_REPL и FORTS_REFDATA_REPL
Внешняя система, может подписаться на получение таблицы событий во всех интересных ей потоках репликации и получить уведомление о том, когда данные готовы. Во всех потоках репликации записи в sys_events, относящиеся к одному событию в торговой системе будут иметь одинаковый event_id. В полях sess_id и message выдается расширенная информация – номер новой или текущей торговой сессии и текстовое сообщение. Обращаем особое внимание на тонкости:
Не гарантируется идентичность значений служебных полей replID, replRev в разных потоках репликации для одного и того же события. Ориентироваться стоит только на event_id.
Уведомление в sys_events приходит ПОСЛЕ всех данных, в частности это означает, что в режиме получения данных on-line внешняя система получит сначала сами новые данные, например, инструменты, назначенные в новую сессию или перенесенные в новую сессию многодневные заявки, а уже потом – уведомление в sys_events.
Не гарантируется консистентность данных при их раздаче в режиме snapshot. В следствие того, что протокол репликации не запоминает порядок получения записей между разными таблицами в потоке, данные раздаются в порядке описания таблиц в схеме, именно поэтому записи в режиме snapshot будут приходить не в том порядке, в каком они приходили в режиме on-line. Например, приход события session_data_ready в момент получения снапшота совершенно не означает, что данные готовы, учитывая вышесказанное, событие session_data_ready вполне может относиться к предыдущей торговой сессии. Поэтому использовать уведомления, приходящие в sys_events, для оценки консистентного состояния данных в системе можно только после перехода в режим on-line.
Помимо реальной торговой системы SPECTRA, существует игровая система и две тестовых системы: T0 - с версией ТС, аналогичной реальной системе SPECTRA, и T+1 - с аналогичной реальной системе SPECTRA или следующей версией ТС.
Расписание работы игровой системы:
Вечерняя торговая сессия: 16:00 - 22:00.
Утренняя торговая сессия: 06:00 - 08:55.
Основная торговая сессия: 09:00 - 15:45.
Промклиринг: 13:00 - 13:05.
Клиринг: 15:45 - 16:00.
Расписание работы тестовых систем T0 и T+1:
Вечерняя торговая сессия: 14:15 - 23:50.
Утренняя торговая сессия: 06:00 - 06:14.
Основная торговая сессия: 06:15 - 13:45.
Промклиринг: 11:00 - 11:04.
Точки Х для поставки: 13:00, 13:15.
Поставка: 13:30 - 14:00.
Полное расписание сессий также можно посмотреть в таблице session потока FORTS_REFDATA_REPL или в терминале в таблице "Сессии".
Перед началом утренней дополнительной торговой сессией, в период с 8.50 до 9.00 московского времени в системе SPECTRA проводится Аукцион открытия. Аукцион открытия служит для исключения аномального скачка цен производных инструментов при открытии торгов. Данный механизм реализован в формате дискретного аукциона заявок по единой Цене аукциона открытия. Цена аукциона открытия выбирается из условия обеспечения совершения сделок с максимальным количеством контрактов по объявленным на момент времени проведения аукциона открытия заявкам. Аукцион открытия состоит из периода сбора заявок и матчинга заявок по цене аукциона открытия, определяемой на основании информации обо всех заявках на момент окончания периода сбора заявок.
Основные особенности аукциона открытия:
В аукционе открытия могут участвовать только фьючерсы, включая вечные фьючерсы. Календарных спредов и опционов нет. Признак допуска инструмента к участию в аукционе открытия устанавливается на уровне БА и действует на все инструменты этого БА.
В период сбора заявок в аукцион открытия можно выставлять только безадресные котировочные заявки (тип Day), включая айсберги. Заявки типа BOK, FOK, IOC - недопустимы.
Контроль кросс-заявок: пересечение ценовых уровней противоположных заявок с одним ИНН не допускается (снимается более поздняя заявка), при этом настройки "Разрешить кросс-сделки" и "Снять пассивную заявку при кросс-сделке" не учитываются.
Цены заявок должны находиться в лимитах ценового коридора инструмента.
Ограничения на выставление заявок в утреннюю сессию на уровне БФ распространяется и на аукцион открытия.
Безадресные заявки с вечерней сессии участвуют в аукционе открытия, включая айсберги и заявки типа Book-or-Cancel.
В период сбора заявок можно ставить и снимать (если это разрешено для инструментов данного БА в этом аукционе) заявки, перестановка заявок запрещена в аукционе открытия.
Время начала сбора заявок – за 10 мин до старта утренней торговой сессии – 8.50 московского времени. Этому моменту в системе соответствует приход синхрособытия discrete_auction_add_order_started в таблицы sys_events потоков FORTS_TRADE_REPL и FORTS_REFDATA_REPL.
Время окончания сбора заявок – случайное для всех инструментов в промежутке, указанном в полях discrete_auction.add_order_finish_from и discrete_auction.add_order_finish_till таблицы discrete_auction в потоке FORTS_REFDATA_REPL. Этому моменту в системе соответствует приход синхрособытия discrete_auction_add_order_finished в таблицы sys_events потоков FORTS_TRADE_REPL и FORTS_REFDATA_REPL.
После завершения фазы сбора заявок и до окончания аукциона не допускаются операции с заявками, включая удаление.
После проведения аукциона и заключения сделок по цене открытия, осуществляется матчинг оставшихся заявок с учетом синтетической ликвидности из календарных спредов. Цены сделок с учетом синтетического матчинга могут отличаться от цены открытия. На этом этапе могут сниматься заявки по календарным спредам при нарушении условий кроссности.
Не сведенные в процессе аукциона открытия заявки переходят в основной режим торгов.
Информация об аукционах открытия в таблицах торгового интерфейса:
Информация о расписании назначенных аукционов открытия содержится в таблицах discrete_auction и discrete_auction_base_contract потока FORTS_REFDATA_REPL торгового интерфейса.
Цена аукциона открытия транслируется в шлюзе в поле opening_auction_price таблицы common потока FORTS_COMMON_REPL на протяжении утренней и дневной торговой сессии. В вечернюю торговую сессию цена аукциона открытия равна нулю.
Информация о состоянии торгов по инструменту передается в поле state (добавлены новые значения 6 и 7) в таблице fut_sess_contents потока FORTS_REFDATA_REPL.
У всех заявок, попавших в аукцион открытия, и сделок, сформированных по результатам этого аукциона, в таблицах заявок и сделок транслируется специальный отличительный признак - DuringDiscreteAuction (0x4000000000000000).
Реализованная в SPECTRA Система Управления Рисками (СУР) позволяет в максимальной степени снизить риск неисполнения обязательств и осуществлять непрерывную оценку уровня рыночного риска позиций каждого участника. Ядром системы является алгоритм расчёта гарантийного обеспечения (initial margin, далее ГО) под открытые позиции и заявки, учитываемые на позиционных счетах участников клиринга и участников торгов.
Одной из ключевых особенностей Системы Управления Рисками SPECTRA является использование онлайн расчёта обеспечения под заявки и позиции, производимого в рамках торговой транзакции. При таком подходе появление в системе необеспеченных заявок и сделок практически исключается, т.к. достаточность обеспечения проверяется до того, как заявка появляется в системе.
Другой важной особенностью Системы Управления Рисками SPECTRA является трехуровневая система позиционных счетов.
Расчетный код – счет верхнего уровня участника клиринга (Расчетной фирмы). Расчетный код является независимой единицей учета средств обеспечения, внесенных участником и(или) его клиентами, а также заявок, поданных в совокупности по всем счетам нижних уровней (суб-счетам), принадлежащих расчетному коду, сделок, заключенных на основании этих заявок, и результирующих позиций. Таким образом, позиция по любому инструменту, учитываемая по расчетному коду, является нетто-суммой всех позиций по этому инструменту, учитываемых на суб-счетах.
Для расчетного кода определяется величина ГО независимо от других расчётных кодов. Все настройки СУР SPECTRA для расчетных кодов контролируются центральным контрагентом (клиринговой организацией).
Во время клиринговой сессии по расчетному коду определяется размер требований и обязательств участника клиринга (вариационная маржа, премия, комиссионные сборы и пр.). Для расчетного кода проверяется достаточность средств обеспечения для покрытия требований ГО.
Расчетный код в зависимости от того, чьи средства учитываются по нему, и за чей счет заключаются сделки, может быть одного из трех типов:
собственный – за счет участника клиринга;
клиентский – за счет непосредственных клиентов и клиентов 2-го уровня участника клиринга;
ДУ – за счет средств, переданных в доверительно управление участнику клиринга.
Для каждого участника клиринга (Расчетной фирмы) открывается как минимум два расчетных кода: собственный и клиентский.
Идентификатор расчетного кода в торговой системе SPECTRA – 5 цифр.
Брокерская фирма – суб-счет расчетного кода. Счет следующего уровня, открываемый по заявлению участника клиринга (Расчетной фирмы). Брокерская фирма принадлежит одному и только одному расчетному коду. Привязка брокерской фирмы к расчетному коду может быть изменена на основании заявления участника клиринга в клиринговую организацию. Для того, чтобы расчетный код поднимался в торговую систему SPECTRA, и по нему был бы возможен учет заявок и позиций, к расчетному коду должна быть привязана хотя бы одна брокерская фирма.
В бэк-офисе клиринговой системы SPECTRA по брокерской фирме ведется учет средств обеспечения, внесенных участником и(или) его клиентами на клиентские разделы брокерской фирмы. Информация о размере учитываемого обеспечения доступна в отчетах.
Расчет величины ГО по брокерской фирме производится по умолчанию в режиме полунетто (margin_type =3 для метода ChangeBFParametersNextSession) относительно риска позиций, учитываемых на клиентских разделах этой брокерской фирмы. Для брокерской фирмы возможен расчет величины ГО в режиме нетто (margin_type =4 для метода ChangeBFParametersNextSession). В этом режиме по брокерской фирме для каждого инструмента рассчитывается позиция как нетто-сумма позиций по этому инструменту на всех разделах брокерской фирмы, а также учитываются все заявки в совокупности, поданные по разделам этой брокерской фирмы; по рассчитанным таким образом нетто-позициям и совокупности всех заявок происходит определение величины ГО по брокерской фирме.
Все параметры маржирования брокерской фирмы могут настраиваться участником клиринга (Расчетной фирмой) с помощью метода ChangeBFParametersNextSession.
Специальная Брокерская фирма (СпецБФ) – специальный суб-счет расчетного кода, аналогичный обычным брокерским фирмам, и предназначенный для учета средств обеспечения, внесенных на расчетный код участником и(или) его клиентами, и не учитываемых на разделах обычных брокерских фирм.
Информация о размере учитываемого обеспечения доступна в отчетах.
Также у каждой СпецБФ существует один раздел, называемый ликвидационным разделом СпецБФ. Позиции на ликвидационном разделе могут создаваться только на основании сделок, заключаемых клиринговым центром для урегулирования неисполненных участником клиринга обязательств (например, Маржинального требования по расчетному коду). Участник клиринга (Расчетная фирма) не может подавать заявки с указанием ликвидационного раздела за исключением заявок, направленных на уменьшение открытой на разделе позиции. Также участник клиринга (Расчетная фирма) может переносить позицию (метод TransferClientPosition) с ликвидационного раздела на разделы других брокерских фирм.
Клиентский раздел – суб-счет брокерской фирмы. Счет нижнего уровня, регистрируемый по заявке участника. Является первичным счетом, на котором учитываются заявки, поданные участником и(или) клиентом, заключенные в результате них сделки, и открытые позиции – именно клиентский раздел (код клиента) указывается в транзакциях объявления заявки. По заявкам и позициям, учитываемым на клиентском разделе, определяется величина ГО. Параметры маржирования клиентского раздела могут настраиваться с помощью методов ChangeClientParameters, ChangeClientParametersNextSession и ChangeBFClientDefaultParametersNextSession.
В бэк-офисе клиринговой системы SPECTRA по клиентским разделам ведется учет средств обеспечения, внесенных участником и(или) его клиентом. Информация о размере учитываемого обеспечения доступна в отчетах.
Маржирование заявок по календарным спредам на фьючерс (связки), а также позиций противоположной направленности по инструментам с разными сроками исполнения на один базовый актив (межмесячный спред) может происходить в двух режимах:
полунетто – величина ГО определяется на основе большего ГО из инструментов, входящих в спред;
нетто – величина ГО определяется, исходя из ставки рассогласования цен на инструменты, входящие в спред.
Для расчетного кода всегда действует режим маржирования календарных спредов нетто.
Для брокерской фирмы можно изменять режим маржирования календарных спредов только, если расчет величины ГО для брокерской фирмы происходит в режиме нетто. В таком случае режим маржирования календарных спредов определяется параметром calendar_spread_margin_type метода ChangeBFParametersNextSession.
Для клиентских разделов можно изменять режим маржирования календарных спредов с помощью параметра calendar_spread_margin_type метода ChangeClientParametersNextSession.
Торговые лимиты ограничивают возможность участника и(или) его клиентов объявлять заявки и открывать позиции на позиционных счетах.
Торговый лимит по расчетному коду определяется, исходя из суммарной оценочной стоимости средств обеспечения, учитываемых по расчетному коду, т.е. совокупной стоимости средств обеспечения, учитываемых по все суб-счетам расчетного кода. В качестве средств обеспечения могут выступать российские рубли, иностранная валюта и ценные бумаги.
Изменить торговый лимит на расчетном коде можно только путем ввода, вывода или перевода средств обеспечения. Данные операции совершаются на основании поручений, подаваемых участником в клиринговую организацию, расчетный депозитарий посредством соответствующих систем электронного документооборота, а также в другие расчетные организации (в случае внесения средств обеспечения). Также возможен перевод средств обеспечения, учитываемых в российских рублях, путем их перевода между суб-счетами (брокерскими фирмами, СпецБФ) расчетных кодов с помощью метода ExchangeBFMoney.
Торговые лимиты используются для резервирования отрицательной вариационной маржи, списания сборов, списания/зачисления премии, резервирования ГО.
Торговый лимит по брокерской фирме по умолчанию также, как и для расчетного кода, определяется исходя из суммарной оценочной стоимости средств обеспечения, учитываемых по разделам брокерской фирмы. В качестве средств обеспечения могут быть российские рубли, иностранная валюта и ценные бумаги. Торговый лимит брокерской фирмы в таком случае можно изменять с помощью метода ChangeBFMoney.
Для брокерской фирмы можно изменить режим определения торгового лимита, сделав его независимым от размера средств обеспечения, учитываемых на разделах брокерской фирмы. В таком режиме торговый лимит брокерской фирмы задается с помощью метода ChangeBFLimit. Также торговый лимит брокерской фирмы меняется на размер прибыли или убытка, определяемого во время вечернего клиринга (вариационная маржа, премия, сборы).
Режим определения торгового лимита брокерской фирмы определяется параметром limit_tied_to_money метода ChangeBFParametersNextSession.
Торговый лимит на клиентском разделе не зависит от размера средств обеспечения, учитываемых на этом разделе. Для управления торговыми лимитами на клиентских разделах используется метод ChangeClientMoney. Он обеспечивает следующие возможности:
Установка/изменение/удаление торговых лимитов.
Автоматический учет результатов торгов клиента в лимитах в следующей торговой сессии.
В общем случае заявка может быть выставлена только при условии, что у всех трех уровней (клиентского раздела, брокерской фирмы и расчетного кода) торговые лимиты достаточны для покрытия требуемой величины ГО. Для брокерской фирмы и клиентского раздела проверку достаточности торгового лимита можно отменить с помощью методов ChangeBFParametersNextSession и ChangeClientMoney соответственно.
Для расчетного кода отключить проверку достаточности торгового лимита (средств обеспечения) невозможно.
Если расчетный код является расчетным кодом Единого пула, то на его суб-счетах (разделах брокерских фирм и СпецБФ) в бэк-офисе клиринговой системы SPECTRA вместо средств обеспечения учитываются профили активов, передаваемые в клиринговую систему SPECTRA из клиринговых систем фондового и валютного рынков. Передача профилей активов происходит на основании поручений участника клиринга, поданных в клиринговую организацию посредством соответствующих систем электронного документооборота. Перевод обеспечения на брокерскую фирму расчетного кода Единого пула невозможен. Перевод профилей между брокерскими фирмами на разных расчетных кодах Единого пула также невозможен.
В торговой системе SPECTRA, профили активов учитываются одновременно как оценочная стоимость актива с учетом знака профиля (изменяет торговый лимит) и позиция по специальному инструменту (для профиля рубля позиция не создается). Позиция по специальному инструменту создается на клиентском разделе БФ, если профиль был переведен на этот раздел, либо на СпецБФ (Код Клиента 000), если профиль был переведен без указания клиентского раздела. Для каждого актива, по которому может быть передан профиль, в торговой системе SPECTRA существует свой специальный инструмент - коллатерал (имеет суффикс _CLT в имени инструмента). Подавать заявки и заключать сделки по такому инструменту запрещено. Единственный способ изменения позиции по специальному инструменту - это перевод соответствующего профиля актива в/из клиринговой системы SPECTRA. При расчете величины ГО на счетах/суб-счетах участника позиция по специальному инструменту маржируется аналогично позиции по фьючерсу на тот же базовый актив.
В остальном управление величиной Гарантийного обеспечения и торговыми лимитами на суб-счетах расчетного кода Единого пула аналогично обычным расчетным кодам.
Система SPECTRA предоставляет возможность вводить дополнительные ограничения на проведение торговых операций клиентом, которые в системе формулируются как запреты.
Реализованный в системе SPECTRA механизм запретов позволяет запретить клиенту (группе клиентов) подавать транзакции по торговому инструменту или группе инструментов. Общие принципы механизма запретов:
Запреты накладываются на стандартное подмножество счетов: РФ, БФ, клиенты. Обращаем внимание, что по РФ в настоящее время запреты не используются.
Запреты применяются по следующим подмножествам торговых инструментов:
отдельный фьючерс или все опционы на один и тот же базовый инструмент;
инструменты с общим базовым активом;
инструменты торговой секции;
все инструменты.
Запреты могут использоваться не только администраторами торгов, но и участниками, имеющими соответствующие полномочия. Предусмотрены также автоматически выставляемые запреты.
Запреты начинают действовать сразу после выставления. Для запретов не существует возможности задания интервала их применения.
Атрибуты запретов
Атрибут | Описание |
---|---|
xprohibition_id | Уникальный идентификатор запрета. |
client_code | Код участника. Может содержать 2, 4 или 7 символов в зависимости от того, на какое подмножество счетов распространяется запрет. |
initiator | Инициатор запрета. Значение определяется в зависимости от уровня логина, выставившего запрет. Может принимать следующие значения:
Параметр используется для определения того, действует ли запрет на логин, подающий транзакцию. Ниже в таблице приведена матрица влияния запретов от разных инициаторов на различные уровни логинов, подающих транзакцию. Обращаем внимание, что все запреты, выставляемые пользователем с помощью шлюзовых команд (см. ниже), имеют инициатора - '1 - Главный трейдер РФ'. |
section | Идентификатор секции. Используется для выставления запрета на торговлю всеми инструментами в секции. Может принимать следующие значения:
|
base_contract_code | Код базового актива. Запрет выставляется только на инструменты, базирующиеся на этом БА. |
isin_id | Уникальный числовой идентификатор инструмента. Используется для запретов на торговлю конкретным инструментом. |
priority | Приоритет запрета. Автоматически вычисляется из параметров запрета (см ниже). |
group_mask | Битовая маска групп инструментов, по которым действует запрет. Может принимать следующие значения:
|
type | Тип запрета. Может принимать следующие значения:
Типы запретов 0-3 упорядочены по строгости следующим образом: 2 > 1 > 3 > 0. |
is_legacy | Признак пользовательского запрета. Может принимать следующие значения:
|
Таблица 1. Матрица влияния запретов
Уровень логина / Инициатор | Главный трейдер РФ | Администратор КЦ | Администратор ТС |
---|---|---|---|
Клиент | + | + | + |
БФ | + | + | + |
РФ, трейдер | + | + | + |
РФ, главный трейдер | - | + | + |
Приоритеты запретов
Параметры транзакции могут удовлетворять нескольким запретам. Для определения эффективного запрета они все сортируются в порядке приоритета и действующим выбирается запрет с максимальным приоритетом. Приоритеты фиксированы и определяются по сочетанию параметров запрета, чем более детализирован запрет тем выше его приоритет. Приоритеты автоматически вычисляются системой на базе параметров запрета. Предусмотрены следующие приоритеты (перечислены в порядке от максимального приоритета к минимальному):
Приоритет | Группа счетов | Группа инструментов |
---|---|---|
9 | Клиентский код | инструмент, isin_id != 0 |
8 | Клиентский код | БА, base_contract_code != 0 |
7 | Клиентский код | все инструменты |
6 | Код БФ | инструмент, isin_id != 0 |
5 | Код БФ | БА, base_contract_code != 0 |
4 | Код БФ | все инструменты |
3 | Код РФ | инструмент, isin_id != 0 |
2 | Код РФ | БА, base_contract_code != 0 |
1 | Код РФ | все инструменты |
Применение запретов
Ниже очень кратко описан алгоритм поиска эффективного запрета для заявки:
Для каждого инициатора, влияющего на логин, с которого подана заявка (см. выше описание параметра initiator), отбираются все запреты, относящиеся к инструменту и семизначному клиентскому разделу, указанному в заявке.
Среди этого множества запретов выбираются запреты с наибольшим приоритетом, а среди них самый строгий запрет (см. выше описание параметра type).
Среди отобранных по каждому инициатору запретов выбирается самый строгий запрет, без учета приоритета.
Таким образом, так как запреты предназначены для ограничения операций, то среди запретов разных инициаторов выбирается наиболее строгий. То есть, даже администратор не сможет преодолеть запрет на заявки, выставленный по всем инструментам на БФ (priority 4) каким-нибудь логином уровня БФ, или запрет на заявки, выставленный по всем инструментам на всю РФ главным трейдером (priority 1). Потому что запрет на заявки - это самый строгий запрет. Если его установил другой инициатор, то запрет может быть отменен (или преодолен для конкретного инструмента и/или клиента) только самим инициатором.
Интерфейсы
Запреты транслируются в шлюзе в таблице prohibition потока FORTS_PROHIBITION_REPL.
Для управления запретами в шлюзе предусмотрены команды FutChangeClientProhibit и OptChangeClientProhibit. Можно по конкретному клиенту (по всем клиентам), инструменту (по всем инструментам) или базовому активу (по всем БА) запретить открывать позиции и выставлять заявки.
Выставление запретов (примеры конфигурации запретов)
Для выставления запретов в шлюзе предусмотрены команды, о которых было сказано выше. При выставлении запретов следует обращать особое внимание на их корректное конфигурирование. Неправильно построенный запрет может привести к возникновению в системе необоснованно большого количества запретов, что, в свою очередь, негативно сказывается на производительности всей системы управления запретами в целом, и прежде всего для самого пользователя, выставившего некорректный запрет (тормоза при открытии потоков и отправке команд управления запретами). Например, вместо того, чтобы ставить много запретов по почти каждому клиенту БФ, намного эффективнее выставить один общий запрет по БФ, а по нужным клиентам выставить соответствующие разрешения. Ниже приведены примеры конфигурации запретов в различных ситуациях. Приводимые в сценариях конфигурации позволяют минимизировать итоговое количество запретов.
Примеры задания запретов, когда все клиенты имеют одинаковые права.
Запретить все операции по n БА (список запрещенных БА). n < 0.5*M, где М – общее количество БА.
Ставятся n запретов БФ на БА. Тип запрета - state=2 (запрет на выставление любых заявок), приоритет запрета - priority=5 (Код БФ / БА, base_contract_code != 0).
Добавление нового БА, входящего в список запрещённых БА, требует явного выставления запрета.
Добавление нового БА, не входящего в список запрещённых БА, не требует выставления нового запрета.
Запретить все операции по n БА (список запрещенных БА). n > 0.5*M, где М – общее количество БА. Сценарий отличается от предыдущего соотношением между количеством запрещенных и разрешенных БА.
Ставится запрет БФ на все БА. Тип запрета - state=2 (запрет на выставление любых заявок), приоритет запрета - priority=4 (Код БФ / все инструменты).
Ставятся М-n разрешений БФ на разрешенные БА (обратного множества к запрещенным БА). Тип запрета - state=0 (разрешены все операции), приоритет запрета - priority=5 (Код БФ / БА, base_contract_code != 0).
Добавление нового БА, входящего в список запрещённых БА, не требует выставления запрета.
Добавление нового БА, не входящего в список запрещённых БА, требует выставления по нему разрешения.
Примеры задания запретов, когда клиенты делятся на две группы: квалифицированные инвесторы и неквалифицированные инвесторы.
Количество квалифицированных инвесторов = m. Количество неквалифицированных инвесторов = n.
Неквалифицированные инвесторы должны иметь доступ только к БА из группы L. Квалифицированные инвесторы имеют доступ ко всем БА.
Разрешить неквалифицированным инвестором торговать только по БА из группы L и запретить по остальным БА. Квалифицированным инвестором разрешить торговать по всем БА. m < n - квалифицированных инвесторов меньше.
Ставится запрет БФ на все БА. Тип запрета - state=2 (запрет на выставление любых заявок), приоритет запрета - priority=4 (Код БФ / все инструменты).
Ставятся разрешения БФ на БА из группы L. Тип запрета - state=0 (разрешены все операции), приоритет запрета - priority=5 (Код БФ / БА, base_contract_code != 0). Т.е. будет разрешено всем клиентам БФ.
Ставятся разрешения квалифицированным инвесторам БФ на все БА. Тип запрета - state=0 (разрешены все операции), приоритет запрета - priority=7 (Клиентский код / все инструменты). Т.е. будет разрешено только всем квалифицированным инвесторам БФ.
Добавление нового квалифицированного инвестора, требует выставить по нему разрешение.
Добавление нового неквалифицированного инвестора, не требует изменений в запретах.
Разрешить неквалифицированным инвестором торговать только по БА из группы L и запретить по остальным БА. Квалифицированным инвестором разрешить торговать по всем БА. m >= n - квалифицированных инвесторов больше. Сценарий отличается от предыдущего соотношением между количеством квалифицированных и неквалифицированных инвесторов.
Ставятся запреты неквалифицированным инвесторам БФ на БА, не входящие в группу L. Тип запрета - state=2 (запрет на выставление любых заявок), приоритет запрета - priority=8 (Клиентский код / БА, base_contract_code != 0).
Добавление нового квалифицированного инвестора, не требует изменений в запретах.
Добавление нового неквалифицированного инвестора, потребует выставить запрет.
Запреты с пользовательским приоритетом
Система предоставляет возможность выставлять запреты с указанным пользователем приоритетом, причем, этот приоритет будет выше чем те, что устанавливаются системой автоматически (приоритет с 1 по 9). Такая возможность позволяет более гибко настраивать сценарии конфигурации запретов. Предусмотрены следующие приоритеты:
10 – пользовательский приоритет низкий;
11 – пользовательский приоритет средний;
12 – пользовательский приоритет высокий.
Для выставления запретов с пользовательским приоритетом в команды FutChangeClientProhibit и OptChangeClientProhibit добавлено поле client_priority (i4), которое принимает значение 10, 11 или 12 (низкий, средний, высокий). Если в команде в поле client_priority указано значение 10, 11 или 12, то выставляется запрет с указанным пользовательский приоритетом. Если пользовательский приоритет не указан, то приоритет будет установлен автоматически, в соответствии с параметрами запрета.
Кроме этого в системе предусмотрено автоматическое выставление запретов на открытие позиций или выставление заявок при обнаружении большого отрицательного торгового лимита. Для управления запретами используется следующий набор параметров:
Pr_state - флаг автоматического выставления запретов; 0 - не выставлять запреты, 1 - выставлять запреты.
Pr_type - тип запрета; 0 - запрет на открытие позиций, 1 - запрет на выставление заявок.
Pr_coeff - повышающий коэффициент; положительное дробное число с точностью до двух знаков после запятой.
Del_ord - флаг автоматического снятия активных заявок при установке запрета; 0 - не снимать заявки, 1 - снимать заявки.
Параметры устанавливаются участником клиринга на уровне БФ. Предусмотрено два набора параметров: применяемых для клиентов БФ и применяемых для всей БФ в совокупности.
Установка параметров производится на основании поручений участника клиринга, поданных в клиринговую организацию посредством соответствующих систем электронного документооборота. Применение параметров происходит в ближайший клиринг, при условии что поручение подано не позднее 1 часа до начала клиринга.
Установка запретов. После раздвижки планок вечернего и промежуточного клиринга автоматически выставляется запрет по семизначному клиентскому разделу или БФ, если одновременно выполняются условия:
, где
Limits_set – флаг проверки клиентского лимита;
Trade_limit – торговый лимит, включающий в себя деньги и залоги с учетом коэффициента ликвидности;
FreeMoney – свободные средства по клиентскому разделу или БФ.
Тип запрета определяется параметром Pr_type. Если параметр Del_ord=1, то при выставлении запрета автоматически снимаются все активные заявки. Проверки на уровне БФ и клиента осуществляются независимо.
Снятие запретов. Установленные запреты не могут быть напрямую сняты брокером, они снимаются автоматически при устранении причин к ним приведших. Каждую минуту производится проверка, после которой запреты снимаются, если соблюдено одно из условий:
Пример. При запрете на открытие позиций клиент может сам снять заявки/закрыть позицию, вызывающую увеличенное требование к гарантийному обеспечению. Максимум через минуту после этого запрет будет снят автоматически.
Снятие запретов не работает во время ночных операций (00:00 - 09:00), даже если в это время ТС доступна для изменения лимитов.
По умолчанию для всех БФ автоматическое выставление запретов отключено (Pr_state=0).
В рамках одной Расчетной Фирмы возможен перенос позиций с одной клиента Брокерской Фирмы на другого клиента Брокерской Фирмы.
Перенос позиций с одного кода раздела учета позиций на другой осуществляется путем подачи Участником клиринга в Торговую систему новой транзакции.
Проверки возможности подачи транзакции на перевод позиций — такие же, как при подаче заявки. Дополнительно проверяется, что в момент подачи транзакции объём переносимой позиции не превышает объёма соответствующей позиции, учитываемой на разделе-источнике; также при переводе позиций с одного клиентского раздела регистра учета позиций на другой ИНН/паспортные данные, закрепленные за такими разделами регистра учета позиций, должны совпадать, в том числе по разделам ОБФ.
Технически перевод позиций оформляется как сделка по покупке (или продаже) с раздела-источника и продаже (покупке) по разделу-приемнику, и юридически сделкой не является (подробнее — см. раздел Типы сделок, формируемые при исполнении и истечении фьючерсов и опционов). Перевод позиций транслируется и в шлюзе, и в отчетах (f04/o04).
Приостановка торгов для расширения лимита колебаний цен сделок осуществляется в соответствии с "Положением о порядке установления и изменения лимитов колебаний цен сделок и о процедуре принудительного закрытия Позиций" (Приложение Ф5 к Правилам осуществления клиринговой деятельности на рынке ценных бумаг, срочном рынке и валютном рынке).
С технической точки зрения при приостановке торгов в системе SPECTRA производятся следующие действия:
При наступлении условий для приостановки торгов по какому-либо базовому активу, торги по этому базовому активу приостанавливаются.
Администраторами торгов рассчитываются новые расширенные лимиты колебаний цен.
Производится пересчет обеспечения по всем позициям по этому базовому активу (при расширении лимитов обеспечение увеличивается).
После завершения расчета обеспечения торги еще некоторое время не возобновляются, чтобы дать возможность участникам удалить заявки.
Возобновление торгов в нормальном режиме.
Данные действия сопровождаются рассылкой администраторами торгов соответствующих уведомлений (см. таблицу sys_messages потока FORTS_REFDATA_REPL):
Предупреждение о том, что если цены не изменятся, то через определенное время произойдет приостановка торгов по такому-то инструменту.
Уведомление о том, что приостановка торгов реально произведена.
Уведомление о том, что обеспечение пересчитано, можно удалять заявки.
Уведомление о возобновлении торгов.
В системе реализован сервис информирования участников о прогнозируемых значениях риск-параметров (сервис ForecastIM). Сервис с заданной периодичностью производит расчет обеспечения, которое могло бы быть в случае раздвижки лимитов, и транслирует эти данные участникам. Алгоритм работы сервиса:
С периодичностью раз в минуту анализируется состояние рынка по инструментам и ищутся те, по которым через некоторое время возможна раздвижка лимитов (нахождение на планке более X минут).
Если такие инструменты есть, производится перерасчет обеспечения по клиентским портфелям. Риск-параметры по инструментам на планке устанавливаются в соответствии с предполагаемой раздвижкой.
Рассчитанные деньги транслируются в потоке реплики FORTS_FORECASTIM_REPL, таблица part_sa_forecast.
Если состояние рынка изменилось, и потенциальная угроза раздвижки исчезла, или раздвижка состоялась, расчет и трансляция прогнозируемых значений риск-параметров прекращаются, а присланные ранее данные считаются невалидными (рассылка CLEARDELETED с максимально возможными ревиженами по таблице с прогнозными значениями).
Если в течение одной торговой сессии по инструменту уже дважды проводилась раздвижка лимитов, то в эту торговую сессию расчет и трансляция прогнозных значений риск-параметров по инструменту больше не выполняется.
Система SPECTRA предоставляет возможность блокировки брокерской комиссии на стороне биржи. Заблокированная комиссия учитывается на клиентском разделе, уменьшая свободные средства клиента (money_free) на величину заблокированной части. Блокировка осуществляется в течение торговой сессии, в вечерний клиринг блокировка сбрасывается.
Брокерская комиссия определяется следующим образом:
, где
N – количество контрактов в сделке;
lower_fee – минимально возможная сумма брокерской комиссии за один контракт;
upper_fee – максимально возможная сумма брокерской комиссии за один контракт;
multiplier – мультипликатор к сумме биржевого и клирингового сбора;
ex_fee – сбор за сделку (клиринговый + биржевой);
additive – постоянная добавка за один контракт.
Параметры lower_fee, upper_fee, multiplier и additive задаются брокером с помощью команды SetBrokerFeeParamNextSession. Параметры могут устанавливать как для отдельного клиента, так и для всех клиентов БФ одновременно. Применение заданных параметров происходит в следующую торговую сессию. Заданные пользователем параметры транслируются в шлюзе в потоке FORTS_BROKER_FEE_PARAMS_REPL.
Например, брокер всегда берет половину биржевой комиссии - тогда multiplier = 0.5, additive = 0, lower_fee = 0.01, upper_fee = inf. Или брокер берет всегда 2 рубля за любой контракт - тогда multiplier = 0, additive = 2, lower_fee = 2, upper_fee = 2.
Брокерская комиссия транслируется в шлюзе в таблице part потока FORTS_PART_REPL (суммарно по клиенту), а также в потоке FORTS_BROKER_FEE_REPL (в разрезе сделок).
В системе SPECTRA реализована поддержка отрицательных цен, обеспечивающая корректное поведение системы в случае ухода цен фьючерсов и страйков опционов в отрицательную зону в ходе торгов или в результате клиринга. Для каждого базового актива возможен один из двух режимов поддержки отрицательных цен:
Режим, при котором цены фьючерсов и страйки опционов не ограничены - в этом режиме в системе допустимы отрицательные и нулевые цены фьючерсов и страйки опционов, а для ценообразования опционов, расчета волатильности и рисков используется модель Башелье, либо скорректированная модель Блэка-Шоулза, учитывающая только внутреннюю стоимость опциона в отрицательном диапазоне.
Режим, в котором цены фьючерсов и страйков ограничены положительными значениями - в этом режиме отрицательные цены в ходе и в результате торгов не могут образоваться, а для ценообразования опционов используется модель Блэка-Шоулза (либо Башелье в качестве альтернативы). Однако, в таком режиме возможно ручное указание отрицательной цены исполнения и/или индикативной текущей рыночной цены (см. ниже), в случае соответствующего решения НКЦ. При этом все равно сохраняется ограничение на положительные значения торговых цен фьючерсов и страйков опционов.
Режим работы и модель ценообразования опционов задаются на уровне БА (базового контракта) и действуют на все инструменты данного БА. Переключение режимов и модели ценообразования опционов возможно во время клиринговой сессии (ПК или ВК). Для задания режима и риск-модели используются следующие параметры базового контракта:
negative_prices - признак ограничения отрицательных цен: 1 – цены фьючерсов и страйки не ограничены; 0 - цены фьючерсов и страйки ограничены положительными значениями.
option_model - модель ценообразования опционов: 1 – модель Башелье; 0 - модель Блэка-Шоулза.
Значения параметров транслируются в шлюзе в потоке FORTS_REFDATA_REPL в таблицах fut_vcb/opt_vcb.
В режиме запрета отрицательный цен (negative_prices=0), в случае соответствующего решения НКЦ, допускается устанавливать в ручном режиме индикативную текущую рыночную цену, транслируемую в потоке FORTS_COMMON_REPL. От этой цены зависит индикативная текущая вариационная маржа, транслируемая в потоке FORTS_VM_REPL, и текущая теоретическая цена опциона, транслируемая в потоке FORTS_VOLAT_REPL. Для индикации того, что текущая рыночная цена для фьючерса установлена в ручном режиме, используется параметр:
price_assigned_by_admin - признак установки текущей рыночной цены Администратором торгов.
Поля таблиц торгового интерфейса, где в режиме отрицательных цен (negative_prices=1) возможно появление отрицательных значений:
Поток | Таблица | Поле | Описание |
---|---|---|---|
FORTS_TRADE_REPL | orders_log | price | Цена в заявке |
FORTS_TRADE_REPL | orders_log | deal_price | Цена заключенной сделки |
FORTS_TRADE_REPL | user_deal | price | Цена заключенной сделки |
FORTS_ORDLOG_REPL | orders_log | price | Цена в заявке |
FORTS_ORDLOG_REPL | orders_log | deal_price | Цена заключенной сделки |
FORTS_USERORDERBOOK_REPL | orders | price | Цена в заявке |
FORTS_ORDBOOK_REPL | orders | price | Цена в заявке |
FORTS_COMMON_REPL | common | best_buy | Цена лучшей заявки на покупку |
FORTS_COMMON_REPL | common | best_sell | Цена лучшей заявки на продажу |
FORTS_COMMON_REPL | common | open_price | Цена открытия |
FORTS_COMMON_REPL | common | close_price | Цена закрытия |
FORTS_COMMON_REPL | common | price | Цена последней сделки |
FORTS_COMMON_REPL | common | min_price | Минимальная цена |
FORTS_COMMON_REPL | common | max_price | Максимальная цена |
FORTS_COMMON_REPL | common | avr_price | Средневзвешенная цена |
FORTS_COMMON_REPL | common | settlement_price_open | Расчетная цена предыдущей сессии |
FORTS_COMMON_REPL | common | market_price | Текущая рыночная цена |
Потоки агрегированных стаканов FORTS_AGGRXX | orders_aggr | price | Ценовой уровень |
FORTS_POS_REPL | position | waprice | Учетная цена позиции |
FORTS_POS_REPL | position_sa | waprice | Учетная цена позиции |
FORTS_REFDATA_REPL | fut_sess_contents | limit_up | Верхний лимит цены |
FORTS_REFDATA_REPL | fut_sess_contents | limit_down | Нижний лимит цены |
FORTS_REFDATA_REPL | fut_sess_contents | settlement_price_open | Расчетная цена на начало сессии |
FORTS_REFDATA_REPL | fut_sess_contents | settlement_price | Расчетная цена после последнего клиринга |
FORTS_REFDATA_REPL | fut_instruments | settlement_price_open | Расчетная цена на начало сессии |
FORTS_REFDATA_REPL | fut_instruments | settlement_price | Расчетная цена после последнего клиринга |
FORTS_REFDATA_REPL | opt_sess_contents | strike | Цена исполнения |
FORTS_MM_REPL | fut_MM_info | price_edge_sell | Цена худшей заявки на продажу, вошедшей в спред |
FORTS_MM_REPL | fut_MM_info | price_edge_buy | Цена худшей заявки на покупку, вошедшей в спред |
FORTS_CLR_REPL | fut_sess_settl | settl_price | Расчетная цена |
FORTS_INFO_REPL | futures_params | risk_range_center | Центр расчета риска |
FORTS_INFO_REPL | futures_params | settlement_price | Расчетная цена последнего клиринга |
FORTS_INFO_REPL | options_params | strike | Цена исполнения |
FORTS_REJECTEDORDERS_REPL | rejected_orders | price | Цена в заявке |
В режиме положительных цен (negative_prices=0), в случае соответствующего решения НКЦ, возможно:
использование отрицательной цены исполнения фьючерса;
трансляция отрицательного значения в качестве индикативной текущей рыночной цены, установленной Администратором торгов (price_assigned_by_admin = 1) в поле market_price.
Отрицательные и нулевые значения в торговых кодах инструментов отображаются следующим образом:
Пример кодов со страйком "-10":
Короткий код контракта (short_isin): "BR-10BF0".
Полный код контракта (isin): "BR-7.20M250620СA-10".
Пример кодов со страйком "0":
Короткий код контракта (short_isin): "BR0BF0".
Полный код контракта (isin): "BR-7.20M250620СA0".
Спонсируемый доступ (Sponsored Market Access - SMA) – это способ предоставления клиентам участников торгов технического доступа к торгово-клиринговой системе срочного рынка, с помощью которого клиент может подавать поручения участнику торгов ("спонсирующей" фирме) для исполнения на рынке путем постановки заявок напрямую в ТС под контролем и ответственностью участника.
Доступ к ТС клиенту участника предоставляется путем выделения ему персонального идентификатора - SMA-логина, с которого напрямую можно выставлять заявки. Доступ возможен через PLAZA II, FIX и TWIME шлюзы.
Для контроля операций, совершаемых со SMA-логина, SMA-логин привязывается к логину участника (MASTER-логину). MASTER-логин – идентификатор участника, с помощью которого участник подсоединяется к ТС, выставляет заявки, контролирует исполнение заявок. Участник вправе использовать один и тот же MASTER-логин для более чем одного SMA-логина. SMA-логин также может быть привязан к нескольким MASTER-логинам. Список логинов транслируется в шлюзе в таблице user потока FORTS_REFDATA_REPL. В этой таблице SMA-логин можно отличить по 1 в третьем бите битовой маски sma_flags. Список связок "MASTER-логин" - "SMA-логин" транслируется в шлюзе в таблице sma_master потока FORTS_REFDATA_REPL.
Для получения SMA-логина участник торгов подает в Клиентский центр Биржи заявление, в котором указывает логин, с помощью которого будет производиться контроль операций, совершаемых со SMA-логина (MASTER-логин).
При организации подачи заявок участником торгов по поручениям клиентов, биржа предоставляет участникам соответствующие средства управления риском, чтобы не допустить попадания ошибочных заявок в торговую систему:
Pre-Trade контроль - дополнительные настройки помимо существующей системы проверок при постановке заявок.
Cancel On Drop-Copy Disconnect - сервис, гарантирующий, что заявки SMA-логина присутствуют в ТС только при подключенном (активном) MASTER-логине. Все выставленные SMA-логином заявки имеют ссылку на этот связанный с ним MASTER-логин (поле aspref таблиц orders_log и multileg_orders_log).
UserKillSwitch - принудительная деактивация SMA-логина участником.
Pre-Trade контроль представляет собой набор дополнительных ограничений/проверок, накладываемых/выполняемых при постановке заявок от SMA-логина. Проверки могут назначаться в разрезе SMA-логинов, инструментов или кодов клиентов. Под инструментом здесь понимается комбинация:
<Базовый актив>: <Тип дериватива>, где <Тип дериватива> = {Фьючерс, Опцион, Календарный Спред} - Инструмент*
<Базовый актив>: <Тип дериватива>, где <Тип дериватива> = {Фьючерс, Опцион} - Инструмент**
Предусмотрены следующие проверки:
Номер проверки | Проверка | Привязка | Единица измерения | Применяются |
---|---|---|---|---|
1 | Отклонение цены в заявке от текущей цены | SMA-логин или SMA-логин х Инструмент** | Проценты | Сразу |
2 | Максимальный объем заявки в контрактах | SMA-логин или SMA-логин х Инструмент* | Количество контрактов | Сразу |
3 | Запретить адресный режим | SMA-логин | Да/Нет | Сразу |
4 | Максимальный объем заявки в рублях | SMA-логин или SMA-логин х Инструмент* | Руб | Сразу |
5 | Максимальная сумма заявок за торговый день (брутто) | SMA-логин или SMA-логин х Инструмент* | Руб | Сразу |
6 | Максимальная позиция в контрактах (long) | SMA-логин x Инструмент** x Код клиента | Количество контрактов | Сразу |
7 | Максимальная позиция в контрактах (short) | SMA-логин x Инструмент** x Код клиента | Количество контрактов | Сразу |
Для назначения/отмены проверок используются шлюзовые команды SetSmaPreTradeCheck и DelSmaPreTradeCheck соответственно. Информация о назначенных проверках доступна в шлюзе в таблице sma_pre_trade_check потока FORTS_REFDATA_REPL.
Cancel On Drop-Copy Disconnect - сервис, гарантирующий, что заявки SMA-логина присутствуют в ТС только при подключенном (активном) MASTER-логине.
При постановке заявки со SMA-логина, производится проверка наличия хотя-бы одного активного MASTER-логина, к которому привязан данный SMA-логин, если таких MASTER-логинов нет, то заявка отвергается с выдачей соответствующей ошибки. Если активный MASTER-логин есть, заявка обрабатывается, а в поле aspref записывается ссылка (id-логина) на этот MASTER-логин.
Сервис в режиме реального времени (по технологии, аналогичной Cancel On Disconnect) отслеживает состояние MASTER-логинов на транзакционном уровне, и при отсутствии транзакционной активности деактивирует логин. Если в результате таких действий у SMA-логина не остается ни одного подключенного MASTER-логина, то все его активные заявки автоматически снимаются.
Активные заявки SMA-логинов, у которых включен режим Cancel On Drop-Copy Disconnect, также автоматически снимаются в конце торгового дня в технологический перерыв.
Сервис Cancel On Drop-Copy Disconnect является настраиваемой опцией, для его подключения следует обратиться в Клиентский центр Биржи.
Команда UserKillSwitch позволяет участнику самому деактивировать (активировать) SMA-логин с опциональной возможностью автоматического снятия всех его активных заявок. Деактивированный SMA-логин не может выполнять торговые операции. Деактивация SMA-логина сохраняется до конца торгового дня и восстанавливается при рестартах ТС в технологический перерыв или при сбоях.
В версии 6.2 реализован проект по разделению статусов участника торгов и участника клиринга с разделением функций и полномочий разных категорий участников. Теперь в торгах могут принимать участие клиенты, не являющиеся участниками клиринга, а участник клиринга для исполнения обязательств по сделкам, заключенным на бирже, не обязан быть участником торгов. В торговой системе выделяются следующие категории участников:
Участник клиринга (УК). Участник клиринга может обслуживать одного или нескольких участников торгов, являясь стороной по сделкам, заключенными такими участниками торгов.
Участник торгов (УТ). Участник торгов имеет право заключать сделки на организованных торгах. При этом обязательства и требования при заключении сделки возникают у участника клиринга, обслуживающего этого участника торгов.
Участник клиринга и участник торгов в одном лице (УК+УТ - текущий статус всех участников). УК+УТ могут сами заключать сделки на организованных торгах, и одновременно являются контрагентами НКЦ по заключенным сделкам. Порядок оказания клиринговых услуг и услуг по организации торгов для таких участников не изменяется.
В терминах SPECTRA сущностью, описывающей участника клиринга, является Расчетная фирма, при этом РФ может принадлежать либо УК, либо УК+УТ.
Участнику торгов соответствуют Брокерские фирмы, открытые в рамках Расчетной фирмы соответствующего участника клиринга. При этом:
одному участнику торгов могут быть открыты несколько Брокерских фирм в рамках одной Расчетной фирмы (одного участника клиринга);
одному участнику торгов могут быть открыты несколько Брокерских фирм в рамках разных Расчетных фирм (разных участников клиринга).
У БФ участник торгов может совпадать в одном лице с участником клиринга (УК=УТ), либо не совпадать (УК!=УТ).
Если РФ - УК, у нее могут быть зарегистрированы только БФ, у которых УК не совпадает в одном лице с УТ. Если РФ - УК+УТ, то возможны комбинации форм БФ.
Разделение статусов участников торгов и участников клиринга подразумевает и разделения полномочий участников на торговые и клиринговые. Под полномочиями здесь понимаются права на просмотр информации в шлюзе и права на выполнение операций.
Основные полномочия участника торгов, которые не доступны участнику клиринга - это подача/снятие торговых заявок и заключение сделок на основании поданных заявок. При этом участник клиринга может совершать некоторые действия с заявками, подавая поручения в НКЦ, а уже НКЦ может выставлять заявку от имени участника клиринга, а также снимать другие заявки (подробнее см. раздел 2.7.3. Урегулирование неисполненных обязательств).
Основные полномочия участника клиринга, которые не доступны участнику торгов - это управление обеспечением (вывод обеспечения, перевод обеспечения между расчетными кодами), а также управление риском в отношении участника торгов, возникающим по сделкам, заключенным участником торгов. Управление риском заключается как в определении лимитов для участника торгов, так и в возможности сокращать (рискованную) позицию участника торгов.
Разделение полномочий производится на уровне логина доступа к ТС. Исходя из этого логины могут обладать следующими полномочиями:
"Логин УК" - логин, обладающий полномочиями участника клиринга.
"Логин УТ" - логин, обладающий полномочиями участника торгов.
"Логин УК+УТ" - логин, обладающий полномочиями и участника клиринга и участника торгов. Для таких логинов логика раздела полномочий осталась прежней (как до раздела статусов участников торгов и участников клиринга).
Ниже в таблице приведен список полномочий "Логин УК":
Операция | Доступные шлюзовые команды |
---|---|
Установка лимитов по БФ. | ChangeBFMoney |
Установка торговых лимитов по БФ. | ChangeBFLimit |
Перевод денежных средств между двумя БФ одного РК. | ExchangeBFMoney |
Установка риск-параметров по БФ. | ChangeBFParametersNextSession |
Перенос позиций между БФ (только для логинов уровня РФ). | TransferClientPosition |
Подача Запросов к НКЦ на заключение сделок с УТ. Технически реализована как подача заявки с особым признаком. | AddOrder |
Отмена Запроса к НКЦ на заключение сделок с УТ. Технически реализована как удаление заявки с особым признаком. | DelOrder |
Изменение Запроса к НКЦ на заключение сделок с УТ. Технически реализована как изменение заявки с особым признаком. | MoveOrder |
Подача Запросов к НКЦ на проверку достаточности обеспечения по БФ. | DelOrdersByBFLimit |
Подача/удаление поручений на досрочную экспирацию опционов. | OptChangeExpiration |
Подача/удаление поручений на исполнение однодневных фьючерсов с автопролонгацией. | FuturesExecutionRequest |
Управление SMA-логинами. | SetSmaPreTradeCheck; DelSmaPreTradeCheck; UserKillSwitch |
Пересчет центрального страйка. | OptRecalcCS |
Ниже в таблице приведен список полномочий "Логин УТ":
Операция | Доступные шлюзовые команды |
---|---|
Подача торговых заявок. | AddOrder; IcebergAddOrder |
Удаление торговых заявок. | DelOrder; DelUserOrders; IcebergDelOrder |
Изменение торговых заявок. | MoveOrder; IcebergMoveOrder |
Подача/удаление поручений на досрочную экспирацию опционов. | OptChangeExpiration |
Подача/удаление поручений на исполнение однодневных фьючерсов с автопролонгацией. | FuturesExecutionRequest |
Управление SMA-логинами. | SetSmaPreTradeCheck; DelSmaPreTradeCheck; UserKillSwitch |
Пересчет центрального страйка. | OptRecalcCS |
"Логин УК+УТ" обладает совокупным набором полномочий "Логина УК" и "Логина УТ", за исключением подачи Запросов к НКЦ, которые может подавать только "Логин УК".
Участник клиринга может получить логины следующих уровней:
Расчетной фирмы.
Брокерской фирмы.
Клиента.
Участник торгов может получить логины следующих уровней:
Брокерской фирмы.
Клиента.
В зависимости от уровня, полномочия логина могут различаться:
При работе с разделами БФ, у которой УК совпадает с УТ, логины уровня РФ и уровня БФ обладают полномочиями "Логин УК+УТ".
При работе с разделами БФ, у которой УК не совпадает с УТ, логин уровня РФ обладает полномочиями "Логин УК".
При работе с разделами БФ, у которой УК не совпадает с УТ, полномочия логина уровня БФ совпадают со значением признака [ "Логин УК" | "Логин УТ" ].
Для любой БФ логин уровня клиента обладает полномочиями "Логин УТ".
В ситуации, когда участник клиринга и участник торгов разные лица, важным является - кто управляет клиентами (клиентскими разделами). Под управлением клиентами здесь понимается возможность видеть информацию по ним: средства, лимиты и индивидуальные риск-параметры, а также и собственно устанавливать лимиты, запреты, правила экспирации и т.п. Возможны две схемы взаимодействия между УК и УТ с точки зрения управления клиентами:
Клиентами управляет УТ. Участник торгов управляет клиентскими разделами, входящими в состав своих Брокерских фирм (схема по умолчанию). В данной схеме участнику клиринга не доступна информация о клиентах участников торгов: средства, лимиты и индивидуальные риск-параметры по клиентским разделам, а также не доступны операции по управлению клиентами.
Клиентами управляет УК. Участник торгов передает клиентские разделы, входящие в состав своих Брокерских фирм, "под управление" участнику клиринга.
Схема взаимодействия задается на уровне БФ путем выставления у нее специального признака: "Клиентами управляет УТ"/"Клиентами управляет УК".
Для иллюстрации приведем пару примеров:
Небольшой региональный брокер для доступа к торгам своих клиентов заключает с участником клиринга договор на обслуживание по модели клирингового брокера. Участник клиринга открывает для такого брокера брокерскую фирму, и регистрирует брокера как участника торгов на бирже. При этом торговать на бирже будут клиенты регионального брокера, а не участника клиринга, и соответственно, управлять клиентами хочет сам брокер - в этом случае применима схема "Клиентами управляет УТ".
Компания нерезидент, чтобы получить доступ к торгам на Московской бирже для своих клиентов, регистрируется в НКЦ в качестве участника клиринга. Далее нерезидент заключает договор поручение с брокерской фирмой (российская дочка нерезидента либо большой УК+УТ) на обслуживание своих клиентов. Но торговать будут клиенты нерезидента и контролировать их он хочет сам - в этом случае используется схема "Клиентами управляет УК".
Ниже в таблице приведен список полномочий, относящийся к праву управления клиентскими разделами. Обладать данными полномочиями будут логины, у которых набор полномочий ("Логин УТ" /"Логин УК") совпадает со схемой, заданной у БФ ("Клиентами управляет УТ"/"Клиентами управляет УК").
Операция | Доступные шлюзовые команды, потоки, таблицы |
---|---|
Установка лимитов по клиентским разделам. | ChangeClientMoney |
Установка риск-параметров по клиентским разделам. | ChangeClientParameters; ChangeClientParametersNextSession; ChangeBFClientDefaultParametersNextSession |
Установка запретов на операции на уровне клиентских разделов. | FutChangeClientProhibit; OptChangeClientProhibit |
Установка риск-параметрами опционов. | OptChangeRiskParametersNextSession |
Перевод клиентских позиций. Только для логинов уровня БФ с признаком "Логин УТ". | TransferClientPosition |
Просмотр информации по клиентским разделам: размер обеспечения и индивидуальные риск-параметры. | FORTS_PART_REPL.part; FORTS_CLR_REPL.money_clearing; FORTS_CLR_REPL.pledge_details |
Также данными полномочиями обладает "Логин УК+УТ".
Участник клиринга не может выставлять и снимать заявки, однако для управления неисполненными обязательствами участника торгов перед участником клиринга, и в том числе, в случае недостаточности обеспечения участника торгов, участник клиринга вправе подавать в адрес НКЦ запросы на заключение сделок с участником торгов. Такой запрос подается участником клиринга с указанием любого клиентского раздела участника торгов. По такому запросу НКЦ выставляет безадресную заявку "в стакан" или адресную заявку, на основании которой будут заключаться сделки.
Технически такой запрос подается в формате обычной торговой заявки, имеющей специальный признак - "Запрос к НКЦ на заключение сделок с участником торгов". Запрос может быть подан как в форме безадресной заявки, так и в форме адресной заявки. Участники торгов ставить (снимать, в том числе массово) заявки с таким признаком не могут. У заявок с признаком "Запрос к НКЦ" в битовой маске признаков выставляется бит NCCRequest (0x4000000000). Аналогичный бит получают и сделки, заключенные на основании таких заявок.
В целях устранения необеспеченности позиций участник клиринга имеет возможность инициировать снятие заявок, поданных участником торгов. Для этого используется команда DelOrdersByBFLimit, которую может подавать участник клиринга по БФ, открытым для участников торгов, обслуживаемых таким участником клиринга. При обработке данной команды в случае отрицательного свободного лимита по БФ, снимаются все активные заявки по клиентским разделам, принадлежащим такой БФ. У снимаемых заявок в битовой маске признаков выставляется бит NCCBulkDeleteOperation (0x8000000000).
Синтетический матчинг – формирование сделок на основании заявок, поступающих в разные стаканы (стаканы разных инструментов). Целью синтетического матчинга является повышение ликвидности инструментов путем объединения нескольких стаканов. Например, синтетический матчинг позволит сведение заявок инструмента типа календарный спред не только со встречной заявкой внутри стакана данного инструмента, но и с отдельными заявками из стаканов фьючерсов его ног. Таким образом заявка КС учитывает встречные интересы из других стаканов своих ног.
Идея синтетического мэтчинга состоит в заключении сделки на основании трех заявок по разным торговым инструментам, если цены этих инструментов связаны между собой определенным соотношением. Например, цена инструмента календарный спред равна разнице цены дальней ноги и цены ближней ноги. Тогда заявка на покупку по календарному спреду RTS-9.18-12.18 по цене 1000 (участник "A"), заявка на покупку по фьючерсу RTS-9.18 по цене 114000 (участник "B") и заявка на продажу по фьючерсу RTS-12.18 по цене 115000 (участник "C") могут быть одновременно исполнены. В результате участник "B" получит длинную позицию по фьючерсу RTS-9.18 по цене 114000. Участник "C" получит короткую позицию по фьючерсу RTS-12.18 по цене 115000. А участник "A" получит две позиции: короткую по фьючерсу RTS-9.18 по цене 114000 и длинную по фьючерсу RTS-12.18 по цене 115000, при чем их цены связаны соотношением 115000 - 114000 = 1000. Таким образом, все три заявки могут быть удовлетворены корректно.
На Московской бирже сделки заключаются с центральным контрагентом (НКЦ). В нашем примере может быть одновременно заключено три сделки:
по календарному спреду RTS-9.18-12.18 между участником "A" и НКЦ
по фьючерсу RTS-9.18 между участником "B" и НКЦ
по фьючерсу RTS-12.18 между участником "C" и НКЦ
Для того, чтобы сделки были заключены, в процессе синтетического матчинга в ядре торговой системы автоматически формируются заявки, поданные от имени НКЦ. Такие заявки называются синтетическими. Синтетическая заявка - заявка создаваемая ядром в ходе синтетического матчинга при выполнении условия сведения заявок. Синтетическая заявка является реальной заявкой, подаваемой центральным контрагентом в торги, и фигурирует в сделках, порождаемых в ходе синтетического матчинга. В анонимных и пользовательских потоках заявок синтетические заявки в полях xstatus помечаются специальным признаком "Synthetic" (0x200000000000).
В рассматриваемом примере формируются следующие синтетические заявки:
заявка от НКЦ на продажу по календарному спреду RTS-9.18-12.18 по цене 1000 (встречная к заявке участника "A")
заявка от НКЦ на продажу по фьючерсу RTS-9.18 по цене 114000 (встречная к заявке участника "B")
заявка от НКЦ на покупку по фьючерсу RTS-12.18 по цене 115000 (встречная к заявке участника "C")
Синтетическая заявка формируется системой на основании двух реальных заявок, поданных участниками в двух других инструментах. В нашем примере система сформировала синтетическую заявку на продажу по календарному спреду RTS-9.18-12.18 по цене 1000 на основании заявки на покупку по фьючерсу RTS-9.18 по цене 114000 (от участника "B") и заявки на продажу по фьючерсу RTS-12.18 по цене 115000 (от участника "C").
Есть два основных сценария синтетического матчинга:
Кейс 1: Заявки отдельных фьючерсов генерируют синтетическую заявку по календарному спреду.
Пример (см. Рисунок 4, «Стаканы календарного спреда»):
В стакан календарного спреда RTS-9.18-12.18 (стакан КС) поступает заявка на покупку в количестве 20 по цене 1000 от участника "A".
Участник "B" поставил заявку на покупку в RTS-9.18 (стакан ближней ноги) в количестве 12 по цене 114000.
Участник "C" ставит заявку на продажу в RTS-12.18 (стакан дальней ноги) в количестве 10 по цене 115000 (входящая активная заявка). В этот момент начинается матчинг.
На основе заявок в стаканах ближней и дальней ног, в стакане КС появляется синтетическая заявка на продажу календарного спреда RTS-9.18-12.18 в количестве 10 (минимальное количество из трех заявок, участвующих в матчинге) по цене 1000 (115000-114000: то есть цена дальней ноги минус цена ближней ноги), выставленная от имени НКЦ, которая сводится в сделку с заявкой по календарному спреду от участника "A".
В стакане ближней ноги появляется синтетическая заявка на продажу RTS-9.18 по цене 114000 с объемом 10 от имени НКЦ, которая сводится в сделку с заявкой от участника "B", в стакане дальней ноги - синтетическая заявка на покупку RTS-12.18 по цене 115000 с объемом 10 от имени НКЦ, которая сводится в сделку с заявкой от участника "C".
Таким образом образуются три сделки: по ближнему фьючерсу (контрагенты: "B" и НКЦ) по цене 114000, по дальнему фьючерсу (контрагенты: "C" и НКЦ) по цене 115000 и по календарному спреду (контрагенты: "A" и НКЦ) по цене 1000. Также образуются две технические сделки, отображающие движение ног по календарному спреду. Для обеих технических сделок контрагенты "A" и НКЦ.
Остались несведенными заявка RTS-9.18-12.18 в объеме 10 и заявка RTS-9.18 в объеме 2.
Кейс 2: Заявка на календарный спред и заявка на один из фьючерсов ног этого спреда генерируют синтетическую заявку на другую из ног этого спреда.
Пример (см. Рисунок 4, «Стаканы календарного спреда»):
Участник "B" поставил заявку на покупку в RTS-9.18 (стакан ближней ноги) в количестве 12 по цене 114000.
В стакан календарного спреда RTS-9.18-12.18 (стакан КС) поступает заявка на покупку в количестве 20 по цене 1000 от участника "A".
Участник "C" ставит заявку на продажу в RTS-12.18 (стакан дальней ноги) в количестве 10 по цене 115000 (входящая активная заявка). В этот момент начинается матчинг.
На основе заявок в стакане ближней ноги и стакане КС, в стакане дальней ноги появляется синтетическая заявка на покупку RTS-12.18 в количестве 10 по цене 115000, выставленная от имени НКЦ, которая сводится в сделку с заявкой от участника "C".
В стакане ближней ноги появляется синтетическая заявка на продажу RTS-9.18 по цене 114000 с объемом 10 от имени НКЦ, которая сводится в сделку с заявкой от участника "B", в стакане КС - синтетическая заявка на продажу RTS-9.18-12.18 по цене 1000 с объемом 10 от имени НКЦ, которая сводится в сделку с заявкой по календарному спреду от участника "A".
Таким образом образуются три сделки: по ближнему фьючерсу (контрагенты: "B" и НКЦ) по цене 114000, по дальнему фьючерсу (контрагенты: "C" и НКЦ) по цене 115000 и по календарному спреду (контрагенты: "A" и НКЦ) по цене 1000. Также образуются две технические сделки, отображающие движение ног по календарному спреду. Для обеих технических сделок контрагенты "A" и НКЦ.
Остались несведенными заявка RTS-9.18-12.18 в объеме 10 и заявка RTS-9.18 в объеме 2.
Таким образом, в зависимости от входящей активной заявки возможны 6 вариантов синтетического матчинга:
Активная заявка | Встречная реальная заявка | Формирование встречной (пассивной) синтетической заявки | Цена встречной пассивной синтетической заявки |
---|---|---|---|
Покупка ближнего фьючерса | Продажа ближнего фьючерса | Продажа дальнего фьючерса + Покупка КС | Цена дальнего фьючерса - Цена КС |
Продажа ближнего фьючерса | Покупка ближнего фьючерса | Покупка дальнего фьючерса + Продажа КС | Цена дальнего фьючерса - Цена КС |
Покупка дальнего фьючерса | Продажа дальнего фьючерса | Продажа ближнего фьючерса + Продажа КС | Цена ближнего фьючерса + Цена КС |
Продажа дальнего фьючерса | Покупка дальнего фьючерса | Покупка ближнего фьючерса + Покупка КС | Цена ближнего фьючерса + Цена КС |
Покупка КС | Продажа КС | Покупка ближнего фьючерса + Продажа дальнего фьючерса | Цена дальнего фьючерса - Цена ближнего фьючерса |
Продажа КС | Покупка КС | Продажа ближнего фьючерса + Покупка дальнего фьючерса | Цена дальнего фьючерса - Цена ближнего фьючерса |
Первый приоритет матчинга - это цена. Вне зависимости от типа заявки (синтетическая/реальная) активная матчится с той пассивной, у которой лучше цена. Если у пассивной синтетической и пассивной реальной заявки цены совпадают, то сначала активная заявка матчится с той, что поступила раньше. Так как у календарного спреда две ноги поступают в разное время, то время такого спреда определяется по времени последней поступившей ноги. В каждом стакане (календарного спреда, ближнего и дальнего фьючерсов) цена заключаемой сделки определяется ценой пассивной заявки, как и в текущей реализации.
При синтетическом матчинге строится синтетика любой глубины, необходимой для сведения активных заявок. В агрегированных стаканах по умолчанию индикативно транслируется глубина 5 ценовых уровней, формируемых индикативными синтетическими заявками. Индикативная синтетическая заявка - "виртуальная заявка", используемая для формирования агрегированного стакана, отражающего доступную синтетическую ликвидность. Ударив по такой заявке участник может совершить сделку посредством синтетического матчинга.
Пример
Допустим, есть три стакана RTS-9.18, RTS-12.18, RTS-9.18-12.18, которые полностью пустые в данный момент.
В стакане RTS-9.18 (стакан 1) участник "A" ставит заявку на покупку по цене 114000 в объёме 12 контрактов. Затем в стакане RTS-12.18 (стакан 2) участник "B" ставит заявку на продажу по цене 115000 в объёме 10 контрактов.
В результате в стакане RTS-9.18-12.18 (стакан 3), появляется индикативная синтетическая заявка на продажу календарного спреда RTS-9.18-12.18 по цене 115000 - 114000 = 1000, в объёме 10 контрактов, образованная из заявок, выставленными участниками "A" и "B".
Участник "C" может ударить по индикативной синтетической заявке - купить КС RTS-9.18-12 в стакане 3 по цене 1000 в объёме 10 контрактов.
На основе заявок в стаканах 1 и 2, выставленных участниками "A" и "B". в стакане 3 появляется синтетическая заявка на продажу календарного спреда RTS-9.18-12.18 в количестве 10 по цене 1000, выставленная от имени НКЦ, которая сводится в сделку с заявкой по календарному спреду от участника "C".
В стакане 1 появляется синтетическая заявка на продажу RTS-9.18 по цене 114000 с объемом 10 от имени НКЦ, которая сводится в сделку с заявкой от участника "A", а в стакане 2 - синтетическая заявка на покупку RTS-12.18 по цене 115000 с объемом 10 от имени НКЦ, которая сводится в сделку с заявкой от участника "B".
Таким образом образуются три сделки: по ближнему фьючерсу (контрагенты: "A" и НКЦ) по цене 114000, по дальнему фьючерсу (контрагенты: "B" и НКЦ) по цене 115000 и по календарному спреду (контрагенты: "C" и НКЦ) по цене 1000. Также образуются две технические сделки, отображающие движение ног по календарному спреду. Для обеих технических сделок контрагенты A и НКЦ.
Синтетическая ликвидность транслируется в потоке агрегатов (FORTS_AGGR##_REPL) совместно с ликвидностью по реальным заявкам. При этом помимо суммарного объема (поле volume), например, если внутри одного ценового уровня есть как и реальные заявки, так и индикативные синтетические объемы, в отдельном поле транслируется синтетический объем (поле synth_volume).
Рассмотрим пример, когда в обычный агрегированный стакан добавляется синтетическая ликвидность. Есть агрегированные стаканы календарного спреда и его ног с натуральной ликвидностью.
Эти же стаканы, но с учетом синтетической ликвидности, выглядят следующим образом.
Изображена вся посчитанная синтетическая ликвидность без учета ограничения на количество уровней агрегированного стакана синтетической ликвидности. Ценовые уровни, где есть синтетическая ликвидность, подсвечены красным.
Видно, что в календарном спреде синтетическая ликвидность существенно сузила ценовой спред и сделала стакан календарного спреда более привлекательным для трейдеров. В этом и заключается цель синтетического матчинга - показать трейдерам лучшую доступную цену и потенциально больший объем исполнения их заявок по лучшей средней цене исполнения.
В стакане дальней ноги ситуация уже не столь радикально изменилась за счет синтетической ликвидности. Хотя и здесь, если трейдер подаст заявку в покупку 15 контрактов по цене 66212, то он получит сделки не только с заявками по тому же инструменту (уровни 5 по 66200, 1 по 66202, 3 по 66210, что дает исполнение 9 контрактов из 15), но еще и получит сделку в синтетическом мачтинге на 6 оставшихся контрактов по цене 66211. Этот синтетический матчинг использует 6 контрактов на продажу Si-6.19-9.19 по 860 и 6 контрактов на продажу Si-6.19 по 65351.
В стакане же ближней ноги синтетическая ликвидность остается на заднем плане, что и понятно - ближняя нога и так наиболее ликвидный инструмент с наименьшим ценовым спредом.
Синтетическая ликвидность в агрегированных стаканах обновляется с той же частотой, с какой обновляется агрегированные стаканы. Частота обновления агрегированных стаканов ниже частоты торговых событий, происходящих в системе. Иными словами, агрегированный стакан, а значит и синтетическая ликвидность в нем не обновляется на каждую заявку или сделку. Участник, желающий оценивать полную глубину синтетической ликвидности (более 5 ценовых уровней) и ее изменение при каждом торговом событии (транзакции), должен самостоятельно рассчитывать доступную синтетическую ликвидность на основании информации в публичном orders_log.
Так же следует учитывать, что в публичном orders_log синтетические заявки появляются только, когда происходит синтетический матчинг, в объеме необходимом для заключения сделки, т.е. синтетические заявки полностью исполняются внутри той транзакции, в которой они порождены. Поэтому если пользователь сам собирает стакан по orders_log (без построения синтетики) и сверяет его, например, с данными, транслируемыми в FORTS_AGGR##_REPL, то стаканы эти будут отличаться – в стакане из FORTS_AGGR##_REPL могут быть цены, которые «не видно» в стакане, построенном по orders_log.
В потоке коммонов (FORTS_COMMON_REPL) поля с лучшими ценами и объемами по лучшей цене также рассчитываются с учетом синтетической ликвидности, при этом в старых полях (типа best_buy, best_sell, xamount_buy, xamount_sell и т.п) транслируется сумма натуральной и синтетической ликвидности, а в новых (с постфиксом _native) - отдельно синтетическая.
Сделки урегулирования заключает НКЦ от имени и по расчетному коду (РК) участника клиринга.
Если участник клиринга не выполнил обязательства в установленный срок, то НКЦ считает такого участника Недобросовестным участником клиринга (НУК). НКЦ от имени и по РК НУК заключает сделки, приводящие к сокращению позиции и выполнению обязательств. Цель сделок – устранить недостаточность обеспечения по обязательствам, с наступившей и не наступившей датой исполнения. Более подробно процедура описана в Правилах Клиринга, статья "Порядок возникновения и исполнения Маржинальных требований".
НКЦ заключает сделки урегулирования от имени и по предварительно согласованному РК Добросовестного участника клиринга (ДУК), в случае если сделка урегулирования с НУК не может быть заключена "в стакане". Более подробно процедура описана в Правилах Клиринга, статья "Порядок заключения закрывающих и/или балансирующих сделок". По сделкам с ДУК комиссии (штрафы) не взимаются.
Признак сделок урегулирования транслируется в шлюзе в таблицах своих заявок orders_log и multileg_orders_log (поле reason) и сделок user_deal и user_multileg_deal (поля reason_buy и reason_sell), а также в отчетах f04, f04cl, o04, o04cl.
Значение поля reason/ reason_buy/ reason_sell | Причина | Участник |
---|---|---|
0 | Обычная сделка. | УК |
4 | Балансирующие Срочные контракты, заключенные с Добросовестным участником клиринга без подачи заявок. | ДУК |
6 | Закрывающие Срочные контракты, заключенные в рамках процедуры кросс-дефолта. | НУК |
7 | Закрывающие Срочные контракты, заключенные в связи с неисполнением Маржинального требования. | НУК |
8 | Закрывающие Срочные контракты, заключенные в связи с неисполнением Обязательства по поставке по поставочным Срочным контрактам на драгоценные металлы. | НУК |
100 | Иное | НУК |
В отчетах f04, f04cl, o04, o04cl причина сделок урегулирования указана в поле Type.
Отчеты о сделках с фьючерсами f04, f04cl:
"3" - для балансирующих Срочных контрактов, заключенных с Добросовестными участниками клиринга без подачи заявок;
"21" - для закрывающих Срочных контрактов, заключенных в рамках процедуры кросс-дефолта;
"22" - для закрывающих Срочных контрактов, заключенных в связи с неисполнением Маржинального требования;
"23" - для закрывающих Срочных контрактов, заключенных в связи с неисполнением Обязательства по поставке по поставочным Срочным контрактам на драгоценные металлы.
Отчеты о заключенных опционных контрактах o04, o04cl:
"3" - для балансирующих Срочных контрактов, заключенных с Добросовестными участниками клиринга без подачи заявок;
"6" - для закрывающих Срочных контрактов, заключенных в рамках процедуры кросс-дефолта;
"7" - для закрывающих Срочных контрактов, заключенных в связи с неисполнением Маржинального требования.
За сделки урегулирования с Недобросовестных участников клиринга вместо комиссии взимается штраф. Сумма штрафа за заключение закрывающих Срочных контрактов равна сумме 5 биржевых сборов, установленных ПАО Московская Биржа, и 5 комиссионных вознаграждений за клиринг от суммы закрывающих Срочных контрактов. Штраф рассчитывается по каждой сделке урегулирования и учитывается по 7-значному разделу участника клиринга, который указан в сделке урегулирования.
Информация о штрафах транслируется в шлюзе в поле penalty в таблице part потока FORTS_PART_REPL (суммарно по 7-значному разделу), а также в таблице penalty потока FORTS_FEE_REPL (в разрезе сделок).
Штрафы и комиссии за заключение сделок урегулирования от имени Добросовестного участника клиринга (балансирующие Срочные контракты, заключенные с Добросовестным участником клиринга без подачи заявок) с ДУК не взимаются.
Штрафы за заключение закрывающих Срочных контрактов с НУК не взимаются:
Если в отношении участника клиринга проводится процедура Ликвидационного неттинга.
Если участник клиринга находится в статусе "Приостановка клирингового обслуживания участника клиринга по причине аннулирования лицензии на осуществление профессиональной деятельности на рынке ценных бумаг".
Информация по данным блокировкам транслируется в шлюзе в таблице clearing_members потока FORTS_REFDATA_REPL.
Сделки урегулирования, по которым штрафы не взимались по причине аннулирования лицензии на осуществление профессиональной деятельности на рынке ценных бумаг, помечаются в таблицах сделок в полях xstatus_sell и xstatus_buy специальным признаком:
DontFineRF (0x80000000000000) - Признак невзимания штрафа за сделки урегулирования.
Информация о сумме штрафа включается в виде нового типа платежа в отчеты pay в дату списания. Штрафы учитываются в отчете в состоянии текущей денежной позиции. Отчеты:
payXXYY.csv;
payclXXYY.csv.
В версии SPECTRA 7.0 на Срочном рынке появляются новые производные инструменты – опционы на акции. Особенность этих инструментов заключается в том, что базовым активом для них является акция, а не фьючерс на нее. То есть логически появляется прямая связка опционной серии (ОС) непосредственно с БА, минуя фьючерс. Однако физически ОС для таких опционов будут заводиться на специальный фьючерс (коллатерал). Данный инструмент уже имеется в ТС SPECTRA и используется для передачи профилей активов на суб-счета расчётных кодов Единого пула. Таким образом, иерархическая структура инструментов не меняется и для опционов на акции остается полностью идентична опционам на фьючерсы.
На первом этапе предполагается ввести только европейские премиальные расчетные опционы на акции.
Так как планируется запуск опционов не только на российские, но и на иностранные акции, то взаиморасчёты по премии и финансовому результату исполнения опционов могут производиться в соответствующей иностранной валюте. В связи с этим следует отличать валюту котирования (поле curr) и валюту расчётов (новое поле settlement_currency) в таблице opt_vcb потока FORTS_REFDATA_REPL.
Обращаем ваше внимание, что в результате ВК на разделах учёта залогов (pledge_details), принадлежащих РК, не входящих в Единый пул, могут образовываться отрицательные остатки по валютам. В связи с этим рублёвая переоценка обеспечения по таким расчётным кодам и БФ с признаком limit_tied_to_money = 1, будет проводиться по формуле: ОБЪЁМ_ОБЕСПЕЧЕНИЯ_В_ВАЛЮТЕ * КУРС_ВАЛЮТЫ - abs(ОБЪЁМ_ОБЕСПЕЧЕНИЯ_В_ВАЛЮТЕ * КУРС_ВАЛЮТЫ * ВАЛЮТНЫЙ_РИСК).
Опцион на акции определяется по следующим признакам:
Опционная серия опциона на акции привязана к коллатеральному фьючерсному инструменту: в поле underlying_id соответствующей записи из таблицы FORTS_REFDATA_REPL:sess_option_series содержится идентификатор фьючерса, который можно найти в таблице FORTS_REFDATA_REPL:fut_sess_contents по полю isin_id; в полученной записи в поле signs должен быть взведён бит 0x40000 (признак коллатерального инструмента);
Базовым активом для коллатерального фьючерсного инструмента является акция: в поле asset_class записи таблицы FORTS_REFDATA_REPL:fut_vcb, связанной с FORTS_REFDATA_REPL:fut_sess_contents по полю base_contract_code, должно быть значение 1 – «Акция». Код акции содержится в поле SECCODE таблицы FORTS_REFDATA_REPL:fut_vcb.
Так как новые опционы являются премиальными, то к ним применяются особые правила исполнения требований и обязательств. В первую же клиринговую сессию после заключения сделки, производится взаиморасчет по премиям. То есть расчет происходит "тут же", без ежедневного перечисления вармаржи, как в случае с маржируемыми опционами.
Премиальные опционы имеют стоимость и (по просьбам участников) будут использоваться в качестве обеспечения по портфелю, а также влиять на объём свободных средств (FreeMoney). Величина корректировки FreeMoney будет доступна в виде нового параметра NetOptionValue (NOV), который будет рассчитываться в ближайшую клиринговую сессию как сумма произведений учетных стоимостей и объемов соответствующих опционных позиций в портфеле с учетом знака:
voli – объем позиции в i-м опционном контракте по итогам текущей клиринговой сессии;
RCi – расчетная цена i-го опционного контракта по итогам текущей клиринговой сессии.
Величина NetOptionValue (поле net_option_value таблиц part и part_sa потока FORTS_PART_REPL) определяется по каждому уровню учета позиций (клиент, БФ, РК). Для фьючерсов и маржируемых опционов на фьючерсы значение NOV всегда равно нулю.
Поскольку по премиальным опционам на акции вариационная маржа отсутствует, значения VM, выдаваемые ТКС всегда будут нулевыми по таким инструментам. В связи с этим появляется новый индикатив по премиям (поле premium в таблице opt_vm потока FORTS_VM_REPL), отражающий величину премии к уплате/получению в ближайшую клиринговую сессию. Вычисляемое значение не включает в себя финансовый результат исполнения опционной позиции в день экспирации опционов на акции. Данная величина рассчитывается индикативно, исключительно для информирования Участников клиринга. А поскольку расчеты могут производиться не только в рублях, то трансляция премии в валюте расчётов будет осуществляться в отдельном поле premium_in_settl_currency таблицы opt_vm потока FORTS_VM_REPL.
При начислении или списании валютной премии будет меняться торговый лимит на клиенте и на БФ (с опцией свободного управления лимитом). Величина изменения лимита равна объёму премии в валюте, пересчитанному в рубли по курсу валюты, зафиксированному на момент клиринга.
Для осуществления взаиморасчетов в момент экспирации необходимы цены БА (акций), которые берутся из поля LCLOSEPRICE таблицы SECURITIES торгового шлюза Фондового рынка. Получение этих данных влечет за собой сдвиг начала вечернего клиринга на 18:50 МСК и окончания клиринговой сессии - на 19:05 MCK. Сдвиг вечерней клиринговой сессии влечет за собой сдвиг начала вечерней торговой сессии на 19:05 MCK.
Поскольку запускаемые опционы на акции являются европейскими и расчётными, исполняться будут только опционы, находящиеся "в деньгах", в автоматическом режиме и заявки на исполнение/отказ от исполнения по таким опционам приниматься не будут.
Как было сказано ранее, для определения цены исполнения опциона в день экспирации используется цена БА, полученная из поля LCLOSEPRICE таблицы SECURITIES торгового шлюза Фондового рынка. Данная цена фиксируется в размерности коллатерального инструмента в поле underlying_price таблицы option_series_settl потока FORTS_CLR_REPL. В остальные дни в этом поле передается цена коллатерала, определенная на момент проведения клиринга согласно методике расчетных цен.
Премия по опционным контрактам с расчетами в рублях, полученная/списанная в промежуточный клиринг, транслируется в шлюзе в поле premium таблицы opt_intercl_info потока FORTS_REFDATA_REPL. Значение включает в себя финансовый результат исполнения опционной позиции в день экспирации опционов на акции. Премия по опционным контрактам с расчетами в валюте, полученная/списанная в промежуточный клиринг, транслируется в отдельном поле premium_in_settl_currency таблицы opt_intercl_info потока FORTS_REFDATA_REPL. При осуществлении расчетов в рублях это поле заполняется нулем. Аналогично, при расчетах в валюте рублевая премия (поле premium) равна нулю.
Премия по опционным контрактам с расчетами в рублях, полученная/списанная в вечернюю клиринговую сессию, транслируется в полях premium таблиц opt_pos и opt_pos_sa потока FORTS_CLR_REPL. Транслируемое значение включает в себя финансовый результат исполнения опционной позиции в день экспирации опционов на акции. Премия по опционным контрактам с расчетами в валюте, полученная/списанная в вечернюю клиринговую сессию, транслируется в полях premium_in_settl_currency таблиц opt_pos и opt_pos_sa потока FORTS_CLR_REPL. При осуществлении расчетов в рублях эти поля заполняются нулем. Аналогично, при расчетах в валюте рублевая премия (поля premium) равна нулю.
Так как базовым активом опционов на акции является коллатеральный фьючерс (по физической сути – спот-актив), значения его риск-параметров, в отличие от реальных торговых фьючерсов, не содержат в себе ничего, кроме рыночного риска. Поэтому все необходимые величины (уровень безрисковой процентной ставки, ставки рассогласования процентного риска и риска изменения прогнозных дивидендов) учитываются уже непосредственно при маржировании самих опционов. Для премиальных европейских опционов на акции не вычисляются риски экспирации, так как инструмент является расчетным, а не поставочным.
В иерархии маржирования системы расчета гарантийного обеспечения появляется новый уровень взятия ГО - опционная серия. Ранее минимальным уровнем являлся фьючерс и его риски неттировались с рисками по всем принадлежащим ему опционным сериям.
Появляются дополнительные поля для описания БА и ОС, значения из которых будут использоваться в формулах ценообразования опционов. Для расчета теоретических цен опционов применяются две модели ценообразования: Блэка-Шоулза и Башелье. В штатном режиме работы модель Башелье не применяется для премиальных опционов на акции, т.к. отрицательные цены по таким БА не предполагаются. Для расчета теоретических цен по опционам на акции будет использоваться модель Блэка-Шоулза с дискретной выплатой дивидендов. В связи с разделением дивидендов на прогнозные и объявленные, денежный поток содержит в себе информацию двух типов. Первый тип включает в себя величину ожидаемых дисконтированных дивидендов, а второй - объявленных.
В связи с тем, что все акционные опционные серии (внутри одного БА) будут заводиться не на разные фьючерсы, а на единственный коллатеральный, невозможно запрещать торговлю группами ОС, так как в нынешней реализации возможно устанавливать определённые ограничения только сразу на все опционы внутри одного фьючерса. Поэтому по опционам на акции возможно устанавливать запреты сразу на все опционы в рамках одного БА - запрет на опционы с isin коллатерального фьючерса (opt_sess_contents.fut_isin_id). Либо полный запрет опционов - group_mask = 0x80000000 (опционы).
ПО PLAZA II шлюз включает в себя следующие программные компоненты:
Модуль P2MQRouter. Данный модуль обеспечивает:
Установку TCP-соединений с серверами биржи.
Стандартно шлюз PLAZA II использует четыре TCP-соединения с серверами биржи:
Соединение для подачи приказов/команд (Order Management).
Соединение для получения основных рыночных данных (Primary Data). К таким данным относятся потоки агрегатов, потоки FORTS_ORDLOG_REPL, FORTS_DEALS_REPL, FORTS_TRADE_REPL, FORTS_COMMON_REPL.
Соединение для получения вспомогательных и справочных потоков (Other Data).
Соединение для получения данных для восстановления при восстановлении связи или первоначальном присоединении (Snapshot).
Все настройки для данных соединений прописаны в конфигурационных файлах роутера, при этом соединение для "Other Data" указывается как исходящее default connection, а остальные как исходящие direct connection. Такое построение является основной штатной конфигурацией при подключении к серверной ферме биржи. Конфигурация соединений при подключении через сервер доступа брокера может отличаться, в этом случае требуется запрашивать конкретную конфигурацию у владельца сервера.
Прием/отправку P2-сообщений.
Шифрацию информации, отправляемую участником, и дешифрацию информации, принимаемую от биржи.
Аутентификацию участника в сети биржи.
Шлюзовая библиотека cgate.
Библиотека является официальными программным интерфейсом, предоставляемым участникам торгов, клиентам участников торгов, а также компаниям-разработчикам для создания программного обеспечения. Данный интерфейс обеспечивает возможность создания и отсылки бизнес-сообщений в ТС, а также получения рыночной информации из нее (репликация данных). Библиотека выпускается для 32х разрядных и 64х разрядных систем Windows, а также для ОС Linux.
Системные библиотеки PLAZA II.
Комплект средств разработки: дополнительные утилиты и командные файлы, документация, тестовые примеры.
Требования к аппаратному обеспечению варьируются в зависимости от способа использования шлюза PLAZA II.
Минимальные требования к компьютеру для индивидуального логина с обработкой данных в памяти без сохранения на диск:
Процессор Core 2 duo с частотой 1 ГГц или выше
Оперативная память не меньше 2 Гб, для 64-битных ОС 4Гб
Минимальные требования к компьютеру для брокерского логина с обработкой данных в памяти без сохранения на диск:
2-х процессорный сервер на Intel Xeon как минимум серии 53xx или аналогичных процессорах от AMD (2 физических процессора, количество ядер от 2-х и больше)
Оперативная память не меньше 24 Гб
Отдельный контроллер SAS. Как минимум 2 диска в RAID1. Два раздела 30 Гб.
Минимальные требования к компьютеру для брокерского логина с обработкой данных с сохранением на диск:
2-х процессорный сервер на Intel Xeon как минимум серии 53xx или аналогичных процессорах от AMD (2 физических процессора, количество ядер от 2-х и больше)
Оперативная память не меньше 4 Гб
Отдельный контроллер SAS с режимом кеширования записи write-back. Как минимум 4 диска в RAID10. Два раздела 30 Гб
Шлюзовое ПО поддерживает следующие версии операционных систем:
Microsoft Windows 10 (допустимы как 32-битные, так и 64-битные версии ОС)
Microsoft Windows Server 2016/2019 (допустимы как 32-битные, так и 64-битные версии ОС)
Linux RedHat/CentOS 7, AstraLinux SE v. 1.7, RedOS v. 7.3, AltLinux workstation 10.1, также возможно использование других дистрибутивов
Заберите новую версию шлюза с сервера разработчиков https://ftp.moex.com/pub/ClientsAPI/Spectra/CGate/. Имя инсталляционного файла - setup_SpectraCGate_x64_vx.x.x.msi, где х.х.х - номер версии ПО, например 7.0.0.
Запустите полученный файл setup_SpectraCGate_x64_vx.x.x.msi. Установка производится с помощью мастера установки.
Нажмите кнопку "Далее" для продолжения установки.
По умолчанию для установки программы предлагается папка C:\Moscow Exchange\SpectraCGate\. Если вас это устраивает, нажмите кнопку "Далее" для продолжения и выбора вида установки.
Если вы хотите выполнить установку в другую папку, нажмите кнопку "Изменить..." и в появившемся окне "Изменение текущей папки назначения" выберите новую папку с помощью окна "Поиск в папке"; для перехода на уровень выше в дереве папок используйте кнопку . Вы также можете создать новую папку назначения при помощи кнопки или ввести путь к уже существующей папке вручную в поле "Имя папки" в нижней части окна. Для сохранения внесённых изменений нажмите кнопку "ОК" — окно изменения папки назначения закроется, и вы вернётесь в предыдущее окно "Папка назначения". Нажмите кнопку "Далее" для продолжения и выбора вида установки.
Обратите внимание, что вы сможете изменить папку назначения только при первой установке программы или при переустановке программы "с нуля". В остальных случаях кнопка "Изменить..." будет неактивна.
Выберите вариант установки, определяющий состав устанавливаемых программных компонентов. Полная установка предполагает установку всех компонентов шлюза: модуля P2MQRouter, библиотеки cgate, дополнительных утилит, а также комплекта средств разработки. Выборочная - это различные комбинации программных компонент.
Нажмите кнопку "Далее", чтобы активировать следующий шаг.
Выберите требуемые программные компоненты и каталог для установки. Директория установки должна быть расположена в соответствии с административными рекомендациями.
Нажмите кнопку "Далее", чтобы активировать следующий шаг.
Выберите ТС, к которой необходимо подключиться (production, тестовая, игровая и т.п.), или введите свои параметры для соединения с серверами биржи. Для каждого варианта подключения параметры соединения хранятся в отдельном конфигурационном файле, который находится в каталоге \links директории установки:
Вариант подключения | Файл с настройками подключения | Описание |
---|---|---|
Выделенный канал | links_public.prod.ini | Подключение к Spectra боевой контур |
Резервный канал | links_public.rezerv.ini | Подключение к Spectra резервный контур |
Тестовая система для разработчиков T0 | links_public.t0.ini | Подключение к Spectra публичный тестовый контур - текущая версия |
Тестовая система для разработчиков T1 | links_public.t1.ini | Подключение к Spectra публичный тестовый контур - будущая версия |
Игровая система | links_public.game.ini | Подключение к Spectra игровой контур |
Свои параметры соединения | links_public.custom.ini | Подключение, заданное пользователем |
После установки ссылка на соответствующий файл с параметрами соединения прописывается в ini-файле модуля P2MQRouter в параметре connections_ini. Такой подход позволяет упростить процесс переключения модуля P2MQRouter между полигонами и системами Spectra - для смены подключения достаточно просто перезапустить инсталлятор и выбрать нужный вариант. Обратите внимание, что в случае переустановки или деинсталляции системы каталог \links и файл с пользовательскими настройками подключения (links_public.custom.ini) не удаляются.
В полях секции пользовательских настроек отображаются:
При первоначальной установке ПО - значения по умолчанию (параметры из links_public.t1.ini в качестве примера).
При переустановке ПО - пользовательские параметры подключения из links_public.custom.ini или client_router.ini. Если файлы отсутствуют, то отображаются значения по умолчанию.
Напоминаем, что для выбора правильных адресов подключения необходимо проконсультироваться с вашим брокером и/или службой технической поддержки биржи.
Нажмите кнопку "Далее", чтобы активировать следующий шаг.
Введите логин и пароль для выбранного на предыдущем шаге подключения. Обратите внимание на то, что логины и пароли от боевых подключений, тестовых и игровых – разные.
После установки логин и пароль прописываются в отдельном конфигурационном файле auth_client.ini, который находится в каталоге \auth директории установки, а в ini-файле модуля P2MQRouter в параметре auth_ini указывается ссылка на этот файл.
При переустановке ПО в полях формы отображаются значения логина и пароля, заданные в auth_client.ini или client_router.ini. Обратите внимание, что в случае переустановки или деинсталляции системы каталог \auth и файл с аутентификационными данными (auth_client.ini) не удаляются.
Нажмите кнопку "Далее", чтобы активировать следующий шаг.
При необходимости установить роутер как сервис ОС Windows выставите чекбокс и нажмите кнопку "Далее", чтобы активировать следующий шаг.
Если при инсталляции P2MQRouter не был зарегистрирован как сервис ОС, в дальнейшем это можно исправить вручную, воспользовавшись командным файлом install_router.cmd (uninstall_router.cmd) из дистрибутива.
Нажмите кнопку "Установить", чтобы начать установку.
Нажмите кнопку "Готово" для завершения процесса установки.
Дистрибутив Cgate состоит из инсталляционого скрипта и архива, в котором находятся загружаемые модули проекта cgate и проекта cgate_java, файлы include, файлы документации и файлы примеров. Дистрибутив доступен для скачивания по адресу: https://ftp.moex.com/pub/ClientsAPI/Spectra/CGate/.
Порядок установки:
Выполните команду:
chmod 755 ./install.sh
Выполните команду:
./install.sh ./cgate_linux_amd64-7.12.0.103.zip
Внимание! Имя архива привязано к версии ПО и может отличаться от имени, которое указано в примере выше.
В ответ на запрос: "Please, enter cgate install path:" укажите полный путь к каталогу, в который вы хотите распаковать шлюз.
В ответ на запрос: "Please, enter P2 login:" укажите логин пользователя.
В ответ на запрос: "Please, enter P2 password:" укажите пароль пользователя.
Дальнейшие шаги установки различаются в зависимости от версии ОС Linux, установленной на компьютере:
Debian 6:
Установить пакет ant
Установить пакет openjdk-6-jdk (компиляция примеров java)
Установить пакет g++ (компиляция примеров C++).
CentOS 6:
Установить пакет gcc
Установить пакет gcc-c++ (компиляция примеров C++)
Установить пакет ant (компиляция примеров java).
Порядок установки:
Скачайте и установите пакет шлюза с помощью команды:
dpkg -i cgate_<version>_amd64.deb
в случае установки из deb-пакета, или команды:
rpm -U cgate-<version>.x86_64.rpm
в случае установки из rpm-пакета.
<version> - номер версии дистрибутива
Таблица раскладки компонентов:
Куда ставится | Описание |
---|---|
/opt/moex/cgate | Бинарники, схемы, документация по шлюзу |
/etc/opt/moex/cgate | Настроечные файлы, auth.ini - файлы |
/var/opt/moex/cgate | Каталог логирования, трейс файлы |
/usr/share/doc | Copyright, документация по установке |
Зайдите в каталог /etc/opt/moex/cgate/auth и в соответствующем ini-файле укажите логин/пароль для подключения:
prod.ini - для подключения к production системе
t1.ini - для подключения к полигону T1
t0.ini - для подключения к полигону T0
game.ini - для подключения к игровому полигону
Внимание! Обратите внимание, что в случае переустановки пакета каталог \auth и файлы с настройками подключения не удаляются, поэтому повторно настраивать логин/пароль не потребуется.
Запустите сервис (роутер) с помощью команды:
systemctl start cgate@<profile>
<profile> - вариант подключения. В качестве профиля можно указать:
prod - подключение к Spectra боевой контур
rezerv - подключение к Spectra резервный контур
t1 - подключение к полигону T1
t0 - подключение к полигону T0
game - подключение к игровому полигону
rfs.prod - подключение к Spectra боевой контур с дополнительным доступом к RFS
rfs.rezerv - подключение к Spectra резервный контур с дополнительным доступом к RFS
rfs.t1 - подключение к полигону T1 с дополнительным доступом к RFS
rfs.t0 - подключение к полигону T0 с дополнительным доступом к RFS
Внимание! Обратите внимание, что при апгрейде пакета запущенный сервис останавливается, поэтому после обновления сервис нужно запустить заново.
Для проверки корректности установки ПО и готовности к разработке можно выполнить тестовую сборку примеров и их исполнение.
Примеры располагаются в каталоге Moscow Exchange\SpectraCGate\SDK\samples для платформы Windows или в каталоге /usr/share/doc/cgate-examples (/opt/moex/cgate/samples) для Linux. Сборка примеров выполняется запуском сборочных скриптов, которые различаются в зависимости от используемой платформы и языка программирования. Для ОС Linux рекомендуется сделать копию примеров в своём домашнем каталоге и собирать их оттуда.
Описание примеров:
Пример aggrspy
aggrspy - пример построения агрегированного стакана на покупку и продажу по фиксированному инструменту по потоку FORTS_AGGR50_REPL. При нажатии Enter в outfile выводится срез стакана.
Команда для запуска:
aggrspy ISIN_ID depth outfile [r]
Входные аргументы:
isin_id - id инструмента;
depth - глубина выводимого стакана в файл (не больше 50);
outfile - файл для печати стакана;
r - включить обратное направление сортировки (параметр используется для инструментов с обратной сортировкой).
Пример repl
repl - получение реплики данных по потоку. Пример печатает все получаемые сообщения в log. При разрыве соединения реплика начинается сначала. Входных аргументов нет.
Пример repl_resume
repl_resume - пример аналогичен repl. Отличие заключается в том, что после разрыва соединения repl_resume продолжает реплику с последнего сообщения TN_COMMIT. Входных аргументов нет.
Пример send
send - выставляет заявку на SPECTRA. Выводит в лог ответ торговой системы. Входных аргументов нет.
Пример orderbook
orderbook - пример построения агрегированного стакана на покупку и продажу по фиксированному инструменту по online потоку FORTS_ORDLOG_REPL и снэпшот потоку FORTS_USERORDERBOOK_REPL. Рекомендуется для разработки late join и минимизации времени простоя при закачке архивных данных. При нажатии Enter в outfile выводится срез стакана.
Команда для запуска:
orderbook ISIN_ID depth outfile [r]
Входные аргументы:
isin_id - id инструмента;
depth - глубина выводимого стакана в файл (не больше 50);
outfile - файл для печати стакана;
r - включить обратное направление сортировки (параметр используется для инструментов с обратной сортировкой).
Пример p2sys
p2sys - пример авторизации роутера из cgate. Повторяет в цикле следующие действия:
Посылает ошибочный набор (login, pwd), в ответ получает сообщение logon failed;
После этого посылает правильный набор (login, pwd);
На сообщение об успешной авторизации посылается запрос на logout;
Возврат к началу.
Пример send_mt
send_mt - пример многопоточной посылки заявки. (Примечание: компилируется только под компиляторами, поддерживающими C++11.). В треде 1 посылаются заявки. В треде 2 обрабатываются reply на посылаемые заявки.
Для исполнения примеров необходимо убедиться, что P2MQRouter запущен и соединен с сетью PLAZA II (анализом сообщений роутера), в доступности библиотек PLAZA II для запускаемого файла примера (возможно потребуется добавление каталога Moscow Exchange\SpectraCGate\bin в переменную окружения PATH или указание каталога Moscow Exchange\SpectraCGate\bin в вашей среде разработки), а также в доступности конфигурационных файлов.
Примечание: Указанные примеры не предназначены для копирования и использования в работе с данными, отличными от тестовых. Использование этих примеров для работы с реальными логинами категорически запрещено.
Приложение пользователя с cgate и модуль P2MQRouter могут функционировать на разных компьютерах. Для разнесения роутера и клиентских приложений на разные компьютеры в сети брокера следует установить роутер из дистрибутива на компьютер, с которого будет осуществляться доступ в сеть биржи, установить cgate из дистрибутива на компьютер, где будет работать приложение пользователя, и сделать следующие настройки:
Со стороны клиента:
Установить свойства Host, Port в значения, соответствующие установке роутера в вашей корпоративной сети.
Правильно установить свойство Password — локальный пароль приложения AppName на роутере. При соединении приложения и роутера вне пределов одного компьютера, требуется задавать пароль локального соединения. Пароль локального соединения и пароль для аутентификации приложения в сети PLAZA II – это разные вещи! Нельзя их путать.
Со стороны роутера:
В ini-файле роутера в секции [AS:Local] прописать строку <AppName>=<local password>, где AppName и local Password – имя приложения и его локальный пароль – должны соответствовать параметрам, передаваемым клиентским приложением.
Набор файлов, который копируется в каталог установки шлюза Moscow Exchange\SpectraCGate\bin, а также схемы данных и сообщений, находящиеся в каталоге Moscow Exchange\SpectraCGate\SDK\scheme, должны копироваться пользователем из каталога установки в каталог со своим приложением и распространяться вместе с ним.
Не допускается использование различных версий модуля P2MQRouter и компонент cgate, так как они не являются совместимыми. При установке приложения пользователя следует контролировать, что используется та же самая версия P2MQRouter, что и при разработке.
В данном разделе описывается состав информации, транслируемой в шлюзе PLAZA II.
Все транслируемые данные разделены на следующие логические группы:
Справочная информация
Торговая информация
Информация для восстановления
Информация о средствах и лимитах
Клиринговая информация
Информация об индексах и курсах
Вспомогательные информационные потоки
Справочная информация содержит следующие данные:
Расписание и статус торговых сессий
Информация о времени проведения торговой сессии и её составляющих, таких как промежуточный клиринг, вечерняя и утренняя сессии, доступны в таблице session потока FORTS_REFDATA_REPL. В этой же таблице указывается статус сессии, что позволяет отслеживать изменения режима сессии.
Справочники инструментов и базовых активов, их свойства
Назначенные в торговую сессию фьючерсные инструменты доступны в таблице fut_sess_contents потока FORTS_REFDATA_REPL. Составные инструменты также перечислены в этой таблице. Опционные инструменты транслируются в таблице opt_sess_contents потока FORTS_REFDATA_REPL. Справочник базовых активов фьючерсов представлен таблицей fut_vcb потока FORTS_REFDATA_REPL.
Указанные справочники могут обновляться в ходе торговой сессии, например, в результате приостановки торгов по какому либо инструменту или во время операции расширения лимитов цен.
Справочники фирм и клиентов
Транслируются в таблицах dealer и investor потока FORTS_REFDATA_REPL. В данных справочниках доступны исключительно сведения о клиентах своей фирмы.
Справочник облигаций
Облигации описываются набором таблиц потока FORTS_REFDATA_REPL: справочник параметров спот-активов fut_bond_registry, справочник инструментов облигаций fut_bond_isin, НКД на даты выплат купонов fut_bond_nkd, размеры выплат номинальной стоимости облигации fut_bond_nominal.
Коэффициенты параметрической кривой волатильности для опционов
Транслируются в таблицах volat_coeff потоков FORTS_RISKINFOBLACK_REPL и FORTS_RISKINFOBACH_REPL.
Для осуществления операций на рынках торговой системы SPECTRA система пользователя должна получать в режиме он-лайн по крайней мере следующие справочные данные:
Расписание сессий (session)
Справочник инструментов (fut_sess_contents, opt_sess_contents)
Торговая информация включает в себя:
Агрегированные стаканы
Формируются на основе системных заявок пользователей путем суммирования объёма для каждого инструмента, ценового уровня и направления заявки. Обновляются в режиме он-лайн и являются основным способом получения информации о текущих ценах и объёмах. Пользователь может выбрать желаемую глубину стакана из вариантов 5, 20 или 50 ценовых уровней в каждом из направлений; данный выбор осуществляется при конфигурировании логина и не может быть изменен в ходе торговой сессии.
Стаканы транслируются несколькими потоками репликации PLAZA II: FORTS_AGGR5_REPL, FORTS_AGGR20_REPL и FORTS_AGGR50_REPL.
Общерыночные показатели
В составе общерыночных показателей транслируется такая информация как лучшие заявки на покупку и продажу, цены открытия, закрытия, текущие расчетные цены и т.п. Данная информация транслируется в потоке FORTS_COMMON_REPL.
Журнал заявок пользователя (а также - полный журнал заявок торговой системы)
В журнале заявок пользователя транслируется вся история операций по заявкам пользователя. Журналы заявок пользователя доступны в таблице orders_log потока FORTS_TRADE_REPL для фьючерсов и опционов, а также в таблице multileg_orders_log потока FORTS_TRADE_REPL для заявок по составным инструментам.
В случае, если пользователь при конфигурации логина указал опцию "Полный журнал заявок", помимо своих заявок, пользователь будет получать полный журнал всех операций с заявками на рынке в анонимизированном виде, доступный в таблице orders_log потока FORTS_ORDLOG_REPL.
Журнал сделок пользователя
Содержит список всех совершенных пользователем за текущую сессию сделок. Журналы сделок пользователя доступны в таблице user_deal потока FORTS_TRADE_REPL для фьючерсов и опционов, а также в таблице user_multileg_deal потока FORTS_TRADE_REPL для сделок по составным инструментам.
Журнал сделок торговой системы
Содержит список всех сделок, совершенных всеми пользователями за текущую сессию. Данные сделок чужих пользователей представлены в анонимизированном виде. Журналы сделок пользователя доступны в таблице deal потока FORTS_DEALS_REPL для фьючерсов и опционов, а также в таблице multileg_deal для сделок по составным инструментам.
Для обеспечения возможности быстрого восстановления получения торговой информации после потери соединения со SPECTRA, равно как и для реализации сценария позднего подключения к бирже, в составе шлюза PLAZA II осуществляется трансляция периодических срезов текущих стаканов в неагрегированном виде. Это позволяет получить актуальное состояние своих заявок (а в случае подключенной опции "Полный журнал заявок" - всех заявок в системе) на текущий момент времени.
Срезы активных заявок транслируются с периодичностью 2 минуты в потоке FORTS_USERORDERBOOK_REPL.
Включает следующие данные:
Информация о позициях
Транслируется в виде временных срезов в потоке FORTS_POS_REPL. Для каждого значения позиции доступен идентификатор последней сделки, вошедней в расчет записи по позиции.
Информация о средствах и лимитах клиентов
Транслируется в виде временных срезов в потоке FORTS_PART_REPL. Для каждого значения клиентского счета указаны размеры средств (как денег, так и залогов) на начало торговой сессии, текущие и резервы средств.
Клиринговая информация, транслируемая в составе шлюза PLAZA II включает следующие данные:
Расчетные цены клиринга
Формируются в момент проведения вечернего клиринга. Доступны в таблице fut_sess_settl потока FORTS_CLR_REPL. Таблица с расчетными ценами включает также инструменты, срок действия которых закончился, что позволяет использовать данную таблицу для получения правильных цен по которым будет произведена поставка.
Вариационная маржа (премия) промежуточного клиринга
Вариационная маржа (премия) промежуточного клиринга доступна в таблицах fut_intercl_info и opt_intercl_info потока FORTS_REFDATA_REPL для фьючерсов и опционов, соответственно.
Реестры отвергнутых в клиринг заявок
Перечисляются заявки, перевыставление которых в клиринг не было произведено по причине нехватки средства. Реестр транслируется в таблице rejected_orders потока FORTS_REJECTEDORDERS_REPL
Средства клиентов по результатам клиринга
Включают в себя информацию о сумме средств на счетах, движении по счетам, сборах, суммарном ГО и ВМ на момент клиринга. Транслируются в потоке FORTS_CLR_REPL.
Заявки на исполнение опционов
В составе данной группы присутствует следующая информация:
Текущие значения индексов РТС
Включает текущие значения биржевых индексов. Значения в данной таблице обновляются с периодичностью 15 секунд. В состав информации об индексах входит значение курса USD, с использованием которого был произведен расчет индекса. Данные транслируются в потоке RTS_INDEX_REPL.
Значения курсов валют
Содержат значения курсов валют, используемые в торговой системе для обработки контрактов, рассчитываемых в валюте, отличной от рублей. Значения курсов валют доступны в таблице curr_online потока MOEX_RATES_REPL.
В данную группу отнесены информационные потоки, предоставляющие дополнительные функции:
Текущие значения вариационной маржи и индикатив по премиям
Транслируются в потоке FORTS_VM_REPL в разрезе позиций клиентов и РК.
Текущие значения волатильности и теоретические цены для опционов
Транслируются в потоке FORTS_VOLAT_REPL.
Каждая реплицируемая таблица имеет в своей структуре три первых поля фиксированного типа i8, предназначенных для обеспечения механизма репликации:
replID — уникальный идентификатор записи в таблице. При вставке каждой новой записи, этой записи присваивается уникальный идентификатор. Несмотря на то, что таблица может иметь некий первичный ключ, определяемый бизнес-логикой, для целей репликации все равно первичным и уникальным идентификатором является поле replID.
replRev — уникальный номер изменения в таблице. При любом изменении в таблице (вставке, редактировании, удалении записи) затронутая запись получает значение replRev, равное максимальному replRev в таблице до изменения +1.
replAct — replAct — признак того, что запись удалена. Если replAct не нулевой — запись удалена. Если replAct = 0 — запись активна..
Для отправки команд необходимо создать публикатор с параметрами NAME = FORTS_SRV, catеgory = FORTS_MSG. Для получения ответов на отправленные сообщения необходимо в функции отправки сообщения задать флаг CG_PUB_NEEDREPLY, а также создать подписчик с типом p2mqreply.
В случае ошибки в доставке и обработке сообщения на системном уровне, код клиента может получить либо ошибку при выполнении функции отправки сообщения, либо ответное сообщение специального типа "системная ошибка" (msgid=100):
Поле | Тип | Описание |
---|---|---|
code | i4 | Код возврата |
message | c255 | Текст сообщения. |
Обратите внимание, что сообщение "системная ошибка" может быть отправлено в ответ на любое сообщение бизнес-логики.
В ТС SPECTRA действует система ограничения аномальной активности клиентских приложений. Она не позволяет приложению пользователя (одному логину в системе SPECTRA) присылать более оговорённого в заявке на подключение количества сообщений в единицу времени. В настоящий момент можно получить логин в систему SPECTRA с ограничением 30, 60, 90 и т.д. (но не более 3000) торговых операций в секунду. К торговым операциям относятся все команды управления заявками. Количество неторговых (всех остальных) операций для любого типа логина ограничено 1000 в секунду.
При превышении лимита сообщений, система контроля не транслирует сообщение в ядро ТС, а посылает пользователю сообщение-ответ с уведомлением об отказе в обслуживании, msgid=99 следующей структуры:
Поле | Тип | Описание |
---|---|---|
queue_size | i4 | Количество сообщений пользователя |
penalty_remain | i4 | Время в миллисекундах, по прошествии которого будет успешно принято следующее сообщение от этого пользователя |
message | c128 | Текст сообщения об ошибке |
Обращаем внимание на два нюанса:
Количество сообщений за истекшую секунду оценивается при приёме КАЖДОГО сообщения. Это значит, что если пользователь постоянно присылает запросы с частотой, больше, чем ему разрешено, то его сообщения перестают обрабатываться вообще.
Сообщение-отказ с типом 99 может быть послано в ответ на любое сообщение пользователя.
В ТС SPECTRA предусмотрен механизм контроля за состоянием подключения клиента (сервис "Cancel On Disconnect"), который позволяет при отключении клиента от ТС автоматически снимать все активные заявки клиента. Снимаются только обычные (без срока истечения), безадресные заявки.
Для включения сервиса (а также отключения) фирме-Участнику торгов необходимо подать соответствующее распоряжение через Клиентский Центр. Сервис включается для идентификатора (p2login), принадлежащего фирме-Участнику.
При подключении идентификатора с включенной услугой "Cancel On Disconnect" к ТС для него активируется режим контроля за состоянием подключения (COD-режим).
Логика работы механизма контроля подключений следующая:
Если для клиента активирован COD-режим, то система отслеживает активность подключения на транзакционном уровне. Каждая команда (сообщение) клиента, зарегистрированная в системе, вне зависимости от её успешности, трактуется как проявление активности.
Если за установленный в качестве порога неактивности временной интервал (в текущей реализации = 20 сек.) клиент не отправил ни одного сообщения или, потеряв подключение к системе, не подключился заново, все его активные заявки автоматически снимаются.
Возможные ситуации, при которых происходит запуск процедуры снятия активных заявок:
Клиент не отправил ни одного сообщения за установленный период времени.
Клиентское приложение потеряло соединение с роутером. Активные заявки будут сняты по истечении установленного периода времени.
Роутер потерял соединение с сервером доступа. Активные заявки будут сняты по истечении установленного периода времени.
Сервер доступа потерял соединение с ТС или утратил работоспособность вследствие возникшей ошибки. Активные заявки клиентов, не установивших соединение с другим сервером доступа, будут сняты по прошествии времени, установленного в качестве порога неактивности.
Возможна ситуация, когда сервер доступа, частично утрачивая работоспособность, оповещает ТС об активности от имени своих клиентов, но фактически теряет с ними соединение. Такая ситуация не может быть идентифицирована ТС Биржи и должна быть урегулирована на стороне Участника.
Для всех клиентов с COD-режимом заявки также автоматически снимаются после окончания вечерней торговой сессии и при восстановлении системы после сбоя.
Заявки, снятые механизмом "Cancel On Disconnect", в таблицах помечаются специальным статусом (поле xstatus).
При отсутствии торговой активности, чтобы предотвратить снятие заявок, клиентское приложение должно информировать ТС об активности подключения путем отправки не реже одного раза в 10 секунд, но не чаще чем раз в секунду, специальной команды CODHeartbeat (msgid=10000) следующей структуры:
Поле | Тип | Описание |
---|---|---|
seq_number | i4 | Номер сообщения-хартбита (в текущей версии не используется). |
Команда не учитывается при расчете сбора за транзакции.
Сервис контроля подключений не отправляет ответных сообщений на хартбиты, поэтому при вызове функции отправки сообщения следует указывать ноль (не ожидать ответа): cg_pub_post(pub, msgptr, 0). Вызов функции cg_pub_post с флагом CG_PUB_NEEDREPLY при отправке хартбита приведет к получению ошибки CG_MSG_P2MQ_TIMEOUT.
В зависимости от подтипа логина пользователя (основной, просмотровый или транзакционный) различен получаемый им набор потоков репликации.
Основной логин получает следующие потоки репликации:
FORTS_CLR_REPL - Клиринговая информация
FORTS_FEERATE_REPL - Поток точных ставок комиссий биржи
FORTS_BROKER_FEE_PARAMS_REPL - Параметры для расчета брокерской комиссии
FORTS_BROKER_FEE_REPL - Брокерские комиссии
FORTS_FEE_REPL - Поток комиссий и штрафов биржи
FORTS_PROHIBITION_REPL - Запреты
FORTS_REFDATA_REPL - Справочная и сессионная информация
FORTS_TRADE_REPL - Заявки и сделки пользователя
FORTS_MM_REPL - Информация об обязательствах ММ
FORTS_USERORDERBOOK_REPL - Заявки пользователя: срез стакана
FORTS_FORECASTIM_REPL - Прогноз рисков после возможной раздвижки
FORTS_INFO_REPL - Справочная информация
FORTS_PART_REPL - Информация о средствах и лимитах
FORTS_POS_REPL - Информация о позициях
FORTS_TNPENALTY_REPL - Информация о сборах за транзакции
FORTS_VM_REPL - Вариационная маржа и премия
FORTS_DEALS_REPL - Поток анонимных сделок
FORTS_COMMON_REPL - Общая информация по сессии
FORTS_VOLAT_REPL - Волатильность
MOEX_RATES_REPL - Курсы валют он-лайн
RTS_INDEX_REPL - Биржевые индексы
FORTS_RISKINFOBLACK_REPL - Риск-параметры для модели Блэка-Шоулза
FORTS_RISKINFOBACH_REPL - Риск-параметры для модели Башелье
FORTS_USER_REPL - Пользователи
FORTS_REJECTEDORDERS_REPL - Отвергнутые в клиринг заявки
Если способ получения рыночных данных – "агрегированные стаканы", основной логин также получает:
FORTS_AGGR5_REPL, FORTS_AGGR20_REPL и FORTS_AGGR50_REPL - Потоки агрегированных стаканов
Если способ получения рыночных данных – "полный журнал заявок", основной логин получает:
FORTS_ORDLOG_REPL - Поток анонимных заявок
FORTS_ORDBOOK_REPL - Срез стакана. Анонимный
Просмотровый логин получает следующие потоки репликации:
FORTS_CLR_REPL - Клиринговая информация
FORTS_FEERATE_REPL - Поток точных ставок комиссий биржи
FORTS_BROKER_FEE_PARAMS_REPL - Параметры для расчета брокерской комиссии
FORTS_BROKER_FEE_REPL - Брокерские комиссии
FORTS_FEE_REPL - Поток комиссий и штрафов биржи
FORTS_PROHIBITION_REPL - Запреты
FORTS_REFDATA_REPL - Справочная и сессионная информация
FORTS_TRADE_REPL - Заявки и сделки пользователя
FORTS_MM_REPL - Информация об обязательствах ММ
FORTS_USERORDERBOOK_REPL - Заявки пользователя: срез стакана
FORTS_FORECASTIM_REPL - Прогноз рисков после возможной раздвижки
FORTS_INFO_REPL - Справочная информация
FORTS_PART_REPL - Информация о средствах и лимитах
FORTS_POS_REPL - Информация о позициях
FORTS_TNPENALTY_REPL - Информация о сборах за транзакции
FORTS_VM_REPL - Вариационная маржа и премия
FORTS_DEALS_REPL - Поток анонимных сделок
FORTS_COMMON_REPL - Общая информация по сессии
FORTS_VOLAT_REPL - Волатильность
MOEX_RATES_REPL - Курсы валют он-лайн
RTS_INDEX_REPL - Биржевые индексы
FORTS_RISKINFOBLACK_REPL - Риск-параметры для модели Блэка-Шоулза
FORTS_RISKINFOBACH_REPL - Риск-параметры для модели Башелье
FORTS_USER_REPL - Пользователи
FORTS_REJECTEDORDERS_REPL - Отвергнутые в клиринг заявки
Если способ получения рыночных данных – "агрегированные стаканы", просмотровый логин также получает:
FORTS_AGGR5_REPL, FORTS_AGGR20_REPL и FORTS_AGGR50_REPL - Потоки агрегированных стаканов
Если способ получения рыночных данных – "полный журнал заявок", просмотровый логин получает:
FORTS_ORDLOG_REPL - Поток анонимных заявок
FORTS_ORDBOOK_REPL - Срез стакана. Анонимный
Транзакционный логин получает следующие потоки репликации:
FORTS_CLR_REPL - Клиринговая информация
FORTS_FEERATE_REPL - Поток точных ставок комиссий биржи
FORTS_BROKER_FEE_PARAMS_REPL - Параметры для расчета брокерской комиссии
FORTS_BROKER_FEE_REPL - Брокерские комиссии
FORTS_FEE_REPL - Поток комиссий и штрафов биржи
FORTS_PROHIBITION_REPL - Запреты
FORTS_REFDATA_REPL - Справочная и сессионная информация
FORTS_TRADE_REPL - Заявки и сделки пользователя
FORTS_MM_REPL - Информация об обязательствах ММ
FORTS_USERORDERBOOK_REPL - Заявки пользователя: срез стакана
FORTS_FORECASTIM_REPL - Прогноз рисков после возможной раздвижки
FORTS_INFO_REPL - Справочная информация
FORTS_PART_REPL - Информация о средствах и лимитах
FORTS_POS_REPL - Информация о позициях
FORTS_TNPENALTY_REPL - Информация о сборах за транзакции
FORTS_VM_REPL - Вариационная маржа и премия
FORTS_USER_REPL - Пользователи
FORTS_REJECTEDORDERS_REPL - Отвергнутые в клиринг заявки
У пользователя имеется возможность самостоятельно сменить свой пароль доступа в торговую систему. Для этого можно воспользоваться одним из следующих методов:
воспользоваться специальной утилитой change_password (её описание дано ниже);
Создать своё приложение для смены пароля (описание соответствующих объектов API можно найти в документе cgate_ru.pdf в разделе "Объекты протокола изменения пароля") и послать в торговую систему сообщение ChangePassword с необходимыми параметрами (см. раздел "Метод ChangePassword").
Утилита change_password
Утилита change_password предназначена для изменения пароля пользователя в торговой системе. Утилита получает на вход старый и новый пароль пользователя, отправляет их в ТС SPECTRA, и получает ответ об успешной (или нет) смене пароля пользователя в торговой системе. Используемый утилитой протокол обеспечивает защищенную передачу данных, пароль и логин пользователя в открытом виде по сети не передаются.
Утилита представляет собой консольное приложение с запуском из командной строки, исполняемый файл change_password.exe. Находится: для среды Windows - C:\Moscow Exchange\SpectraCGate\bin\change_password.exe; для среды Linux - \opt\moex\cgate\bin\change_password.
При запуске утилите могут быть переданы следующие параметры:
имя приложения. Необязательный параметр;
пароль для локального соединения с роутером. Необязательный параметр;
ip-адрес роутера. Необязательный параметр, значение по умолчанию 127.0.0.1;
порт роутера. Необязательный параметр. Значение по умолчанию 4001;
ini-файл с настройками логирования. Необязательный параметр. Если ini-файл не задан, результат операции выводится на консоль.
Пример строки запуска:
C:\Moscow Exchange\SpectraCGate\bin\change_password.exe --port=4001
Для смены пароля необходимо выполнить следующие действия:
Запустить утилиту.
В консоли ввести старый и новый пароль.
Нажать Enter.
Утилита возвращает "0" в случае успешного выполнения команды смены пароля и "1" в случае неуспеха.
Обратите внимание, что получение ответа об успешном выполнении означает изменение пароля пользователя в торговой системе, при этом авторизация текущего соединения роутера не меняется. Для авторизации роутера с новым паролем необходимо изменить пароль в ini-файле роутера и перезапустить роутер.
В ТС SPECTRA поддерживается разделение (партиционирование) торговых инструментов на группы, и торговля ими раздельно на нескольких независимых модулях сведения заявок (модулях матчинга), при этом каждый модуль матчинга обрабатывает свою группу инструментов. Принадлежность инструмента к группе (матчингу) определяется кодом базового актива (base_contract_code) инструмента.
Трансляция торговых данных производится также раздельно и независимо, для каждого из модулей матчинга назначаются собственные потоки репликации. Принадлежность потоков репликации матчингу определяется по постфиксу _MATCH${id} в названии потока, где ${id} - ID модуля матчинга. Например, поток FORTS_TRADE_REPL_MATCH1 - заявки и сделки пользователя по фьючерсным инструментам, которые обрабатываются на MATCH1.
Потоки, транслируемые раздельно для каждого матчинга (имеют постфикс _MATCH${id}):
Для сопоставления инструментов матчингу, на котором они обрабатываются, в потоке FORTS_REFDATA_REPL транслируется таблица instr2matching_map с полями:
base_contract_id - числовой идентификатор базового контракта;
matching_id - идентификатор матчинга.
Привязка инструментов к матчингам может меняться при смене торговой сессии.
Новый алгоритм получения торговых данных:
По таблицам fut_sess_contents / opt_sess_contents для isin_id определяем код базового актива (base_contract_code).
По таблицам fut_vcb / opt_vcb для base_contract_code определяем идентификатор базового контракта (base_contract_id).
В таблице instr2matching_map по base_contract_id определяем идентификатор матчинга.
Для получения торговых данных по инструменту открываем потоки с соответствующим _MATCH${id}.
В ТС SPECTRA версии 6.3 модуль сведения заявок будет один, и для обратной совместимости оставлены старые потоки репликации (без разделения по матчингам), но в последующих версиях системы старые потоки будут удалены, поэтому пользователям рекомендуется перестраивать свои системы на работу с новыми потоками данных. Также в систему добавлены две новые команды MoveOrder (msgid=438) и DelOrder (msgid=436), которые следует использовать для перемещения и удаления заявок по фьючерсам и опционам в ТС с несколькими матчингами.
Различают следующие типы потоков данных:
"Достоверный" ('Reliable') - Данные, опубликованные в таких потоках, актуальны, достоверны и не подлежат изменению. Любое изменение - это форс-мажор, связанный с нештатной ситуацией на Бирже. На данные из таких потоков участник может полностью опираться при принятии решений.
"Условно достоверный" ('Almost Reliable') - Требуется сверка с отчетами. Данные в таких потоках обычно не подлежат изменению, но могут быть редкие ситуации, когда окончательные значения, публикуемые в отчетах, отличаются от онлайн данных. Например, расчетная цена может быть скорректирована решением НКЦ (такая ситуация предусмотрена регуляторными документами). На данные из таких потоков участник может опираться, с учетом, что возможно потребуется скорректировать полученные данные на основании автоматической сверки с отчетами.
"Информационный" ('Informational') - Данные, на которые участник не может полагаться, как на единственный источник при принятии тех или иных решений. Данные из таких потоков нужно использовать с осторожностью, по возможности, проводя взвешенное сравнение с аналогичными данными, полученными другим способом. Примером таких данных могут служить данные о волатильности, которые носят оценочный характер, зависящий от используемой модели и методики расчета.
Ниже в таблице приведена градация потоков по типам:
Имя потока | Описание | Тип |
---|---|---|
FORTS_TRADE_REPL | Заявки и сделки пользователя | R |
FORTS_ORDLOG_REPL | Поток анонимных заявок | R |
FORTS_DEALS_REPL | Поток анонимных сделок | R |
FORTS_USERORDERBOOK_REPL | Заявки пользователя: срез стакана | R |
FORTS_ORDBOOK_REPL | Срез стакана. Анонимный | R |
FORTS_PROHIBITION_REPL | Запреты | R |
FORTS_REFDATA_REPL | Справочная и сессионная информация | R |
RTS_INDEX_REPL | Биржевые индексы | R |
FORTS_INFO_REPL | Справочная информация | R |
FORTS_USER_REPL | Пользователи | R |
FORTS_REJECTEDORDERS_REPL | Отвергнутые в клиринг заявки | R |
FORTS_FEE_REPL | Поток комиссий и штрафов биржи | AR |
FORTS_FEERATE_REPL | Поток точных ставок комиссий биржи | AR |
FORTS_CLR_REPL | Клиринговая информация | AR |
FORTS_COMMON_REPL | Общая информация по сессии | I |
FORTS_AGGR##_REPL | Агрегированные стаканы | I |
FORTS_POS_REPL | Информация о позициях | I |
FORTS_PART_REPL | Информация о средствах и лимитах | I |
FORTS_MM_REPL | Информация об обязательствах ММ | I |
FORTS_VM_REPL | Вариационная маржа и премия | I |
FORTS_VOLAT_REPL | Волатильность | I |
FORTS_TNPENALTY_REPL | Информация о сборах за транзакции | I |
MOEX_RATES_REPL | Курсы валют он-лайн | I |
FORTS_FORECASTIM_REPL | Прогноз рисков после возможной раздвижки | I |
FORTS_RISKINFOBLACK_REPL | Риск-параметры для модели Блэка-Шоулза | I |
FORTS_RISKINFOBACH_REPL | Риск-параметры для модели Башелье | I |
В системе существует ограничение на количество одновременных подписок на один поток PLAZA II (Cgate) от одного шлюзового логина - не более 20. При превышении этого ограничения, каждая последующая попытка подписаться на поток будет завершаться с кодом ошибки ERROR:TOO MANY CONNECTIONS, отражающаяся в журнале работы Cgate.
Шлюз PLAZA II в стандартной конфигурации использует четыре TCP соединения с серверами биржи:
Соединение для подачи приказов/команд.
Соединение для получения основных рыночных данных. К таким данным относятся потоки агрегатов, потоки FORTS_ORDLOG_REPL, FORTS_DEALS_REPL, FORTS_TRADE_REPL, FORTS_COMMON_REPL.
Соединение для получения вспомогательных и справочных потоков.
Соединение для получения данных для восстановления при восстановлении связи или первоначальном присоединении (Snapshot).
Для обеспечения надежности в торговой системе реализовано дублирование аппаратных компонентов, обслуживающих соединения пользователей, с использованием балансировщиков нагрузки, которые направляют пользователя при установке соединения на тот сервер, который наименее загружен в данный момент.
За установку TCP соединений отвечает ПО P2MQRouter, все настройки для данных соединений прописаны в конфигурационном файле роутера, при этом соединение для "Other Data" указывается как исходящее default connection, а остальные как исходящие direct connection. Такое построение является основной штатной конфигурацией при подключении к серверной ферме биржи. Конфигурация соединений при подключении через сервер доступа брокера может отличаться, в этом случае требуется запрашивать конкретную конфигурацию у владельца сервера.
За восстановление соединения в случае разрыва также отвечает P2MQRouter, при обрыве он автоматически, с заданной периодичностью пытается восстановить соединение, при этом пользовательское приложение повлиять на эти процессы никак не может. И в этом случае, отследить разрыв соединения приложение пользователя может по изменению статуса P2MQRouter с ROUTER_CONNECTED на ROUTER_RECONNECTING, получая уведомления об изменении статуса от объекта "connection".
Библиотека CGate ведет себя следующим образом:
Разрыв соединения с гейтом обработки входных приказов диагностируется непосредственно в момент получения ошибки TCP-соединения. При этом, затронутые разрывом объекты publisher переходят в ошибочное состояние.
Диагностика разрыва соединения, используемого для получения основных рыночных данных, происходит в течение 30 секунд. Затронутые объекты listener при этом переходят в ошибочное состояние.
Объекты в состоянии ERROR необходимо освободить, и с какой-то периодичностью (например, раз в несколько секунд) пытаться переоткрыть заново.
При работе с публикатором типа p2mq и подписчиком p2mqreply клиентский код может получить код ответа СG_MSG_P2MQ_TIMEOUT, сигнализирующий о том, что не был получен ответ на сообщение, ссылка на которое передается вместе с кодом ответа, в течение заданного пользователем времени. Получение ответа типа "таймаут" свидетельствует о проблемах соединения либо об иных инфраструктурных проблемах со стороны участника или биржи. Такая ситуация является ситуацией неопределенности - невозможно сказать было ли отправленное сообщение успешно обработано системой или нет. Для минимизации вероятности таких ситуаций следует задавать большие таймауты в коде - порядка 60 секунд.
При получении ответа типа "таймаут" рекомендуется иметь процедуру верификации отправленного сообщения:
Проверить, что пара публикатор p2mq и подписчик p2mqreply не перешли в ошибочное состояние. Если публикатор или подписчик в ошибочном состоянии, провести их закрытие и удаление и инициализировать заново.
Для команд управления заявками рекомендуется всегда задавать внешний номер заявки (параметр ext_id). В случае получения "таймаута" на команду AddOrder или MoveOrder возможной безопасной реакцией будет удалить заявку с помощью команды DelUserOrders с указанием ext_id.
Если "таймаут" произошел при удалении/отмене заявки, исходите из предположения, что заявка НЕ удалена. Повторите удаление после восстановления соединения или через ВПТС, работающее с другим ЦОД биржи.
Проанализируйте данные таблицы собственных заявок orders_log потока FORTS_TRADE_REPL на предмет наличия или отсутствия в ней отправленных заявок или отмен заявок.
Если "таймаут" произошел при отправке неторговой команды, проанализируйте состояние соответствующей таблицы в потоке реплики – отражены ли там запрошенные изменения.
В общем случае, алгоритм восстановления подключения следующий:
После старта предпринимать периодические попытки открыть соединение с P2MQRouter.
При восстановлении соединения рутера с сетью PLAZA II объект соединение перейдет в состояние ACTIVE.
Произвести открытие нужных потоков. Для ускорения процедуры восстановления рекомендуется выполнять получение данных с момента последнего обновления. При открытии потока следует указывать replstate, полученный в момент закрытия потока, или явно задавать номера ревизий для таблиц и номер жизни схемы, используя последние номера фактически полученных данных.
Произвести восстановление списка активных заявок (см. далее).
Зарегистрировать publisher для приказов/команд.
Ниже в таблице приведены рекомендуемые способы восстановления данных в зависимости от получаемого потока:
Имя потока (таблицы) | Информация в потоке | Способ восстановления |
---|---|---|
FORTS_TRADE_REPL
| Журналы операций со своими заявками по фьючерсам и опционам | Список активных заявок:
Журнал действий с заявками:
|
FORTS_TRADE_REPL
| Журналы операций со своими заявками по связкам | Журнал действий с заявками:
|
FORTS_ORDLOG_REPL
| Полный анонимный журнал операций с заявками по фьючерсам и опционам | Список активных заявок:
Журнал действий с заявками:
|
FORTS_ORDLOG_REPL
| Полный анонимный журнал операций с заявками по связкам | Журнал действий с заявками:
|
FORTS_DEALS_REPL
FORTS_TRADE_REPL
| Журнал сделок по фьючерсам, составным инструментам и опционам | Переоткрытие соответствующего потока с указанием последнего полученного номера ревизии или repl state, полученного в момент закрытия потока |
FORTS_COMMON_REPL | Общая рыночная информация по фьючерсам и опционам | Переоткрытие потока с нуля |
FORTS_AGGR##_REPL | Стаканы по фьючерсам и опционам (## - глубина стакана) | Переоткрытие соответствующего потока с нуля |
FORTS_REFDATA_REPL | Справочная и сессионная информация | Быстрый способ:
Допустимый способ:
|
FORTS_PART_REPL | Информация о лимитах | Переоткрытие потока с нуля |
FORTS_POS_REPL | Информация о позициях | Переоткрытие потока с нуля |
FORTS_VM_REPL | Информация о вариационной марже и премии | Переоткрытие потока с нуля |
FORTS_VOLAT_REPL | Информация о волатильности и теоретических ценах опционов | Переоткрытие потока с нуля |
RTS_INDEX_REPL | Значения биржевых индексов | Переоткрытие потока с нуля |
При восстановлении соединения важной задачей является получение текущих активных заявок пользователя:
Получение набора активных в момент восстановления заявок.
Получение журнал действий с заявками в период отсутствия соединения.
Задача 1 решается путём получения среза заявок (FORTS_USERORDERBOOK_REPL) — заявки, отсутствующие в срезе, были сведены или отвергнуты в период отсутствия соединения.
Задача 2 решается получением журнала действий со своими заявками (таблица orders_log потока FORTS_TRADE_REPL, а также таблица multileg_orders_log потока FORTS_TRADE_REPL) за период отсутствия соединения. Для этого надо открыть соответствующий поток с указанием номера ревизии последней фактически полученной до сбоя записи. Все действия с заявками, происходившие до момента восстановления, будут отражены в виде записей этих таблиц. Индикатором получения всей пропущенной истории действий с заявками является переход потока в состояние ONLINE.
Примечание: Приведенная выше процедура восстановления подходит и для позднего входа.
В общем же случае, для минимизации вероятности возникновения сетевых сбоев в пользовательских приложениях Биржа рекомендует устанавливать дублирующие каналы связи, иметь два логина для шлюза, с одинаковым набором прав, и, соответственно, запускать одновременно два пользовательских приложения, которые будут получать одинаковые данные, с возможностью переключения между ними при сбоях. Как альтернатива, в коде самого приложения должен быть предусмотрен механизм переключения на дублирующий канал связи, то есть установка соединения с P2MQRouter, работающим через резервный канал к бирже.
Под такими проблемами понимаются аварии на стороне биржи, связанные с нарушениями в работе ядра ТС или сервисов, формирующих какие-либо рыночные данные. Как правило, это приводит к останову и перезапуску этих сервисов.
При регламентных работах, штатных или нештатных перезапусках сервисов на стороне биржи и после восстановления связи с клиентом, сервисы публикации данных присылают уведомления об очистке старых данных, перед тем как присылать текущее состояние данных.
Уведомления об очистке есть двух типов:
CG_MSG_P2REPL_CLEARDELETED – по каждой таблице, с указанием ревижена. Уведомление инструктирует клиента о необходимости удалить все записи со значением replRev меньшим, чем указано в уведомлении. Для оптимизации передачи данных, в уведомлении может быть указан ревижен, равный MAX(int64). Это означает, что клиент должен произвести полную очистку данных по таблице, таблица будет передана целиком.
CG_MSG_P2REPL_LIFENUM - для всего потока репликации целиком, с указанием нового "номера жизни" потока. Означает существенно изменение данных потока со времени последнего соединения. Клиент должен очистить все данные по всем таблицам, данные будут переданы "с нуля".
В штатном режиме работы, включая регламентные работы во внеторговое время, при открытии или переоткрытии любого потока репликации, кроме потоков, связанных с историей заявок и сделок (FORTS_TRADE_REPL, FORTS_ORDLOG_REPL и FORTS_DEALS_REPL), клиент может получить как нотификации CG_MSG_P2REPL_CLEARDELETED, так и нотификации CG_MSG_P2REPL_LIFENUM, которые требуется корректно обработать.
В штатном режиме для потоков, связанных с историей заявок и сделок (см. выше), уведомление CG_MSG_P2REPL_LIFENUM рассылается только при смене версии системы, после тестовых торгов, чтобы пользователи очистили тестовые данные. В уведомлении CG_MSG_P2REPL_CLEARDELETED указывается значение replRev для первой по времени, доступной в системе в настоящий момент заявки или сделки.
Приход уведомления CG_MSG_P2REPL_LIFENUM с новым "номером жизни" потока непосредственно в торгах означает, что в ТС произошел серьезный сбой, и требуется перепослать данные по заявкам и сделкам, которые могли быть уже разосланы пользователям.
Дополнительно по каналам, не связанным с самой ТС (система СОИ, новости на сайте биржи и т.п.), будет публиковаться информация о том, были ли в результате исправления ошибочных данных затронуты данные, которые реально попали к пользователям. В частности, был ли откат к состоянию системы до момента аварии, и какой последний номер заявки и сделки после перезапуска системы будет доступен пользователю.
Таблицы:
Таблица 2. Поля таблицы orders_log
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
public_order_id | i8 | Идентификационный номер заявки (для айсбергов - номер видимой части айсберга) |
sess_id | i4 | Идентификатор торговой сессии |
isin_id | i4 | Уникальный числовой идентификатор инструмента |
public_amount | i8 | Количество контрактов в операции (для айсбергов - количество контрактов в операции по видимой части айсберга) |
public_amount_rest | i8 | Оставшееся количество контрактов в заявке (для айсбергов - оставшееся количество контрактов в видимой части айсберга) |
id_deal | i8 | Идентификатор сделки по данной записи журнала заявок |
xstatus | i8 | Расширенный статус заявки |
xstatus2 | i8 | Расширение для статусов заявок (в дополнение к полю xstatus) |
price | d16.5 | Цена |
moment | t | Время изменения состояния заявки |
moment_ns | u8 | Время изменения состояния заявки (UNIX-время в наносекундах по стандарту UTC) |
dir | i1 | Направление |
public_action | i1 | Действие с заявкой (для айсбергов - действие с видимой частью айсберга) |
deal_price | d16.5 | Цена заключенной сделки |
client_code | c7 | Код клиента |
login_from | c20 | Логин пользователя, поставившего заявку |
comment | c20 | Комментарий трейдера |
ext_id | i4 | Внешний номер |
broker_to | c7 | Код SPECTRA фирмы-адресата внесистемной заявки |
broker_to_rts | c7 | Код РТС фирмы-адресата внесистемной заявки |
broker_from_rts | c7 | Код РТС фирмы - владельца заявки |
date_exp | t | Дата истечения заявки |
id_ord1 | i8 | Номер первой заявки |
aspref | i4 | Идентификатор пользователя. Для заявок, поданных от SMA-логина - идентификатор MASTER-логина. |
private_order_id | i8 | Идентификационный номер заявки (для айсбергов – идентификационный номер всей айсберг-заявки) |
private_amount | i8 | Количество контрактов в операции (для айсбергов – количество контрактов в операции со всей айсберг-заявкой) |
private_amount_rest | i8 | Оставшееся количество контрактов в заявке (для айсбергов - оставшееся количество контрактов во всей айсберг-заявке) |
variance_amount | i8 | Амплитуда отклонения (в контрактах) случайной надбавки к всплывающей части айсберг-заявки |
disclose_const_amount | i8 | Количество единиц инструмента в постоянной составляющей всплывающей части айсберг-заявки |
private_action | i1 | Действие с заявкой (для айсбергов – действие в отношении всей айсберг-заявки) |
reason | i4 | Признак (причина) заявки, выставленной для заключения сделки урегулирования обязательств. |
match_ref | c10 | Текст-связка для однозначного сопоставления двух встречных адресных заявок |
compliance_id | c1 | Способ ввода заявки |
Примечания:
Поле xstatus представляет собой битовую маску, перечень возможных значений поля приведен в разделе Признаки, выставляемые у заявок и сделок.
Поле dir может принимать следующие значения:
Buy
Sell
Поле public_action может принимать следующие значения
Заявка удалена
Заявка добавлена
Заявка сведена в сделку
Поле id_ord1 содержит номер первой заявки в последовательности перевыставлений заявки со сроком истечения
Поле private_action (action) может принимать следующие значения:
Заявка удалена
Заявка добавлена
Заявка сведена в сделку
Заявка добавлена в результате появления новой видимой части айсберга
Поле reason может принимать следующие значения:
Обычная заявка
Балансирующие Срочные контракты, заключенные с Добросовестным участником клиринга без подачи заявок
Закрывающие Срочные контракты, заключенные в рамках процедуры кросс-дефолта
Закрывающие Срочные контракты, заключенные в связи с неисполнением Маржинального требования
Закрывающие Срочные контракты, заключенные в связи с неисполнением Обязательства по поставке по поставочным Срочным контрактам на драгоценные металлы
Иное
Поле compliance_id может принимать следующие значения:
Не заполнено/Не задано
Ручной ввод
В результате срабатывания условного поручения (стоп-лосс)
В результате работы алгоритма-робота
В результате алгоритма автоследования
Закрытие позиции в результате не исполненного MarginCall
Таблица 3. Поля таблицы multileg_orders_log
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
public_order_id | i8 | Идентификационный номер заявки (для айсбергов - номер видимой части айсберга) |
sess_id | i4 | Идентификатор торговой сессии |
isin_id | i4 | Идентификатор инструмента-связки |
public_amount | i8 | Количество контрактов в операции (для айсбергов - количество контрактов в операции по видимой части айсберга) |
public_amount_rest | i8 | Оставшееся количество контрактов в заявке (для айсбергов - оставшееся количество контрактов в видимой части айсберга) |
id_deal | i8 | Идентификатор сделки по данной записи журнала заявок |
xstatus | i8 | Расширенный статус заявки |
xstatus2 | i8 | Расширение для статусов заявок (в дополнение к полю xstatus) |
price | d16.5 | Цена. Поле не используется. |
moment | t | Время изменения состояния заявки |
moment_ns | u8 | Время изменения состояния заявки (UNIX-время в наносекундах по стандарту UTC) |
dir | i1 | Направление |
public_action | i1 | Действие с заявкой (для айсбергов - действие с видимой частью айсберга) |
deal_price | d16.5 | Цена первой ноги заключенной сделки |
rate_price | d16.5 | Ставка заявки. Поле не используется. |
swap_price | d16.5 | Своп-цена заявки |
client_code | c7 | Код клиента |
login_from | c20 | Логин пользователя, поставившего заявку |
comment | c20 | Комментарий трейдера |
ext_id | i4 | Внешний номер |
broker_to | c7 | Код SPECTRA фирмы-адресата внесистемной заявки |
broker_to_rts | c7 | Код РТС фирмы-адресата внесистемной заявки |
broker_from_rts | c7 | Код РТС фирмы - владельца заявки |
date_exp | t | Дата истечения заявки |
id_ord1 | i8 | Номер первой заявки |
aspref | i4 | Идентификатор пользователя. Для заявок, поданных от SMA-логина - идентификатор MASTER-логина. |
private_order_id | i8 | Идентификационный номер заявки (для айсбергов – идентификационный номер всей айсберг-заявки) |
private_amount | i8 | Количество контрактов в операции (для айсбергов – количество контрактов в операции со всей айсберг-заявкой) |
private_amount_rest | i8 | Оставшееся количество контрактов в заявке (для айсбергов - оставшееся количество контрактов во всей айсберг-заявке) |
variance_amount | i8 | Амплитуда отклонения (в контрактах) случайной надбавки к всплывающей части айсберг-заявки |
disclose_const_amount | i8 | Количество единиц инструмента в постоянной составляющей всплывающей части айсберг-заявки |
private_action | i1 | Действие с заявкой (для айсбергов – действие в отношении всей айсберг-заявки) |
reason | i4 | Признак (причина) заявки, выставленной для заключения сделки урегулирования обязательств. |
match_ref | c10 | Текст-связка для однозначного сопоставления двух встречных адресных заявок |
compliance_id | c1 | Способ ввода заявки |
Примечания:
Поле xstatus представляет собой битовую маску, перечень возможных значений поля приведен в разделе Признаки, выставляемые у заявок и сделок.
Поле dir может принимать следующие значения:
Buy
Sell
Поле public_action может принимать следующие значения
Заявка удалена
Заявка добавлена
Заявка сведена в сделку
Поле private_action (action) может принимать следующие значения:
Заявка удалена
Заявка добавлена
Заявка сведена в сделку
Заявка добавлена в результате появления новой видимой части айсберга
Поле reason может принимать следующие значения:
Обычная заявка
Балансирующие Срочные контракты, заключенные с Добросовестным участником клиринга без подачи заявок
Закрывающие Срочные контракты, заключенные в рамках процедуры кросс-дефолта
Закрывающие Срочные контракты, заключенные в связи с неисполнением Маржинального требования
Закрывающие Срочные контракты, заключенные в связи с неисполнением Обязательства по поставке по поставочным Срочным контрактам на драгоценные металлы
Иное
Поле compliance_id может принимать следующие значения:
Не заполнено/Не задано
Ручной ввод
В результате срабатывания условного поручения (стоп-лосс)
В результате работы алгоритма-робота
В результате алгоритма автоследования
Закрытие позиции в результате не исполненного MarginCall
Таблица 4. Поля таблицы user_deal
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
sess_id | i4 | Идентификатор торговой сессии |
isin_id | i4 | Уникальный числовой идентификатор инструмента |
id_deal | i8 | Номер сделки |
id_deal_multileg | i8 | Номер сделки по связке |
id_repo | i8 | Номер сделки по другой ноге |
xpos | i8 | Количество позиций по инструменту на рынке после сделки |
xamount | i8 | Объем, количество единиц инструмента |
public_order_id_buy | i8 | Идентификатор заявки покупателя (для айсбергов - номер видимой части айсберг-заявки покупателя) |
public_order_id_sell | i8 | Идентификатор заявки продавца (для айсбергов - номер видимой части айсберг-заявки продавца) |
price | d16.5 | Цена |
moment | t | Время заключения сделки |
moment_ns | u8 | Время заключения сделки (UNIX-время в наносекундах по стандарту UTC) |
nosystem | i1 | Признак внесистемной сделки |
xstatus_buy | i8 | Статус сделки со стороны покупателя |
xstatus_sell | i8 | Статус сделки со стороны продавца |
xstatus2_buy | i8 | Расширение для статусов сделок (в дополнение к полю xstatus_buy) |
xstatus2_sell | i8 | Расширение для статусов сделок (в дополнение к полю xstatus_sell) |
ext_id_buy | i4 | Внешний номер из заявки покупателя |
ext_id_sell | i4 | Внешний номер из заявки продавца |
code_buy | c7 | Код покупателя |
code_sell | c7 | Код продавца |
comment_buy | c20 | Комментарий из заявки покупателя |
comment_sell | c20 | Комментарий из заявки продавца |
fee_buy | d26.2 | Сбор по сделке покупателя |
fee_sell | d26.2 | Сбор по сделке продавца |
login_buy | c20 | Логин пользователя покупателя |
login_sell | c20 | Логин пользователя продавца |
code_rts_buy | c7 | Код РТС фирмы покупателя |
code_rts_sell | c7 | Код РТС фирмы продавца |
private_order_id_buy | i8 | Идентификатор заявки покупателя (для айсбергов - идентификатор всей айсберг-заявки покупателя) |
private_order_id_sell | i8 | Идентификатор заявки продавца (для айсбергов - идентификатор всей айсберг-заявки продавца) |
reason_buy | i4 | Признак (причина) сделки урегулирования покупателя. |
reason_sell | i4 | Признак (причина) сделки урегулирования продавца. |
Примечания:
Поля code_sell, comment_sell, ext_id_sell, login_sell, code_rts_sell, fee_sell, code_buy, comment_buy, ext_id_buy, login_buy, code_rts_buy, fee_buy, заполняются только для своих сделок
Поля xstatus_sell и xstatus_buy являются битовыми масками (подробнее см. раздел Признаки, выставляемые у заявок и сделок)
Для технических сделок, являющимися результатами сделок по инструментам-связкам, поле nosystem всегда установлено в 1, вне зависимости от того, является ли сделка по связке системной или адресной. Для определения системности исходной сделки надо использовать признак nosystem соответствующей записи таблицы multileg_deal.
Поле id_repo содержит номер сделки по другой ноге. Для I-й ноги поле содержит номер сделки по II-й ноге, для II-й ноги – номер сделки по I-й.
Поле id_deal_multileg содержит код сделки по инструменту-связке, в случае если данная запись является записью о технической сделке. В случае сделки по обычному инструменту данное поле содержит 0.
Для "чужих" сделок в полях xstatus_buy и xstatus_sell могут выставляться признаки NonQuote, ClearingTrade, Address и Strategy.
В сделках экспирации id поручения на экспирацию указывается в поле private_order_id_buy, если экспирировался опцион колл, либо в поле private_order_id_sell, если экспирировался опцион пут.
Поля fee_buy и fee_sell содержат оценочный размер лимита, блокируемого под комиссию по сделке. Размер комиссии необходимо смотреть в потоке FORTS_FEE_REPL.
Поля reason_buy и reason_sell могут принимать следующие значения:
Обычная сделка
Балансирующие Срочные контракты, заключенные с Добросовестным участником клиринга без подачи заявок
Закрывающие Срочные контракты, заключенные в рамках процедуры кросс-дефолта
Закрывающие Срочные контракты, заключенные в связи с неисполнением Маржинального требования
Закрывающие Срочные контракты, заключенные в связи с неисполнением Обязательства по поставке по поставочным Срочным контрактам на драгоценные металлы
Иное
Таблица 5. Поля таблицы user_multileg_deal
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
sess_id | i4 | Идентификатор торговой сессии |
isin_id | i4 | Идентификатор инструмента-связки |
isin_id_rd | i4 | Идентификатор инструмента первой ноги |
isin_id_rb | i4 | Идентификатор инструмента второй ноги |
duration | i4 | Разница в календарных днях между датами исполнения двух фьючерсов |
id_deal | i8 | Номер сделки по связке |
id_deal_rd | i8 | Идентификатор сделки по первой ноге |
id_deal_rb | i8 | Идентификатор сделки по второй ноге |
public_order_id_buy | i8 | Идентификатор заявки покупателя (для айсбергов - номер видимой части айсберг-заявки покупателя) |
public_order_id_sell | i8 | Идентификатор заявки продавца (для айсбергов - номер видимой части айсберг-заявки продавца) |
xamount | i8 | Объем, количество единиц инструмента |
price | d16.5 | Цена первой части парной связки |
rate_price | d16.5 | Ставка сделки |
swap_price | d16.5 | Своп-цена сделки |
moment | t | Время заключения сделки |
moment_ns | u8 | Время заключения сделки (UNIX-время в наносекундах по стандарту UTC) |
nosystem | i1 | Признак внесистемной сделки |
xstatus_buy | i8 | Расширенный статус сделки со стороны покупателя |
xstatus_sell | i8 | Расширенный статус сделки со стороны продавца |
xstatus2_buy | i8 | Расширение для статусов сделок (в дополнение к полю xstatus_buy) |
xstatus2_sell | i8 | Расширение для статусов сделок (в дополнение к полю xstatus_sell) |
ext_id_buy | i4 | Внешний номер из заявки покупателя |
ext_id_sell | i4 | Внешний номер из заявки продавца |
code_buy | c7 | Код покупателя |
code_sell | c7 | Код продавца |
comment_buy | c20 | Комментарий из заявки покупателя |
comment_sell | c20 | Комментарий из заявки продавца |
login_buy | c20 | Логин пользователя покупателя |
login_sell | c20 | Логин пользователя продавца |
code_rts_buy | c7 | Код РТС фирмы покупателя |
code_rts_sell | c7 | Код РТС фирмы продавца |
private_order_id_buy | i8 | Идентификатор заявки покупателя (для айсбергов - идентификатор всей айсберг-заявки покупателя) |
private_order_id_sell | i8 | Идентификатор заявки продавца (для айсбергов - идентификатор всей айсберг-заявки продавца) |
reason_buy | i4 | Признак (причина) сделки урегулирования покупателя. |
reason_sell | i4 | Признак (причина) сделки урегулирования продавца. |
Примечания:
Поля code_sell, comment_sell, ext_id_sell, code_rts_sell, fee_sell, code_buy, comment_buy, ext_id_buy, code_rts_buy, fee_buy, заполняются только для своих сделок
Поле rate_price для инструментов, торгуемых в своп цене, содержит 0.
Поля reason_buy и reason_sell могут принимать следующие значения:
Обычная сделка
Балансирующие Срочные контракты, заключенные с Добросовестным участником клиринга без подачи заявок
Закрывающие Срочные контракты, заключенные в рамках процедуры кросс-дефолта
Закрывающие Срочные контракты, заключенные в связи с неисполнением Маржинального требования
Закрывающие Срочные контракты, заключенные в связи с неисполнением Обязательства по поставке по поставочным Срочным контрактам на драгоценные металлы
Иное
Данная таблица наполняется ядром торговой системы с определенной периодичностью и может быть использована для задач синхронизации (например, для проверки прихода всех сделок за определенный момент времени). Таблица используется в режиме добавления записей; очистка таблицы происходит в ночное время.
Примечания:
Возможные типы событий
event_type = 1
message = "session_data_ready"
Закончена загрузка данных из клиринговой системы в торговую перед началом новой торговой сессии
event_type = 2
message = "intraday_clearing_finished"
Все расчетные процедуры в промклиринге закончены
event_type = 4
message = "intraday_clearing_started"
Начало промклиринга
event_type = 5
message = "clearing_started"
Начало основного клиринга
event_type = 6
message = "extension_of_limits_finished"
Раздвижка лимитов закончена
event_type = 8
message = "broker_recalc_finished"
Денежные средства после промклиринга пересчитаны
event_type = 23
message = "discrete_auction_add_order_started"
Начало приема заявок в аукцион открытия
event_type = 24
message = "discrete_auction_add_order_finished"
Окончание приема заявок в аукцион открытия
Таблицы:
Таблица 8. Поля таблицы orders_log
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
public_order_id | i8 | Идентификационный номер заявки (для айсбергов - номер видимой части айсберга) |
sess_id | i4 | Идентификатор торговой сессии |
isin_id | i4 | Уникальный числовой идентификатор инструмента |
public_amount | i8 | Количество контрактов в операции (для айсбергов - количество контрактов в операции по видимой части айсберга) |
public_amount_rest | i8 | Оставшееся количество контрактов в заявке (для айсбергов - оставшееся количество контрактов в видимой части айсберга) |
id_deal | i8 | Идентификатор сделки по данной записи журнала заявок |
xstatus | i8 | Расширенный статус заявки |
xstatus2 | i8 | Расширение для статусов заявок (в дополнение к полю xstatus) |
price | d16.5 | Цена |
moment | t | Время изменения состояния заявки |
moment_ns | u8 | Время изменения состояния заявки (UNIX-время в наносекундах по стандарту UTC) |
dir | i1 | Направление |
public_action | i1 | Действие с заявкой (для айсбергов - действие с видимой частью айсберга) |
deal_price | d16.5 | Цена заключенной сделки |
Примечания:
Поле xstatus представляет собой битовую маску, перечень возможных значений поля приведен в разделе Признаки, выставляемые у заявок и сделок.
Поле dir может принимать следующие значения:
Buy
Sell
Поле public_action может принимать следующие значения
Заявка удалена
Заявка добавлена
Заявка сведена в сделку
Таблица 9. Поля таблицы multileg_orders_log
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
public_order_id | i8 | Идентификационный номер заявки (для айсбергов - номер видимой части айсберга) |
sess_id | i4 | Идентификатор торговой сессии |
isin_id | i4 | Уникальный числовой идентификатор инструмента |
public_amount | i8 | Количество контрактов в операции (для айсбергов - количество контрактов в операции по видимой части айсберга) |
public_amount_rest | i8 | Оставшееся количество контрактов в заявке (для айсбергов - оставшееся количество контрактов в видимой части айсберга) |
id_deal | i8 | Идентификатор сделки по данной записи журнала заявок |
xstatus | i8 | Расширенный статус заявки |
xstatus2 | i8 | Расширение для статусов заявок (в дополнение к полю xstatus) |
price | d16.5 | Цена. Поле не используется. |
moment | t | Время изменения состояния заявки |
moment_ns | u8 | Время изменения состояния заявки (UNIX-время в наносекундах по стандарту UTC) |
dir | i1 | Направление |
public_action | i1 | Действие с заявкой (для айсбергов - действие с видимой частью айсберга) |
deal_price | d16.5 | Цена первой ноги заключенной сделки |
rate_price | d16.5 | Ставка заявки. Поле не используется. |
swap_price | d16.5 | Своп-цена заявки |
Примечания:
Поле xstatus представляет собой битовую маску, перечень возможных значений поля приведен в разделе Признаки, выставляемые у заявок и сделок.
Поле dir может принимать следующие значения:
Buy
Sell
Поле public_action может принимать следующие значения
Заявка удалена
Заявка добавлена
Заявка сведена в сделку
Данная таблица наполняется ядром торговой системы с определенной периодичностью и может быть использована для задач синхронизации (например, для проверки прихода всех сделок за определенный момент времени). Таблица используется в режиме добавления записей; очистка таблицы происходит в ночное время.
Примечания:
Возможные типы событий
event_type = 1
message = "session_data_ready"
Закончена загрузка данных из клиринговой системы в торговую перед началом новой торговой сессии
event_type = 2
message = "intraday_clearing_finished"
Все расчетные процедуры в промклиринге закончены
event_type = 4
message = "intraday_clearing_started"
Начало промклиринга
event_type = 5
message = "clearing_started"
Начало основного клиринга
event_type = 6
message = "extension_of_limits_finished"
Раздвижка лимитов закончена
event_type = 8
message = "broker_recalc_finished"
Денежные средства после промклиринга пересчитаны
event_type = 23
message = "discrete_auction_add_order_started"
Начало приема заявок в аукцион открытия
event_type = 24
message = "discrete_auction_add_order_finished"
Окончание приема заявок в аукцион открытия
Таблицы:
Таблица 12. Поля таблицы deal
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
sess_id | i4 | Идентификатор торговой сессии |
isin_id | i4 | Уникальный числовой идентификатор инструмента |
id_deal | i8 | Номер сделки |
xpos | i8 | Количество позиций по инструменту на рынке после сделки |
xamount | i8 | Объем, количество единиц инструмента |
public_order_id_buy | i8 | Идентификатор заявки покупателя (для айсбергов - номер видимой части айсберг-заявки покупателя) |
public_order_id_sell | i8 | Идентификатор заявки продавца (для айсбергов - номер видимой части айсберг-заявки продавца) |
price | d16.5 | Цена |
moment | t | Время заключения сделки |
moment_ns | u8 | Время заключения сделки (UNIX-время в наносекундах по стандарту UTC) |
nosystem | i1 | Признак внесистемной сделки |
xstatus_buy | i8 | Статус сделки со стороны покупателя |
xstatus_sell | i8 | Статус сделки со стороны продавца |
xstatus2_buy | i8 | Расширение для статусов сделок (в дополнение к полю xstatus_buy) |
xstatus2_sell | i8 | Расширение для статусов сделок (в дополнение к полю xstatus_sell) |
Примечания:
В сделках экспирации id поручения на экспирацию указывается в поле public_order_id_sell, если это сделка по опциону, в поле public_order_id_buy в сделках по фьючерсу для опциона колл, в поле public_order_id_sell в сделках по фьючерсу для опциона пут.
Поля xstatus_sell и xstatus_buy являются битовыми масками (подробнее см. раздел Признаки, выставляемые у заявок и сделок)
Таблица 13. Поля таблицы multileg_deal
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
sess_id | i4 | Идентификатор торговой сессии |
isin_id | i4 | Идентификатор инструмента-связки |
id_deal | i8 | Номер сделки |
public_order_id_buy | i8 | Идентификатор заявки покупателя (для айсбергов - номер видимой части айсберг-заявки покупателя) |
public_order_id_sell | i8 | Идентификатор заявки продавца (для айсбергов - номер видимой части айсберг-заявки продавца) |
xamount | i8 | Объем, количество единиц инструмента |
price | d16.5 | Цена первой части парной связки |
rate_price | d16.5 | Ставка сделки |
swap_price | d16.5 | Своп-цена сделки |
moment | t | Время заключения сделки |
moment_ns | u8 | Время заключения сделки (UNIX-время в наносекундах по стандарту UTC) |
nosystem | i1 | Признак внесистемной сделки |
xstatus_buy | i8 | Статус сделки со стороны покупателя |
xstatus_sell | i8 | Статус сделки со стороны продавца |
xstatus2_buy | i8 | Расширение для статусов сделок (в дополнение к полю xstatus_buy) |
xstatus2_sell | i8 | Расширение для статусов сделок (в дополнение к полю xstatus_sell) |
Примечания:
Поля xstatus_sell и xstatus_buy являются битовыми масками (подробнее см. раздел Признаки, выставляемые у заявок и сделок)
Данная таблица наполняется ядром торговой системы с определенной периодичностью и может быть использована для задач синхронизации (например, для проверки прихода всех сделок за определенный момент времени). Таблица используется в режиме добавления записей; очистка таблицы происходит в ночное время.
Примечания:
Возможные типы событий
event_type = 1
message = "session_data_ready"
Закончена загрузка данных из клиринговой системы в торговую перед началом новой торговой сессии
event_type = 2
message = "intraday_clearing_finished"
Все расчетные процедуры в промклиринге закончены
event_type = 4
message = "intraday_clearing_started"
Начало промклиринга
event_type = 5
message = "clearing_started"
Начало основного клиринга
event_type = 6
message = "extension_of_limits_finished"
Раздвижка лимитов закончена
event_type = 8
message = "broker_recalc_finished"
Денежные средства после промклиринга пересчитаны
event_type = 23
message = "discrete_auction_add_order_started"
Начало приема заявок в аукцион открытия
event_type = 24
message = "discrete_auction_add_order_finished"
Окончание приема заявок в аукцион открытия
Таблицы:
Таблица 16. Поля таблицы adjusted_fee
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
id_deal | i8 | Номер сделки |
moment | t | Время заключения сделки |
moment_ns | u8 | Время заключения сделки (UNIX-время в наносекундах по стандарту UTC) |
code_buy | c7 | Код покупателя |
code_sell | c7 | Код продавца |
initial_fee_buy | d26.2 | Сбор по сделке покупателя, грубо |
initial_fee_sell | d26.2 | Сбор по сделке продавца, грубо |
adjusted_fee_buy | d26.2 | Сбор по сделке покупателя, точно |
adjusted_fee_trade_buy | d26.2 | Биржевой сбор по сделке покупателя, точно |
adjusted_fee_clearing_buy | d26.2 | Клиринговый сбор по сделке покупателя, точно |
adjusted_fee_sell | d26.2 | Сбор по сделке продавца, точно |
adjusted_fee_trade_sell | d26.2 | Биржевой сбор по сделке продавца, точно |
adjusted_fee_clearing_sell | d26.2 | Клиринговый сбор по сделке продавца, точно |
id_deal_multileg | i8 | Номер сделки по связке |
Таблица 17. Поля таблицы penalty
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
sess_id | i4 | Номер сессии |
id_deal | i8 | Номер сделки |
id_deal_multileg | i8 | Номер сделки по связке |
moment | t | Время заключения сделки |
moment_ns | u8 | Время заключения сделки (UNIX-время в наносекундах по стандарту UTC) |
code_buy | c7 | Код покупателя |
code_sell | c7 | Код продавца |
penalty_buy | d26.2 | Штраф по сделке покупателя |
penalty_sell | d26.2 | Штраф по сделке продавца |
Примечания:
Возможные типы событий
event_type = 1
message = "session_data_ready"
Закончена загрузка данных из клиринговой системы в торговую перед началом новой торговой сессии
event_type = 2
message = "intraday_clearing_finished"
Все расчетные процедуры в промклиринге закончены
event_type = 4
message = "intraday_clearing_started"
Начало промклиринга
event_type = 5
message = "clearing_started"
Начало основного клиринга
event_type = 6
message = "extension_of_limits_finished"
Раздвижка лимитов закончена
event_type = 8
message = "broker_recalc_finished"
Денежные средства после промклиринга пересчитаны
Таблицы:
option_rate - Точные ставки комиссий по опционам
Таблица 19. Поля таблицы futures_rate
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
isin_id | i4 | Уникальный числовой идентификатор инструмента |
sess_id | i4 | Идентификатор торговой сессии |
exchange_fee_negdeal | d26.2 | Точная ставка биржевой комиссии для адресных сделок |
exchange_fee | d26.2 | Точная ставка биржевой комиссии для анонимных сделок |
clearing_fee_negdeal | d26.2 | Точная ставка клиринговой комиссии для адресных сделок |
clearing_fee | d26.2 | Точная ставка клиринговой комиссии для анонимных сделок |
exp_clearing_fee | d26.2 | Точная ставка клиринговой комиссии за исполнение контракта. |
Таблица 20. Поля таблицы option_rate
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
isin_id | i4 | Уникальный числовой идентификатор инструмента |
sess_id | i4 | Идентификатор торговой сессии |
exchange_fee_negdeal | d26.2 | Точная ставка биржевой комиссии для адресных сделок |
exchange_fee | d26.2 | Точная ставка биржевой комиссии для анонимных сделок |
clearing_fee_negdeal | d26.2 | Точная ставка клиринговой комиссии для адресных сделок |
clearing_fee | d26.2 | Точная ставка клиринговой комиссии для анонимных сделок |
exp_clearing_fee | d26.2 | Точная ставка клиринговой комиссии за исполнение контракта. |
Примечания:
Возможные типы событий
event_type = 1
message = "session_data_ready"
Закончена загрузка данных из клиринговой системы в торговую перед началом новой торговой сессии
event_type = 2
message = "intraday_clearing_finished"
Все расчетные процедуры в промклиринге закончены
event_type = 4
message = "intraday_clearing_started"
Начало промклиринга
event_type = 5
message = "clearing_started"
Начало основного клиринга
event_type = 6
message = "extension_of_limits_finished"
Раздвижка лимитов закончена
event_type = 8
message = "broker_recalc_finished"
Денежные средства после промклиринга пересчитаны
Таблицы:
Таблица 22. Поля таблицы broker_fee
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
sess_id | i4 | Номер сессии |
id_deal | i8 | Номер сделки |
moment | t | Время заключения сделки |
moment_ns | u8 | Время заключения сделки (UNIX-время в наносекундах по стандарту UTC) |
code_buy | c7 | Код покупателя |
code_sell | c7 | Код продавца |
broker_fee_buy | d26.2 | Брокерская комиссия по сделке покупателя |
broker_fee_sell | d26.2 | Брокерская комиссия по сделке продавца |
id_deal_multileg | i8 | Номер сделки по связке |
Примечания:
Возможные типы событий
event_type = 1
message = "session_data_ready"
Закончена загрузка данных из клиринговой системы в торговую перед началом новой торговой сессии
event_type = 2
message = "intraday_clearing_finished"
Все расчетные процедуры в промклиринге закончены
event_type = 4
message = "intraday_clearing_started"
Начало промклиринга
event_type = 5
message = "clearing_started"
Начало основного клиринга
event_type = 6
message = "extension_of_limits_finished"
Раздвижка лимитов закончена
event_type = 8
message = "broker_recalc_finished"
Денежные средства после промклиринга пересчитаны
Таблицы:
Таблица 24. Поля таблицы broker_fee_params
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
sess_id | i4 | Номер сессии |
client_code | c7 | Код клиента (код брокера) |
lower_fee | d26.2 | Минимально возможная сумма брокерской комиссии за один контракт |
upper_fee | d26.2 | Максимально возможная сумма брокерской комиссии за один контракт |
multiplier | d26.2 | Мультипликатор к сумме биржевого и клирингового сбора |
additive | d26.2 | Постоянная добавка за один контракт |
Примечания:
Поле client_code может содержать либо код клиентского раздела, либо код брокерской фирмы. Если указан код клиента, то заданные параметры используются для расчета брокерской комиссии по сделкам данного клиента. Если указан код брокера, то параметры используются для расчета брокерской комиссии по всем клиентам БФ.
Поле sess_id может принимать следующие значения:
Текущие (действующие сейчас) параметры расчета.
Добавление новых параметров расчета. Параметры применяются в следующей торговой сессии.
Удаление текущих параметров расчета. Параметры удаляются в следующей торговой сессии.
Примечания:
Возможные типы событий
event_type = 1
message = "session_data_ready"
Закончена загрузка данных из клиринговой системы в торговую перед началом новой торговой сессии
event_type = 2
message = "intraday_clearing_finished"
Все расчетные процедуры в промклиринге закончены
event_type = 4
message = "intraday_clearing_started"
Начало промклиринга
event_type = 5
message = "clearing_started"
Начало основного клиринга
event_type = 6
message = "extension_of_limits_finished"
Раздвижка лимитов закончена
event_type = 8
message = "broker_recalc_finished"
Денежные средства после промклиринга пересчитаны
В потоке с периодичностью раз в 2 минуты в таблице orders публикуется срез активных заявок, и запись в таблице info с ревизией последней обработанной транзакции из orders_log, номером жизни потока и состоянием публикации среза (поле publication_state). В момент публикации среза поле publication_state принимает значение 0. После того как срез опубликован publication_state принимает значение 1. До момента publication_state=1 данные в таблице orders могут быть неконсистентны.
Таблицы:
Таблица 26. Поля таблицы orders
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
public_order_id | i8 | Идентификационный номер заявки (для айсбергов - номер видимой части айсберга) |
sess_id | i4 | Идентификатор торговой сессии |
client_code | c7 | Код клиента |
moment | t | Время изменения состояния заявки |
moment_ns | u8 | Время изменения состояния заявки (UNIX-время в наносекундах по стандарту UTC) |
xstatus | i8 | Расширенный статус заявки |
xstatus2 | i8 | Расширение для статусов заявок (в дополнение к полю xstatus) |
public_action | i1 | Действие с заявкой (для айсбергов - действие с видимой частью айсберга) |
isin_id | i4 | Уникальный числовой идентификатор инструмента |
dir | i1 | Направление |
price | d16.5 | Цена |
public_amount | i8 | Количество контрактов в операции (для айсбергов - количество контрактов в операции по видимой части айсберга) |
public_amount_rest | i8 | Оставшееся количество контрактов в заявке (для айсбергов - оставшееся количество контрактов в видимой части айсберга) |
comment | c20 | Комментарий трейдера |
ext_id | i4 | Внешний номер |
login_from | c20 | Логин пользователя, поставившего заявку |
broker_to | c7 | Код SPECTRA фирмы-адресата внесистемной заявки |
broker_to_rts | c7 | Код РТС фирмы-адресата внесистемной заявки |
date_exp | t | Дата истечения заявки |
id_ord1 | i8 | Номер первой заявки |
broker_from_rts | c7 | Код РТС фирмы - владельца заявки |
aspref | i4 | Идентификатор пользователя. Для заявок, поданных от SMA-логина - идентификатор MASTER-логина. |
private_order_id | i8 | Идентификационный номер заявки (для айсбергов – идентификационный номер всей айсберг-заявки) |
private_amount | i8 | Количество контрактов в операции (для айсбергов – количество контрактов в операции со всей айсберг-заявкой) |
private_amount_rest | i8 | Оставшееся количество контрактов в заявке (для айсбергов - оставшееся количество контрактов во всей айсберг-заявке) |
variance_amount | i8 | Амплитуда отклонения (в контрактах) случайной надбавки к всплывающей части айсберг-заявки |
disclose_const_amount | i8 | Количество единиц инструмента в постоянной составляющей всплывающей части айсберг-заявки |
private_action | i1 | Действие с заявкой (для айсбергов – действие в отношении всей айсберг-заявки) |
private_init_moment | t | Время появления заявки (для айсбергов - время появления всей айсберг-заявки) |
private_init_amount | i8 | Начальное количество контрактов в заявке (для айсбергов - начальное количество контрактов во всей айсберг-заявке) |
reason | i4 | Признак (причина) заявки, выставленной для заключения сделки урегулирования обязательств. |
public_init_moment | t | Время появления заявки (для айсбергов - время появления видимой части айсберга) |
public_init_amount | i8 | Начальное количество контрактов в заявке (для айсбергов - начальное количество контрактов в видимой части айсберга) |
compliance_id | c1 | Способ ввода заявки |
Примечания:
Поле xstatus представляет собой битовую маску, перечень возможных значений поля приведен в разделе Признаки, выставляемые у заявок и сделок.
Поле dir может принимать следующие значения:
Buy
Sell
Поле public_action может принимать следующие значения:
Заявка удалена
Заявка добавлена
Заявка сведена в сделку
Поле private_action (action) может принимать следующие значения:
Заявка удалена
Заявка добавлена
Заявка сведена в сделку
Заявка добавлена в результате появления новой видимой части айсберга
Поле reason может принимать следующие значения:
Обычная заявка
Балансирующие Срочные контракты, заключенные с Добросовестным участником клиринга без подачи заявок
Закрывающие Срочные контракты, заключенные в рамках процедуры кросс-дефолта
Закрывающие Срочные контракты, заключенные в связи с неисполнением Маржинального требования
Закрывающие Срочные контракты, заключенные в связи с неисполнением Обязательства по поставке по поставочным Срочным контрактам на драгоценные металлы
Иное
Поле compliance_id может принимать следующие значения:
Не заполнено/Не задано
Ручной ввод
В результате срабатывания условного поручения (стоп-лосс)
В результате работы алгоритма-робота
В результате алгоритма автоследования
Закрытие позиции в результате не исполненного MarginCall
Таблица 27. Поля таблицы info
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
infoID | i8 | Уникальный ключ |
logRev | i8 | Последняя обработанная ревизия на момент формирования среза |
lifeNum | i4 | Номер жизни потока |
moment | t | Время формирования среза |
publication_state | i1 | Состояние публикации среза |
Примечания:
Поле publication_state может принимать следующие значения:
in progress (данные не готовы)
done
В потоке с периодичностью раз в 2 минуты в таблице orders публикуется срез активных заявок, и запись в таблице info с ревизией последней обработанной транзакции из orders_log, номером жизни потока и состоянием публикации среза (поле publication_state). В момент публикации среза поле publication_state принимает значение 0. После того как срез опубликован publication_state принимает значение 1. До момента publication_state=1 данные в таблице orders могут быть неконсистентны.
Таблицы:
Таблица 28. Поля таблицы orders
Поле | Тип | Описание |
---|---|---|
replID | i8 | Служебное поле подсистемы репликации |
replRev | i8 | Служебное поле подсистемы репликации |
replAct | i8 | Служебное поле подсистемы репликации |
public_order_id | i8 | Идентификационный номер заявки (для айсбергов - номер видимой части айсберга) |
sess_id | i4 | Идентификатор торговой сессии |
moment | t | Время изменения состояния заявки |
moment_ns | u8 | Время изменения состояния заявки (UNIX-время в наносекундах по стандарту UTC) |
xstatus | i8 | Расширенный статус заявки |
xstatus2 | i8 | Расширение для статусов заявок (в дополнение к полю xstatus) |
public_action | i1 | Действие с заявкой (для айсбергов - действие с видимой частью айсберга) |
isin_id | i4 | Уникальный числовой идентификатор инструмента |
dir | i1 | Направление |