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

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

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

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

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

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

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

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

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

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

Список расчетных и брокерских фирм доступен в таблице dealer потока FORTS_REFDATA_REPL. Список клиентов доступен в таблице investor потока FORTS_REFDATA_REPL. Раскрытие информации о клиентах и брокерах ограничено правами пользователя, запрашивающего информацию.

Кроме того, в различных потоках и таблицах есть ссылки на семисимвольные коды участников или на четырехсимвольные коды брокеров.

Пользователь или логин в системе может быть привязан к разным уровням иерархии участников:

В схеме сообщений-команд (см. раздел Описание команд) есть поле 'broker_code'. Приложение, использующее логин уровня расчетной фирмы, обязано при отправке сообщения заполнять это поле четырехсимвольным кодом брокера SPECTRA. Приложения, использующие логины уровня брокера или клиента, заполнять это поле не обязаны.

Базовый актив представляет собой сущность, к которой привязывается конкретный контракт — акцию, которую необходимо будет передать или получить для инструментов фондовой секции, товар — для инструментов товарной секции или индекс/курс валюты/индикатор для расчетных фьючерсов. Базовый актив содержит атрибуты, общие для всех инструментов, привязанных к нему, а именно:

Базовый актив НЕ ЯВЛЯЕТСЯ ТОРГОВЫМ инструментом.

Информация о базовых активах содержится в таблице fut_vcb потока FORTS_REFDATA_REPL.

Фьючерсные контракты — основной тип торговых инструментов в системе SPECTRA.

Фьючерсы привязаны к конкретному базовому активу. Каждый фьючерс имеет уникальные атрибуты срочности (даты поставки), лота, шага цены и стоимости шага цены.

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

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

Фьючерсы котируются в пунктах цены. Цена в рублях за контракт вычисляется как:

, где

Для фьючерсов с валютой стоимости шага USR, заполняются еще три дополнительных поля:

Каждый торговый инструмент при появлении в системе недоступен для торгов в ближайшие дополнительные торговые сессии (вечернюю и утреннюю), и начинает быть доступным для торгов только в основную торговую сессию (подробнее о торговых сессиях см. раздел Расписание торгов и клиринга). О доступности инструмента для торговли в основную или дополнительные торговые сессии можно узнать из поля signs (признаки) таблицы fut_sess_contents.

Информация о фьючерсах содержится в трех таблицах торгового интерфейса:

Еще одним типом производных финансовых инструментов в системе SPECTRA являются опционы. В отличие от фьючерсов опцион означает не обязанность, а право на покупку (продажу) базового актива, которое может быть реализовано или нет.

Различают колл и пут опционы. Опцион колл (опцион на покупку) – контракт, предоставляющий держателю (покупателю) опциона право купить базовый актив в указанный срок в будущем по фиксированной цене – цене исполнения опциона (страйк). Опцион пут (опцион на продажу) – контракт, предоставляющий держателю (покупателю) опциона право продать базовый актив в указанный срок в будущем по фиксированной цене – цене исполнения опциона (страйк). В качестве базового актива для опционов могут служить активы фондового и валютного рынков (акции, товар, валюта и т.п.), а так же срочные фьючерсные контракты.

Опционы могут быть маржируемого типа, с уплатой вариационной маржи между участниками торгов на основании расчетной цены, определяемой дважды в торговую сессию, и премиального типа, с уплатой премии подписчику опциона в момент совершения сделки (в ближайший клиринг).

По способу исполнения опционы подразделяются на европейские и американские. Европейские опционы можно исполнить только в день истечения срока действия опциона (дату экспирации). Американские опционы отличаются тем, что держатель может реализовать свое право на продажу/покупку базового актива в любой момент, не дожидаясь наступления даты истечения опциона.

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

В настоящий момент в системе SPECTRA поддерживаются европейские премиальные расчетные опционы на спот-активы (акции, товар, валюту и т.п.) и американские маржируемые поставочные опционы на фьючерсы.

Опционы также как и фьючерсы имеют разные даты исполнения, но в отличие от фьючерсов существуют недельные опционы, с исполнением в середине ближайшей недели и в ВК пятницы (опционы на акции американских компаний).

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

Информация об опционах содержится в следующих таблицах торгового интерфейса:

Торговая система SPECTRA поддерживает составные инструменты — инструменты, которые состоят из нескольких взаимосвязанных частей (атомарных инструментов), что позволяет реализовывать широко используемую стратегию торговли на рынке, когда при выполнении сделки по связке у клиента появляются позиции по двум или более инструментам. В настоящий момент в виде составных инструментов реализованы календарные спреды на фьючерсы.

Список имеющихся в системе составных инструментов можно получить из таблицы fut_sess_contents потока FORTS_REFDATA_REPL, проверяя поле multileg_type. Записи, со значением этого поля не равным 0, описывают составные инструменты.

Для получения составных частей инструмента следует пользоваться таблицей multileg_dict потока FORTS_REFDATA_REPL, в которой для каждого составного инструмента существует две или более записей, описывающей отдельные части такого инструмента (Рис. 1). Записи таблицы multileg_dict ссылаются обратно в fut_sess_contents, т.к. составные части инструментов являются обычными инструментами торговой системы. Для каждой составной части также указывается коэффициент, на который умножается объём исходной заявки для получения объёма заявки по составной части. Знак этого коэффициента указывает на направление заявки по составляющей — положительное значение означает, что составляющая будет направлена в ту же сторону, что и заявка по составному инструменту, отрицательное — в противоположную сторону.

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

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

Значение 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).

С точки зрения времени жизни заявки подразделяются на обычные и многодневные. У обычных заявок дата истечения заявки не задана, такие заявки (неисполненные) "живут" до конца текущей торговой сессии. Для многодневных заявок указывается дата истечения (диапазон дат — до года). Такие заявки автоматически перевыставляются в следующую торговую сессию, получая при этом новый номер и ссылку на номер самой первой выставленной заявки. При перевыставлении делаются проверки на наличие инструмента, клиента, достаточности средств. Заявки с истекшей датой автоматически снимаются после завершения вечерней сессии (если она есть в этот день).

Для нужд разработчиков в заявках предусмотрены два дополнительных атрибута:

Примечание: Уникальность значений дополнительных атрибутов заявки торговой системой SPECTRA не анализируется.

Информация о заявках содержится в таблицах orders_log потоков FORTS_TRADE_REPL и FORTS_ORDLOG_REPL.

Таблица orders_log — это история изменений заявок, на каждое изменение заявки добавляется отдельная запись. В таблице orders_log потока FORTS_TRADE_REPL содержится информация только по "своим" заявкам. Под своими заявками здесь понимается:

Данные по своим заявкам раскрываются полностью, включая служебные и пользовательские поля.

При желании пользователь может подписаться на получение таблицы orders_log потока FORTS_ORDLOG_REPL, в этом случае он будет получать всю историю изменений по всем заявкам в системе в анонимном виде.

Возможны следующие операции над заявками:

Адресная заявка — это заявка, адресованная конкретному пользователю. По сравнению с безадресными эти заявки имеют некоторые ограничения в возможности управления заявками и в выборе контрагента:

Сделки в торговой системе заключаются после постановки заявок в случае, если цена в заявке одного направления по инструменту удовлетворяет цене заявки другого направления по тому же инструменту. Ценой сделки считается цена заявки, выставленной раньше. Сделки бывают адресные и безадресные. Многие атрибуты сделок эквивалентны атрибутам заявок. Сделки не изменяются и не удаляются из системы.

Информация о собственных сделках содержится в таблицах 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.

Ниже в таблице приведены сценарии поведения безадресных заявок, приводящих к кросс-сделкам, для различных типов заявок и значений флага "Снять пассивную заявку при кросс-сделке":

Для адресных заявок логика обработки ситуаций с кросс-сделками аналогична. Если кросс-сделки не разрешены (нет признака "Разрешить кросс-сделки" у кого-либо из контрагентов), то в зависимости от значения признака "Снять пассивную заявку при кросс-сделке" у контрагента - автора пассивной заявки (НЕТ/ДА), отклоняется активная заявка либо снимается пассивная.

В случае синтетического матчинга, два стакана с заявками анализируются независимо – т.е. могут быть сняты как одна так и две пассивные заявки. Если для обеих пассивных заявок снятие не разрешено ("Снять пассивную заявку при кросс-сделке"=НЕТ), то отклоняется активная заявка, иначе снимаются (независимо) пассивные заявки, для которых снятие разрешено ("Снять пассивную заявку при кросс-сделке"=ДА).

У снятых пассивных кросс-заявок в поле xstatus выставляется отличительный признак DueToCrossCancel (0x2000).

Торговая система SPECTRA поддерживает составные инструменты (связки) — инструменты, которые состоят из нескольких взаимосвязанных частей (атомарных инструментов), что позволяет реализовывать широко используемую стратегию торговли на рынке, когда при выполнении сделки по связке у клиента появляются позиции по двум или более инструментам. В настоящий момент в виде составных инструментов реализованы календарные спреды на фьючерсы.

Основные особенности торговли связками:

Айсберг-заявка - это разновидность котировочной заявки, у которой определенная часть объема скрыта от рынка (т.е. в стакане), чтобы минимизировать влияние на рыночную цену крупных относительно рынка заявок. Айсберг-заявки появляются в стакане порциями (видимая часть). Когда видимая часть заявки полностью сводится в сделки, тогда "всплывает" очередная порция. Так может повторяться до тех пор, пока вся скрытая часть заявки не будет исчерпана.

Основные особенности айсберг-заявок:

В разрезе поставки фьючерсы бывают трех типов:

В настоящий момент система SPECTRA поддерживает американские опционы на фьючерсы и европейские опционы на акции.

Прекращение обязательств по вечным фьючерсам (ВФ) может осуществляться по требованию одной из сторон путем подачи поручения на исполнение. Вечный фьючерс исполняется в ближайший по сроку исполнения обычный фьючерс на тот же самый спот-актив. Поручения на исполнение вечного фьючерса могут подаваться в течение всей торговой сессии за три торговых дня до последнего дня обращения фьючерса, в который исполняется ВФ. Подача поручений производится с помощь шлюзовой команды FuturesExecutionRequest. Поданные в торговую систему поручения транслируются в шлюзе в таблице fut_exec_orders потока FORTS_REFDATA_REPL.

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

При исполнении позиция по вечному фьючерсу превращается в позицию по обычному фьючерсу, что технически оформляется сделкой закрытия позиции в вечном фьючерсе и сделкой открытия позиции в обычном фьючерсе, которые в таблице сделок помечаются специальными признаками в полях xstatus_sell и xstatus_buy:

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

Для отличия адресных сделок от сделок, формируемых по результатам проверки котировок RFS, следует проверять не только бит Address, но и признак RFSOrder. В заявках и сделках, заключенных в результате сведения котировок из системы RFS, бит RFSOrder поднят, тогда как в адресных сделках этот бит снят.

Для удобства работы бэк-офисов информация в Plaza-2 шлюзах и отчётах синхронизирована. Для этого в отчётах f04_XXYY.csv, f04clXXYYZZZ.csv, o04_XXYY.csv, o04clXXYYZZZ.csv используются поля signs_buy и signs_sell. Эти поля построены на основе битовой маски в Plaza-2.

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

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

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

Торги в системе SPECTRA осуществляются в рамках торговой сессии. Торговая сессия в системе не связана с календарными сутками и включает в себя:

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

Внутри основной торговой сессии существует перерыв, который в реальной системе SPECTRA длится с 14.00 до 14.05 по московскому времени, в течение которого проходит промежуточная клиринговая сессия (промежуточный клиринг). Промежуточная клиринговая сессия нужна для того, чтобы зафиксировать в середине дня новые расчетные цены по инструментам и перечислить вариационную маржу (премию) между участниками клиринга.

В промежуточный клиринг изменяются:

В промежуточный клиринг не изменяются:

Основной клиринг проводится по окончании торговой сессии в период с 18.50 до 19.05 московского времени. В процессе клиринга выполняется:

После основного клиринга производится генерация и рассылка отчетов по итогам текущей торговой сессии.

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

Для уведомления внешних систем о наступлении определенного состояния торговой системы, в потоках репликации транслируется таблица sys_events следующего формата:

Таблица транслируется в следующих потоках репликации:

Правила синхронизации данных следующие - при наступлении глобального события в торговой системе, после генерации всех данных по этому событию всеми подсистемами торговой системы, в таблицы sys_events вставляется запись с одним и тем же event_id, с event_type, соответствующим типу события:

Внешняя система, может подписаться на получение таблицы событий во всех интересных ей потоках репликации и получить уведомление о том, когда данные готовы. Во всех потоках репликации записи в sys_events, относящиеся к одному событию в торговой системе будут иметь одинаковый event_id. В полях sess_id и message выдается расширенная информация – номер новой или текущей торговой сессии и текстовое сообщение. Обращаем особое внимание на тонкости:

Помимо реальной торговой системы SPECTRA, существует игровая система и две тестовых системы: T0 - с версией ТС, аналогичной реальной системе SPECTRA, и T+1 - с аналогичной реальной системе SPECTRA или следующей версией ТС.

Расписание работы игровой системы:

Расписание работы тестовых систем T0 и T+1:

Полное расписание сессий также можно посмотреть в таблице session потока FORTS_REFDATA_REPL или в терминале в таблице "Сессии".

Перед началом утренней дополнительной торговой сессией, в период с 8.50 до 9.00 московского времени в системе SPECTRA проводится Аукцион открытия. Аукцион открытия служит для исключения аномального скачка цен производных инструментов при открытии торгов. Данный механизм реализован в формате дискретного аукциона заявок по единой Цене аукциона открытия. Цена аукциона открытия выбирается из условия обеспечения совершения сделок с максимальным количеством контрактов по объявленным на момент времени проведения аукциона открытия заявкам. Аукцион открытия состоит из периода сбора заявок и матчинга заявок по цене аукциона открытия, определяемой на основании информации обо всех заявках на момент окончания периода сбора заявок.

Основные особенности аукциона открытия:

Информация об аукционах открытия в таблицах торгового интерфейса:

Реализованная в SPECTRA Система Управления Рисками (СУР) позволяет в максимальной степени снизить риск неисполнения обязательств и осуществлять непрерывную оценку уровня рыночного риска позиций каждого участника. Ядром системы является алгоритм расчёта гарантийного обеспечения (initial margin, далее ГО) под открытые позиции и заявки, учитываемые на позиционных счетах участников клиринга и участников торгов.

Одной из ключевых особенностей Системы Управления Рисками SPECTRA является использование онлайн расчёта обеспечения под заявки и позиции, производимого в рамках торговой транзакции. При таком подходе появление в системе необеспеченных заявок и сделок практически исключается, т.к. достаточность обеспечения проверяется до того, как заявка появляется в системе.

Другой важной особенностью Системы Управления Рисками SPECTRA является трехуровневая система позиционных счетов.

Расчетный код – счет верхнего уровня участника клиринга (Расчетной фирмы). Расчетный код является независимой единицей учета средств обеспечения, внесенных участником и(или) его клиентами, а также заявок, поданных в совокупности по всем счетам нижних уровней (суб-счетам), принадлежащих расчетному коду, сделок, заключенных на основании этих заявок, и результирующих позиций. Таким образом, позиция по любому инструменту, учитываемая по расчетному коду, является нетто-суммой всех позиций по этому инструменту, учитываемых на суб-счетах.

Для расчетного кода определяется величина ГО независимо от других расчётных кодов. Все настройки СУР SPECTRA для расчетных кодов контролируются центральным контрагентом (клиринговой организацией).

Во время клиринговой сессии по расчетному коду определяется размер требований и обязательств участника клиринга (вариационная маржа, премия, комиссионные сборы и пр.). Для расчетного кода проверяется достаточность средств обеспечения для покрытия требований ГО.

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

Для каждого участника клиринга (Расчетной фирмы) открывается как минимум два расчетных кода: собственный и клиентский.

Идентификатор расчетного кода в торговой системе SPECTRA – 5 цифр.

Брокерская фирма – суб-счет расчетного кода. Счет следующего уровня, открываемый по заявлению участника клиринга (Расчетной фирмы). Брокерская фирма принадлежит одному и только одному расчетному коду. Привязка брокерской фирмы к расчетному коду может быть изменена на основании заявления участника клиринга в клиринговую организацию. Для того, чтобы расчетный код поднимался в торговую систему SPECTRA, и по нему был бы возможен учет заявок и позиций, к расчетному коду должна быть привязана хотя бы одна брокерская фирма.

В бэк-офисе клиринговой системы SPECTRA по брокерской фирме ведется учет средств обеспечения, внесенных участником и(или) его клиентами на клиентские разделы брокерской фирмы. Информация о размере учитываемого обеспечения доступна в отчетах.

Расчет величины ГО по брокерской фирме производится по умолчанию в режиме полунетто (margin_type =3 для метода ChangeBFParametersNextSession) относительно риска позиций, учитываемых на клиентских разделах этой брокерской фирмы. Для брокерской фирмы возможен расчет величины ГО в режиме нетто (margin_type =4 для метода ChangeBFParametersNextSession). В этом режиме по брокерской фирме для каждого инструмента рассчитывается позиция как нетто-сумма позиций по этому инструменту на всех разделах брокерской фирмы, а также учитываются все заявки в совокупности, поданные по разделам этой брокерской фирмы; по рассчитанным таким образом нетто-позициям и совокупности всех заявок происходит определение величины ГО по брокерской фирме.

Все параметры маржирования брокерской фирмы могут настраиваться участником клиринга (Расчетной фирмой) с помощью метода ChangeBFParametersNextSession.

Специальная Брокерская фирма (СпецБФ) – специальный суб-счет расчетного кода, аналогичный обычным брокерским фирмам, и предназначенный для учета средств обеспечения, внесенных на расчетный код участником и(или) его клиентами, и не учитываемых на разделах обычных брокерских фирм.

Информация о размере учитываемого обеспечения доступна в отчетах.

Также у каждой СпецБФ существует один раздел, называемый ликвидационным разделом СпецБФ. Позиции на ликвидационном разделе могут создаваться только на основании сделок, заключаемых клиринговым центром для урегулирования неисполненных участником клиринга обязательств (например, Маржинального требования по расчетному коду). Участник клиринга (Расчетная фирма) не может подавать заявки с указанием ликвидационного раздела за исключением заявок, направленных на уменьшение открытой на разделе позиции. Также участник клиринга (Расчетная фирма) может переносить позицию (метод TransferClientPosition) с ликвидационного раздела на разделы других брокерских фирм.

Клиентский раздел – суб-счет брокерской фирмы. Счет нижнего уровня, регистрируемый по заявке участника. Является первичным счетом, на котором учитываются заявки, поданные участником и(или) клиентом, заключенные в результате них сделки, и открытые позиции – именно клиентский раздел (код клиента) указывается в транзакциях объявления заявки. По заявкам и позициям, учитываемым на клиентском разделе, определяется величина ГО. Параметры маржирования клиентского раздела могут настраиваться с помощью методов ChangeClientParameters, ChangeClientParametersNextSession и ChangeBFClientDefaultParametersNextSession.

В бэк-офисе клиринговой системы SPECTRA по клиентским разделам ведется учет средств обеспечения, внесенных участником и(или) его клиентом. Информация о размере учитываемого обеспечения доступна в отчетах.

Торговые лимиты ограничивают возможность участника и(или) его клиентов объявлять заявки и открывать позиции на позиционных счетах.

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

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

Торговые лимиты используются для резервирования отрицательной вариационной маржи, списания сборов, списания/зачисления премии, резервирования ГО.

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

Для брокерской фирмы можно изменить режим определения торгового лимита, сделав его независимым от размера средств обеспечения, учитываемых на разделах брокерской фирмы. В таком режиме торговый лимит брокерской фирмы задается с помощью метода ChangeBFLimit. Также торговый лимит брокерской фирмы меняется на размер прибыли или убытка, определяемого во время вечернего клиринга (вариационная маржа, премия, сборы).

Режим определения торгового лимита брокерской фирмы определяется параметром limit_tied_to_money метода ChangeBFParametersNextSession.

Торговый лимит на клиентском разделе не зависит от размера средств обеспечения, учитываемых на этом разделе. Для управления торговыми лимитами на клиентских разделах используется метод ChangeClientMoney. Он обеспечивает следующие возможности:

В общем случае заявка может быть выставлена только при условии, что у всех трех уровней (клиентского раздела, брокерской фирмы и расчетного кода) торговые лимиты достаточны для покрытия требуемой величины ГО. Для брокерской фирмы и клиентского раздела проверку достаточности торгового лимита можно отменить с помощью методов ChangeBFParametersNextSession и ChangeClientMoney соответственно.

Для расчетного кода отключить проверку достаточности торгового лимита (средств обеспечения) невозможно.

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

Автоматические запреты

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

• 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):

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

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

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

Система SPECTRA предоставляет возможность блокировки брокерской комиссии на стороне биржи. Заблокированная комиссия учитывается на клиентском разделе, уменьшая свободные средства клиента (money_free) на величину заблокированной части. Блокировка осуществляется в течение торговой сессии, в вечерний клиринг блокировка сбрасывается.

Брокерская комиссия определяется следующим образом:

, где

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

Режим работы и модель ценообразования опционов задаются на уровне БА (базового контракта) и действуют на все инструменты данного БА. Переключение режимов и модели ценообразования опционов возможно во время клиринговой сессии (ПК или ВК). Для задания режима и риск-модели используются следующие параметры базового контракта:

Значения параметров транслируются в шлюзе в потоке FORTS_REFDATA_REPL в таблицах fut_vcb/opt_vcb.

В режиме запрета отрицательный цен (negative_prices=0), в случае соответствующего решения НКЦ, допускается устанавливать в ручном режиме индикативную текущую рыночную цену, транслируемую в потоке FORTS_COMMON_REPL. От этой цены зависит индикативная текущая вариационная маржа, транслируемая в потоке FORTS_VM_REPL, и текущая теоретическая цена опциона, транслируемая в потоке FORTS_VOLAT_REPL. Для индикации того, что текущая рыночная цена для фьючерса установлена в ручном режиме, используется параметр:

Поля таблиц торгового интерфейса, где в режиме отрицательных цен (negative_prices=1) возможно появление отрицательных значений:

В режиме положительных цен (negative_prices=0), в случае соответствующего решения НКЦ, возможно:

Отрицательные и нулевые значения в торговых кодах инструментов отображаются следующим образом:

Пример кодов со страйком "-10":

Пример кодов со страйком "0":

В терминах SPECTRA сущностью, описывающей участника клиринга, является Расчетная фирма, при этом РФ может принадлежать либо УК, либо УК+УТ.

Участнику торгов соответствуют Брокерские фирмы, открытые в рамках Расчетной фирмы соответствующего участника клиринга. При этом:

У БФ участник торгов может совпадать в одном лице с участником клиринга (УК=УТ), либо не совпадать (УК!=УТ).

Если РФ - УК, у нее могут быть зарегистрированы только БФ, у которых УК не совпадает в одном лице с УТ. Если РФ - УК+УТ, то возможны комбинации форм БФ.

Рисунок 2. Иерархия сущностей

Разделение статусов участников торгов и участников клиринга подразумевает и разделения полномочий участников на торговые и клиринговые. Под полномочиями здесь понимаются права на просмотр информации в шлюзе и права на выполнение операций.

Основные полномочия участника торгов, которые не доступны участнику клиринга - это подача/снятие торговых заявок и заключение сделок на основании поданных заявок. При этом участник клиринга может совершать некоторые действия с заявками, подавая поручения в НКЦ, а уже НКЦ может выставлять заявку от имени участника клиринга, а также снимать другие заявки (подробнее см. раздел 2.7.3. Урегулирование неисполненных обязательств).

Основные полномочия участника клиринга, которые не доступны участнику торгов - это управление обеспечением (вывод обеспечения, перевод обеспечения между расчетными кодами), а также управление риском в отношении участника торгов, возникающим по сделкам, заключенным участником торгов. Управление риском заключается как в определении лимитов для участника торгов, так и в возможности сокращать (рискованную) позицию участника торгов.

Разделение полномочий производится на уровне логина доступа к ТС. Исходя из этого логины могут обладать следующими полномочиями:

Ниже в таблице приведен список полномочий "Логин УК":

Ниже в таблице приведен список полномочий "Логин УТ":

"Логин УК+УТ" обладает совокупным набором полномочий "Логина УК" и "Логина УТ", за исключением подачи Запросов к НКЦ, которые может подавать только "Логин УК".

Участник клиринга может получить логины следующих уровней:

Участник торгов может получить логины следующих уровней:

В зависимости от уровня, полномочия логина могут различаться:

В ситуации, когда участник клиринга и участник торгов разные лица, важным является - кто управляет клиентами (клиентскими разделами). Под управлением клиентами здесь понимается возможность видеть информацию по ним: средства, лимиты и индивидуальные риск-параметры, а также и собственно устанавливать лимиты, запреты, правила экспирации и т.п. Возможны две схемы взаимодействия между УК и УТ с точки зрения управления клиентами:

Схема взаимодействия задается на уровне БФ путем выставления у нее специального признака: "Клиентами управляет УТ"/"Клиентами управляет УК".

Для иллюстрации приведем пару примеров:

Рисунок 3. Примеры

Ниже в таблице приведен список полномочий, относящийся к праву управления клиентскими разделами. Обладать данными полномочиями будут логины, у которых набор полномочий ("Логин УТ" /"Логин УК") совпадает со схемой, заданной у БФ ("Клиентами управляет УТ"/"Клиентами управляет УК").

Также данными полномочиями обладает "Логин УК+УТ".

Участник клиринга не может выставлять и снимать заявки, однако для управления неисполненными обязательствами участника торгов перед участником клиринга, и в том числе, в случае недостаточности обеспечения участника торгов, участник клиринга вправе подавать в адрес НКЦ запросы на заключение сделок с участником торгов. Такой запрос подается участником клиринга с указанием любого клиентского раздела участника торгов. По такому запросу НКЦ выставляет безадресную заявку "в стакан" или адресную заявку, на основании которой будут заключаться сделки.

Технически такой запрос подается в формате обычной торговой заявки, имеющей специальный признак - "Запрос к НКЦ на заключение сделок с участником торгов". Запрос может быть подан как в форме безадресной заявки, так и в форме адресной заявки. Участники торгов ставить (снимать, в том числе массово) заявки с таким признаком не могут. У заявок с признаком "Запрос к НКЦ" в битовой маске признаков выставляется бит 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. Таким образом, все три заявки могут быть удовлетворены корректно.

На Московской бирже сделки заключаются с центральным контрагентом (НКЦ). В нашем примере может быть одновременно заключено три сделки:

Для того, чтобы сделки были заключены, в процессе синтетического матчинга в ядре торговой системы автоматически формируются заявки, поданные от имени НКЦ. Такие заявки называются синтетическими. Синтетическая заявка - заявка создаваемая ядром в ходе синтетического матчинга при выполнении условия сведения заявок. Синтетическая заявка является реальной заявкой, подаваемой центральным контрагентом в торги, и фигурирует в сделках, порождаемых в ходе синтетического матчинга. В анонимных и пользовательских потоках заявок синтетические заявки в полях xstatus помечаются специальным признаком "Synthetic" (0x200000000000).

В рассматриваемом примере формируются следующие синтетические заявки:

Рисунок 4. Стаканы календарного спреда

Синтетическая заявка формируется системой на основании двух реальных заявок, поданных участниками в двух других инструментах. В нашем примере система сформировала синтетическую заявку на продажу по календарному спреду RTS-9.18-12.18 по цене 1000 на основании заявки на покупку по фьючерсу RTS-9.18 по цене 114000 (от участника "B") и заявки на продажу по фьючерсу RTS-12.18 по цене 115000 (от участника "C").

Есть два основных сценария синтетического матчинга:

Кейс 1: Заявки отдельных фьючерсов генерируют синтетическую заявку по календарному спреду.

Пример (см. Рисунок 4, «Стаканы календарного спреда»):

Кейс 2: Заявка на календарный спред и заявка на один из фьючерсов ног этого спреда генерируют синтетическую заявку на другую из ног этого спреда.

Пример (см. Рисунок 4, «Стаканы календарного спреда»):

Таким образом, в зависимости от входящей активной заявки возможны 6 вариантов синтетического матчинга:

Первый приоритет матчинга - это цена. Вне зависимости от типа заявки (синтетическая/реальная) активная матчится с той пассивной, у которой лучше цена. Если у пассивной синтетической и пассивной реальной заявки цены совпадают, то сначала активная заявка матчится с той, что поступила раньше. Так как у календарного спреда две ноги поступают в разное время, то время такого спреда определяется по времени последней поступившей ноги. В каждом стакане (календарного спреда, ближнего и дальнего фьючерсов) цена заключаемой сделки определяется ценой пассивной заявки, как и в текущей реализации.

При синтетическом матчинге строится синтетика любой глубины, необходимой для сведения активных заявок. В агрегированных стаканах по умолчанию индикативно транслируется глубина 5 ценовых уровней, формируемых индикативными синтетическими заявками. Индикативная синтетическая заявка - "виртуальная заявка", используемая для формирования агрегированного стакана, отражающего доступную синтетическую ликвидность. Ударив по такой заявке участник может совершить сделку посредством синтетического матчинга.

Пример

Синтетическая ликвидность транслируется в потоке агрегатов (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.

В отчетах f04, f04cl, o04, o04cl причина сделок урегулирования указана в поле Type.

Отчеты о сделках с фьючерсами f04, f04cl:

Отчеты о заключенных опционных контрактах o04, o04cl:

За сделки урегулирования с Недобросовестных участников клиринга вместо комиссии взимается штраф. Сумма штрафа за заключение закрывающих Срочных контрактов равна сумме 5 биржевых сборов, установленных ПАО Московская Биржа, и 5 комиссионных вознаграждений за клиринг от суммы закрывающих Срочных контрактов. Штраф рассчитывается по каждой сделке урегулирования и учитывается по 7-значному разделу участника клиринга, который указан в сделке урегулирования.

Информация о штрафах транслируется в шлюзе в поле penalty в таблице part потока FORTS_PART_REPL (суммарно по 7-значному разделу), а также в таблице penalty потока FORTS_FEE_REPL (в разрезе сделок).

Штрафы и комиссии за заключение сделок урегулирования от имени Добросовестного участника клиринга (балансирующие Срочные контракты, заключенные с Добросовестным участником клиринга без подачи заявок) с ДУК не взимаются.

Штрафы за заключение закрывающих Срочных контрактов с НУК не взимаются:

Информация по данным блокировкам транслируется в шлюзе в таблице clearing_members потока FORTS_REFDATA_REPL.

Сделки урегулирования, по которым штрафы не взимались по причине аннулирования лицензии на осуществление профессиональной деятельности на рынке ценных бумаг, помечаются в таблицах сделок в полях xstatus_sell и xstatus_buy специальным признаком:

Информация о сумме штрафа включается в виде нового типа платежа в отчеты pay в дату списания. Штрафы учитываются в отчете в состоянии текущей денежной позиции. Отчеты:

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

Премиальные опционы имеют стоимость и (по просьбам участников) будут использоваться в качестве обеспечения по портфелю, а также влиять на объём свободных средств (FreeMoney). Величина корректировки FreeMoney будет доступна в виде нового параметра NetOptionValue (NOV), который будет рассчитываться в ближайшую клиринговую сессию как сумма произведений учетных стоимостей и объемов соответствующих опционных позиций в портфеле с учетом знака:

Величина 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 (опционы).