PLAZA II шлюз (версия 7.27)


Содержание

A. История изменений
Введение
Назначение документа
Круг пользователей
Сокращения
Краткий обзор системы SPECTRA
Субъекты (участники) торгов
Расчетные фирмы
Брокерские фирмы
Клиенты
Кодировка в системе
Раскрытие информации об участниках в системе
Пользователи. Привязка пользователя к участнику торгов
Инструменты
Базовые активы
Фьючерсы
Однодневные фьючерсы с автопролонгацией
Опционы
Составные инструменты (связки)
Идентификация инструментов
Торговые операции
Заявки – общие возможности
Адресные заявки
Адресный режим с мэтчингом по уникальному коду
Сделки
Кросс-сделки
Особенности торговли связками
Айсберг-заявки
Айсберг-заявки в информационных потоках системы
Операции над айсберг-заявками
Смена идентификаторов заявок при операциях над айсберг-заявкой
Поставка активов и экспирация опционов
Поставка по фьючерсам
Реализация поставки фьючерсных контрактов срочного рынка на фондовом рынке (режим Т+2)
Экспирация опционов
Экспирация американских поставочных опционов на фьючерсы
Экспирация европейских рачетных опционов
Расчет опционных рисков перед экспирацией
Прекращение обязательств по однодневным фьючерсам с автопролонгацией ("вечным фьючерсам")
Расчет сделки по заявке с указанием спреда TAS (В текущей версии данный сервис недоступен)
Признаки, выставляемые у заявок и сделок
Типы сделок, формируемые при исполнении и истечении фьючерсов и опционов
Расписание торгов и клиринга
Расписание торгов. Торговые сессии
Промежуточный клиринг
Основной клиринг
Особенности поведения разных сущностей в системе при назначении новой торговой сессии
Справочная и сессионная информация
Деньги и позиции
Заявки и сделки
Инструменты
Потоки репликации
Использование механизма синхрособытий для получения консистентного состояния данных в системе
Расписание игровых и тестовых торгов
Аукцион открытия
Управление рисками и лимитирование торговых операций
Гарантийное обеспечение
Маржирование календарных спредов
Торговые лимиты
Единый пул обеспечения
Ограничения на торговые операции и открытие позиций для клиентов
Запреты - общие возможности
Автоматические запреты
Перенос позиций (обязательств)
Приостановка торгов для расширения лимита колебаний цен сделок
Информирование участников о прогнозируемых значениях риск-параметров
Блокировка брокерской части клиентского сбора
Поддержка отрицательных цен в SPECTRA
Клиентские SMA-логины (спонсируемый доступ)
Разделение статусов участников торгов и участников клиринга
Соответствие сущностям системы
Разделение полномочий участников
Управление участником клиринга обязательствами участника торгов
Синтетический матчинг
Синтетические заявки
Синтетическая ликвидность в агрегированных стаканах
Сделки урегулирования
Причины сделок урегулирования
Штрафы и комиссии
Опционы на акции
Изменения в расчете свободных средств под опционы на акции
Новый индикатив - величина премии подлежащей к уплате/получению в ближайшую клиринговую сессию
Изменение расписания клиринговых сессий
Исполнение опционов на акции
Маржирование опционов на акции
Запреты по опционам на акции
Описание торгового шлюза
Состав, установка и настройка ПО PLAZA II шлюз
Состав и архитектура шлюза
Требования к аппаратной и программной инфраструктурам
Аппаратные требования
Программные требования
Установка ПО в среде Windows
Установка ПО в среде Linux
Установка из zip-архива
Установка из deb-пакета или rpm-пакета
Рекомендации по разработке
Использование тестовых примеров
Распределенные конфигурации
Рекомендации по включению рантаймов МБ в приложение пользователя при распространении пользовательского ПО сторонним компаниям
Состав транслируемой информации
Справочная информация
Торговая информация
Информация для восстановления
Информация о средствах и лимитах
Клиринговая информация
Информация об индексах и курсах
Вспомогательные информационные потоки
Особенности использования шлюза
Служебные поля репликации
Команды
Контроль аномальной активности
Автоматическое снятие заявок при отключении пользователя от торгов
Потоки, получаемые логинами разных подтипов
Смена пароля доступа в торговую систему
Партиционирование матчинга
Типы потоков данных
Ограничение количества одновременно открытых потоков репликации от одного соединения PLAZA II
Обработка нештатных ситуаций
Восстановление при потере соединения с Биржей
Диагностика разрыва соединений
Обработка таймаутов при отправке команд/транзакций
Процедура восстановления
Общие рекомендации
Восстановление при проблемах в инфраструктуре Биржи
Очистка данных по потокам
Возможные изменения данных при нештатной работе сервисов публикации
Описание схемы репликации FORTS_PUBLIC
Поток FORTS_TRADE_REPL - Заявки и сделки пользователя (Type=R)
Схема данных
Таблица orders_log: Журнал заявок
Таблица multileg_orders_log: Журнал заявок по связкам
Таблица user_deal: Журнал сделок пользователя
Таблица user_multileg_deal: Журнал сделок пользователя по связкам
Таблица heartbeat: Служебная таблица cерверных часов
Таблица sys_events: Таблица событий
Поток FORTS_ORDLOG_REPL - Поток анонимных заявок (Type=R)
Схема данных
Таблица orders_log: Журнал заявок
Таблица multileg_orders_log: Журнал заявок по связкам
Таблица heartbeat: Служебная таблица cерверных часов
Таблица sys_events: Таблица событий
Поток FORTS_DEALS_REPL - Поток анонимных сделок (Type=R)
Схема данных
Таблица deal: Журнал сделок
Таблица multileg_deal: Журнал сделок по связкам
Таблица heartbeat: Служебная таблица cерверных часов
Таблица sys_events: Таблица событий
Поток FORTS_FEE_REPL - Поток комиссий и штрафов биржи (Type=AR)
Схема данных
Таблица adjusted_fee: Комиссии биржи
Таблица penalty: Штрафы биржи
Таблица sys_events: Таблица событий
Поток FORTS_FEERATE_REPL - Поток точных ставок комиссий биржи (Type=AR)
Схема данных
Таблица futures_rate: Точные ставки комиссий по фьючерсам и инструментам-связкам
Таблица option_rate: Точные ставки комиссий по опционам
Таблица sys_events: Таблица событий
Поток FORTS_BROKER_FEE_REPL - Брокерские комиссии (Type=I)
Схема данных
Таблица broker_fee: Брокерская комиссия
Таблица sys_events: Таблица событий
Поток FORTS_BROKER_FEE_PARAMS_REPL - Параметры для расчета брокерской комиссии (Type=I)
Схема данных
Таблица broker_fee_params: Параметры для расчета брокерской комиссии
Таблица sys_events: Таблица событий
Поток FORTS_USERORDERBOOK_REPL - Заявки пользователя: Cрез стакана (Type=R)
Схема данных
Таблица orders: Таблица активных фьючерсных и опционных заявок
Таблица info: Информация о стаканах
Поток FORTS_ORDBOOK_REPL - Cрез стакана. Анонимный (Type=R)
Схема данных
Таблица orders: Таблица активных анонимных заявок
Таблица info: Информация о стаканах
Поток FORTS_COMMON_REPL - Общая информация по сессии (Type=I)
Схема данных
Таблица common: Общая информация по сессии
Таблица sys_events: Таблица событий
Потоки агрегированных стаканов (Type=I)
Схема данных
Таблица orders_aggr: Агрегированные стаканы
Поток FORTS_POS_REPL - Информация о позициях (Type=I)
Схема данных
Таблица position: Позиции клиентов
Таблица position_sa: Позиции уровня Расчётного кода
Таблица sys_events: Таблица событий
Поток FORTS_PART_REPL - Информация о средствах и лимитах (Type=I)
Схема данных
Таблица part: Средства и лимиты по клиентам и брокерским фирмам
Таблица part_sa: Средства и лимиты по Расчетному коду
Таблица sys_events: Таблица событий
Поток FORTS_PROHIBITION_REPL - Запреты (Type=R)
Схема данных
Таблица prohibition: Запреты
Таблица sys_events: Таблица событий
Поток FORTS_REFDATA_REPL - Справочная и сессионная информация (Type=R)
Схема данных
Таблица rates: Справочник курсов валют
Таблица fut_sess_contents: Справочник торгуемых инструментов (фьючерсы)
Таблица fut_vcb: Справочник торгуемых активов (фьючерсы)
Таблица fut_instruments: Справочник инструментов
Таблица fut_bond_registry: Справочник параметров спот-активов
Таблица dealer: Справочник фирм
Таблица sys_messages: Сообщения торговой системы
Таблица opt_sess_contents: Справочник торгуемых инструментов (опционы)
Таблица opt_vcb: Справочник торгуемых активов (опционы)
Таблица multileg_dict: Справочник связок
Таблица fut_intercl_info: Информация о вариационной марже по фьючерсам, рассчитанной по результатам промежуточного клиринга
Таблица opt_intercl_info: Информация о вариационной марже и премии по опционам, рассчитанной по результатам промежуточного клиринга
Таблица opt_exp_orders: Поручения на экспирацию
Таблица fut_bond_nkd: НКД на дату исполнения срочного контракта с облигацией
Таблица fut_bond_nominal: Размеры выплат номинальной стоимости облигации
Таблица fut_bond_isin: Справочник соответствия инструментов спот-активам
Таблица user: Пользователи системы
Таблица sess_option_series: Опционные серии по сессиям
Таблица investor: Справочник клиентов
Таблица fut_margin_type: Тип маржирования
Таблица fut_settlement_account: Расчетный Код
Таблица sma_master: Привязка SMA-логина к MASTER-логину
Таблица sma_pre_trade_check: Настройки предварительных проверок SMA-логина
Таблица clearing_members: Участники клиринга
Таблица instr2matching_map: Сопоставление инструментов матчингу
Таблица fut_exec_orders: Поручения на исполнение однодневных фьючерсов с автопролонгацией
Таблица discrete_auction: Параметры назначенных аукционов открытия
Таблица discrete_auction_base_contract: Базовые контракты, назначенные в аукцион открытия
Таблица session: Информация о торговой сессии
Таблица brokers_base_contracts_params: Индивидуальный коэффициент ГО в разрезе базового контракта и БФ
Таблица sys_events: Таблица событий
Поток FORTS_MM_REPL - Информация об обязательствах ММ (Type=I)
Схема данных
Таблица mm_agreement_filter: Таблица с номерами и типами договоров на оказание маркет-мейкерских услуг
Таблица fut_MM_info: Обязательства ММ по фьючерсам
Таблица opt_MM_info: Обязательства ММ по опционам
Таблица cs_mm_rule: Таблица с инструментами для пересчета центрального страйка
Поток FORTS_CLR_REPL - Клиринговая информация (Type=AR)
Схема данных
Таблица money_clearing: Клиентские деньги в клиринге
Таблица clr_rate: Курсы валют и индексов
Таблица fut_pos: Информация о позиционном состоянии на момент вечернего клиринга по фьючерсам
Таблица opt_pos: Информация о позиционном состоянии на момент вечернего клиринга по опционам
Таблица fut_sess_settl: Расчетные цены по фьючерсам
Таблица opt_sess_settl: Расчетные цены по опционам
Таблица pledge_details: Таблица детализации залогов
Таблица money_clearing_sa: Клиентские деньги в клиринге
Таблица fut_pos_sa: Информация о позиционном состоянии РК на момент вечернего клиринга по фьючерсам
Таблица opt_pos_sa: Информация о позиционном состоянии РК на момент вечернего клиринга по опционам
Таблица option_series_settl: Расчетные цены по опционным сериям
Таблица sys_events: Таблица событий
Поток RTS_INDEX_REPL - Биржевые индексы (Type=R)
Схема данных
Таблица rts_index: Таблица индексов
Поток FORTS_VM_REPL - Вариационная маржа и премия (Type=I)
Схема данных
Таблица fut_vm: Вариационная маржа по фьючерсам в разрезе позиций клиентов
Таблица opt_vm: Вариационная маржа и премия по опционам в разрезе позиций клиентов
Таблица fut_vm_sa: Вариационная маржа по фьючерсам в разрезе позиций РК
Таблица opt_vm_sa: Вариационная маржа и премия по опционам в разрезе позиций РК
Таблица sys_events: Таблица событий
Поток FORTS_VOLAT_REPL - Волатильность (Type=I)
Схема данных
Таблица volat: Волатильность
Таблица sys_events: Таблица событий
Поток FORTS_RISKINFOBLACK_REPL - Риск-параметры для модели Блэка-Шоулза (Type=I)
Схема данных
Таблица volat_coeff: Риск-параметры для модели Блэка-Шоулза
Поток FORTS_RISKINFOBACH_REPL - Риск-параметры для модели Башелье (Type=I)
Схема данных
Таблица volat_coeff: Риск-параметры для модели Башелье
Поток FORTS_INFO_REPL - Справочная информация (Type=R)
Схема данных
Таблица currency_params: Параметры валют
Таблица base_contracts_params: Параметры базовых контрактов
Таблица futures_params: Параметры фьючерсов
Таблица option_series_params: Параметры опционных серий
Таблица options_params: Параметры опционов
Таблица investor: Справочник клиентов
Таблица dealer: Справочник фирм
Таблица multileg_dictionary: Справочник связок
Таблица common_params: Параметры расчёта ГО
Таблица brokers_base_contracts_params: Индивидуальный коэффициент ГО в разрезе базового контракта и БФ
Таблица sys_events: Таблица событий
Поток FORTS_TNPENALTY_REPL - Информация о сборах за транзакции (Type=I)
Схема данных
Таблица fee_tn: Детализированная информация по количеству некорректных транзакций
Таблица fee_all: Информация о количестве начисленных баллов
Таблица heartbeat: Служебная таблица cерверных часов
Поток MOEX_RATES_REPL - Курсы валют он-лайн (Type=I)
Схема данных
Таблица curr_online: Значения курсов валют
Поток FORTS_FORECASTIM_REPL - Прогноз рисков после возможной раздвижки (Type=I)
Схема данных
Таблица part_sa_forecast: Прогноз объема свободных средств для РК
Таблица sys_events: Таблица событий
Поток FORTS_USER_REPL - Пользователи (Type=R)
Схема данных
Таблица user: Пользователи системы
Таблица sma_master: Привязка SMA-логина к MASTER-логину
Таблица sma_pre_trade_check: Настройки предварительных проверок SMA-логина
Таблица sys_events: Таблица событий
Поток FORTS_REJECTEDORDERS_REPL - Отвергнутые в клиринг заявки (Type=R)
Схема данных
Таблица rejected_orders: Отвергнутые в клиринг заявки
Описание команд
Метод AddOrder - Добавление заявок
Метод DelOrder - Удаление заявок
Метод DelUserOrders - Массовое удаление заявок
Метод MoveOrder - Изменение заявок
Метод IcebergAddOrder - Добавление айсберг-заявок
Метод IcebergDelOrder - Удаление айсберг-заявок
Метод IcebergMoveOrder - Изменение айсберг-заявок
Метод ChangeClientMoney - Изменение клиентских лимитов
Метод ChangeBFMoney - Изменение лимитов БФ
Метод OptChangeExpiration - Поручения на экспирацию опционов
Метод FuturesExecutionRequest - Поручения на исполнение однодневных фьючерсов с автопролонгацией
Метод FutChangeClientProhibit - Изменение клиентских ограничений для фьючерсов
Метод OptChangeClientProhibit - Изменение клиентских ограничений для опционов
Метод ExchangeBFMoney - Перевод денежных средств между двумя БФ одного РК
Метод OptRecalcCS - Изменение центрального страйка
Метод TransferClientPosition - Перенос позиций между БФ
Метод OptChangeRiskParametersNextSession - Управление риск-параметрами опционов
Метод ChangeBFParametersNextSession - Изменение параметров БФ Участником клиринга
Метод ChangeClientParameters - Изменение параметров на клиентских разделах
Метод ChangeClientParametersNextSession - Изменение параметров на клиентских разделах в клиринг
Метод ChangeBFClientDefaultParametersNextSession - Изменение на клиентских разделах параметров по умолчанию в клиринг
Метод ChangeBFClientBaseContractParametersNextSession - Изменение параметров клиентов БФ по БА
Метод ChangeBFLimit - Изменение торговых лимитов БФ
Метод CODHeartbeat - Сообщение-хартбит для сервиса Cancel on Disconnect
Метод SetSmaPreTradeCheck - Установка предварительной проверки для заявок SMA-логина
Метод DelSmaPreTradeCheck - Удаление предварительной проверки для заявок SMA-логина
Метод UserKillSwitch - Запрет торговых операций для логина
Метод SetBrokerFeeParamNextSession - Установка параметров для расчета брокерской комиссии
Метод DelOrdersByBFLimit - Запрос к НКЦ на проверку достаточности обеспечения по БФ
Метод ChangePassword - Изменение пароля пользователя в торговой системе
B. Типы данных платформы PLAZA II
C. Справочник кодов возврата

A. История изменений

ДатаИзменения
08.07.2024Внесённые изменения:
  • Поток FORTS_TRADE_REPL:

    • В таблицы orders_log и multileg_orders_log добавлено поле match_ref.

  • Удален устаревший поток FORTS_MISCINFO_REPL. Вместо него надо использовать потоки FORTS_RISKINFOBLACK_REPL и FORTS_RISKINFOBACH_REPL.

12.04.2024Внесённые изменения:
  • Поток FORTS_REFDATA_REPL:

    • В таблице fut_sess_contents в поле state добавлена трансляция новых значений:

      • 8 - Сессия по этому инструменту идет. Можно ставить заявки в закрытие по этому инструменту.

      • 9 - Аукцион открытия по этому инструменту идет. Можно ставить заявки в закрытие по этому инструменту.

    • В таблице opt_sess_contents в поле state добавлена трансляция новых значений:

      • 6 - Стартовал аукцион открытия по этому инструменту. Можно ставить и удалять заявки по этому инструменту.

      • 7 - Аукцион открытия по этому инструменту завершен.

      • 8 - Сессия по этому инструменту идет. Можно ставить заявки в закрытие по этому инструменту.

      • 9 - Аукцион открытия по этому инструменту идет. Можно ставить заявки в закрытие по этому инструменту.

    • В таблицы fut_sess_contents и fut_instruments добавлено поле tas_base_fut_isin_id.

  • Добавлены новые коды ошибок: 140

18.03.2024Внесённые изменения:
  • Добавлен раздел "2.4.4. Расчет сделки по заявке с указанием спреда TAS".

  • В раздел "2.4.5. Признаки, выставляемые у заявок и сделок" добавлено описание новых флагов:

    • "TASSettlement (0x10000)" - Расчет сделки по заявке с указанием спреда TAS.

  • Добавлен раздел "3.4.1.2. Обработка таймаутов при отправке команд/транзакций".

  • Поток FORTS_TRADE_REPL:

    • В таблицы orders_log и multileg_orders_log добавлено поле compliance_id.

  • Поток FORTS_USERORDERBOOK_REPL:

    • В таблицу orders добавлено поле compliance_id.

  • Поток FORTS_REFDATA_REPL:

    • В таблице fut_sess_contents для поля signs появился новый бит: 0x100000 - TAS-фьючерс.

    • В таблице fut_vcb для поля signs появился новый бит: 0x4 - TAS-фьючерс.

    • В таблице dealer для поля status появился новый бит: 0x10000 - НКЦ.

    • В таблицу sys_messages добавлено поле type_id.

    • Удалены устаревшие таблицы fut_rejected_orders и opt_rejected_orders. Вместо этих таблиц надо использовать таблицу rejected_orders потока FORTS_REJECTEDORDERS_REPL.

  • Начиная с версии 7.21 поток FORTS_MISCINFO_REPL объявляется устаревшим и будет удален в версии 7.27. Вместо него надо использовать потоки FORTS_RISKINFOBLACK_REPL и FORTS_RISKINFOBACH_REPL.

  • Поток FORTS_INFO_REPL:

    • В таблицу futures_params добавлено поле tas_base_fut_isin_id.

    • В таблице futures_params для поля attribute появился новый бит: 0x100000 - TAS-фьючерс.

  • Изменения в репозитории схем подачи команд:

    • В команду AddOrder добавлено поле compliance_id (c1). Добавлен новый тип команды AddOrder (msgid=474).

    • В команду IcebergAddOrder добавлено поле compliance_id (c1). Добавлен новый тип команды IcebergAddOrder (msgid=475).

    • В команду MoveOrder добавлено поле compliance_id (c1). Добавлен новый тип команды AddOrder (msgid=476).

    • В команду IcebergMoveOrder добавлено поле compliance_id (c1). Добавлен новый тип команды IcebergAddOrder (msgid=477).

    • Внесены дополнения в раздел "5.25. Метод SetSmaPreTradeCheck - Установка предварительной проверки для заявок SMA-логина".

01.12.2023Внесённые изменения:
  • Изменено название документа: вместо "Шлюз SPECTRA Plaza-2" стало "PLAZA II шлюз".

  • Добавлен раздел "2.3.2.1. Адресный режим с мэтчингом по уникальному коду".

  • В раздел "2.4.4. Признаки, выставляемые у заявок и сделок" добавлено описание новых флагов:

    • Устаревший бит "InternalHalfTrade (0x80000000)" переименован в "NegotiatedMatchByRef (0x80000000)" - Признак заявки или сделки, сформированной в режиме "Адресный с мэтчингом по уникальному коду".

  • Добавлен новый поток FORTS_REJECTEDORDERS_REPL - Отвергнутые в клиринг заявки. Таблицы:

    • rejected_orders - Отвергнутые в клиринг заявки. Таблица используется вместо устаревших таблиц fut_rejected_orders и opt_rejected_orders потока FORTS_REFDATA_REPL.
  • Поток FORTS_COMMON_REPL:

    • Из таблицы sys_events удалено устаревшее поле type. Вместо него следует использовать поле event_type.

  • Поток FORTS_REFDATA_REPL:

    • Из таблицы session удалено устаревшее поле opt_sess_id. Вместо него следует использовать поле sess_id.

    • Начиная с версии 7.18 таблицы fut_rejected_orders и opt_rejected_orders объявляются устаревшими и будут удалены в версии 7.21. Вместо этих таблиц надо использовать таблицу rejected_orders потока FORTS_REJECTEDORDERS_REPL.

  • Поток RTS_INDEX_REPL:

    • Из таблицы rts_index удалено устаревшее поле value. Вместо него следует использовать поле value_highprec.

  • Изменения в репозитории схем подачи команд:

    • Удалены медленные версии команды ChangeClientMoney (версии команд с ID in = 4, 60, 63, 67, 409, 425 / Reply ID out = 104 ), ранее объявленные устаревшими. Используйте более быструю версию команды ChangeClientMoney с ID in = 458 / Reply ID out = 187.

04.09.2023Внесённые изменения:
  • Раздел "3.1.4. Установка ПО в среде Linux" разбит на две части:

    • "3.1.4.1. Установка из zip-архива".

    • "3.1.4.2. Установка из deb-пакета или rpm-пакета"

  • Добавлен новый поток FORTS_USER_REPL - Пользователи. Таблицы:

    • user - Пользователи системы
    • sma_master - Привязка SMA-логина к MASTER-логину
    • sma_pre_trade_check - Настройки предварительных проверок SMA-логина
    • sys_events - Таблица событий
  • Поток FORTS_PROHIBITION_REPL:

    • Удалено значение "0x20000000 (Споты)" для поля group_mask в таблице prohibition.

  • Поток FORTS_REFDATA_REPL:

    • Удалена устаревшая таблица option_series. Вместо этой таблицы надо использовать таблицу sess_option_series.

    • В таблицу sess_option_series добавлены поля interest_rate_risk_up, interest_rate_risk_down, r2, interest_rate2_risk_up, interest_rate2_risk_down.

    • Из таблицы sess_option_series удалено устаревшее поле state. Вместо него следует использовать поле state из таблицы opt_sess_contents.

    • Из таблицы investor удалено устаревшее поле status. Вместо него следует использовать поле xstatus.

  • Поток FORTS_CLR_REPL:

    • В таблицы fut_pos, opt_pos, fut_pos_sa и opt_pos_sa добавлено поле sbor_nosys.

    • В таблицу fut_sess_settl добавлено поле index_div.

  • Поток FORTS_VM_REPL:

    • Добавлена таблица событий sys_events.

  • Поток FORTS_VOLAT_REPL:

    • Добавлена таблица событий sys_events.

  • Поток FORTS_INFO_REPL:

    • В таблицу option_series_params добавлены поля r2, interest_rate2_risk_up, interest_rate2_risk_down.

  • Поток FORTS_TNPENALTY_REPL:

    • В таблицу fee_tn добавлено поле num_orders.

  • Удалены коды ошибок: 9999.

02.06.2023Внесённые изменения:
  • Поток FORTS_COMMON_REPL:

    • В таблицу sys_events добавлено поле event_type.

    • Начиная с версии 7.12 поле type в таблице sys_events объявляется устаревшим и будет удалено в версии 7.18. Вместо него следует использовать поле event_type.

  • Поток FORTS_REFDATA_REPL:

    • Из таблицы opt_sess_contents удалены устаревшие поля d_exec_beg и d_exec_end. Вместо них следует использовать поле expiration_date из таблицы sess_option_series.

    • Из таблицы opt_sess_contents удалено устаревшее поле step_price. Вместо него следует использовать поле step_price из таблицы sess_option_series.

    • Начиная с версии 7.12 поле opt_sess_id в таблице session объявляется устаревшим и будет удалено в версии 7.18. Вместо него следует использовать поле sess_id.

    • В таблицу sess_option_series добавлены поля step_price_clr и step_price_interclr.

  • Поток FORTS_CLR_REPL:

    • Из таблиц fut_pos, opt_pos, fut_pos_sa и opt_pos_sa удалены поля vat_ex и vat_cc.

  • Поток RTS_INDEX_REPL:

    • Начиная с версии 7.12 поле value в таблице rts_index объявляется устаревшим и будет удалено в версии 7.18. Вместо него следует использовать поле value_highprec.

  • Изменения в репозитории схем подачи команд:

    • Медленные версии команды ChangeClientMoney (версии команд с ID in = 4, 60, 63, 67, 409, 425 / Reply ID out = 104 ) начиная с версии 7.12 объявляются устаревшими и будут удалены в версии 7.18. Используйте более быструю версию команды ChangeClientMoney с ID in = 458 / Reply ID out = 187.

  • В версии 7.12 в системе введено ограничение на количество одновременных подписок на один поток Plaza2 (Cgate) от одного шлюзового логина - не более 20 (подробнее см. раздел "3.3.9. Ограничение количества одновременно открытых потоков репликации от одного соединения Plaza2").

27.03.2023Внесённые изменения:
  • В раздел "2.4.4. Типы сделок, формируемые при исполнении и истечении фьючерсов и опционов" добавлено описание новых флагов:

    • Устаревший бит "eREPOCCStatus (0x2000)" переименован в "DueToCrossCancel (0x2000)" - Признак снятия пассивной заявки при кросс-сделке.

  • Начиная с версии 7.9 в системе SPECTRA сервис информирования участников о прогнозных значениях риск-параметров (ForecastIM) объявляется устаревшим с последующим удалением сервиса в версии 7.15.

  • Поток FORTS_COMMON_REPL:

    • В таблицу common добавлено поле swap_rate.

    • Добавлена таблица событий sys_events.

  • Поток FORTS_PROHIBITION_REPL:

    • В таблицу prohibition добавлены поля section_id и base_contract_id.

    • Начиная с версии 7.9 значение "0x20000000 (Споты)" для поля group_mask в таблице prohibition объявляется устаревшим и будет удалено в версии 7.15.

  • Поток FORTS_REFDATA_REPL:

    • Из таблиц fut_sess_contents и fut_instruments удалено устаревшее поле is_percent. Вместо него следует использовать поле asset_class из таблицы fut_vcb.

    • В таблицу investor добавлено поле xstatus. Поле xstatus отличается от существующего поля status расширенным типом i8 и трансляцией в нем двух дополнительных флагов:

      • 0x10000000000 - Квалифицированный инвестор

      • 0x40000000000 - Снять пассивную заявку при кросс-сделке

    • Начиная с версии 7.9 поле status в таблице investor объявляется устаревшим и будет удалено в версии 7.15. Вместо него следует использовать поле xstatus.

    • Добавлена таблица brokers_base_contracts_params.

    • В таблицу opt_sess_contents добавлено поле state.

    • Начиная с версии 7.9 поле state из таблиц option_series и sess_option_series объявляется устаревшим и будет удалено в версии 7.15. Вместо него следует использовать поле state из таблицы opt_sess_contents.

  • Поток FORTS_INFO_REPL:

    • Из таблицы base_contracts_params удалено устаревшее поле is_percent. Вместо него следует использовать поле asset_class.

    • Добавлена таблица brokers_base_contracts_params.

  • Изменения в репозитории схем подачи команд:

    • Добавлена новая команда ChangeBFClientBaseContractParametersNextSession (msgid=1057) - Изменение параметров клиентов БФ по БА.

09.11.2022Внесённые изменения:
  • В раздел "2.3.1. Заявки – общие возможности" добавлено описание заявок типа Book-or-Cancel (BOC).

  • Раздел "2.4.4. Типы сделок, формируемые при исполнении и истечении фьючерсов и опционов" разбит на две части:

    • "2.4.4. Признаки, выставляемые у заявок и сделок".

    • "2.4.5. Типы сделок, формируемые при исполнении и истечении фьючерсов и опционов"

  • В раздел "2.4.4. Признаки, выставляемые у заявок и сделок" добавлено описание новых флагов:

    • DuringDiscreteAuction (0x4000000000000000) - Признак заявки или сделки в аукционе открытия.

    • BOC (0x1000000000000000) - Заявка Book-or-Cancel (BOC).

  • Добавлен раздел "2.5.7. Аукцион открытия".

  • Поток FORTS_TRADE_REPL:

    • В таблицы orders_log и multileg_orders_log добавлено поле xstatus2.

    • В таблицы user_deal и user_multileg_deal добавлены поля xstatus2_buy и xstatus2_sell.

  • Поток FORTS_ORDLOG_REPL:

    • В таблицы orders_log и multileg_orders_log добавлено поле xstatus2.

  • Поток FORTS_DEALS_REPL:

    • В таблицы deal и multileg_deal добавлены поля xstatus2_buy и xstatus2_sell.

  • Поток FORTS_USERORDERBOOK_REPL:

    • В таблицу orders добавлено поле xstatus2.

  • Поток FORTS_ORDBOOK_REPL:

    • В таблицу orders добавлено поле xstatus2.

  • Поток FORTS_COMMON_REPL:

    • В таблицу common добавлено поле opening_auction_price.

  • Поток FORTS_REFDATA_REPL:

    • Добавлены таблицы sess_option_series, discrete_auction и discrete_auction_base_contract.

    • Из таблицы opt_sess_contents удалены поля europe, min_step, lot_volume.

    • В таблицу user добавлено поле user_level.

    • Начиная с версии 7.6 таблица option_series объявляется устаревшей и будет удалена в последующих версиях. Вместо этой таблицы надо использовать таблицу sess_option_series.

  • Поток FORTS_CLR_REPL:

    • В таблицы fut_pos, opt_pos, fut_pos_sa и opt_pos_sa добавлены поля pos_exec и charge_exec.

    • Начиная с версии 7.6 поля vat_ex и vat_cc в таблицах fut_pos, opt_pos, fut_pos_sa и opt_pos_sa объявляются устаревшими и будут удалены в версии 7.12.

  • Поток FORTS_INFO_REPL:

    • Из таблицы base_contracts_params удалено поле subrisk_step.

    • Из таблицы futures_params удалено поле subrisk.

  • Изменения в репозитории схем подачи команд:

    • В команду IcebergAddOrder добавлено поле type (i4). Добавлен новый тип команды IcebergAddOrder (msgid=472).

  • Добавлены новые коды ошибок: 82, 85, 90, 95, 100, 105, 110, 115, 120, 125, 130, 135, 3002, 4300-4305

  • Изменены тексты кодов ошибок: 62

15.09.2022Внесённые изменения:
  • Добавлен раздел "2.3.4. Кросс-сделки".

  • Добавлен раздел "2.4.3. Прекращение обязательств по однодневным фьючерсам с автопролонгацией ("вечным фьючерсам")".

  • В раздел "2.4.4. Типы сделок, формируемые при исполнении и истечении фьючерсов и опционов" добавлено описание новых флагов:

    • ePerpetualFuturesExecutionVoluntary (0x10000000000000) - Техническая сделка вследствие добровольного выхода из вечного фьючерса (на основании поданного поручения).

    • ePerpetualFuturesExecutionForced (0x400000000000000) - Техническая сделка вследствие принудительного выхода из вечного фьючерса (реализация неудовлетворённого спроса).

    • ePerpetualFuturesExecution (0x800000000000000) - Техническая сделка в связанном инструменте вследствие выхода из вечного фьючерса.

  • Поток FORTS_FEE_REPL:

    • В таблицу adjusted_fee добавлены поля adjusted_fee_trade_buy, adjusted_fee_clearing_buy, adjusted_fee_trade_sell, adjusted_fee_clearing_sell.

  • Поток FORTS_PROHIBITION_REPL:

    • Добавлена таблица событий sys_events.

  • Поток FORTS_REFDATA_REPL:

    • Удалена устаревшая таблица prohibition. Вместо этой таблицы надо использовать таблицу prohibition потока FORTS_PROHIBITION_REPL.

    • Добавлена таблица fut_exec_orders.

    • Начиная с версии 7.3 поле is_percent из таблиц fut_sess_contents и fut_instruments объявляется устаревшим и будет удалено в версии 7.9. Вместо него следует использовать поле asset_class из таблицы fut_vcb.

    • Начиная с версии 7.3 поля d_exec_beg и d_exec_end в таблице opt_sess_contents объявляются устаревшим и будут удалены в версии 7.9. Вместо них следует использовать поле expiration_date из таблицы option_series.

  • Поток FORTS_INFO_REPL:

    • Из таблицы currency_params удалено поле signs.

    • Начиная с версии 7.3 поле is_percent в таблице base_contracts_params объявляется устаревшим и будет удалено в версии 7.9. Вместо него следует использовать поле asset_class.

  • Изменения в репозитории схем подачи команд:

    • В команды FutChangeClientProhibit и OptChangeClientProhibit добавлено поле client_priority (i4). Добавлены новые типы команд FutChangeClientProhibit (msgid=469) и OptChangeClientProhibit (msgid=468).

    • Добавлена новая команда FuturesExecutionRequest (msgid=470) - Поручения на исполнение однодневных фьючерсов с автопролонгацией.

    • В команде OptChangeExpiration тип поля order_id изменен на i8. Добавлен новый тип команды OptChangeExpiration (msgid=471).

  • Добавлены новые коды ошибок: 4283, 5052-5055, 5061-5065, 5069, 5071-5073.

  • Изменены тексты кодов ошибок: 4050-4055, 4060-4067, 4069, 4070.

  • Удалены коды ошибок: 300-307, 4068.

17.05.2022Внесённые изменения:
  • Добавлен раздел "2.11. Опционы на акции".

  • Изменен раздел "2.2.3. Опционы".

  • Изменен раздел "2.4.2. Экспирация опционов".

  • В раздел "2.4.3. Типы сделок, формируемые при исполнении и истечении фьючерсов и опционов" добавлено описание новых флагов:

    • eSyntheticPassive (0x200000000000000) - Признак пассивной синтетической заявки.

  • Изменен раздел "2.5. Расписание торгов и клиринга".

  • Изменен раздел "2.6.3. Ограничения на торговые операции и открытие позиций для клиентов".

  • Поток FORTS_TRADE_REPL:

    • Из таблиц orders_log и multileg_orders_log удалены поля id_ord, xamount, xamount_rest, action.

    • Из таблиц user_deal и user_multileg_deal удалены поля id_ord_buy и id_ord_sell.

  • Поток FORTS_USERORDERBOOK_REPL:

    • Из таблицы orders удалены поля id_ord, xamount, xamount_rest, action, init_moment, xinit_amount.

  • Поток FORTS_POS_REPL:

    • В таблицы position и position_sa добавлено поле last_quantity.

  • Поток FORTS_PART_REPL:

    • В таблицы part и part_sa добавлены поля premium_intercl и net_option_value.

  • Поток FORTS_PROHIBITION_REPL:

    • Из таблицы prohibition удалено поле prohib_id.

  • Поток FORTS_REFDATA_REPL:

    • В таблицу option_series добавлены поля margin_style, settlement_type, exercise_style, min_step, step_price, lot_coefficient, r, fixed_spot_discount, projected_spot_discount, step_price_curr, underlying_price, lot_volume, state.

    • Из таблицы opt_sess_contents удалено поле base_isin_id.

    • Начиная с версии 7.0 поле europe в таблице opt_sess_contents объявляется устаревшим и будет удалено в версии 7.6. Вместо него следует использовать поле exercise_style из таблицы option_series.

    • Начиная с версии 7.0 поле min_step в таблице opt_sess_contents объявляется устаревшим и будет удалено в версии 7.6. Вместо него следует использовать поле min_step из таблицы option_series.

    • Начиная с версии 7.0 поле lot_volume в таблице opt_sess_contents объявляется устаревшим и будет удалено в версии 7.6. Вместо него следует использовать поле lot_volume из таблицы option_series.

    • Начиная с версии 7.0 поле step_price в таблице opt_sess_contents объявляется устаревшим и будет удалено в версии 7.6. Вместо него следует использовать поле step_price из таблицы option_series.

    • В таблицу fut_vcb добавлены поля asset_class и board_md.

    • В таблице fut_vcb для поля asset_class удалено значение: '7' - Драгоценные металлы.

    • В таблицу opt_intercl_info добавлены поля premium и premium_in_settl_currency.

    • В таблицу opt_vcb добавлено поле settlement_currency.

    • Из таблицы prohibition удалено поле prohib_id.

    • Удалена устаревшая таблица usd_online.

    • Из таблицы option_series удалены поля A, B, C, D, E, S.

  • Поток FORTS_CLR_REPL:

    • В таблицы opt_pos и opt_pos_sa добавлены поля premium и premium_in_settl_currency.

    • Добавлена таблица option_series_settl.

  • Поток FORTS_VM_REPL:

    • В таблицы opt_vm и opt_vm_sa добавлены поля premium и premium_in_settl_currency.

  • Поток FORTS_INFO_REPL:

    • Начиная с версии 7.0 поле subrisk_step в таблице base_contracts_params объявляется устаревшим и будет удалено в версии 7.6. Вместо него следует использовать поле strike_step из таблицы option_series_params.

    • В таблицу base_contracts_params добавлены поля asset_class и cf_risk.

    • В таблице base_contracts_params для поля asset_class удалено значение: '7' - Драгоценные металлы.

    • Начиная с версии 7.0 поле subrisk в таблице futures_params объявляется устаревшим и будет удалено в версии 7.6. Вместо него следует использовать поле sub_risk из таблицы option_series_params.

    • В таблицу option_series_params добавлены поля sub_risk, spread_aspect, enforce_half_netting, min_step, step_price, lot_coefficient, r, interest_rate_risk_up, interest_rate_risk_down, fixed_spot_discount, projected_spot_discount.

    • Из таблицы option_series_params удалены поля a, b, c, d, e, s.

  • Изменены тексты кодов ошибок: 4067.

05.04.2022Внесённые изменения:
  • Добавлен раздел "2.2.2.1. Однодневные фьючерсы с автопролонгацией".

  • Удален раздел "3.3.4. Мониторинг latency со стороны клиента", являющийся устаревшим.

  • Поток FORTS_REFDATA_REPL:

    • В таблице fut_sess_contents для поля signs появился новый бит: 0x4000 - Однодневный фьючерсный контракт с автопролонгацией (CFD - Contract for difference).

  • Поток FORTS_CLR_REPL:

    • В таблицу fut_sess_settl добавлено поле swap_rate.

20.10.2021Внесённые изменения:
  • Доработка утилиты для смены пароля (change_password.exe):

    • В строку запуска добавлен параметр app_name (имя приложения).

    • В строку запуска добавлен параметр local_pass (пароль для локального соединения с роутером).

    • Из возможных ключей строки запуска удален ключ key.

  • Добавлен новый поток FORTS_PROHIBITION_REPL - Запреты. Таблица prohibition вынесена в отдельный поток.

  • Поток FORTS_REFDATA_REPL:

    • Начиная с версии 6.15 таблица prohibition объявляется устаревшей и будет удалена в версии 7.3. Вместо этой таблицы надо использовать таблицу prohibition потока FORTS_PROHIBITION_REPL.

  • Поток FORTS_INFO_REPL:

    • Начиная с версии 6.15 поле signs в таблице currency_params объявляется устаревшим и будет удалено в версии 7.3.

  • Добавлены новые коды ошибок: 81, 4280-4282.

  • Изменены тексты кодов ошибок: 4160.

  • Удалены коды ошибок: 4168.

23.07.2021Внесённые изменения:
  • Добавлен раздел "2.10. Сделки урегулирования".

  • Поток FORTS_PART_REPL:

    • Из таблицы part удалено поле balance_money.

  • Поток FORTS_REFDATA_REPL:

    • В таблицы fut_sess_contents и fut_instruments добавлено поле enforce_ims_half_netting.

  • Поток FORTS_INFO_REPL:

    • В таблицу futures_params добавлено поле enforce_ims_half_netting.

    • В таблицу option_series_params добавлены поля margin_style, settlement_type, exercise_style.

  • Поток FORTS_FEERATE_REPL:

    • В таблицы futures_rate, option_rate добавлено поле exp_clearing_fee. В версии 6.12 поле всегда будет содержать "0.0". В версии 6.15 это поле будет заполняться значениями ставки.

  • Удалены коды ошибок: 4120, 4121.

  • Добавлены новые коды ошибок: 80.

14.05.2021Внесённые изменения:
  • В раздел "2.4.3. Типы сделок, формируемые при исполнении и истечении фьючерсов и опционов" добавлено описание новых флагов:

    • eDontFineRF (0x80000000000000) - Признак невзимания штрафа за сделки урегулирования.

  • Удалены потоки FORTS_FUTTRADE_REPL и FORTS_OPTTRADE_REPL. Вместо них следует использовать поток FORTS_TRADE_REPL.

  • Удалены потоки FORTS_FUTORDERBOOK_REPL и FORTS_OPTORDERBOOK_REPL. Вместо них следует использовать поток FORTS_USERORDERBOOK_REPL.

  • Удалены потоки FORTS_FUTCOMMON_REPL и FORTS_OPTCOMMON_REPL. Вместо них следует использовать поток FORTS_COMMON_REPL.

  • Удалены потоки FORTS_FUTINFO_REPL и FORTS_OPTINFO_REPL. Вместо них следует использовать поток FORTS_REFDATA_REPL.

  • Удалены потоки FORTS_FUTAGGR5_REPL, FORTS_FUTAGGR20_REPL, FORTS_FUTAGGR50_REPL, FORTS_OPTAGGR5_REPL, FORTS_OPTAGGR20_REPL и FORTS_OPTAGGR50_REPL. Вместо них следует использовать потоки FORTS_AGGR5_REPL, FORTS_AGGR20_REPL и FORTS_AGGR50_REPL.

  • Поток FORTS_TRADE_REPL:

    • Из таблиц orders_log и multileg_orders_log удавлено поле local_stamp.

    • В таблицы orders_log и multileg_orders_log добавлено поле reason.

    • В таблицы user_deal и user_multileg_deal добавлены поля reason_buy и reason_sell.

  • Поток FORTS_FEE_REPL:

    • Добавлена таблица penalty.

  • Поток FORTS_USERORDERBOOK_REPL:

    • В таблицу orders добавлено поле reason.

  • Поток FORTS_PART_REPL:

    • В таблицу part добавлено поле penalty.

    • В таблицу part_sa добавлено поле blocked_tax.

  • Поток FORTS_REFDATA_REPL:

    • Из таблиц fut_sess_contents, fut_instruments и opt_sess_contents удавлено поле d_start.

    • В таблицу prohibition добавлено поле xprohibition_id.

    • Начиная с версии 6.9 в таблице prohibition поле prohib_id объявляется устаревшим и будет удалено в версии 6.15.

    • Начиная с версии 6.9 таблица usd_online объявляется устаревшей и будет удалена в версии 6.15. Вместо этой таблицы надо использовать таблицу curr_online потока MOEX_RATES_REPL.

  • Поток FORTS_CLR_REPL:

    • В таблицу money_clearing_sa добавлено поле blocked_tax.

  • Изменения в репозитории схем подачи команд:

    • Из команд AddOrder, MoveOrder, DelOrder, DelUserOrders, IcebergAddOrder, IcebergMoveOrder и IcebergDelOrder удалено поле local_stamp. Добавлены новые типы команд: AddOrder (msgid=465), MoveOrder (msgid=460), DelOrder (msgid=461), DelUserOrders (msgid=466), IcebergAddOrder (msgid=462), IcebergMoveOrder (msgid=463) и IcebergDelOrder (msgid=464).

    • Удалена устаревшая команда FutTransferRisk.

  • Добавлены новые коды ошибок: 3001.

  • Изменены тексты кодов ошибок: 4017.

25.02.2021Внесённые изменения:
  • Поток FORTS_PART_REPL:

    • Начиная с версии 6.8 в таблице part поле balance_money объявляется устаревшим и будет удалено в версии 6.12.

12.01.2021Внесённые изменения:
  • Поток FORTS_REFDATA_REPL:

    • В таблицу dealer добавлено поле order_allowed_in_morning_session.

  • Поток FORTS_INFO_REPL:

    • В таблицу dealer добавлено поле order_allowed_in_morning_session.

  • Изменения в репозитории схем подачи команд:

    • Начиная с версии 6.7 процедура FutTransferRisk объявляется устаревшей и будет удалена в последующих версиях.

  • Добавлены новые коды ошибок: 4226.

19.10.2020Внесённые изменения:
  • Изменен раздел "2.5. Расписание торгов и клиринга".

  • Изменен раздел "2.4.3. Типы сделок, формируемые при исполнении и истечении фьючерсов и опционов".

  • Поток FORTS_TRADE_REPL:

    • В таблицах orders_log и multileg_orders_log поле local_stamp объявляется устаревшим и будет удалено в версии 6.9.

  • Поток FORTS_DEALS_REPL:

    • В таблицу deal добавлены поля xstatus_buy и xstatus_sell.

    • В таблицу multileg_deal добавлены поля xstatus_buy и xstatus_sell.

  • Поток FORTS_USERORDERBOOK_REPL:

    • В таблицу info добавлено поле publication_state.

  • Поток FORTS_ORDBOOK_REPL:

    • В таблицу info добавлено поле publication_state.

  • Поток FORTS_REFDATA_REPL:

    • В таблицу user добавлено поле password_expiration_date.

  • Изменения в репозитории схем подачи команд:

    • Обновленная команда установки клиентских лимитов ChangeClientMoney (msgid=458).

    • Удалены следующие устаревшие команды: FutAddOrder, OptAddOrder, FutAddMultilegOrder, FutDelOrder, OptDelOrder, FutMoveOrder, OptMoveOrder, FutDelUserOrders, OptDelUserOrders, FutChangeClientMoney, FutChangeBFMoney, FutExchangeBFMoney, FutTransferClientPosition, OptTransferClientPosition, FutChangeBFLimit.

    • Команда OptChangeRiskParameters переименована в OptChangeRiskParametersNextSession.

    • В командах поле local_stamp объявляется устаревшим и будет удалено в версии 6.9.

  • Добавлены новые коды ошибок: 300-307, 4175.

  • Изменены тексты кодов ошибок 4006-4011, 4017.

17.08.2020Внесённые изменения:
  • Добавлен раздел "2.3.5. Айсберг-заявки".

  • В раздел "2.4.3. Типы сделок, формируемые при исполнении и истечении фьючерсов и опционов" добавлено описание новых флагов:

    • eIceberg (0x800000000000) - признак айсберг-заявки, сделки по айсберг-заявке

    • eSynthetic (0x200000000000) - признак синтетической заявки

    • eOperatorInputSA (0x1000000000000) - блокировка по Расчетному коду

  • Изменен раздел "2.6.9. Поддержка отрицательных цен в SPECTRA".

  • Добавлен раздел "2.9. Синтетический матчинг".

  • Добавлен новый поток FORTS_TRADE_REPL - объединение FORTS_FUTTRADE_REPL и FORTS_OPTTRADE_REPL.

  • Потоки FORTS_FUTTRADE_REPL и FORTS_OPTTRADE_REPL в версии СПЕКТРА 6.5 объявляются устаревшими, изменения следует смотреть в описании FORTS_TRADE_REPL.

  • Поток FORTS_TRADE_REPL:

    • В таблицу orders_log добавлены поля public_order_id, public_amount, public_amount_rest, public_action, private_order_id, private_amount, private_amount_rest, variance_amount, private_action, disclose_const_amount.

    • В таблицу multileg_orders_log добавлены поля public_order_id, public_amount, public_amount_rest, public_action, private_order_id, private_amount, private_amount_rest, variance_amount, private_action, disclose_const_amount.

    • В таблицу user_deal добавлены поля public_order_id_buy, public_order_id_sell, private_order_id_buy, private_order_id_sell.

    • В таблицу user_multileg_deal добавлены поля public_order_id_buy, public_order_id_sell, private_order_id_buy, private_order_id_sell.

  • Добавлен новый поток FORTS_USERORDERBOOK_REPL - объединение FORTS_FUTORDERBOOK_REPL и FORTS_OPTORDERBOOK_REPL.

  • Потоки FORTS_FUTORDERBOOK_REPL и FORTS_OPTORDERBOOK_REPL в версии СПЕКТРА 6.5 объявляются устаревшими, изменения следует смотреть в описании FORTS_USERORDERBOOK_REPL.

  • Поток FORTS_USERORDERBOOK_REPL:

    • В таблицу orders добавлены поля public_order_id, public_amount, public_amount_rest, public_action, private_order_id, private_amount, private_amount_rest, variance_amount, private_action, disclose_const_amount, public_init_moment, public_init_amount, private_init_moment, private_init_amount.

  • В таблицах orders_log и multileg_orders_log потока FORTS_ORDLOG_REPL:

    • Поле id_ord переименовано в public_order_id.

    • Поле xamount переименовано в public_amount.

    • Поле xamount_rest переименовано в public_amount_rest.

    • Поле action переименовано в public_action.

  • В таблицах deal и multileg_deal потока FORTS_DEALS_REPL:

    • Поле id_ord_buy переименовано в public_order_id_buy.

    • Поле id_ord_sell переименовано в public_order_id_sell.

  • В таблице orders потока FORTS_ORDBOOK_REPL:

    • Поле id_ord переименовано в public_order_id.

    • Поле xamount переименовано в public_amount.

    • Поле xamount_rest переименовано в public_amount_rest.

    • Поле action переименовано в public_action.

    • Поле init_moment переименовано в public_init_moment.

    • Поле xinit_amount переименовано в public_init_amount.

  • Добавлен новый поток FORTS_COMMON_REPL - объединение FORTS_FUTCOMMON_REPL и FORTS_OPTCOMMON_REPL.

  • Потоки FORTS_FUTCOMMON_REPL и FORTS_OPTCOMMON_REPL в версии СПЕКТРА 6.5 объявляются устаревшими, изменения следует смотреть в описании FORTS_COMMON_REPL.

  • Поток FORTS_COMMON_REPL:

    • В таблице common изменено описание полей best_buy, xamount_buy, orders_buy_qty, xorders_buy_amount, best_sell, xamount_sell, orders_sell_qty, xorders_sell_amount.

    • В таблицу common добавлены поля best_buy_native, xamount_buy_native, xorders_buy_amount_native, best_sell_native, xamount_sell_native, xorders_sell_amount_native.

    • Из таблицы common удалены поля old_kotir и cur_kotir.

  • Потоки агрегированных стаканов:

    • Добавлены новые потоки FORTS_AGGR5_REPL, FORTS_AGGR20_REPL, FORTS_AGGR50_REPL - объединение соответствующих фьючерсных и опционных агрегированных потоков.

    • В таблице orders_aggr изменено описание поля volume и добавлено поле synth_volume.

  • Поток FORTS_CLR_REPL:

    • Из таблицы money_clearing удалено поле share.

    • Из таблицы fut_pos удалено поле account.

    • Из таблицы opt_pos удалено поле account.

  • Добавлен новый поток FORTS_REFDATA_REPL - объединение FORTS_FUTINFO_REPL и FORTS_OPTINFO_REPL.

  • Потоки FORTS_FUTINFO_REPL и FORTS_OPTINFO_REPL в версии СПЕКТРА 6.5 объявляются устаревшими, изменения следует смотреть в описании FORTS_REFDATA_REPL.

  • Поток FORTS_REFDATA_REPL:

    • Из таблицы fut_sess_contents удалены поля code_vcb, old_kotir, d_pg и last_cl_quote.

    • Из таблицы fut_vcb удалены поля code_vcb и is_foreign.

    • Из таблицы fut_instruments удалены поля code_vcb, old_kotir, d_pg, d_exp, exec_name и last_cl_quote.

    • Из таблицы dealer удалено поле go_ratio.

    • Из таблицы prohibition удалено поле code_vcb.

    • В таблицу fut_margin_type добавлено поле operator_input.

    • Из таблицы opt_sess_contents удалены поля code_vcb, old_kotir, d_pg, bgo_c, bgo_nc, bgo_buy и last_cl_quote.

    • Из таблицы opt_vcb удалено поле code_vcb.

    • В таблицу option_series добавлено поле m_bach.

  • Поток FORTS_INFO_REPL:

    • Из таблицы base_contracts_params удалено поле code_vcb.

    • Из таблицы futures_params удалены поля code_vcb, settl_price и settl_price_real.

    • Из таблицы investor удалено поле go_ratio.

    • Из таблицы dealer удалено поле go_ratio.

    • В таблицу option_series_params добавлено поле m_bach.

  • Поток FORTS_PART_REPL:

    • Из таблицы part удалены поля coeff_go, no_fut_discount и num_clr_2delivery.

  • Поток FORTS_RISKINFOBACH_REPL:

    • В таблицу volat_coeff добавлено поле m.

  • Изменения в репозитории схем подачи команд:

    • Добавлена новая команда AddOrder - объединяет FutAddOrder, OptAddOrder и FutAddMultilegOrder.

    • Добавлена новая команда DelUserOrders - объединяет FutDelUserOrders и OptDelUserOrders.

    • Добавлены новые команды IcebergAddOrder, IcebergDelOrder, IcebergMoveOrder - команды для управления айсберг-заявками.

    • Команда ChangeBFParameters переименована в ChangeBFParametersNextSession.

    • Команда ChangeBFClientDefaultParameters переименована в ChangeBFClientDefaultParametersNextSession.

  • Добавлены новые коды ошибок: 4174, 4258, 4259, 4260, 4261, 4262, 4264, 4266, 4268.

19.06.2020Внесённые изменения:
  • Добавлен раздел "2.6.9. Поддержка отрицательных цен в SPECTRA".

  • Добавлен новый поток FORTS_RISKINFOBLACK_REPL - Риск-параметры для модели Блэка-Шоулза.

  • Добавлен новый поток FORTS_RISKINFOBACH_REPL - Риск-параметры для модели Башелье. В релизе 6.4.20 в параметрах транслируется 0.

  • Поток FORTS_FUTCOMMON_REPL:

    • В таблицу common добавлено поле price_assigned_by_admin.

  • Поток FORTS_FUTINFO_REPL:

    • В таблицу fut_vcb добавлены поля negative_prices, option_model.

  • Поток FORTS_OPTINFO_REPL:

    • В таблицу opt_vcb добавлены поля negative_prices, option_model.

    • В таблицу option_series добавлены поля a-s_black, a-s_bach.

  • Поток FORTS_INFO_REPL:

    • В таблицу base_contracts_params добавлено поле option_model. Поля has_options и spot_price объявляются устаревшими и будут удалены в версии 6.6.

    • В таблицу futures_params добавлены поля attribute, mr_addon_up, mr_addon_down.

    • В таблицу option_series_params добавлены поля a-s_black, a-s_bach.

  • Поток FORTS_VOLAT_REPL:

    • В таблицу volat добавлено поле option_model.

15.01.2020Внесённые изменения:
  • Добавлен раздел "2.6.8. Блокировка брокерской части клиентского сбора".

  • Добавлен новый поток FORTS_BROKER_FEE_REPL - Брокерские комиссии.

  • Добавлен новый поток FORTS_BROKER_FEE_PARAMS_REPL - Параметры для расчета брокерской комиссии.

  • Поток FORTS_PART_REPL:

    • В таблицу part добавлено поле broker_fee.

  • Поток FORTS_OPTCOMMON_REPL:

    • В таблицу common добавлено поле total_premium_volume.

  • Изменения в репозитории схем подачи команд:

    • Удалена команда FutChangeBFParameters.

    • Добавлена новая команда SetBrokerFeeParamNextSession - Установка параметров для расчета брокерской комиссии.

  • Добавлены новые коды ошибок: 3000.

10.12.2019Внесённые изменения:
  • Внесены изменения в раздел "3.1.3. Установка ПО в среде Windows".

12.09.2019Внесённые изменения:
  • Добавлен раздел "3.3.10. Типы потоков данных". В описания потоков добавлен тип, к которому они относятся.

31.08.2019Внесённые изменения:
  • Добавлен раздел "3.3.9. Партиционирование матчинга".

  • В раздел "2.4.3. Типы сделок, формируемые при исполнении и истечении фьючерсов и опционов" добавлено описание двух новых флагов, которые проставляются в заявках и сделках: eActiveSide (0x20000000000), ePassiveSide (0x40000000000).

  • Поток FORTS_FUTINFO_REPL:

    • Добавлена таблица instr2matching_map.

  • Поток RTS_INDEX_REPL:

    • Из таблицы rts_index удалены устаревшие поля prev_close_value, open_value, max_value, min_value.

  • Изменения в репозитории схем подачи команд:

    • Добавлены новые команды DelOrder, MoveOrder, ChangeClientParameters.

    • В командах ChangeBFParameters и ChangeClientParametersNextSession у полей calendar_spread_margin_type и ics_margin_type тип поля i4 изменен на i1.

  • Добавлены новые коды ошибок 78, 79, 4269.

20.06.2019Внесённые изменения:
  • Поток FORTS_FUTTRADE_REPL:

    • Из таблицы orders_log удалены поля hedge и trust.

    • Из таблицы multileg_orders_log удалены поля hedge и trust.

    • Из таблицы user_deal удалены поля trust_buy, trust_sell, hedge_buy, hedge_sell.

    • Из таблицы user_multileg_deal удалены поля isin_id_repo, buyback_amount, trust_buy, trust_sell, hedge_buy, hedge_sell.

  • Поток FORTS_OPTTRADE_REPL:

    • Из таблицы orders_log удалены поля hedge и trust.

    • Из таблицы user_deal удалены поля trust_buy, trust_sell, hedge_buy, hedge_sell.

  • Из таблицы multileg_deal потока FORTS_DEALS_REPL удалено поле buyback_amount.

  • Из таблицы adjusted_fee потока FORTS_FEE_REPL удалено поле id_repo.

  • Поток FORTS_FUTORDERBOOK_REPL / FORTS_OPTORDERBOOK_REPL:

    • Из таблицы orders удалены поля hedge и trust.

  • Поток FORTS_FUTCOMMON_REPL:

    • Из таблицы common удалено поле cur_kotir_real, и добавлены в таблицу поля settlement_price_open и market_price.

  • Поток FORTS_OPTCOMMON_REPL:

    • В таблицу common добавлено поле settlement_price_open.

  • Поток FORTS_FUTINFO_REPL:

    • Добавлена таблица clearing_members.

    • Из таблицы fut_sess_contents удалены поля d_exp и price_dir, и добавлены в таблицу поля base_contract_code, settlement_price_open, settlement_price, last_trade_date.

    • В таблицу fut_vcb добавлены поля base_contract_code, signs.

    • Из таблицы fut_instruments удалено поле price_dir, и добавлены в таблицу поля base_contract_code, settlement_price_open, settlement_price, last_trade_date, d_exp_start, series_type.

    • В таблицу prohibition добавлено поле base_contract_code.

    • В таблицу dealer добавлены поля coeff_im, short_option_minimum_charge_ratio, ics_margin_type.

    • В таблицу investor добавлены поля is_blank, short_option_minimum_charge_ratio, ics_margin_type, coeff_im, no_fut_discount, num_clr_2delivery, exp_weight.

  • Поток FORTS_OPTINFO_REPL:

    • В таблицу opt_sess_contents добавлены поля base_contract_code, settlement_price_open, base_im_covered_sell, base_im_sell, last_trade_date, base_im_buy, settlement_price.

    • В таблицу opt_vcb добавлено поле base_contract_code.

    • В таблицу option_series добавлено поле signs.

  • Поток FORTS_CLR_REPL:

    • В таблицы money_clearing и money_clearing_sa добавлено поле asset_type.

    • В таблицу fut_pos добавлено поле account_type.

    • В таблицу opt_pos добавлено поле account_type.

    • Из таблицы pledge_details удалено поле com_ensure.

  • Поток FORTS_VM_REPL:

    • Из таблиц fut_vm, opt_vm, fut_vm_sa, opt_vm_sa удалено поле vm_real.

  • Поток FORTS_INFO_REPL:

    • Добавлена таблица multileg_dictionary.

    • Из таблицы base_contracts_params удалено поле is_usd, и добавлены в таблицу поля base_contract_code, window_size.

    • В таблицу futures_params добавлены поля base_contract_code, settlement_price, risk_range_center.

    • Удалена таблица virtual_futures_params.

    • В таблицу investor добавлены поля is_blank, coeff_im, short_option_minimum_charge_ratio, ics_margin_type.

    • В таблице investor поле n_clr_2delivery переименовано в num_clr_2delivery.

    • В таблицу dealer добавлены поля coeff_im, short_option_minimum_charge_ratio, ics_margin_type.

  • Изменения в репозитории схем подачи команд:

    • В командах FutAddOrder, OptAddOrder удалены поля du, hedge.

    • В команде FutChangeBFMoney удалено поле limit_pledge.

    • В команде FutExchangeBFMoney удалено поле amount_pledge.

    • В команде FutAddMultiLegOrder удалены поля price, hedge, trust, trade_mode, поле rate_price переименовано в swap_price.

    • В командах FutDelUserOrders, OptDelUserOrders, FutChangeClientProhibit, OptChangeClientProhibit поле code_vcb переименовано в base_contract_code.

    • Добавлены новые команды ChangeClientMoney, ChangeBFMoney, ExchangeBFMoney, ChangeBFLimit, ChangeBFParameters, TransferClientPosition, ChangeClientParametersNextSession.

    • Команда FutChangeBFClientDefaultParameters переименована в ChangeBFClientDefaultParameters.

    • В команду OptChangeRiskParameters добавлено поле short_option_minimum_charge_ratio - "Индивидуальный коэффициент веса сценария SOMC".

  • Добавлены новые коды ошибок 77, 4225.

14.01.2019Внесённые изменения:
  • В таблицу fut_vcb потока FORTS_FUTINFO_REPL добавлено поле base_contract_id.

  • В таблицу opt_vcb потока FORTS_OPTINFO_REPL добавлено поле base_contract_id.

05.12.2018Внесённые изменения:
  • Добавлены разделы "2.7. Разделение статусов участников торгов и участников клиринга" и "3.3.8. Смена пароля доступа в торговую систему".

  • В команды FutAddOrder, FutAddMultiLegOrder, FutDelOrder, FutMoveOrder, OptAddOrder, OptDelOrder, OptMoveOrder добавлено поле ncc_request - признак "Запрос к НКЦ на заключение сделок с участником торгов". А также изменены идентификаторы этих команд.

  • Добавлены команды DelOrdersByBFLimit и ChangePassword.

  • В команде OptRecalcCS поле isin_id заменено на option_series_id, а также изменен идентификатор команды.

  • Добавлены новые коды ошибок 682, 4168, 4169, 4170, 4171, 4172, 4173, 4221, 4222, 4223, 4224, 4230.

  • Поток FORTS_OPTINFO_REPL:

    • Добавлена таблица option_series.

    • В таблице opt_sess_contents удалены поля is_limited, limit_up, limit_down, exch_pay и добавлено поле option_series_id.

  • Поток FORTS_FUTINFO_REPL:

    • Удалены таблицы diler и investr.

    • В таблицу dealer добавлены поля firm_id и tm_name.

    • Из таблицы fut_sess_contents удалены поля is_limited и exch_pay, и добавлены в таблицу поля d_exp_start и d_exp_end.

    • Из таблицы fut_instruments удалены поля is_limited, volat_min, volat_max, is_limit_opt, limit_up_opt, limit_down_opt, adm_lim, adm_lim_offmoney и apply_adm_limit.

  • Поток FORTS_MM_REPL:

    • В таблице cs_mm_rule поле isin_id переименовано в option_series_id.

  • Поток FORTS_MISCINFO_REPL:

    • В таблице volat_coeff поле isin_id переименовано в option_series_id.

  • Поток FORTS_INFO_REPL:

    • В таблице option_series_params поле isin переименовано в small_name, поле exp_date переименовано в expiration_date, и добавлены поля option_series_id и underlying_id.

    • Из таблицы base_contracts_params удалено поле currency_volat.

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Внесённые изменения:
  • Изменены описания полей is_cupon в таблицах fut_bond_nkd и fut_bond_nominal

  • Переименована таблица fut_bond_nkd.

26.07.2018Добавлен новый код ошибки 4220.
26.07.2018Внесённые изменения:
  • Поток FORTS_CLR_REPL:

    • Из таблиц fut_pos, opt_pos, fut_pos_sa, opt_pos_sa удалены поля pos_beg, pos_end

    • из таблицы pledge_details удалены поля amount_beg, pay, amount, amount_beg_money, pay_money, amount_money.

  • Поток FORTS_DEALS_REPL:

    • из таблицы deal удалены поля pos, amount.

    • из таблицы multileg_deal удалено поле amount.

  • Поток FORTS_FUTCOMMON_REPL: из таблицы common удалены поля amount_buy, orders_buy_amount, amount_sell, orders_sell_amount, amount, contr_count, pos.

  • Поток FORTS_OPTCOMMON_REPL: из таблицы common удалены поля amount_buy, orders_buy_amount, amount_sell, orders_sell_amount, amount, contr_count, pos.

  • Поток FORTS_MM_REPL: из таблиц fut_MM_info и opt_MM_info удалены поля amount_sells, amount_buys, mm_amount.

  • Поток FORTS_OPTINFO_REPL:

    • из таблицы opt_rejected_orders удалено поле amount

    • из таблицы opt_exp_orders удалены поля amount, amount_apply

  • Поток FORTS_ORDLOG_REPL: из таблиц orders_log и multileg_orders_log удалены поля amount, amount_rest, status.

  • Поток FORTS_POS_REPL: из таблиц position и position_sa удалены поля pos, buys_qty, sells_qty, open_qty.

  • Поток FORTS_FUTINFO_REPL:

    • из таблицы fut_rejected_orders удалено поле amount

    • добавлены таблицы user, sma_master, sma_pre_trade_check

    • удалена таблица fut_sess_settl

    • в таблицу fut_margin_type добавлено поле type

    • изменены описания полей UCP_type и prohibit_coeff.

  • Поток FORTS_INFO_REPL:

    • удалена таблица opt_sess_settl

    • добавлены таблицы sma_master, sma_pre_trade_check

    • из таблицы opt_vcb удалено поле min_vol.

  • Поток FORTS_FUTTRADE_REPL:

    • в таблицы orders_log и multileg_orders_log добавлено поле aspref

    • из таблиц orders_log и multileg_orders_log удалены поля amount, amount_rest, status

    • из таблицы user_deal удалены поля pos, amount, status_buy, status_sell

    • из таблицы user_multileg_deal удалены поля amount, status_buy, status_sell.

  • Поток FORTS_OPTTRADE_REPL:

    • в таблицу orders_log добавлено поле aspref

    • из таблицы orders_log удалены поля amount, amount_rest, status

    • из таблицы user_deal удалены поля pos, amount, status_buy, status_sell.

  • Поток FORTS_ORDBOOK_REPL:

    • В таблицу orders добавлено поле aspref

    • Из таблицы orders удалены поля status, amount, amount_rest, init_amount.

  • Потоки FORTS_FUTORDERBOOK_REPL/FORTS_OPTORDERBOOK_REPL:

    • В таблицу orders добавлено поле aspref

    • Из таблицы orders удалены поля status, amount, amount_rest, init_amount.

  • Поток RTS_INDEX_REPL: в таблицу rts_index добавлены поля value_highprec, prev_close_value_highprec, open_value_highprec, max_value_highprec, min_value_highprec.

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Внесённые изменения:
  • В таблицу dealer потока FORTS_FUTINFO_REPL добавлено поле signs.

  • В таблицу virtual_futures_params потока FORTS_INFO_REPL добавлены поля strike_step, exp_clearings_bf и exp_clearings_cc.

  • В таблицу futures_params потока FORTS_INFO_REPL добавлено поле lot.

  • В таблицу base_contracts_params потока FORTS_INFO_REPL добавлены поля has_options, msp_type и currency_id.

  • В поток FORTS_INFO_REPL добавлены таблицы currency_params и common_params.

28.02.2018Из потока FORTS_FORECASTIM_REPL удалена таблица part_forecast.
26.02.2018Внесённые изменения:
  • Из таблицы fut_vcb потока FORTS_FUTINFO_REPL удалены поля client_code, exch_pay, exch_pay_scalped, clear_pay, clear_pay_scalped, exch_pay_spot, exch_pay_spot_repo, sell_fee и buy_fee.

  • Из таблицы opt_vcb потока FORTS_OPTINFO_REPL удалены поля client_code, exch_pay, exch_pay_scalped, clear_pay, clear_pay_scalped, is_spec, spec_spread, sell_fee и buy_fee.

21.02.2018Добавлены новые коды ошибок: 4148, 4149.

Изменено описание кодов ошибок: 4127, 4138

20.02.2018Внесённые изменения:
  • Добавлено описание команды FutChangeBFLimit.

  • В таблицу part_sa потока FORTS_PART_REPL добавлены поля money_blocked и vm_reserve.

31.01.2018Внесённые изменения:
  • Из таблицы money_clearing потока FORTS_CLR_REPL удалено поле ext_reserve.

  • Из таблиц fut_sess_contents и fut_instruments потока FORTS_FUTINFO_REPL удалено поле coeff.

  • В таблице fut_bond_registry потока FORTS_FUTINFO_REPL изменён тип поля bond_type на i4.

  • Из потока FORTS_FUTTRADE_REPL удалены таблицы deal и multileg_deal.

  • Из потока FORTS_OPTTRADE_REPL удалена таблица deal.

  • Из таблицы base_contracts_params потока FORTS_INFO_REPL удалено поле points_num. В эту же таблицу добавлены поля spot_price, mr1, mr2, mr3, lk1, lk2, risk_points_n.

  • Из таблицы futures_params потока FORTS_INFO_REPL удалены поля limit и spot_signs. В эту же таблицу добавлены поля interest_rate_risk_up, interest_rate_risk_down, time_to_expiration, normalized_spot.

  • Из таблицы virtual_futures_params потока FORTS_INFO_REPL удалены поля is_net_positive, volat_range, t_squared и max_addrisk. В эту же таблицу добавлены поля exp_clearings_sa, volatility_risk, volatility_risk_mismatch, time_to_expiration.

  • В таблицу sys_events потока FORTS_INFO_REPL добавлено поле server_time.

  • Из таблицы common потока FORTS_OPTCOMMON_REPL удалено поле isin_is_spec.

  • Из таблицы part потока FORTS_PART_REPL удалены поля pledge_free, pledge_blocked, coeff_liquidity, pledge_old, pledge_amount.

  • Из таблицы part_sa потока FORTS_PART_REPL удалены поля pledge_amount и liquidity_ratio. В эту же таблицу добавлены поля vm_intercl и fee.

  • Добавлено описание потока FORTS_FEERATE_REPL - Поток точных комиссий биржи.

  • Добавлено описание команд FutChangeBFParameters, FutChangeClientParameters и FutChangeBFClientDefaultParameters.

  • В таблицу diler потока FORTS_FUTINFO_REPL добавлены поля: exp_weight, num_clr_2delivery, margin_type, calendar_spread_margin_type, num_clr_2delivery_client_default, exp_weight_client_default, go_ratio, check_limit_on_withdrawal, limit_tied_money, limits_set, no_fut_discount, no_fut_discount_client_default.

  • В таблицу investr потока FORTS_FUTINFO_REPL добавлено поле calendar_spread_margin_type.

  • В поток FORTS_FUTINFO_REPL добавлены таблицы dealer и investor.

  • В поток FORTS_INFO_REPL добавлены таблицы dealer и investor.

26.12.2017Внесённые изменения:
  • В таблицу position потока FORTS_POS_REPL добавлено поле account_type

  • В поток FORTS_POS_REPL добавлена таблица position_sa.

21.12.2017Добавлены новые коды ошибок (4160 - 4166).
16.11.2017Изменено описание параметра code_vcb метода FutDelUserOrders.
25.10.2017Внесённые изменения:
  • Из потока FORTS_FUTINFO_REPL удалена таблица delivery_report

  • В таблицу fut_rejected_orders потока FORTS_FUTINFO_REPL добавлено поле xamount

  • В таблицы opt_rejected_orders и opt_exp_orders потока FORTS_OPTINFO_REPL добавлено поле xamount

  • В таблицу opt_exp_orders потока FORTS_OPTINFO_REPL добавлено поле xamount_apply.

24.10.2017Внесённые изменения:
  • В таблицу fut_MM_info потока FORTS_MM_REPL добавлены поля xamount_sells, xamount_buys, xmm_amount

  • В таблицу opt_MM_info потока FORTS_MM_REPL добавлены поля xamount_sells, xamount_buys, xmm_amount

28.08.2017

В сообщениях OptChangeExpiration, FutTransferClientPosition, OptTransferClientPosition изменены тип сообщения и тип поля amount.

23.06.2017Удалён поток RTS_INDEXLOG_REPL.
02.06.2017Внесенные изменения:
  • В таблицу multileg_dict потока FORTS_FUTINFO_REPL добавлено поле leg_order_no.

  • В таблицу fut_margin_type потока FORTS_FUTINFO_REPL добавлены поля UCP_type, prohibit_coeff, prohibit_type.

18.05.2017Внесенные изменения:
  • В таблицы fut_pos, opt_pos, fut_pos_sa и opt_pos_sa потока FORTS_CLR_REPL добавлены поля xpos_beg и xpos_end.

  • В таблицу pledge_details потока FORTS_CLR_REPL добавлены поля xamount_beg, xpay, xamount, xamount_beg_money, xpay_money, xamount_money.

15.05.2017Внесенные изменения:
  • В таблицы common потоков FORTS_FUTCOMMON_REPL и FORTS_OPTCOMMON_REPL добавлены поля xamount_buy, xorders_buy_amount, xamount_sell, xorders_sell_amount, xamount, xcontr_count, xpos.

  • В таблицы orders потоков FORTS_ORDBOOK_REPL, FORTS_FUTORDERBOOK_REPL и FORTS_OPTORDERBOOK_REPL добавлены поля xamount, xamount_rest, xinit_amount.

  • В таблицу position потока FORTS_POS_REPL добавлены поля xpos, xbuys_qty, xsells_qty, xopen_qty.

05.05.2017

Внесенные изменения:

  • В таблицу deal потока FORTS_DEALS_REPL добавлены поля xpos и xamount.

  • В таблицу multileg_deal потока FORTS_DEALS_REPL добавлено поле xamount.

  • В таблицу orders_log потока FORTS_FUTTRADE_REPL добавлены поля xamount и xamount_rest.

  • В таблицу multileg_orders_log потока FORTS_FUTTRADE_REPL добавлены поля xamount и xamount_rest.

  • В таблицу deal потока FORTS_FUTTRADE_REPL добавлены поля xpos и xamount.

  • В таблицу multileg_deal потока FORTS_FUTTRADE_REPL добавлено поле xamount.

  • В таблицу user_deal потока FORTS_FUTTRADE_REPL добавлены поля xpos и xamount.

  • В таблицу user_multileg_deal потока FORTS_FUTTRADE_REPL добавлено поле xamount.

  • В таблицу orders_log потока FORTS_OPTTRADE_REPL добавлены поля xamount и xamount_rest.

  • В таблицу deal потока FORTS_OPTTRADE_REPL добавлены поля xpos и xamount.

  • В таблицу user_deal потока FORTS_OPTTRADE_REPL добавлены поля xpos и xamount.

  • В таблицу orders_log потока FORTS_ORDLOG_REPL добавлены поля xamount и xamount_rest.

  • В таблицу multileg_orders_log потока FORTS_ORDLOG_REPL добавлены поля xamount и xamount_rest.

24.03.2017

Внесенные изменения:

  • В таблице fut_vcb потока FORTS_FUTIINFO_REPL поля exch_pay, exch_pay_scalped, clear_pay, clear_pay_scalped, sell_fee, buy_fee, exch_pay_spot, exch_pay_spot_repo, client_code заполняются значениями по умолчанию (нули, пустые строки).

  • В таблице opt_vcb потока FORTS_OPTINFO_REPL поля exch_pay, exch_pay_scalped, clear_pay, clear_pay_scalped, sell_fee, buy_fee, is_spec, spec_spread, client_code заполняются значениями по умолчанию (нули, пустые строки).

28.12.2016

Внесенные изменения:

  • Добавлен раздел "Поток FORTS_FORECASTIM_REPL - Прогноз рисков после возможной раздвижки".

  • Из таблицы part потока FORTS_PART_REPL удалено поле exp_weight.

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

Внесенные изменения:

  • Удалено описание методов для работы со Спотами:

    • "FutChangeBrokerVcb - Изменение параметров БФ по БА";

    • "FutChangeClientVcb - Изменение клиентских параметров по БА";

    • "FutChangeMoney - Изменение лимита на покупку спотов по БФ".

  • В таблицу fut_instruments потока FORTS_FUTINFO_REPL добавлено поле exec_name (Признак срочности опциона).

  • Добавлено описание метода "OptChangeRiskParameters - Управление риск-параметрами опционов".

  • Из сообщения "FutChangeClientMoney - Изменение клиентских лимитов" удалено поле num_clr_2delivery. Для старых версий сообщений это поле будет игнорироваться в случае заполнения.

  • Добавлено описание метода "FutTransferRisk - Перенос риска".

  • Добавлены коды возврата: 75, 331, 339, 383, 4127, 4138, 4139, 4150-4155, 9999, 10000, 10001, 10004-10006.

  • В поток FORTS_FUTINFO_REPL добавлены таблицы fut_settlement_account и fut_margin_type.

  • В поток FORTS_PART_REPL добавлена таблица part_sa.

  • В поток FORTS_CLR_REPL добавлены таблицы: money_clearing_sa, fut_pos_sa, opt_pos_sa.

  • В поток FORTS_VM_REPL добавлены таблицы fut_vm_sa и opt_vm_sa.

  • В таблицу part потока FORTS_PART_REPL добавлены поля num_clr_2delivery и exp_weight.

  • Из таблицы part потока FORTS_PART_REPL удалено поле cal_exp_extra_risk.

  • В таблицу virtual_futures_params потока FORTS_INFO_REPL добавлены поля exp_clearings_bf и exp_clearings_cc.

  • Из таблицы virtual_futures_params потока FORTS_INFO_REPL удалены поля allow_use_extra_exp_risk и calc_extra_exp_risk.

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

Добавлены новые поля:

  • fulfil_min - процент минимального исполнения обязательств за торговую сессию

    fulfil_partial - процент частичного исполнения обязательств за торговую сессию

    fulfil_total - процент полного исполнения обязательств за торговую сессию

    is_fulfil_min - признак минимального исполнения обязательств в текущий момент

    is_fulfil_partial - признак частичного исполнения обязательств в текущий момент

    is_fulfil_total - признак полного исполнения обязательств в текущий момент

в таблицы fut_MM_info, opt_MM_info потока FORTS_MM_REPL

31.05.2013

Добавлено новое поле:

  • rate_id - Идентификатор курса

в таблицу clr_rate потока FORTS_CLR_REPL

18.04.2013

Добавлен анонимный поток orderbook:

  • FORTS_ORDBOOK_REPL

Добавлено поле:

  • ext_reserve - Дополнительный резерв

в таблицу money_clearing потока FORTS_CLR_REPL

Удален поток FORTS_CLMONEY_REPL

12.04.2013

Добавлено новое поле:

  • exch_pay - Биржевой сбор за 1 контракт в рублях

в таблицу fut_sess_contents потока FORTS_FUTINFO_REPL

10.04.2013

Добавлено новое поле:

  • exch_pay - Биржевой сбор за 1 контракт в рублях

в таблицу opt_sess_contents потока FORTS_OPTINFO_REPL

26.03.2013

Добавлено новое поле:

  • rate_id - Идентификатор курса

в таблицы fut_vcb и opt_vcb потоков FORTS_FUTINFO_REPL и FORTS_OPTINFO_REPL

Добавлен поток репликации:

  • MOEX_RATES_REPL - Курсы валют он-лайн

Добавлена новая таблица:

  • rates - Справочник курсов валют

в поток FORTS_FUTINFO_REPL

27.11.2012Изменение описания таблицы user_deal.
01.11.2012

Добавлено описание двух событий для таблицы sys_events.

30.10.2012Обновление документации:
  • В разделе "Метод FutChangeMoney - Изменение лимита на покупку спотов по БФ" дополнено описание параметра limit_spot_buy.

  • В разделах "Метод FutMoveOrder - Перемещение двух заявок" и "Метод OptMoveOrder - Перемещение двух заявок" дополнено описание логики работы команды MoveOrder.

22.10.2012Обновление документации:
  • Внесены изменения в разделы: "Пользователи. Привязка пользователя к участнику торгов", "Состав, установка и настройка ПО шлюз SPECTRA Plaza-2", "Рекомендации по включению рантаймов РТС в приложение пользователя при распространении пользовательского ПО сторонним компаниям", "Восстановление и поздний вход".

  • Удален раздел "Интерфейс технического центра ".

10.02.12Обновления документации:
  • В раздел "Особенности использования шлюза" добавлен пункт "Команды".

  • Добавлен раздел "Приостановка торгов для расширения лимита колебаний цен сделок".

  • Исправлена ошибка в описании формулы расчета цены фьючерса.

  • Обновлено описание инсталлятора шлюза.

09.02.2012

Добавлено новое поле:

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

в таблицы:

  • fut_rejected_orders - Отвергнутые в клиринг заявки

  • opt_rejected_orders - Отвергнутые в клиринг заявки

потоков:

  • FORTS_FUTINFO_REPL - Фьючерсы: справочная и сессионная информация

  • FORTS_OPTINFO_REPL - Опционы: справочная и сессионная информация

24.01.2012

В таблицу orders потоков:

  • FORTS_FUTORDERBOOK_REPL - Фьючерсы: Cрез стакана

  • FORTS_OPTORDERBOOK_REPL - Опционы: Cрез стакана

добавлены следующие поля:

  • init_moment - Время появления заявки

  • init_amount - Начальное количество в заявке

23.01.2012

Добавлена таблица событий sys_events в потоки:

  • FORTS_CLMONEY_REPL - Деньги в клиринг

  • FORTS_CLR_REPL - Клиринговая информация

17.01.2012

В таблицу fut_vcb потока FORTS_FUTINFO_REPL добавлено поле exch_pay_spot_repo, содержащее биржевой сбор по Репо

12.01.2012

Добавлен поток репликации:

  • FORTS_ORDLOG_REPL - поток, в котором передаются все действия с заявками в анонимном виде

02.11.2011

Добавлены новые поля:

  • Поле comment - Комментарий трейдера

  • Поле ext_id - Внешний номер

в таблицы:

  • fut_rejected_orders - Отвергнутые в клиринг заявки

  • opt_rejected_orders - Отвергнутые в клиринг заявки

25.11.2011Добавлен раздел "Использование тестовых примеров".
7.11.2011Ревизия документа. Доработаны разделы "Введение" и "Описание торгового шлюза". Добавлен раздел "Краткий обзор системы SPECTRA".
20.10.2011

Добавлены следующие поля:

  • Поле theor_price_limit - теоретическая цена опциона, рассчитанная исходя из котировки фьючерса, ограниченной лимитом

  • Поле vm_real, содержащее текущую ВМ по опционам, рассчитанную исходя из рыночной котировки опциона theor_price. При этим, значение в старом поле vm рассчитывается исходя из ограниченной котировки опциона theor_price_limit.

Добавлена таблица событий sys_events в потоки:

  • FORTS_FUTTRADE_REPL -- Фьючерсы: заявки и сделки

  • FORTS_OPTTRADE_REPL - Опционы: заявки и сделки

  • FORTS_POS_REPL - Информация о позициях

  • FORTS_PART_REPL - Информация о средствах и лимитах

  • FORTS_FUTINFO_REPL - Фьючерсы: справочная и сессионная информация

  • FORTS_OPTINFO_REPL - Опционы: справочная и сессионная информация

  • FORTS_INFO_REPL - Дополнительная справочная информация

4.10.2011

Добавлены потоки репликации:

  • FORTS_CLR_REPL - поток, транслирующий клиринговую информацию, в том числе информация о сборах и ВМ на момент клиринга, зафиксированные значения курсов валют, используемые для расчетов, а также расчетные цены клиринга

  • FORTS_MM_REPL - поток, содержащий информацию об обязательствах ММ в режиме он-лайн

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

14.09.2011

Исправлены ошибки в значениях по умолчанию некоторых команд: Если параметр является строковым - его значение по умолчанию берется в кавычки

15.04.2011

Добавлены следующие поля:

  • поле status таблицы diler потока FORTS_FUTINFO_REPL - информация по разделам РФ и БФ

  • поле status таблицы investr потока FORTS_FUTINFO_REPL - информация по клиентским разделам

  • поле vm_order_reserve потока FORTS_PART_REPL - резерв ВМ по заявкам

  • поле waprice потока FORTS_POS_REPL - средневзвешенная цена

Изменения в системе команды:

  • Важно: изменился формат команд FutAddOrder, OptAddOrder и FutAddMultilegOrder - в каждую из команд добавлен параметр dont_check_money. Изменились идентификаторы команд. Команды старого формата поддерживаются со старыми идентификаторами.

  • Добавлена команда FutExchangeBFMoney, предназначенная для выполнения переводов между БФ разделами

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

Исправлен ряд ошибок в именовании полей команд, а также значения по умолчанию некоторых команд:

  • Значение по умолчанию параметра ext_id для команды FutDelUserOrders установлено в 0.

  • Значения по умолчанию параметров comment, hedge, broker_to, ext_id, trust, date_exp для команды FutAddMultiLegOrder установлены в 0 или пустую строку в зависимости от типа сообщения.

  • Значение по умолчанию параметров price1 и price2 для команды OptMoveOrder установлены в 0.

  • Значение по умолчанию параметра no_fut_discount для команды FutChangeClientMoney установлено в 0.

  • Значение по умолчанию параметра limit_spot для команды FutChangeBrokerVcb установлено в -1.

  • В ответах команд FutChangeClientMoney, FutChangeBFMoney, FutChangeClientVcb и OptChangeExpiration поле Message исправлено на message для достижения единообразия с остальными командами.

.

26.11.2010

Изменен формат агрегированных стаканов - убрано поле price2. Теперь поле price принимает различный смысл в зависимости от значения признака 0x1000 инструмента (поле signs таблицы fut_sess_contents потока FORTS_FUTINFO_REPL): в случае установки признака поле price содержит ставку, иначе - своп-цену.

15.10.2010

Новые признаки инструмента (поле signs таблицы fut_sess_contents потока FORTS_FUTINFO_REPL):

  • 0x800 - признак инструмента RTS Money

  • 0x1000 - признак основной цены для составных инструментов (0 - котируется в своп-цене, 1 - котируется в ставке)

Новое значение признака составных инструментов 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)

Добавлены таблицы:

  • fut_sess_settl в поток FORTS_FUTINFO_REPL с расчетными ценами за прошедший клиринг
  • opt_sess_settl в поток FORTS_OPTINFO_REPL со значениями волатильности и теоретической цены опциона на момент клиринга

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

Добавлена информация о параметрах инструментов:

  • таблицы base_contracts_params, futures_params, virtual_futures_params, options_params

Добавлена информация о стоимости шага цены инструмента в вечерний клиринг – поле step_price_clr таблицы fut_sess_contents потока FORTS_FUTINFO_REPL, а также в пром. клиринг – поле step_price_interclr той же таблицы.

19.04.2010

Изменены типы многих полей, в частности:

  • объём агрегированных стаканов d16.5 -> i8
  • направление заявок i4 -> i1
  • признаки инструментов (signs) i1 -> i4

Таблица money_clearing перенесена из потока FORTS_FUTINFO_REPL в поток FORTS_CLMONEY_REPL.

Переименованы:

  • таблица repo_orders_log -> multileg_orders_log
  • таблица repo_deal -> multileg_deal
  • команда FutAddRepo -> FutAddMultiLegOrder

Добавлены:

  • таблица multileg_dict – справочник связок
  • поля price_dir, multileg_type, legs_qty таблицы fut_sess_contents
  • поля с идентификатором и ценой сделки в таблицы orders_log фьючерсную и опционную
  • поля fee_sell, fee_buy таблицы deal потока FORTS_OPTTRADE_REPL
  • потоки FORTS_FUTORDERBOOK_REPL и FORTS_OPTORDERBOOK_REPL с информацией о текущем состоянии стаканов
  • таблица broker_params потока FORTS_INFO_REPL
  • таблицы fut_instruments потока FORTS_FUTINFO_REPL
  • таблицы usd_online потока FORTS_FUTINFO_REPL

Удалены:

  • поле state таблицы opt_sess_contents

16.03.2010

Изменен описание команды FutAddRepo: • вместо параметра swap_price, теперь используется параметр repo_rate

24.02.2010

Добавлено:

  • описание таблиц repo_orders_log, repo_deals
  • описание статусов заявок и сделок Репо
  • описание новых статусов заявок и сделок
  • описание команды FutAddRepo
  • поле last_deal_id в таблицу position потока FORTS_POS_REPL

18.01.2010

  • Добавлено описание команд: FutChangeBrokerVcb, FutChangeClientProhibit, FutChangeMoney, OptChangeClientProhibit
  • Добавлено поле limits_set таблицы part потока FORTS_PART_REPL
  • Исправлен ряд ошибок в описании команд

15.01.2010

  • Изменены типы идентификаторов заявок и сделок (i4 -> i8)
  • Изменены типы статусов заявок и сделок (i2 -> i4)
  • Исправлен ряд ошибок в описании команд

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

Субъекты (участники) торгов

Субъекты (участники) торгов это:

  • Участники клиринга (Расчетные фирмы)

  • Участники торгов (Брокерские фирмы)

  • Клиенты участников торгов и участников клиринга

Обычно участник торгов и участник клиринга - это одно и то же лицо, он заключает сделки и является стороной по заключенным сделкам, ниже речь пойдет именно о таких участниках, однако, начиная с версии SPECTRA 6.2 на срочном рынке реализован проект по разделению статусов участников торгов и участников клиринга, где функции участников могут быть выделены в явном виде. Более подробно о разделении статусов участников можно ознакомиться в разделе 2.7. Разделение статусов участников торгов и участников клиринга. Обращаем внимание, что реализованный SPECTRA 6.2 проект по разделению статусов участников торгов и участников клиринга никоим образом не затрагивает существующих участников торгов, для них порядок организации торгов остается прежним.

Расчетные фирмы

Расчетные фирмы — это организации, непосредственно несущие ответственность и покрывающие риски своих клиентов и субброкеров.

Расчетные фирмы имеют возможности:

  • Совершать сделки от своего имени и за свой счет.

  • Совершать сделки от своего имени и за счет обслуживаемых клиентов.

  • Вести расчеты с НКЦ напрямую.

  • Обслуживать клиентов, в том числе и брокерские фирмы.

  • Контролировать работу клиентов и брокерских фирм в ходе торгов.

Расчетные фирмы несут обязательства:

  • Членство в Секции срочного рынка.

  • Взнос в Гарантийный фонд.

  • Гарантийное обеспечение собственных сделок и сделок своих клиентов.

Брокерские фирмы

В отличие от расчетных фирм, брокерские фирмы не рассчитываются по операциям напрямую с биржей, а рассчитываются со своей расчетной фирмой, для брокеров нет требований по наличию лицензий и по внесению средств в Гарантийный фонд.

Брокерские фирмы имеют возможности:

  • Совершать сделки за свой счет.

  • Совершать сделки за счет обслуживаемых клиентов.

  • Выставлять заявки в Торговой системе с клиентского терминала.

  • Контролировать работу своих клиентов в ходе торгов.

Брокерские фирмы несут обязательства:

  • Гарантийное обеспечение собственных сделок и сделок своих клиентов.

Клиенты

Любое юридическое и физическое лицо может принимать участие в торгах на рынке фьючерсов и опционов SPECTRA в качестве клиента. Для этого необходимо заключить договор на торговое обслуживание с брокерской фирмой или непосредственно с расчетной фирмой. Важным атрибутом клиента служит ИНН или номер паспорта.

Кодировка в системе

Участники торгов в системе кодируются с помощью семисимвольной строки вида:XXYYZZZ, где

  • XX — код расчетной фирмы

  • YY — код брокерской фирмы

  • ZZZ — код клиента

Код брокерской фирмы 00 предназначен для отражения состояния самой расчетной фирмы.

Пример 1.

Q100 – код для представления расчетной фирмы Q1

Q1DU – субброкер DU расчетной фирмы Q1


Код Клиента 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, т.к. составные части инструментов являются обычными инструментами торговой системы. Для каждой составной части также указывается коэффициент, на который умножается объём исходной заявки для получения объёма заявки по составной части. Знак этого коэффициента указывает на направление заявки по составляющей — положительное значение означает, что составляющая будет направлена в ту же сторону, что и заявка по составному инструменту, отрицательное — в противоположную сторону.

Рисунок 1. Составные инструменты

Составные инструменты

Идентификация инструментов

В системе SPECTRA инструмент имеет четыре идентификатора:

  1. Поле isin_id — уникальный числовой идентификатор инструмента в системе.

  2. Поле isin — символьный идентификатор инструмента.

  3. Поле short_isin — короткий символьный код инструмента для информационных систем.

  4. Поле 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 заявки, количество в операции, остаток, действие и др.):

  1. Публичные данные транслируются в полях с префиксом "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 - Номер видимой части айсберг-заявки продавца.

  2. Приватные данные транслируются в полях с префиксом "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_idpublic_ amountpublic_ amount_ restpublic_ actionpricemomentdirclient_ codeprivate_ order_idprivate_ amountprivate_ amount_ restprivate_ actioncomment
10110010013122019-01-11 11:55:581OD01123101100010001Add Iceberg
1021113122019-01-11 14:56:581PJ99888102111Add standard Order
10325025013102019-01-11 16:58:582FS010201032502501Add standard Order
101100023122019-01-11 16:58:581OD011231011009002Match Iceberg
10310015023102019-01-11 16:58:582FS010201031001502Match standard Order
1021023122019-01-11 16:58:581PJ99888102102Match standard Order
103114923102019-01-11 16:58:582FS0102010311492Match standard Order
10410010013122019-01-11 16:58:581OD011231011009003Pop-up Iceberg
104100023122019-01-11 16:58:581OD011231011008002Match Iceberg
1031004923102019-01-11 16:58:582FS01020103100492Match standard Order
10510010013122019-01-11 16:58:581OD011231011008003Pop-up Iceberg
105495123122019-01-11 16:58:581OD01123101497512Match Iceberg
10349023102019-01-11 16:58:582FS010201034902Match standard Order
10551003122019-01-11 17:00:581OD0112310175100Cancel 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_idpublic_ amountpublic_ amount_ restpublic_ actionid_ordxamountxamount_ restactionprivate_ order_idprivate_ amountprivate_ amount_ restprivate_ actioncomment
1011001001101100010001101100010001Add Iceberg
102111102111102111Add Order
103250250110325025011032502501Add Order
1011000210110090021011009002Match Iceberg
103100150210310015021031001502Match Order
102102102102102102Match Order
103114921031149210311492Match Order
104100100110110090031011009003Pop-up Iceberg
1041000210110080021011008002Match Iceberg
103100492103100492103100492Match Order
105100100110110080031011008003Pop-up Iceberg
10549512101497512101497512Match Iceberg
103490210349021034902Match Order
10551001017510010175100Cancel 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_idpublic_actionprivate_order_idprivate_actionid_ord1
Добавление10011001 
Сведение в сделку10021002 
Всплытие новой части10511003 
Перевыставление в ВК1106111061100
Передвижка (move)1106011060100
1200112001 

Пояснения к таблице:

  • Добавление - добавляется айсберг-заявка (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)

Исполнение всех поставочных фьючерсных контрактов производится путём автоматического заключения сделок Т+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 (В текущей версии данный сервис недоступен)

Сервис TAS (Trade at Settlement) - это возможность купить или продать фьючерсный контракт по будущей расчетной цене текущего торгового дня, определяемой в вечерний клиринг, плюс некий спред, который участник готов заплатить/уступить дополнительно от расчетной цены контракта. Именно спред является соглашением контрагентов в сделке и указывается в заявке TAS в качестве цены. Технически TAS в торговой системе реализован как обычный фьючерсный контракт с указанием спреда TAS в качестве цены в заявке (TAS-фьючерс), базисным активом (БА-фьючерсом) которого служит искомый фьючерсный контракт (фьючерс на фьючерс). Совершая сделку по заявке с указанием спреда TAS, участник получает позицию по TAS-фьючерсу.

Расчет сделки по заявке с указанием спреда TAS осуществляется в вечернюю клиринговую сессию. В результате позиция по TAS-фьючерсу превращается в позицию по БА-фьючерсу, что технически оформляется технической сделкой закрытия позиции в TAS-фьючерсе по цене 0 и сделкой открытия позиции в БА-фьючерсе по расчетной цене БА-фьючерса. Сделки в таблице сделок помечаются специальным признаком в полях xstatus_sell и xstatus_buy (бит 0x10000 (TASSettlement) - Расчет сделки по заявке с указанием спреда TAS).

Признаки, выставляемые у заявок и сделок

Признаки, выставляемые у заявок и сделок:

Наименование признакаБитовая маскаОписание
Типы рыночных заявок
Auction0x1Котировочная заявка (Day).
Opposite0x2Встречная заявка (IOC).
FOK0x80000Заявка Fill-or-Kill (FOK).
BOC0x1000000000000000Заявка Book-or-Cancel (BOC).
Типы клиринговых сделок
NonQuote0x4Признак заявки/сделки, которая не участвует в расчете котировок. Признак выставляется в адресных заявках и сделках, технических сделках, клиринговых сделках, сделках по ногам мультилегов и сделках RFS.
Exec0x20Сделка, возникшая в результате исполнения опциона. Флаг ставится для опционных сделок и для фьючерсных сделок, которые появились в результате экспирации опционов.
Expiration0x80Истечение времени жизни инструмента, фьючерса или опциона.
DUFlow0x800Сделка переноса ДУ между РФ.
TASSettlement0x10000Расчет сделки по заявке с указанием спреда TAS. (В текущей версии недоступно)
OptionLapse0x800000Сделка истечения опциона.
ClearingTrade0x2000000Техническая клиринговая сделка, сформированная вне торгов. Выставляется у всех клиринговых сделок.
FuturesExecution0x40000000Сделка исполнения фьючерса.
CollateralInstrument0x400000000Сделка по коллатеральному инструменту.
PerpetualFuturesExecutionVoluntary0x10000000000000Техническая сделка вследствие добровольного выхода из вечного фьючерса (на основании поданного поручения).
PerpetualFuturesExecutionForced0x400000000000000Техническая сделка вследствие принудительного выхода из вечного фьючерса (реализация неудовлетворённого спроса).
PerpetualFuturesExecution0x800000000000000Техническая сделка в связанном инструменте вследствие выхода из вечного фьючерса.
Адресные заявки и сделки
TransferClientPosition0x8Признак переноса позиций между БФ.
Address0x4000000Признак адресной заявки, адресной сделки, сделки RFS или заявки, формируемой по результатам проверки котировок RFS.
NegotiatedMatchByRef0x80000000Признак заявки или сделки, сформированной в режиме "Адресный с мэтчингом по уникальному коду".
TransferSource0x200000000Признак источника переноса позиций между БФ.
Операции над связками
REPOBack0x4000Признак операции над второй ногой связки.
Strategy0x8000000Признак заявки или сделки по связке. Ставится у операций над ногами связки.
Другое
DontCheckMoney0x10Не проверять обеспечение по клиентскому уровню.
ExternalUseEveningExecution0x100Признак заявки или сделки в вечернюю сессию.
DontCheckLimits0x200Не проверять лимиты по опционам.
Charge0x400Конец логической транзакции. Флаг ставится ядром на заявки, чтобы по ордер логу можно было получить число (и границы) транзакций, то есть последовательности заявок, порожденных одной транзакцией.
LastRec0x1000Признак последней записи в транзакции матчинга.
DueToCrossCancel0x2000Признак снятия пассивной заявки при кросс-сделке.
MoveOperation0x100000Признак передвижки заявки.
DeleteOperation0x200000Признак одиночного удаления заявки.
BulkDeleteOperation0x400000Признак группового удаления заявок.
OppositeOrderTailDeleteDueToCrossTrade0x20000000Признак удаления остатка IOC-заявки по причине кросс-сделки.
CODBulkDeleteOperation0x100000000Признак операции удаления заявки сервисом Cancel On Disconnect.
FineOperation0x1000000000Проставляется при снятии заявки в результате штрафа в RFS.
UKSBulkDeleteOperation0x2000000000Признак снятия заявок по команде UserKillSwitch
NCCRequest0x4000000000Признак того, что операция является следствием подачи поручения НКЦ
NCCBulkDeleteOperation0x8000000000Признак снятия заявок по команде DelOrdersByBFLimit
LiqNettingRF0x10000000000Признак заявки или сделки, сформированной в процессе ликвидационного неттинга.
ActiveSide0x20000000000Активная сторона в сделке. Заявка, приведшая к сделке при добавлении в стакан.
PassiveSide0x40000000000Пассивная сторона в сделке. Заявка из стакана, участвующая в сделке.
Synthetic0x200000000000Признак синтетической заявки и стороны сделки, соответствующей этой синтетической заявке.
RFSOrder0x400000000000Заявка из системы RFS.
Iceberg0x800000000000Признак айсберг-заявки, сделки по айсберг-заявке.
OperatorInputSA0x1000000000000Признак заявки или сделки, сформированной при блокировке по Расчетному коду.
DontFineRF0x80000000000000Признак невзимания штрафа за сделки урегулирования.
MorningSession0x100000000000000Признак того, что сделка совершена в утреннюю торговую сессию.
SyntheticPassive0x200000000000000Признак пассивной синтетической заявки.
DuringDiscreteAuction0x4000000000000000Признак заявки или сделки в аукционе открытия.

Для отличия адресных сделок от сделок, формируемых по результатам проверки котировок 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).

Типы сделок, формируемые при исполнении и истечении фьючерсов и опционов

Типы сделок, формируемые при исполнении и истечении фьючерсов и опционов, перечислены в следующей таблице:

Тип операцииСделка закрытия позицииСделка открытия позицииДата и время, когда сделки появятся в отчете и шлюзе
Исполнение поставочного фьючерса
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до минимального шага цены.

  • Техническая сделка, юридически не является сделкой.

  • В шлюзах и отчётах в битовой маске признаки: NonQuote, Expiration, FuturesExecution, ClearingTrade.

НетУтром в день исполнения
Исполнение расчетного фьючерса
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до 5 знака после запятой.

  • Техническая сделка, юридически не является сделкой.

  • В шлюзах и отчётах в битовой маске признаки: NonQuote, Expiration, FuturesExecution, ClearingTrade.

НетВечером в день исполнения фьючерса
Исполнение поставочного опциона
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки равна 0.

  • Техническая сделка, юридически не является сделкой.

  • В шлюзах и отчётах в битовой маске признаки: NonQuote, Exec, ClearingTrade.

  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до 5 знака после запятой.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске признаки: NonQuote, Exec, ClearingTrade.

Сделки исполнения опционов генерируются:

  • В промклиринге

  • В вечернем клиринге

В зависимости от времени подачи заявки на исполнение опциона (генерация в ближайшем клиринге)

Исполнение расчетного опциона
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до 5 знака после запятой.

  • Техническая сделка, юридически не является сделкой.

  • В шлюзах и отчётах в битовой маске признаки: NonQuote, Exec, ClearingTrade.

Нет

Сделки исполнения опционов генерируются:

  • В промклиринге

  • В вечернем клиринге

Истечение опциона
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки равна 0.

  • Техническая сделка, юридически не является сделкой.

  • В шлюзах и отчётах в битовой маске признаки: NonQuote, Expiration, ClearingTrade, OptionLapse.

НетВечером в день исполнения фьючерса
Перенос позиции ОБФ
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки равна 0.

  • Техническая сделка, юридически не является сделкой.

  • В шлюзах и отчётах в битовой маске признаки: NonQuote, Address, TransferClientPosition, ClearingTrade.

  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки равна 0.

  • Техническая сделка, юридически не является сделкой.

  • В шлюзах и отчётах в битовой маске признаки: NonQuote, Address, TransferClientPosition, TransferSource, ClearingTrade.

Вечером
Добровольный выход из вечного фьючерса (на основании поданного поручения)
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки равна расчетной цене вечного фьючерса.

  • Техническая сделка, юридически не является сделкой.

  • В шлюзах и отчётах в битовой маске признаки: NonQuote, PerpetualFuturesExecutionVoluntary, ClearingTrade.

  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки равна расчетной цене вечного фьючерса, умноженной на коэффициент, учитывающий разницу в размерностях инструментов.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске признаки: NonQuote, PerpetualFuturesExecution, ClearingTrade.

Вечером в день подачи поручения на исполнение
Принудительный выход из вечного фьючерса (реализация неудовлетворённого спроса)
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки равна расчетной цене вечного фьючерса.

  • Техническая сделка, юридически не является сделкой.

  • В шлюзах и отчётах в битовой маске признаки: NonQuote, PerpetualFuturesExecutionForced, ClearingTrade.

  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки равна расчетной цене вечного фьючерса, умноженной на коэффициент, учитывающий разницу в размерностях инструментов.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске признаки: NonQuote, PerpetualFuturesExecution, ClearingTrade.

Вечером в день подачи поручения на исполнение
Расчет сделки по заявке с указанием спреда TAS (В текущей версии недоступно)
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки равна 0.

  • Техническая сделка, юридически не является сделкой.

  • В шлюзах и отчётах в битовой маске признаки: NonQuote, ClearingTrade, TASSettlement.

  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки равна расчетной цене БА-фьючерса.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске признаки: NonQuote, ClearingTrade, TASSettlement.

Вечером в день исполнения TAS-фьючерса

Торговые сделки отражаются следующим образом:

Операции в ходе торговИнформация по операциям
Сделка по фьючерсу на акции на основании адресной заявки
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до минимального шага цены.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске: признаки NonQuote, Address.

Сделка по фьючерсу на акции на основании безадресной заявки
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до минимального шага цены.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске: все биты выключены.

Сделка по опциону на фьючерсы на акции на основании адресной заявки
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до минимального шага цены.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске: признаки NonQuote, Address.

Сделка по опциону на фьючерсы на акции на основании безадресной заявки
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до минимального шага цены.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске: все биты выключены.

Сделка по переносу позиций
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до 5 знака после запятой.

  • Юридически не является сделкой.

  • В шлюзах и отчётах в битовой маске: признаки NonQuote, Address, TransferClientPosition, TransferSource.

Техническая сделка на основании 1 части адресной парной заявки
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до 5 знака после запятой.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске: признаки NonQuote, Address, Strategy.

Техническая сделка на основании 2 части адресной парной заявки
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до 5 знака после запятой.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске: признаки NonQuote, Address, Strategy, REPOBack.

Техническая сделка на основании 1 части безадресной парной заявки
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до 5 знака после запятой.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске: признаки NonQuote, Strategy.

Техническая сделка на основании 2 части безадресной парной заявки
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до 5 знака после запятой.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске: признаки NonQuote, Strategy, REPOBack.

Сделка по фьючерсу на акции на основании сделки в RFS
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до минимального шага цены.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске: признаки NonQuote, Address, RFSOrder.

Сделка по опциону на фьючерсы на акции на основании сделки в RFS
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до минимального шага цены.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске: признаки NonQuote, Address, RFSOrder.

Техническая сделка по 1 части парной заявки на основании сделки в RFS
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до 5 знака после запятой.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске: признаки NonQuote, Address, Strategy, RFSOrder.

Техническая сделка по 2 части парной заявки на основании сделки в RFS
  • В шлюзах и отчётах будет уникальный ненулевой id.

  • Цена сделки округляется с точностью до 5 знака после запятой.

  • Юридически является сделкой.

  • В шлюзах и отчётах в битовой маске: признаки NonQuote, Address, Strategy, REPOBack, RFSOrder.

Расписание торгов и клиринга

Расписание торгов. Торговые сессии

Торги в системе 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.

Потоки, которые не переоткрываются:

Использование механизма синхрособытий для получения консистентного состояния данных в системе

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

  • Данные для новой торговой сессии закачены и рассчитаны (~18:54-18:55, Московского времени)

  • Начало промежуточного клиринга (14:00, Московского времени)

  • Денежные средства после промклиринга перерассчитаны (~14:01:30, Московского времени)

  • Все расчетные процедуры в промклиринге закончены (~14:02, Московского времени)

  • Начало основного клиринга (18:50, Московского времени)

  • Данные после основного клиринга перерассчитаны (~18:54, Московского времени)

  • Раздвижка лимитов закончена (в течение торгов)

  • Начало приема заявок в аукцион открытия (~8.50, Московского времени)

  • Окончание приема заявок в аукцион открытия (~8.59, Московского времени)

Для уведомления внешних систем о наступлении определенного состояния торговой системы, в потоках репликации транслируется таблица sys_events следующего формата:

ПолеТипОписание
replIDi8Служебное поле подсистемы репликации
replRevi8Служебное поле подсистемы репликации
replActi8Служебное поле подсистемы репликации
event_idi8Уникальный идентификатор события
sess_idi4Номер сессии
event_typei4Тип события
messagec64Описание события

Таблица транслируется в следующих потоках репликации:

Правила синхронизации данных следующие - при наступлении глобального события в торговой системе, после генерации всех данных по этому событию всеми подсистемами торговой системы, в таблицы 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 - Главный трейдер РФ;

  • 2 - Администратор КЦ;

  • 3 - Администратор ТС.

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

Обращаем внимание, что все запреты, выставляемые пользователем с помощью шлюзовых команд (см. ниже), имеют инициатора - '1 - Главный трейдер РФ'.

section

Идентификатор секции. Используется для выставления запрета на торговлю всеми инструментами в секции. Может принимать следующие значения:

  • 1 - Фондовая;

  • 2 - Товарная;

  • 3 - Денежная;

  • 4 - Мосэнергобиржа, MOSENEX;

  • 8 - Биржа СПб, SPBEX;

  • 9 - SPBEX_OAO;

  • 10 - NAMEX.

base_contract_codeКод базового актива. Запрет выставляется только на инструменты, базирующиеся на этом БА.
isin_idУникальный числовой идентификатор инструмента. Используется для запретов на торговлю конкретным инструментом.
priorityПриоритет запрета. Автоматически вычисляется из параметров запрета (см ниже).
group_mask

Битовая маска групп инструментов, по которым действует запрет. Может принимать следующие значения:

  • 0x40000000 - Фьючерсы.

  • 0x80000000 - Опционы.

type

Тип запрета. Может принимать следующие значения:

  • 0 - Разрешены все операции. Используется для точечного разрешения в случае наличия более широкого запрета;

  • 1 - Запрет на открытие позиций;

  • 2 - Запрет на выставление любых заявок;

  • 3 - Запрет на открытие позиций на продажу;

  • 0x08 - Запрет брокера на подачу поручений на Экспирацию;

  • 0x10 - Запрет Главного трейдера РФ на подачу поручений на Экспирацию. Но ему самому - можно;

  • 0x20 - Запрет на запрос потока ликвидности без автоподтверждения (RFS);

  • 0x40 - Запрет на запрос потока ликвидности (RFS);

  • 0x80 - Запрет на заключения сделки при недостаточном количестве котировок (RFS);

  • 0x100 - Запрет на запрос потока ликвидности с ограничением времени жизни котировок (RFS).

Типы запретов 0-3 упорядочены по строгости следующим образом: 2 > 1 > 3 > 0.

is_legacy

Признак пользовательского запрета. Может принимать следующие значения:

  • 0 - Запрет был выставлен Администратором торгов или клиринга и не может быть изменен пользователем;

  • 1 - Запрет был выставлен пользователем и может быть изменен средствами шлюзового API.

Таблица 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. Можно по конкретному клиенту (по всем клиентам), инструменту (по всем инструментам) или базовому активу (по всем БА) запретить открывать позиции и выставлять заявки.

Выставление запретов (примеры конфигурации запретов)

Для выставления запретов в шлюзе предусмотрены команды, о которых было сказано выше. При выставлении запретов следует обращать особое внимание на их корректное конфигурирование. Неправильно построенный запрет может привести к возникновению в системе необоснованно большого количества запретов, что, в свою очередь, негативно сказывается на производительности всей системы управления запретами в целом, и прежде всего для самого пользователя, выставившего некорректный запрет (тормоза при открытии потоков и отправке команд управления запретами). Например, вместо того, чтобы ставить много запретов по почти каждому клиенту БФ, намного эффективнее выставить один общий запрет по БФ, а по нужным клиентам выставить соответствующие разрешения. Ниже приведены примеры конфигурации запретов в различных ситуациях. Приводимые в сценариях конфигурации позволяют минимизировать итоговое количество запретов.

  1. Примеры задания запретов, когда все клиенты имеют одинаковые права.

    1. Запретить все операции по n БА (список запрещенных БА). n < 0.5*M, где М – общее количество БА.

      • Ставятся n запретов БФ на БА. Тип запрета - state=2 (запрет на выставление любых заявок), приоритет запрета - priority=5 (Код БФ / БА, base_contract_code != 0).

        Добавление нового БА, входящего в список запрещённых БА, требует явного выставления запрета.

        Добавление нового БА, не входящего в список запрещённых БА, не требует выставления нового запрета.

    2. Запретить все операции по n БА (список запрещенных БА). n > 0.5*M, где М – общее количество БА. Сценарий отличается от предыдущего соотношением между количеством запрещенных и разрешенных БА.

      • Ставится запрет БФ на все БА. Тип запрета - state=2 (запрет на выставление любых заявок), приоритет запрета - priority=4 (Код БФ / все инструменты).

      • Ставятся М-n разрешений БФ на разрешенные БА (обратного множества к запрещенным БА). Тип запрета - state=0 (разрешены все операции), приоритет запрета - priority=5 (Код БФ / БА, base_contract_code != 0).

        Добавление нового БА, входящего в список запрещённых БА, не требует выставления запрета.

        Добавление нового БА, не входящего в список запрещённых БА, требует выставления по нему разрешения.

  2. Примеры задания запретов, когда клиенты делятся на две группы: квалифицированные инвесторы и неквалифицированные инвесторы.

    Количество квалифицированных инвесторов = m. Количество неквалифицированных инвесторов = n.

    Неквалифицированные инвесторы должны иметь доступ только к БА из группы L. Квалифицированные инвесторы имеют доступ ко всем БА.

    1. Разрешить неквалифицированным инвестором торговать только по БА из группы L и запретить по остальным БА. Квалифицированным инвестором разрешить торговать по всем БА. m < n - квалифицированных инвесторов меньше.

      • Ставится запрет БФ на все БА. Тип запрета - state=2 (запрет на выставление любых заявок), приоритет запрета - priority=4 (Код БФ / все инструменты).

      • Ставятся разрешения БФ на БА из группы L. Тип запрета - state=0 (разрешены все операции), приоритет запрета - priority=5 (Код БФ / БА, base_contract_code != 0). Т.е. будет разрешено всем клиентам БФ.

      • Ставятся разрешения квалифицированным инвесторам БФ на все БА. Тип запрета - state=0 (разрешены все операции), приоритет запрета - priority=7 (Клиентский код / все инструменты). Т.е. будет разрешено только всем квалифицированным инвесторам БФ.

        Добавление нового квалифицированного инвестора, требует выставить по нему разрешение.

        Добавление нового неквалифицированного инвестора, не требует изменений в запретах.

    2. Разрешить неквалифицированным инвестором торговать только по БА из группы 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

В системе 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_REPLorders_logpriceЦена в заявке
FORTS_TRADE_REPLorders_logdeal_priceЦена заключенной сделки
FORTS_TRADE_REPLuser_dealpriceЦена заключенной сделки
FORTS_ORDLOG_REPLorders_logpriceЦена в заявке
FORTS_ORDLOG_REPLorders_logdeal_priceЦена заключенной сделки
FORTS_USERORDERBOOK_REPLorderspriceЦена в заявке
FORTS_ORDBOOK_REPLorderspriceЦена в заявке
FORTS_COMMON_REPLcommonbest_buyЦена лучшей заявки на покупку
FORTS_COMMON_REPLcommonbest_sellЦена лучшей заявки на продажу
FORTS_COMMON_REPLcommonopen_priceЦена открытия
FORTS_COMMON_REPLcommonclose_priceЦена закрытия
FORTS_COMMON_REPLcommonpriceЦена последней сделки
FORTS_COMMON_REPLcommonmin_priceМинимальная цена
FORTS_COMMON_REPLcommonmax_priceМаксимальная цена
FORTS_COMMON_REPLcommonavr_priceСредневзвешенная цена
FORTS_COMMON_REPLcommonsettlement_price_openРасчетная цена предыдущей сессии
FORTS_COMMON_REPLcommonmarket_priceТекущая рыночная цена
Потоки агрегированных стаканов FORTS_AGGRXXorders_aggrpriceЦеновой уровень
FORTS_POS_REPLpositionwapriceУчетная цена позиции
FORTS_POS_REPLposition_sawapriceУчетная цена позиции
FORTS_REFDATA_REPLfut_sess_contentslimit_upВерхний лимит цены
FORTS_REFDATA_REPLfut_sess_contentslimit_downНижний лимит цены
FORTS_REFDATA_REPLfut_sess_contentssettlement_price_openРасчетная цена на начало сессии
FORTS_REFDATA_REPLfut_sess_contentssettlement_priceРасчетная цена после последнего клиринга
FORTS_REFDATA_REPLfut_instrumentssettlement_price_openРасчетная цена на начало сессии
FORTS_REFDATA_REPLfut_instrumentssettlement_priceРасчетная цена после последнего клиринга
FORTS_REFDATA_REPLopt_sess_contentsstrikeЦена исполнения
FORTS_MM_REPLfut_MM_infoprice_edge_sellЦена худшей заявки на продажу, вошедшей в спред
FORTS_MM_REPLfut_MM_infoprice_edge_buyЦена худшей заявки на покупку, вошедшей в спред
FORTS_CLR_REPLfut_sess_settlsettl_priceРасчетная цена
FORTS_INFO_REPLfutures_paramsrisk_range_centerЦентр расчета риска
FORTS_INFO_REPLfutures_paramssettlement_priceРасчетная цена последнего клиринга
FORTS_INFO_REPLoptions_paramsstrikeЦена исполнения
FORTS_REJECTEDORDERS_REPLrejected_orderspriceЦена в заявке

В режиме положительных цен (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".

Клиентские SMA-логины (спонсируемый доступ)

Спонсируемый доступ (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. Иерархия сущностей

Иерархия сущностей

Разделение полномочий участников

Разделение статусов участников торгов и участников клиринга подразумевает и разделения полномочий участников на торговые и клиринговые. Под полномочиями здесь понимаются права на просмотр информации в шлюзе и права на выполнение операций.

Основные полномочия участника торгов, которые не доступны участнику клиринга - это подача/снятие торговых заявок и заключение сделок на основании поданных заявок. При этом участник клиринга может совершать некоторые действия с заявками, подавая поручения в НКЦ, а уже НКЦ может выставлять заявку от имени участника клиринга, а также снимать другие заявки (подробнее см. раздел 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

"Логин УК+УТ" обладает совокупным набором полномочий "Логина УК" и "Логина УТ", за исключением подачи Запросов к НКЦ, которые может подавать только "Логин УК".

Участник клиринга может получить логины следующих уровней:

  • Расчетной фирмы.

  • Брокерской фирмы.

  • Клиента.

Участник торгов может получить логины следующих уровней:

  • Брокерской фирмы.

  • Клиента.

В зависимости от уровня, полномочия логина могут различаться:

  • При работе с разделами БФ, у которой УК совпадает с УТ, логины уровня РФ и уровня БФ обладают полномочиями "Логин УК+УТ".

  • При работе с разделами БФ, у которой УК не совпадает с УТ, логин уровня РФ обладает полномочиями "Логин УК".

  • При работе с разделами БФ, у которой УК не совпадает с УТ, полномочия логина уровня БФ совпадают со значением признака [ "Логин УК" | "Логин УТ" ].

  • Для любой БФ логин уровня клиента обладает полномочиями "Логин УТ".

В ситуации, когда участник клиринга и участник торгов разные лица, важным является - кто управляет клиентами (клиентскими разделами). Под управлением клиентами здесь понимается возможность видеть информацию по ним: средства, лимиты и индивидуальные риск-параметры, а также и собственно устанавливать лимиты, запреты, правила экспирации и т.п. Возможны две схемы взаимодействия между УК и УТ с точки зрения управления клиентами:

  • Клиентами управляет УТ. Участник торгов управляет клиентскими разделами, входящими в состав своих Брокерских фирм (схема по умолчанию). В данной схеме участнику клиринга не доступна информация о клиентах участников торгов: средства, лимиты и индивидуальные риск-параметры по клиентским разделам, а также не доступны операции по управлению клиентами.

  • Клиентами управляет УК. Участник торгов передает клиентские разделы, входящие в состав своих Брокерских фирм, "под управление" участнику клиринга.

Схема взаимодействия задается на уровне БФ путем выставления у нее специального признака: "Клиентами управляет УТ"/"Клиентами управляет УК".

Для иллюстрации приведем пару примеров:

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

  2. Компания нерезидент, чтобы получить доступ к торгам на Московской бирже для своих клиентов, регистрируется в НКЦ в качестве участника клиринга. Далее нерезидент заключает договор поручение с брокерской фирмой (российская дочка нерезидента либо большой УК+УТ) на обслуживание своих клиентов. Но торговать будут клиенты нерезидента и контролировать их он хочет сам - в этом случае используется схема "Клиентами управляет УК".

Рисунок 3. Примеры

Примеры

Ниже в таблице приведен список полномочий, относящийся к праву управления клиентскими разделами. Обладать данными полномочиями будут логины, у которых набор полномочий ("Логин УТ" /"Логин УК") совпадает со схемой, заданной у БФ ("Клиентами управляет УТ"/"Клиентами управляет УК").

ОперацияДоступные шлюзовые команды, потоки, таблицы
Установка лимитов по клиентским разделам.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")

Рисунок 4. Стаканы календарного спреда

Стаканы календарного спреда

Синтетическая заявка формируется системой на основании двух реальных заявок, поданных участниками в двух других инструментах. В нашем примере система сформировала синтетическую заявку на продажу по календарному спреду 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).

Рассмотрим пример, когда в обычный агрегированный стакан добавляется синтетическая ликвидность. Есть агрегированные стаканы календарного спреда и его ног с натуральной ликвидностью.

Рисунок 5. Обычные агрегированные стаканы календарного спреда

Обычные агрегированные стаканы календарного спреда

Эти же стаканы, но с учетом синтетической ликвидности, выглядят следующим образом.

Рисунок 6. Агрегированные стаканы с синтетической ликвидностью

Агрегированные стаканы с синтетической ликвидностью

Изображена вся посчитанная синтетическая ликвидность без учета ограничения на количество уровней агрегированного стакана синтетической ликвидности. Ценовые уровни, где есть синтетическая ликвидность, подсвечены красным.

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

В стакане дальней ноги ситуация уже не столь радикально изменилась за счет синтетической ликвидности. Хотя и здесь, если трейдер подаст заявку в покупку 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 шлюз

Состав и архитектура шлюза

ПО 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.

  • Комплект средств разработки: дополнительные утилиты и командные файлы, документация, тестовые примеры.

Рисунок 7. PLAZA II шлюз. Архитектура

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, также возможно использование других дистрибутивов

Установка ПО в среде Windows

Заберите новую версию шлюза с сервера разработчиков 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. Установка производится с помощью мастера установки.

Рисунок 8. Начало установки

Начало установки

Нажмите кнопку "Далее" для продолжения установки.

Рисунок 9. Папка назначения

Папка назначения

По умолчанию для установки программы предлагается папка C:\Moscow Exchange\SpectraCGate\. Если вас это устраивает, нажмите кнопку "Далее" для продолжения и выбора вида установки.

Если вы хотите выполнить установку в другую папку, нажмите кнопку "Изменить..." и в появившемся окне "Изменение текущей папки назначения" выберите новую папку с помощью окна "Поиск в папке"; для перехода на уровень выше в дереве папок используйте кнопку . Вы также можете создать новую папку назначения при помощи кнопки или ввести путь к уже существующей папке вручную в поле "Имя папки" в нижней части окна. Для сохранения внесённых изменений нажмите кнопку "ОК" — окно изменения папки назначения закроется, и вы вернётесь в предыдущее окно "Папка назначения". Нажмите кнопку "Далее" для продолжения и выбора вида установки.

Обратите внимание, что вы сможете изменить папку назначения только при первой установке программы или при переустановке программы "с нуля". В остальных случаях кнопка "Изменить..." будет неактивна.

Рисунок 10. Вид установки

Вид установки

Выберите вариант установки, определяющий состав устанавливаемых программных компонентов. Полная установка предполагает установку всех компонентов шлюза: модуля P2MQRouter, библиотеки cgate, дополнительных утилит, а также комплекта средств разработки. Выборочная - это различные комбинации программных компонент.

Нажмите кнопку "Далее", чтобы активировать следующий шаг.

Рисунок 11. Выборочная установка

Выборочная установка

Выберите требуемые программные компоненты и каталог для установки. Директория установки должна быть расположена в соответствии с административными рекомендациями.

Нажмите кнопку "Далее", чтобы активировать следующий шаг.

Рисунок 12. Варианты подключения к ТС

Варианты подключения к ТС

Выберите ТС, к которой необходимо подключиться (production, тестовая, игровая и т.п.), или введите свои параметры для соединения с серверами биржи. Для каждого варианта подключения параметры соединения хранятся в отдельном конфигурационном файле, который находится в каталоге \links директории установки:

Вариант подключенияФайл с настройками подключенияОписание
Выделенный каналlinks_public.prod.iniПодключение к Spectra боевой контур
Резервный каналlinks_public.rezerv.iniПодключение к Spectra резервный контур
Тестовая система для разработчиков T0links_public.t0.iniПодключение к Spectra публичный тестовый контур - текущая версия
Тестовая система для разработчиков T1links_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. Если файлы отсутствуют, то отображаются значения по умолчанию.

Рисунок 13. Секция пользовательских настроек подключения

Секция пользовательских настроек подключения

Напоминаем, что для выбора правильных адресов подключения необходимо проконсультироваться с вашим брокером и/или службой технической поддержки биржи.

Нажмите кнопку "Далее", чтобы активировать следующий шаг.

Рисунок 14. Ввод логина и пароля

Ввод логина и пароля

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

После установки логин и пароль прописываются в отдельном конфигурационном файле auth_client.ini, который находится в каталоге \auth директории установки, а в ini-файле модуля P2MQRouter в параметре auth_ini указывается ссылка на этот файл.

При переустановке ПО в полях формы отображаются значения логина и пароля, заданные в auth_client.ini или client_router.ini. Обратите внимание, что в случае переустановки или деинсталляции системы каталог \auth и файл с аутентификационными данными (auth_client.ini) не удаляются.

Нажмите кнопку "Далее", чтобы активировать следующий шаг.

Рисунок 15. Регистрация роутера как сервис ОС

Регистрация роутера как сервис ОС

При необходимости установить роутер как сервис ОС Windows выставите чекбокс и нажмите кнопку "Далее", чтобы активировать следующий шаг.

Если при инсталляции P2MQRouter не был зарегистрирован как сервис ОС, в дальнейшем это можно исправить вручную, воспользовавшись командным файлом install_router.cmd (uninstall_router.cmd) из дистрибутива.

Рисунок 16. Запуск установки

Запуск установки

Нажмите кнопку "Установить", чтобы начать установку.

Рисунок 17. Завершение установки

Завершение установки

Нажмите кнопку "Готово" для завершения процесса установки.

Установка ПО в среде Linux

Установка из zip-архива

Дистрибутив Cgate состоит из инсталляционого скрипта и архива, в котором находятся загружаемые модули проекта cgate и проекта cgate_java, файлы include, файлы документации и файлы примеров. Дистрибутив доступен для скачивания по адресу: https://ftp.moex.com/pub/ClientsAPI/Spectra/CGate/.

Порядок установки:

  1. Выполните команду:

    chmod 755 ./install.sh
  2. Выполните команду:

    ./install.sh ./cgate_linux_amd64-7.12.0.103.zip

    Внимание! Имя архива привязано к версии ПО и может отличаться от имени, которое указано в примере выше.

  3. В ответ на запрос: "Please, enter cgate install path:" укажите полный путь к каталогу, в который вы хотите распаковать шлюз.

  4. В ответ на запрос: "Please, enter P2 login:" укажите логин пользователя.

  5. В ответ на запрос: "Please, enter P2 password:" укажите пароль пользователя.

  6. Дальнейшие шаги установки различаются в зависимости от версии ОС Linux, установленной на компьютере:

    • Debian 6:

      • Установить пакет ant

      • Установить пакет openjdk-6-jdk (компиляция примеров java)

      • Установить пакет g++ (компиляция примеров C++).

    • CentOS 6:

      • Установить пакет gcc

      • Установить пакет gcc-c++ (компиляция примеров C++)

      • Установить пакет ant (компиляция примеров java).

Установка из deb-пакета или rpm-пакета

Порядок установки:

  1. Скачайте и установите пакет шлюза с помощью команды:

    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/docCopyright, документация по установке
  2. Зайдите в каталог /etc/opt/moex/cgate/auth и в соответствующем ini-файле укажите логин/пароль для подключения:

    • prod.ini - для подключения к production системе

    • t1.ini - для подключения к полигону T1

    • t0.ini - для подключения к полигону T0

    • game.ini - для подключения к игровому полигону

    Внимание! Обратите внимание, что в случае переустановки пакета каталог \auth и файлы с настройками подключения не удаляются, поэтому повторно настраивать логин/пароль не потребуется.

  3. Запустите сервис (роутер) с помощью команды:

    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 рекомендуется сделать копию примеров в своём домашнем каталоге и собирать их оттуда.

Описание примеров:

  1. Пример aggrspy

    aggrspy - пример построения агрегированного стакана на покупку и продажу по фиксированному инструменту по потоку FORTS_AGGR50_REPL. При нажатии Enter в outfile выводится срез стакана.

    Команда для запуска:

    aggrspy ISIN_ID depth outfile [r]

    Входные аргументы:

    • isin_id - id инструмента;

    • depth - глубина выводимого стакана в файл (не больше 50);

    • outfile - файл для печати стакана;

    • r - включить обратное направление сортировки (параметр используется для инструментов с обратной сортировкой).

  2. Пример repl

    repl - получение реплики данных по потоку. Пример печатает все получаемые сообщения в log. При разрыве соединения реплика начинается сначала. Входных аргументов нет.

  3. Пример repl_resume

    repl_resume - пример аналогичен repl. Отличие заключается в том, что после разрыва соединения repl_resume продолжает реплику с последнего сообщения TN_COMMIT. Входных аргументов нет.

  4. Пример send

    send - выставляет заявку на SPECTRA. Выводит в лог ответ торговой системы. Входных аргументов нет.

  5. Пример 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 - включить обратное направление сортировки (параметр используется для инструментов с обратной сортировкой).

  6. Пример p2sys

    p2sys - пример авторизации роутера из cgate. Повторяет в цикле следующие действия:

    • Посылает ошибочный набор (login, pwd), в ответ получает сообщение logon failed;

    • После этого посылает правильный набор (login, pwd);

    • На сообщение об успешной авторизации посылается запрос на logout;

    • Возврат к началу.

  7. Пример 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):

ПолеТипОписание
codei4Код возврата
messagec255Текст сообщения.

Обратите внимание, что сообщение "системная ошибка" может быть отправлено в ответ на любое сообщение бизнес-логики.

Контроль аномальной активности

В ТС SPECTRA действует система ограничения аномальной активности клиентских приложений. Она не позволяет приложению пользователя (одному логину в системе SPECTRA) присылать более оговорённого в заявке на подключение количества сообщений в единицу времени. В настоящий момент можно получить логин в систему SPECTRA с ограничением 30, 60, 90 и т.д. (но не более 3000) торговых операций в секунду. К торговым операциям относятся все команды управления заявками. Количество неторговых (всех остальных) операций для любого типа логина ограничено 1000 в секунду.

При превышении лимита сообщений, система контроля не транслирует сообщение в ядро ТС, а посылает пользователю сообщение-ответ с уведомлением об отказе в обслуживании, msgid=99 следующей структуры:

ПолеТипОписание
queue_sizei4Количество сообщений пользователя
penalty_remaini4Время в миллисекундах, по прошествии которого будет успешно принято следующее сообщение от этого пользователя
messagec128Текст сообщения об ошибке

Обращаем внимание на два нюанса:

  1. Количество сообщений за истекшую секунду оценивается при приёме КАЖДОГО сообщения. Это значит, что если пользователь постоянно присылает запросы с частотой, больше, чем ему разрешено, то его сообщения перестают обрабатываться вообще.

  2. Сообщение-отказ с типом 99 может быть послано в ответ на любое сообщение пользователя.

Автоматическое снятие заявок при отключении пользователя от торгов

В ТС SPECTRA предусмотрен механизм контроля за состоянием подключения клиента (сервис "Cancel On Disconnect"), который позволяет при отключении клиента от ТС автоматически снимать все активные заявки клиента. Снимаются только обычные (без срока истечения), безадресные заявки.

Для включения сервиса (а также отключения) фирме-Участнику торгов необходимо подать соответствующее распоряжение через Клиентский Центр. Сервис включается для идентификатора (p2login), принадлежащего фирме-Участнику.

При подключении идентификатора с включенной услугой "Cancel On Disconnect" к ТС для него активируется режим контроля за состоянием подключения (COD-режим).

Логика работы механизма контроля подключений следующая:

  • Если для клиента активирован COD-режим, то система отслеживает активность подключения на транзакционном уровне. Каждая команда (сообщение) клиента, зарегистрированная в системе, вне зависимости от её успешности, трактуется как проявление активности.

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

Возможные ситуации, при которых происходит запуск процедуры снятия активных заявок:

  • Клиент не отправил ни одного сообщения за установленный период времени.

  • Клиентское приложение потеряло соединение с роутером. Активные заявки будут сняты по истечении установленного периода времени.

  • Роутер потерял соединение с сервером доступа. Активные заявки будут сняты по истечении установленного периода времени.

  • Сервер доступа потерял соединение с ТС или утратил работоспособность вследствие возникшей ошибки. Активные заявки клиентов, не установивших соединение с другим сервером доступа, будут сняты по прошествии времени, установленного в качестве порога неактивности.

  • Возможна ситуация, когда сервер доступа, частично утрачивая работоспособность, оповещает ТС об активности от имени своих клиентов, но фактически теряет с ними соединение. Такая ситуация не может быть идентифицирована ТС Биржи и должна быть урегулирована на стороне Участника.

Для всех клиентов с COD-режимом заявки также автоматически снимаются после окончания вечерней торговой сессии и при восстановлении системы после сбоя.

Заявки, снятые механизмом "Cancel On Disconnect", в таблицах помечаются специальным статусом (поле xstatus).

При отсутствии торговой активности, чтобы предотвратить снятие заявок, клиентское приложение должно информировать ТС об активности подключения путем отправки не реже одного раза в 10 секунд, но не чаще чем раз в секунду, специальной команды CODHeartbeat (msgid=10000) следующей структуры:

ПолеТипОписание
seq_numberi4Номер сообщения-хартбита (в текущей версии не используется).

Команда не учитывается при расчете сбора за транзакции.

Сервис контроля подключений не отправляет ответных сообщений на хартбиты, поэтому при вызове функции отправки сообщения следует указывать ноль (не ожидать ответа): cg_pub_post(pub, msgptr, 0). Вызов функции cg_pub_post с флагом CG_PUB_NEEDREPLY при отправке хартбита приведет к получению ошибки CG_MSG_P2MQ_TIMEOUT.

Потоки, получаемые логинами разных подтипов

В зависимости от подтипа логина пользователя (основной, просмотровый или транзакционный) различен получаемый им набор потоков репликации.

Основной логин получает следующие потоки репликации:

Если способ получения рыночных данных – "агрегированные стаканы", основной логин также получает:

Если способ получения рыночных данных – "полный журнал заявок", основной логин получает:

Просмотровый логин получает следующие потоки репликации:

Если способ получения рыночных данных – "агрегированные стаканы", просмотровый логин также получает:

Если способ получения рыночных данных – "полный журнал заявок", просмотровый логин получает:

Транзакционный логин получает следующие потоки репликации:

Смена пароля доступа в торговую систему

У пользователя имеется возможность самостоятельно сменить свой пароль доступа в торговую систему. Для этого можно воспользоваться одним из следующих методов:

  • воспользоваться специальной утилитой 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.

При запуске утилите могут быть переданы следующие параметры:

--app_name

имя приложения. Необязательный параметр;

--local_pass

пароль для локального соединения с роутером. Необязательный параметр;

--host

ip-адрес роутера. Необязательный параметр, значение по умолчанию 127.0.0.1;

--port

порт роутера. Необязательный параметр. Значение по умолчанию 4001;

--ini

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

В системе существует ограничение на количество одновременных подписок на один поток 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).

Рисунок 18. Схема соединений

Схема соединений

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

Диагностика разрыва соединений

За установку 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 секунд.

При получении ответа типа "таймаут" рекомендуется иметь процедуру верификации отправленного сообщения:

  1. Проверить, что пара публикатор p2mq и подписчик p2mqreply не перешли в ошибочное состояние. Если публикатор или подписчик в ошибочном состоянии, провести их закрытие и удаление и инициализировать заново.

  2. Для команд управления заявками рекомендуется всегда задавать внешний номер заявки (параметр ext_id). В случае получения "таймаута" на команду AddOrder или MoveOrder возможной безопасной реакцией будет удалить заявку с помощью команды DelUserOrders с указанием ext_id.

  3. Если "таймаут" произошел при удалении/отмене заявки, исходите из предположения, что заявка НЕ удалена. Повторите удаление после восстановления соединения или через ВПТС, работающее с другим ЦОД биржи.

  4. Проанализируйте данные таблицы собственных заявок orders_log потока FORTS_TRADE_REPL на предмет наличия или отсутствия в ней отправленных заявок или отмен заявок.

  5. Если "таймаут" произошел при отправке неторговой команды, проанализируйте состояние соответствующей таблицы в потоке реплики – отражены ли там запрошенные изменения.

Процедура восстановления

В общем случае, алгоритм восстановления подключения следующий:

  • После старта предпринимать периодические попытки открыть соединение с P2MQRouter.

  • При восстановлении соединения рутера с сетью PLAZA II объект соединение перейдет в состояние ACTIVE.

  • Произвести открытие нужных потоков. Для ускорения процедуры восстановления рекомендуется выполнять получение данных с момента последнего обновления. При открытии потока следует указывать replstate, полученный в момент закрытия потока, или явно задавать номера ревизий для таблиц и номер жизни схемы, используя последние номера фактически полученных данных.

  • Произвести восстановление списка активных заявок (см. далее).

  • Зарегистрировать publisher для приказов/команд.

Ниже в таблице приведены рекомендуемые способы восстановления данных в зависимости от получаемого потока:

Имя потока (таблицы)Информация в потокеСпособ восстановления
FORTS_TRADE_REPL
  • orders_log

Журналы операций со своими заявками по фьючерсам и опционамСписок активных заявок:
  • использование потока FORTS_USERORDERBOOK_REPL для получения snapshot, а затем открытие потока FORTS_TRADE_REPL с указанным в snapshot номером ревизии

Журнал действий с заявками:

  • открытие FORTS_TRADE_REPL с последнего полученного номера ревизии

FORTS_TRADE_REPL
  • multileg_orders_log

Журналы операций со своими заявками по связкамЖурнал действий с заявками:
  • открытие FORTS_TRADE_REPL с последнего полученного номера ревизии

FORTS_ORDLOG_REPL
  • orders_log

Полный анонимный журнал операций с заявками по фьючерсам и опционамСписок активных заявок:
  • использование потока FORTS_ORDRBOOK_REPL для получения snapshot, а затем открытие потока FORTS_ORDLOG_REPL с указанным в snapshot номером ревизии

Журнал действий с заявками:

  • открытие FORTS_ORDLOG_REPL с последнего полученного номера ревизии

FORTS_ORDLOG_REPL
  • multileg_orders_log

Полный анонимный журнал операций с заявками по связкамЖурнал действий с заявками:
  • открытие FORTS_ORDLOG_REPL с последнего полученного номера ревизии

FORTS_DEALS_REPL
  • deal

  • multileg_deal

FORTS_TRADE_REPL

  • user_deal

  • multileg_deal

Журнал сделок по фьючерсам, составным инструментам и опционамПереоткрытие соответствующего потока с указанием последнего полученного номера ревизии или repl state, полученного в момент закрытия потока
FORTS_COMMON_REPLОбщая рыночная информация по фьючерсам и опционамПереоткрытие потока с нуля
FORTS_AGGR##_REPLСтаканы по фьючерсам и опционам (## - глубина стакана)Переоткрытие соответствующего потока с нуля
FORTS_REFDATA_REPLСправочная и сессионная информацияБыстрый способ:
  • Переоткрытие потока с указанием последнего полученного номера ревизии или repl state, полученного в момент закрытия потока

Допустимый способ:

  • Переоткрытие потока с нуля

FORTS_PART_REPLИнформация о лимитахПереоткрытие потока с нуля
FORTS_POS_REPLИнформация о позицияхПереоткрытие потока с нуля
FORTS_VM_REPLИнформация о вариационной марже и премииПереоткрытие потока с нуля
FORTS_VOLAT_REPLИнформация о волатильности и теоретических ценах опционовПереоткрытие потока с нуля
RTS_INDEX_REPLЗначения биржевых индексовПереоткрытие потока с нуля

При восстановлении соединения важной задачей является получение текущих активных заявок пользователя:

  1. Получение набора активных в момент восстановления заявок.

  2. Получение журнал действий с заявками в период отсутствия соединения.

Задача 1 решается путём получения среза заявок (FORTS_USERORDERBOOK_REPL) — заявки, отсутствующие в срезе, были сведены или отвергнуты в период отсутствия соединения.

Задача 2 решается получением журнала действий со своими заявками (таблица orders_log потока FORTS_TRADE_REPL, а также таблица multileg_orders_log потока FORTS_TRADE_REPL) за период отсутствия соединения. Для этого надо открыть соответствующий поток с указанием номера ревизии последней фактически полученной до сбоя записи. Все действия с заявками, происходившие до момента восстановления, будут отражены в виде записей этих таблиц. Индикатором получения всей пропущенной истории действий с заявками является переход потока в состояние ONLINE.

Примечание: Приведенная выше процедура восстановления подходит и для позднего входа.

Общие рекомендации

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

Рисунок 19. Дублирование каналов связи

Дублирование каналов связи

Восстановление при проблемах в инфраструктуре Биржи

Под такими проблемами понимаются аварии на стороне биржи, связанные с нарушениями в работе ядра ТС или сервисов, формирующих какие-либо рыночные данные. Как правило, это приводит к останову и перезапуску этих сервисов.

Очистка данных по потокам

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

Уведомления об очистке есть двух типов:

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

Дополнительно по каналам, не связанным с самой ТС (система СОИ, новости на сайте биржи и т.п.), будет публиковаться информация о том, были ли в результате исправления ошибочных данных затронуты данные, которые реально попали к пользователям. В частности, был ли откат к состоянию системы до момента аварии, и какой последний номер заявки и сделки после перезапуска системы будет доступен пользователю.

Описание схемы репликации FORTS_PUBLIC

Поток FORTS_TRADE_REPL - Заявки и сделки пользователя (Type=R)

Схема данных

Таблицы:

  • orders_log - Журнал заявок
  • multileg_orders_log - Журнал заявок по связкам
  • user_deal - Журнал сделок пользователя
  • user_multileg_deal - Журнал сделок пользователя по связкам
  • heartbeat - Служебная таблица cерверных часов
  • sys_events - Таблица событий
Таблица orders_log: Журнал заявок

Таблица 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 может принимать следующие значения:

    1

    Buy

    2

    Sell

  • Поле public_action может принимать следующие значения

    0

    Заявка удалена

    1

    Заявка добавлена

    2

    Заявка сведена в сделку

  • Поле id_ord1 содержит номер первой заявки в последовательности перевыставлений заявки со сроком истечения

  • Поле private_action (action) может принимать следующие значения:

    0

    Заявка удалена

    1

    Заявка добавлена

    2

    Заявка сведена в сделку

    3

    Заявка добавлена в результате появления новой видимой части айсберга

  • Поле reason может принимать следующие значения:

    0

    Обычная заявка

    4

    Балансирующие Срочные контракты, заключенные с Добросовестным участником клиринга без подачи заявок

    6

    Закрывающие Срочные контракты, заключенные в рамках процедуры кросс-дефолта

    7

    Закрывающие Срочные контракты, заключенные в связи с неисполнением Маржинального требования

    8

    Закрывающие Срочные контракты, заключенные в связи с неисполнением Обязательства по поставке по поставочным Срочным контрактам на драгоценные металлы

    100

    Иное

  • Поле compliance_id может принимать следующие значения:

    " " (пробел или пустая строка)

    Не заполнено/Не задано

    M

    Ручной ввод

    S

    В результате срабатывания условного поручения (стоп-лосс)

    R

    В результате работы алгоритма-робота

    A

    В результате алгоритма автоследования

    D

    Закрытие позиции в результате не исполненного MarginCall

Таблица multileg_orders_log: Журнал заявок по связкам

Таблица 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 может принимать следующие значения:

    1

    Buy

    2

    Sell

  • Поле public_action может принимать следующие значения

    0

    Заявка удалена

    1

    Заявка добавлена

    2

    Заявка сведена в сделку

  • Поле private_action (action) может принимать следующие значения:

    0

    Заявка удалена

    1

    Заявка добавлена

    2

    Заявка сведена в сделку

    3

    Заявка добавлена в результате появления новой видимой части айсберга

  • Поле reason может принимать следующие значения:

    0

    Обычная заявка

    4

    Балансирующие Срочные контракты, заключенные с Добросовестным участником клиринга без подачи заявок

    6

    Закрывающие Срочные контракты, заключенные в рамках процедуры кросс-дефолта

    7

    Закрывающие Срочные контракты, заключенные в связи с неисполнением Маржинального требования

    8

    Закрывающие Срочные контракты, заключенные в связи с неисполнением Обязательства по поставке по поставочным Срочным контрактам на драгоценные металлы

    100

    Иное

  • Поле compliance_id может принимать следующие значения:

    " " (пробел или пустая строка)

    Не заполнено/Не задано

    M

    Ручной ввод

    S

    В результате срабатывания условного поручения (стоп-лосс)

    R

    В результате работы алгоритма-робота

    A

    В результате алгоритма автоследования

    D

    Закрытие позиции в результате не исполненного MarginCall

Таблица user_deal: Журнал сделок пользователя

Таблица 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 могут принимать следующие значения:

    0

    Обычная сделка

    4

    Балансирующие Срочные контракты, заключенные с Добросовестным участником клиринга без подачи заявок

    6

    Закрывающие Срочные контракты, заключенные в рамках процедуры кросс-дефолта

    7

    Закрывающие Срочные контракты, заключенные в связи с неисполнением Маржинального требования

    8

    Закрывающие Срочные контракты, заключенные в связи с неисполнением Обязательства по поставке по поставочным Срочным контрактам на драгоценные металлы

    100

    Иное

Таблица user_multileg_deal: Журнал сделок пользователя по связкам

Таблица 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 могут принимать следующие значения:

    0

    Обычная сделка

    4

    Балансирующие Срочные контракты, заключенные с Добросовестным участником клиринга без подачи заявок

    6

    Закрывающие Срочные контракты, заключенные в рамках процедуры кросс-дефолта

    7

    Закрывающие Срочные контракты, заключенные в связи с неисполнением Маржинального требования

    8

    Закрывающие Срочные контракты, заключенные в связи с неисполнением Обязательства по поставке по поставочным Срочным контрактам на драгоценные металлы

    100

    Иное

Таблица heartbeat: Служебная таблица cерверных часов

Данная таблица наполняется ядром торговой системы с определенной периодичностью и может быть использована для задач синхронизации (например, для проверки прихода всех сделок за определенный момент времени). Таблица используется в режиме добавления записей; очистка таблицы происходит в ночное время.

Таблица 6. Поля таблицы heartbeat

ПолеТипОписание
replID i8 Служебное поле подсистемы репликации
replRev i8 Служебное поле подсистемы репликации
replAct i8 Служебное поле подсистемы репликации
server_time t Дата и время сервера


Таблица sys_events: Таблица событий

Таблица 7. Поля таблицы sys_events

ПолеТипОписание
replID i8 Служебное поле подсистемы репликации
replRev i8 Служебное поле подсистемы репликации
replAct i8 Служебное поле подсистемы репликации
event_id i8 Уникальный идентификатор события
sess_id i4 Номер сессии
event_type i4 Тип события
message c64 Описание события


Примечания:

  • Возможные типы событий

    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"

    Окончание приема заявок в аукцион открытия

Поток FORTS_ORDLOG_REPL - Поток анонимных заявок (Type=R)

Схема данных

Таблицы:

Таблица orders_log: Журнал заявок

Таблица 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 может принимать следующие значения:

    1

    Buy

    2

    Sell

  • Поле public_action может принимать следующие значения

    0

    Заявка удалена

    1

    Заявка добавлена

    2

    Заявка сведена в сделку

Таблица multileg_orders_log: Журнал заявок по связкам

Таблица 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 может принимать следующие значения:

    1

    Buy

    2

    Sell

  • Поле public_action может принимать следующие значения

    0

    Заявка удалена

    1

    Заявка добавлена

    2

    Заявка сведена в сделку

Таблица heartbeat: Служебная таблица cерверных часов

Данная таблица наполняется ядром торговой системы с определенной периодичностью и может быть использована для задач синхронизации (например, для проверки прихода всех сделок за определенный момент времени). Таблица используется в режиме добавления записей; очистка таблицы происходит в ночное время.

Таблица 10. Поля таблицы heartbeat

ПолеТипОписание
replID i8 Служебное поле подсистемы репликации
replRev i8 Служебное поле подсистемы репликации
replAct i8 Служебное поле подсистемы репликации
server_time t Дата и время сервера


Таблица sys_events: Таблица событий

Таблица 11. Поля таблицы sys_events

ПолеТипОписание
replID i8 Служебное поле подсистемы репликации
replRev i8 Служебное поле подсистемы репликации
replAct i8 Служебное поле подсистемы репликации
event_id i8 Уникальный идентификатор события
sess_id i4 Номер сессии
event_type i4 Тип события
message c64 Описание события


Примечания:

  • Возможные типы событий

    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"

    Окончание приема заявок в аукцион открытия

Поток FORTS_DEALS_REPL - Поток анонимных сделок (Type=R)

Схема данных

Таблицы:

  • deal - Журнал сделок
  • multileg_deal - Журнал сделок по связкам
  • heartbeat - Служебная таблица cерверных часов
  • sys_events - Таблица событий
Таблица deal: Журнал сделок

Таблица 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 являются битовыми масками (подробнее см. раздел Признаки, выставляемые у заявок и сделок)

Таблица multileg_deal: Журнал сделок по связкам

Таблица 13. Поля таблицы multileg_deal

ПолеТипОписание
replIDi8Служебное поле подсистемы репликации
replRevi8Служебное поле подсистемы репликации
replActi8Служебное поле подсистемы репликации
sess_idi4Идентификатор торговой сессии
isin_idi4Идентификатор инструмента-связки
id_deali8Номер сделки
public_order_id_buyi8Идентификатор заявки покупателя (для айсбергов - номер видимой части айсберг-заявки покупателя)
public_order_id_selli8Идентификатор заявки продавца (для айсбергов - номер видимой части айсберг-заявки продавца)
xamounti8Объем, количество единиц инструмента
priced16.5Цена первой части парной связки
rate_priced16.5Ставка сделки
swap_priced16.5Своп-цена сделки
momenttВремя заключения сделки
moment_nsu8Время заключения сделки (UNIX-время в наносекундах по стандарту UTC)
nosystemi1Признак внесистемной сделки
xstatus_buyi8Статус сделки со стороны покупателя
xstatus_selli8Статус сделки со стороны продавца
xstatus2_buyi8Расширение для статусов сделок (в дополнение к полю xstatus_buy)
xstatus2_selli8Расширение для статусов сделок (в дополнение к полю xstatus_sell)


Примечания:

Таблица heartbeat: Служебная таблица cерверных часов

Данная таблица наполняется ядром торговой системы с определенной периодичностью и может быть использована для задач синхронизации (например, для проверки прихода всех сделок за определенный момент времени). Таблица используется в режиме добавления записей; очистка таблицы происходит в ночное время.

Таблица 14. Поля таблицы heartbeat

ПолеТипОписание
replID i8 Служебное поле подсистемы репликации
replRev i8 Служебное поле подсистемы репликации
replAct i8 Служебное поле подсистемы репликации
server_time t Дата и время сервера


Таблица sys_events: Таблица событий

Таблица 15. Поля таблицы sys_events

ПолеТипОписание
replID i8 Служебное поле подсистемы репликации
replRev i8 Служебное поле подсистемы репликации
replAct i8 Служебное поле подсистемы репликации
event_id i8 Уникальный идентификатор события
sess_id i4 Номер сессии
event_type i4 Тип события
message c64 Описание события


Примечания:

  • Возможные типы событий

    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"

    Окончание приема заявок в аукцион открытия

Поток FORTS_FEE_REPL - Поток комиссий и штрафов биржи (Type=AR)

Схема данных

Таблицы:

Таблица adjusted_fee: Комиссии биржи

Таблица 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 Номер сделки по связке


Таблица penalty: Штрафы биржи

Таблица 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 Штраф по сделке продавца


Таблица sys_events: Таблица событий

Таблица 18. Поля таблицы sys_events

ПолеТипОписание
replID i8 Служебное поле подсистемы репликации
replRev i8 Служебное поле подсистемы репликации
replAct i8 Служебное поле подсистемы репликации
event_id i8 Уникальный идентификатор события
sess_id i4 Номер сессии
event_type i4 Тип события
message c64 Описание события


Примечания:

  • Возможные типы событий

    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"

    Денежные средства после промклиринга пересчитаны

Поток FORTS_FEERATE_REPL - Поток точных ставок комиссий биржи (Type=AR)

Схема данных

Таблицы:

  • futures_rate - Точные ставки комиссий по фьючерсам и инструментам-связкам
  • option_rate - Точные ставки комиссий по опционам

  • sys_events - Таблица событий
Таблица futures_rate: Точные ставки комиссий по фьючерсам и инструментам-связкам

Таблица 19. Поля таблицы futures_rate

ПолеТипОписание
replIDi8Служебное поле подсистемы репликации
replRevi8Служебное поле подсистемы репликации
replActi8Служебное поле подсистемы репликации
isin_idi4Уникальный числовой идентификатор инструмента
sess_idi4Идентификатор торговой сессии
exchange_fee_negdeald26.2Точная ставка биржевой комиссии для адресных сделок
exchange_feed26.2Точная ставка биржевой комиссии для анонимных сделок
clearing_fee_negdeald26.2Точная ставка клиринговой комиссии для адресных сделок
clearing_feed26.2Точная ставка клиринговой комиссии для анонимных сделок
exp_clearing_feed26.2

Точная ставка клиринговой комиссии за исполнение контракта.


Таблица option_rate: Точные ставки комиссий по опционам

Таблица 20. Поля таблицы option_rate

ПолеТипОписание
replIDi8Служебное поле подсистемы репликации
replRevi8Служебное поле подсистемы репликации
replActi8Служебное поле подсистемы репликации
isin_idi4Уникальный числовой идентификатор инструмента
sess_idi4Идентификатор торговой сессии
exchange_fee_negdeald26.2Точная ставка биржевой комиссии для адресных сделок
exchange_feed26.2Точная ставка биржевой комиссии для анонимных сделок
clearing_fee_negdeald26.2Точная ставка клиринговой комиссии для адресных сделок
clearing_feed26.2Точная ставка клиринговой комиссии для анонимных сделок
exp_clearing_feed26.2

Точная ставка клиринговой комиссии за исполнение контракта.


Таблица sys_events: Таблица событий

Таблица 21. Поля таблицы sys_events

ПолеТипОписание
replID i8 Служебное поле подсистемы репликации
replRev i8 Служебное поле подсистемы репликации
replAct i8 Служебное поле подсистемы репликации
event_id i8 Уникальный идентификатор события
sess_id i4 Номер сессии
event_type i4 Тип события
message c64 Описание события


Примечания:

  • Возможные типы событий

    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"

    Денежные средства после промклиринга пересчитаны

Поток FORTS_BROKER_FEE_REPL - Брокерские комиссии (Type=I)

Схема данных

Таблицы:

Таблица broker_fee: Брокерская комиссия

Таблица 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 Номер сделки по связке


Таблица sys_events: Таблица событий

Таблица 23. Поля таблицы sys_events

ПолеТипОписание
replID i8 Служебное поле подсистемы репликации
replRev i8 Служебное поле подсистемы репликации
replAct i8 Служебное поле подсистемы репликации
event_id i8 Уникальный идентификатор события
sess_id i4 Номер сессии
event_type i4 Тип события
message c64 Описание события


Примечания:

  • Возможные типы событий

    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"

    Денежные средства после промклиринга пересчитаны

Поток FORTS_BROKER_FEE_PARAMS_REPL - Параметры для расчета брокерской комиссии (Type=I)

Схема данных

Таблицы:

  • broker_fee_params - Параметры для расчета брокерской комиссии
  • sys_events - Таблица событий
Таблица broker_fee_params: Параметры для расчета брокерской комиссии

Таблица 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 может принимать следующие значения:

    sess_id

    Текущие (действующие сейчас) параметры расчета.

    -1

    Добавление новых параметров расчета. Параметры применяются в следующей торговой сессии.

    -2

    Удаление текущих параметров расчета. Параметры удаляются в следующей торговой сессии.

Таблица sys_events: Таблица событий

Таблица 25. Поля таблицы sys_events

ПолеТипОписание
replID i8 Служебное поле подсистемы репликации
replRev i8 Служебное поле подсистемы репликации
replAct i8 Служебное поле подсистемы репликации
event_id i8 Уникальный идентификатор события
sess_id i4 Номер сессии
event_type i4 Тип события
message c64 Описание события


Примечания:

  • Возможные типы событий

    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"

    Денежные средства после промклиринга пересчитаны

Поток FORTS_USERORDERBOOK_REPL - Заявки пользователя: Cрез стакана (Type=R)

В потоке с периодичностью раз в 2 минуты в таблице orders публикуется срез активных заявок, и запись в таблице info с ревизией последней обработанной транзакции из orders_log, номером жизни потока и состоянием публикации среза (поле publication_state). В момент публикации среза поле publication_state принимает значение 0. После того как срез опубликован publication_state принимает значение 1. До момента publication_state=1 данные в таблице orders могут быть неконсистентны.

Схема данных

Таблицы:

  • orders - Таблица активных фьючерсных и опционных заявок
  • info - Информация о стаканах
Таблица 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 может принимать следующие значения:

    1

    Buy

    2

    Sell

  • Поле public_action может принимать следующие значения:

    0

    Заявка удалена

    1

    Заявка добавлена

    2

    Заявка сведена в сделку

  • Поле private_action (action) может принимать следующие значения:

    0

    Заявка удалена

    1

    Заявка добавлена

    2

    Заявка сведена в сделку

    3

    Заявка добавлена в результате появления новой видимой части айсберга

  • Поле reason может принимать следующие значения:

    0

    Обычная заявка

    4

    Балансирующие Срочные контракты, заключенные с Добросовестным участником клиринга без подачи заявок

    6

    Закрывающие Срочные контракты, заключенные в рамках процедуры кросс-дефолта

    7

    Закрывающие Срочные контракты, заключенные в связи с неисполнением Маржинального требования

    8

    Закрывающие Срочные контракты, заключенные в связи с неисполнением Обязательства по поставке по поставочным Срочным контрактам на драгоценные металлы

    100

    Иное

  • Поле compliance_id может принимать следующие значения:

    " " (пробел или пустая строка)

    Не заполнено/Не задано

    M

    Ручной ввод

    S

    В результате срабатывания условного поручения (стоп-лосс)

    R

    В результате работы алгоритма-робота

    A

    В результате алгоритма автоследования

    D

    Закрытие позиции в результате не исполненного MarginCall

Таблица info: Информация о стаканах

Таблица 27. Поля таблицы info

ПолеТипОписание
replIDi8Служебное поле подсистемы репликации
replRevi8Служебное поле подсистемы репликации
replActi8Служебное поле подсистемы репликации
infoIDi8Уникальный ключ
logRevi8Последняя обработанная ревизия на момент формирования среза
lifeNumi4Номер жизни потока
momenttВремя формирования среза
publication_statei1Состояние публикации среза


Примечания:

  • Поле publication_state может принимать следующие значения:

    0

    in progress (данные не готовы)

    1

    done

Поток FORTS_ORDBOOK_REPL - Cрез стакана. Анонимный (Type=R)

В потоке с периодичностью раз в 2 минуты в таблице orders публикуется срез активных заявок, и запись в таблице info с ревизией последней обработанной транзакции из orders_log, номером жизни потока и состоянием публикации среза (поле publication_state). В момент публикации среза поле publication_state принимает значение 0. После того как срез опубликован publication_state принимает значение 1. До момента publication_state=1 данные в таблице orders могут быть неконсистентны.

Схема данных

Таблицы:

  • orders - Таблица активных анонимных заявок
  • info - Информация о стаканах
Таблица 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 Направление