Clearing firms are firms which incur liabilities for risks and cover risks of their clients and sub-brokers.

Clearing firms are authorized to:

Clearing firms are obliged to:

Unlike clearing firms, brokerage firms do not settle up with exchange directly; instead, they use their clearing firms. Also, brokerage firms are not obliged to obtain licences and pay fees to the Guarantee Fund.

Brokerage firms are authorized to:

Brokerage firms are obliged to:

Any physical or corporate person can participate in the SPECTRA market as a client on the authority of trading service agreement signed with a brokerage firm or with clearing firm directly.

There is a 7-symbol code pattern (XXYYZZZ) to identify each participant in the system, where

The 00 brokerage firm code indicates state of account of the clearing firm.

The 000 client code indicates state of account of the brokerage firm.

The list of clearing and brokerage firms is stored in the 'dealer' table of the 'FORTS_REFDATA_REPL stream, and the list of clients is stored in the 'investor' table of the FORTS_REFDATA_REPL stream. Disclosure of data on brokerage firms and clients is limited in accordance with user access rights.

Streams and tables also contain links to 7-symbol clients' codes and 4-symbol brokerage firms' codes.

A user (login) can be associated with various levels of participants:

There is a special 4-symbol 'broker_code' field within the scheme of message-command (see Commands description). Every application using the clearing firm account is to fill in this field with a 4-symbol code of a brokerage company registered with SPECTRA when sending messages. Applications which use the client or the brokerage firm account are exempt from this rule.

An underlying asset is an entity related to a certain contract. Therefore, it can be a stock in a stock exchange, a lot of tradable commodity in a commodities exchange or an index/exchange rate/indicator for settling futures. There are certain attributes characterising an underlying asset along with its instruments, which are:

An underlying asset IS IN NO WAY A TRADING INSTRUMENT!

Data concerning underlying assets are contained in the 'fut_vcb' table of the 'FORTS_REFDATA_REPL stream.

Futures contracts are the main trading instruments in the SPECTRA system.

Each futures contract is linked to a certain underlying asset and has its own unique characteristics of the maturity (the date of delivery), lot characteristics, minimum price step and cost of the price step value.

Delivery dates for futures in the trading system are set at three-month (quarterly futures) or monthly (monthly futures) intervals. There can be more than one futures contract for each underlying asset.

Futures contract with various dates of delivery may form a calendar spread. In this case, when risks are calculated, the price correlation is always taken into account. As a result, the total collateral for the spread can be less than sum of collaterals for each futures contract itself.

Futures are quoted in price points. The price in roubles for a contract is calculated as following:

, where:

Three more fields are required to fill when it comes about future contracts quoted in USR:

When an instrument has successfully added into the trading system, it is not yet available for trading in the nearest additional trading sessions (in the evening and in the morning); thus, the instrument will be available for trading starting the nearest main trading session (for more info, see Trading and clearing schedule). For information about instruments availability for trading in the additional/main trading session please refer to the value in the field ‘signs’ of table 'fut_sess_contents'.

Futures contract data ara stored in following tables of trade interface:

Options are another type of derivative financial instruments in the Spectra system. Unlike futures, an option does not mean an obligation, but the right to buy (sell) the underlying asset, which can be realized or not.

Distinguish between Call and Put options. A Call option (purchase option) is a contract that gives the holder (buyer) of the option the right to buy the underlying asset at a specified time in the future at a fixed price - the option exercise price (strike). A Put option (option to sell) is a contract that gives the holder (buyer) of the option the right to sell the underlying asset at a specified time in the future at a fixed price - the option exercise price (strike). Assets of the Securities and FX markets (shares, commodities, currencies, etc.) and futures contracts can serve as the underlying asset for options.

Options can be of the futures-style, with the payment of a variation margin between trading participants based on the settlement price determined twice per trading session, and of the equity-style, with the payment of a premium to the option subscriber at the time of the performing of the trade (at the next clearing).

According to the method of exercise, options are divided into European and American. European options can be exercised on the expiration date of the option only. American options differ in that the holder can exercise his right to sell/buy the underlying asset at any time without waiting for the option expiration date.

Options can be deliverable or cash-settled. A deliverable option involves physical delivery.. The cash-settled option does not involve delivery, but provides for the recalculation of profit/loss between the participants in the form of accrual and write-off of funds.

The SPECTRA system currently supports European premium cash-settled options on spot assets (shares, commodities, currencies, etc.) and American margined deliverable options on futures.

Options, like futures, have different exercise dates, but unlike futures, there are weekly options, with exercising in the middle of the nearest week and Friday evening clearing (equity options of US companies).

For options for trading, a certain subset of strikes is assigned, which lies in the vicinity of the current settlement price of the underlying asset to which the option is linked, therefore, the list of options assigned for trading, in general, can be different every day.

Options data are stored in the following tables:

The SPECTRA system supports multi-leg trading instruments, i.e. the instruments consisting of more than one components. This allows to use a trading strategy, when a client gets additional positions on two or more instruments when trade is complete. The instruments available now are calendar spreads for futures.

The list of the multi-leg instruments available in the system can be obtained in the 'fut_sess_contents' table of the 'FORTS_REFDATA_REPL' stream, by looking at the 'multileg_type' field. If a value in the field is not equal 0, than the record describes a compound instrument.

To obtain the list of components of compound instruments you should use the 'multileg_dict' table of the 'FORTS_REFDATA_REPL' stream, where every multi-leg instrument has two or more entries describing components of such instrument (see pic. 1). The 'multileg_dict' table entries refer back to 'fut_sess_contents', because the components of these instruments present as common trading instruments. We indicate a special coefficient for every single part, which should be multiplied by the amount from initial order to acquire the amount of a compound part of the order. The sign of this coefficient indicates the direction of order of the component — a positive value means that the component will be in the same direction as in the order by a multi-leg instrument, while a negative value means the opposite direction.

Figure 1. Multileg instruments

The SPECTRA system has four fields to identify each instrument:

A value in the 'isin_id' field is the primary unique instrument's code, which is used throughout of data structure of the system wherever a corresponded reference exists.

The 'isin' field contains the main symbol futures' code, which is used in order's instructions. The uniqueness and invariability in time of the 'isin' value is guaranteed.

The 'short_isin' field is an alternative symbol contract code. It has been implemented in order to ease access to the SPECTRA system data for news agencies.

Order — a command, which is sent into the trading system by a trading participant, aimed to perform an action of buying or selling an instrument at specified price. There are two main types of orders available: negotiated and system.

System orders — a common type of orders available for all users of the system. System orders have to participate in auction along with offsetting orders. If there is an offsetting order available for any system order at a better or equal price, the order itself has to be exercised at the price equal to that of the offsetting order. The unexercised part of the order remains in the system as an order with less amount of instruments.

Orders can be subdivided into three types: day, immediate-or-cancel, fill-or-kill and book-or-cancel orders. A day order remains in queue after it has been fully or partly exercised. An immediate-or-cancel orders have to be removed from the system after auction ended, no matter whether it has been exercised fully or partly. At last, the fill-or-kill orders — the immediate-or-cancel orders which can only be exercised fully. Book-or-Cancel (BOC) - this is a kind of quote order, which either completely gets into the order-book, or is rejected by the system. Such an order can only be a passive side in the trade (Maker).

All orders can be also subdivided into common and multy-day orders, in accordance with their lifetime. Common orders do not have the date of expiration specified; such orders remain in queue until the end of the current trading session. Contrary, the expiration date for multi-day orders is specified, ranged from 1 day up to one year. Such orders are relisted automatically at opening of the next session; additionally each order receives a new ID and a link to the initial order's ID. When relisting, the orders are checked for having sufficient instrument, client and funds. Orders which are out-of-date are automatically removed after the evening session ends.

There are two additional fields added to meet the developers' needs:

Note: The SPECTRA system does not check values of the additional fields for being unique.

Orders data are stored in the 'orders_log' tables of the 'FORTS_TRADE_REPL' and 'FORTS_ORDLOG_REPL' streams. The tables contain orders changing log, where every change is recorded as a separate record in the table. The table 'orders_log' of the stream 'FORTS_TRADE_REPL' contains information on the 'own' orders only. The 'own' orders are:

Users can view all data on the 'own' orders, including data in service fields and user fields.

Clients are able to be subscribed for receiving the table 'orders_log' of the stream 'FORTS_ORDLOG_REPL; in this case, they will receive complete history of changes for all orders in the trading system in anonymous mode.

Users can do the following:

An order addressed to a certain client are called negotiated order. Unlike system orders, negotiated orders have some limitations for users in managing orders and selecting counterparts, namely the following:

Within SPECTRA trading system, a trade will be performed if an instrument price in one order meets the instrument price in an opposite order, i.e. sell or buy one for the same instrument. The price of the order settled first is the price of the trade. There are two types of trades: negotiated and system. Many trade's attributes are equivalent of that of the orders. Trades cannot be edited, or deleted from the system.

Data on own trades are stored in tables 'user_deal' and 'user_multileg_deal' of stream 'FORTS_TRADE_REPL'. The data on all trades in the system are distributed in accordance with the following rules: a user gets access only to their own part of the trade (buyer's or seller's). If a user acts as a brokerage firm, or a clearing firm, and both buyer and seller parts are the clients of the same firm, the user gets access to the data concerning both parts of the trade. Data on all trades are available for all users in tables 'deal' and 'multileg_deal' of stream 'FORTS_DEALS_REPL'. All data in tables are anonymised.

Along with the records containing the trades-related data, there are some additional records stored in tables containing trades data. These records cannot be classified as trades legally, but still they render some transactions within the system, which influence the participant's status. These trades are so called 'technical trades'. One can tell trading trades from the technical ones by values in fields 'xstatus_sell' and 'xstatus_buy' in tables 'user_deal' and 'user_multileg_deal' of stream 'FORTS_TRADE_REPL', or by the flag nosystem in table 'deal' and 'multileg_deal' of stream 'FORTS_DEALS_REPL' (for details see Flags applied to orders and trades).

Cross-trade is a trade based on orders submitted from the same client account, or submitted from different accounts with the same TIN. By default, cross-trades are prohibited and rejected by the system. Cross-trades are allowed on an individual basis for negotiated orders. The system also provides the ability to cancel a passive order, rather than an active one, when a cross-transaction occurs.

The system provides two flags to determine the logic of processing cross-trades:

These flags are set at the level of the seven-digit client account based on the trading member's application. The set flags are broadcast in the gateway in the 'xstatus' field of the 'investor' table of the FORTS_REFDATA_REPL stream.

The table below shows scenarios for the behavior of anonymous orders leading to cross-trades for various types of orders and the values of the 'Cancel a passive order in a cross-trade' flag:

The logic of processing situations with cross-trades is similar for negotiated orders. If cross-trades are not allowed (none of the counterparties has the 'Allow cross-trades' flag), then, depending on the value of the 'Cancel a passive order in a cross-trade' flag of the counterparty - the author of the passive order (NO/YES), the active order is rejected or the passive one is cancelled.

In the case of synthetic matching, two orderbooks with orders are analyzed independently – that is, both one and two passive orders can be cancelled. If cancellation is not allowed for both passive orders ('Cancel a passive order in a cross-trade'=NO), then the active order is rejected, otherwise the passive orders for which cancellation is allowed are cancelled (independently).('Cancel a passive order in a cross-trade'=YES).

The cancelled passive cross-orders have a distinctive signe 'DueToCrossCancel' (0x2000) in the 'status' field.

The SPECTRA system supports multi-leg trading instruments, i.e. the instruments consisting of more than one components. This allows to use a trading strategy, when a client gets additional positions on two or more instruments when trade is complete. The instruments available now are calendar spreads for futures.

The main specifics of multi-leg instruments trading:

An Iceberg order is a variation of a quote order. It allows you to hide a part of its volume from the market (that is, in the Order-book window) to minimize the impact on the large orders market price. Iceberg orders appear in the order-book in portions. The next portion "pops up" only after the visible part of the order will be executed. This process can be repeated until the whole hidden part is used.

The iceberg orders main features:

There are three types of futures exist in terms of deliveries:

At present, the SPECTRA system supports American futures options and European equity options.

Termination of obligations under perpetual futures can be carried out at the request of one of the side by submitting requests for exercise. A perpetual futures is exercised turning into the nearest standard future on the same spot asset. Requests for exercise of a perpetual futures can be submitted during the entire trading session three trading days before the last day of the futures circulation on which the perpetual futures is exercised. The gateway command FuturesExecutionRequest is used for submit requests. Requests submitted to the trading system are transmitted in the gateway in the 'fut_exec_orders' table of the FORTS_REFDATA_REPL stream.

The exercising of the perpetual futures is carried out in the evening clearing session of the day of the requests submission. The perpetual futures exercising consists of matching counter requests for exercising and, in case of unsatisfied requests for exercise and open positions with the opposite direction in the market, the procedure for their forced matching.

When exercising, a perpetual futures position becomes a common futures position. Technically, a position closing trade in a perpetual futures and a position opening trade in the nearest futures are formed, which are marked with special signs in the trades table in the 'xstatus_sell' and 'xstatus_buy' fields:

Flags applied to orders and trades:

In order to distinguish negotiated trades from indicative trades, it is recommended to check both 'Address' and 'RFSOrder' flag status. Please note that flag 'RFSOrder' is active for orders and trades resulting from matched indicative quotes (RFS), and inactive for negotiated trades.

The data in the Plaza-2 gateways and reports are synchronized for providing convenience work of the back-offices. The 'signs_buy' and 'signs_sell' fields is used in the f04_XXYY.csv, f04clXXYYZZZ.csv, o04_XXYY.csv, o04clXXYYZZZ.csv reports. This fields is based on the bitmask of Plaza-2.

Since version 7.9, the following signs of orders and trades, are not currently used, will be redefined and used for other purposes:

Trade types, created upon execution and expiration of futures and options are listed in the table below:

Trades are shown as following:

In the SPECTRA system, the trading session is subdivided into two parts (not related to the astronomical day!), which are:

During a trading session, the same trading instruments are traded and the same parameters are used to calculate the collateral to pledge. There are very important operations taking place in the SPECTRA system between the two sessions: clearing, contracts expirations, reports generating and forwarding and many others.

There is a gap in the main trade session (2 PM - 2.05 PM, Moscow time), during which the intermediate clearing session takes place. It is used to fix new settlement price for instruments and transfer variation margins (premium) to members.

The following values are changed during the intermediate clearing:

The following values are not changed during the intermediate clearing:

The main clearing session is taking place in the end of the trading session, from 6.50 PM till 7.05 PM (Moscow time). The following operations are performed:

After the main clearing session has finished, the corresponding reports are generated and sent out.

If a developed system demands the possibility of synchronizing the consistent states of data, then the event-sensitive scheme should be used. The following events are used to start synchronization:

The 'sys_events' table is translated in the replication streams in order to inform outer systems about the events occurred

The table is translated into the following replication streams:

The rules of the synchronization are the following: when a global event occurs in the system, and when all the data regarding this event are generated by all the subsystems, the new record is added to the 'sys_event' table containing the same 'event_id' value, with the 'event_type' value corresponding to the following event occurred:

An outer system may subscribe to receive the event table via all the available replication streams; when the data are ready, a notification will be sent to the outer system. The 'sys_event' table records, relating to the same event, will have the same 'event_id' field value in every replication stream. There are additional data available in the 'sess_id' and 'message' fields: the number of the current or upcoming trading session and a text message, respectively. Please also note that:

Along with the SPECTRA trading system run in production mode, there are also a game trading system, and two test trading systems, i.e. T0, with the same trading system version as of that run in production mode, and T+1, with the trading system version is either the same as of that run in production mode, or the same as of the next planned one.

X-points — a point on the arrow of time, upon reaching which the negotiated trades are allowed only when both seller and buyer are clients of the same brokerage firm. This period of time is necessary for brokers to close all the positions, where deliveries are physically impossible.

Game system schedule:

Test systems T0 and T+1 schedule:

For the detailed sessions schedule please refer either to table 'session' of stream 'FORTS_REFDATA_REPL', or to the table 'Session' available via the trading workstation (trading terminal).

Before the start of the early additional trading session, in the period from 8.50 to 9.00 AM Moscow time, an opening auction is held in the SPECTRA system. The opening auction is used to exclude an abnormal jump in the prices of derivatives at the opening of trading. This mechanism is implemented in the format of a discrete auction of orders submitted to the opening auction at a single opening auction price. The opening auction price is selected from the condition for performing trades with the maximum number of contracts for the orders announced at the time of the opening auction. The opening auction consists of a period for collecting orders and matching orders at the opening auction price, determined based on information about all orders at the end of the orders collection period.

The main parameters of the opening auction:

Information about opening auctions in the tables of the trading interface:

The Risk Management System implemented into SPECTRA allows to dramatically reduce risks of non-fullfilment of obligations by permanent evaluation of market risks for every participant's position. The core of the system is the initial margin (hereinafter also referred to as IM) calculation algorithm, applied to open positions and orders recognized on clearing and trading participants' position accounts.

One of the key features of the SPECTRA Risk Management System is the calculating initial margin on orders and positions per one trading transaction in online mode. Therefore, it is almost impossible for non-pledged orders and trades to appear in the system, because the initial margin is always verified before any relating order appears in the system.

Another important feature of the SPECTRA Risk Management System is the three-level calculating scheme, in accordance to which the position accounts are subdivided into three groups:

Settlement Account - the upper-level account of a clearing participant (i.e. Clearing Firm). The Settlement Account is an independent account for recognizing collateral assets margined by a trading participant (and/or their clients), orders added for all lower-level accounts (sub-accounts) belonging to the Settlement Account, trades performed basing on these orders, and resultant positions. Therefore, a position for an instrument recognized under the Settlement Account is equal to the net amount of all positions for the given instrument which are recognized under the sub-accounts.

The amount of initial margin for a Settlement Account is calculated independently of the other settlement account. All settings of SPECTRA Risk Management System are specified by the Central Counterparty (clearing firm).

During a clearing session, the system calculates the clearing participant's obligations and requirements (variation margin, premium, commission fees, etc.). Also, the system calculates collateral sufficiency to meet initial margin requirements.

Settlement accounts are subdivided into three sections:

For each clearing participant (Clearing Firm), there are at least two Settlement Accounts assigned: own and client.

Each Settlement Account will be identified by trading system SPECTRA in accordance with its unique 5-digit code.

Brokerage Firm - a sub-account of a Settlement account, which can be set up upon application by the clearing participant (Clearing Firm). Each Brokerage Firm belongs to a single Settlement Account, where the Settlement Account is subject to change upon the clearing participant application applied to the clearing entity. To make a Settlement Account available in SPECTRA , there should be at least one Brokerage Firm bound to it.

The clearing system of SPECTRA recognizes the initial margin deposited by a client, and/or their clients to client section of the Brokerage Firm. Detailed information on initial margin values are available in reports.

By default, initial margin value is calculated in half nett mode (margin_type =3 in command ChangeBFParametersNextSession) in accordance with risk values for positions recognised at client sections of Brokerage Firm. Nett mode is also available for Brokerage Firm for initial margin calculation (margin_type =4 in command ChangeBFParametersNextSession); using this mode, the initial margin value of a Brokerage Firm will be calculated according to nett sum of all positions for the given instrument at all sections of the Brokerage Firm, and total amount of orders added for sections of the Brokerage Firm.

All margining settings of a Brokerage Firm can be changed by a clearing participant (Clearing Firm) using the command ChangeBFParametersNextSession.

Separate Brokerage Firm (SBF) - a separated sub-account of a Settlement account, similar to common Brokerage Firms, purposed for recognizing collateral assets deposited by a client, and/or their clients, and not recognized at any section of common Brokerage Firms.

Detailed information on initial margin values are available in reports.

Also, each SBF contains a special account called liquidation account, which is purposed to recognize positions based upon trades performed by Clearing Centre in order to handle obligations unperformed by a clearing participant (for example, an unperformed Margin Call requirement for the Settlement Account). None of clearing participants (a Clearing Firm) is able to add orders with the liquidation account specified; excluding the orders aimed to lower the amount of an opened position for the given account. Also, clearing participants (Clearing Firms) are able to transfer positions from the liquidation account to other Brokerage Firms' accounts (command TransferClientPosition).

Client Account - a sub-account of Brokerage Firm. The low-level account, which can be opened upon the application by client, and specified as the 'client code' in order adding transaction. This is the primary account to recognize orders added by participant and/or client, trades performed upon these orders, and open positions; the initial margin value will be calculated using these orders and positions. One can change Client Account margining settings via commands ChangeClientParameters, ChangeClientParametersNextSession, ChangeBFClientDefaultParametersNextSession.

The clearing system of SPECTRA recognizes the initial margin deposited by a client, and/or their clients to a Client Account. Detailed information on initial margin values are available in reports.

Trading limits are aimed to restrict a participant, and/or their clients, from adding orders and open positions for position accounts.

Trading limit for a Settlement Account can be calculated based upon total imputed value of IM recognized for the given Settlement Account, i.e. total value of IM recognized for all sub-accounts of the given Settlement Account. Collateral assets may consists of Russian Rubles, foreign exchanges, and securities.

Trading limit for a Settlement Account can be changed by depositing, withdrawal, or transferring collaterals, based upon requests applied to the clearing entity, or clearing depositary (as well as to other settlement entities, once there have been any collateral deposited) by participant via the appropriate EDM systems. Another way to change trading limit is to transfer collateral (Russian Rubles) from one sub-account of Settlement Accounts (Brokerage Firm/Separated Brokerage Firm) to another using command ExchangeBFMoney.

Trading limits are used to reserve negative variating margins, withdraw fees and premiums, accrue premiums and reserve collaterals.

By default, trading limit for a Settlement Account (similar to that of Settlement Accounts) will be calculated based upon total imputed value of IM recognized for sub-accounts of a Brokerage Firm. Collateral assets may consists of Russian Rubles, foreign exchanges, and securities. To change trading limit of a Brokerage Firm, please use command ChangeBFMoney.

For a Brokerage Firm, it is possible to switch trading limit calculation mode, in order to calculate the trading limit independently of value of IM recognized for the Brokerage Firm's sub-accounts. To switch to that mode, please use command ChangeBFLimit. Also, trading limit will be changed in accordance with the profit/loss value resulted from the evening clearing session (variation margin, premium and fees).

To change trading limit mode, please use setting 'limit_tied_to_money' of command ChangeBFParametersNextSession.

Trading limit for Client Account does not depend on IM value recognized for the given account, To manage trading limits for Client Accounts, please use command ChangeClientMoney, with the following possibilities:

As a rule, one is able to add an order only if there are sufficient limits to cover the required IM for all three levels (CLient Account, Brokerage Firm, Settlement Account). It is possible to switch off the limit sufficiency verification for Brokerage Firm and Client Account using commands ChangeBFParametersNextSession and ChangeClientMoney, appropriately.

Please note that it is not possible to switch off the limit sufficiency verification for a Settlement Account.

The SPECTRA system provides an opportunity to introduce additional restrictions on client's trading operations, which are formulated in the system as prohibitions.

Automatic prohibitions

Also, the system provides possibilities of automatic prohibition on opening positions and adding orders in case of occurrence of a large negative trading limit. The following parameters are used to manage the prohibition settings:

• Pr_state - Automatic prohibition application; 0 - do not apply prohibition, 1 - apply prohibition.

• Pr_type - Prohibition type; 0 - prohibition on opening positions, 1 - prohibition on adding orders.

• Pr_coeff - Multiplying coefficient; a positive fractional number with an accuracy of 2 decimal places.

• Del_ord - Action on applying the prohibition; 0 - do not cancel orders, 1 - cancel orders.

The settings can be applied by a clearing participant acting on behalf of a Brokerage Firm. There are two sets of parameters available for applying prohibitions, with one set is applicable for the Brokerage Firm's clients, and the other one is applicable for the Brokerage Firm as a whole.

The prohibition settings are applied based on a clearing participant's request sent to the Clearing Firm using the appropriate electronic document flow systems. The new settings will be applied at the next clearing session. Please note that the prohibition request should be sent not later than 1 hour prior to the clearing session.

Apply prohibitions. After the limits have been extended during the evening and intraday clearing sessions, the prohibition will be automatically applied for the appropriate 7-symbol client section, or Brokerage Firm, when all the following conditions are met simultaneously:

, where

• Limits_set – Client limit verification setting;

• Trade_limit – Trading limit, i. e. funds and collateral, including liquidity ratio.

• FreeMoney – Free funds available for the client section/Brokerage Firm

The prohibition type is specified via parameter 'Pr_type'. If 'Del_ord=1', then all active orders will be automatically cancelled at applying the prohibition. Limit verifications are held independently for the Brokerage Firm and for the clients.

Cancel prohibitions. The applied prohibitions cannot be cancelled by the Brokerage FIrm; instead, the prohibitions will be cancelled automatically following the every minute verification result, when there is at least one condition met:

Example. If a prohibition is set on opening positions, a client is able to cancel the orders, or close the position which causes the increased collateral requirements. The prohibition then will be automatically cancelled in not more than a minute.

One is unable to cancel prohibitions during the night sessions (12 AM - 09 AM Moscow time), despite the availability of trading system.

By default, prohibitions are disabled from being set for all Brokerage Firms (Pr_state=0).

The SPECTRA system provides possibility to transfer a positions from one Brokerage Firm client to another client of the same Brokerage Firm.

To transfer a position from one clearing register to another, a clearing participant should add a new transaction into the Trading system.

Verification procedures on position transfer are the same as that of adding an order. Additionally, it is verified that volume of the position to be transferred does not exceed that of the donor account. Also, the VAT/personal data (including separated brokerage firms accounts) must be equal for both accounts.

Technically, the position transfer is a trade, performed between a donor account and a recipient account. Juridically, it is not a trade (for details see Trade types, created upon exercising and expiration of futures and options). Position transfer is visible both in the gateway and in the reports (f04/o04).

Technically, the following actions take place in the SPECTRA system when pausing trading:

The corresponding notifications are sent on every action listed above (see the 'sys_message' table of the 'FORTS_REFDATA_REPL' stream):

Attention! Starting from version 7.9 in the SPECTRA system, the service for informing participants about the forecast values of risk parameters (ForecastIM) is deprecated with the subsequent removal of the service in version 7.15.

The Trading System provides risk parameters forecast information to the trading participants (via service ForecastIM). The service recalculates the Initial Margin value at a specified time interval, forecasting a new most probable value which would occur after the limits were extended. Then, the new data will be transmitted to the trading participants.

This will be done in the following steps:

If the limits have been already extended twice for the same instrument during a single trading session, there will be no more risk parameters forecasted and forecast information transmitted for this given instrument during this trading session.

The SPECTRA system allows the broker to block part of the client fee on the exchange side. The blocked fee is taken into the client account, reducing the client’s free funds (money_free) by the amount of the blocked part. The blocking is carried out during the trading session and is reset in the evening clearing.

Brokerage fee is calculated based on the exchange fee. The brokerage part of the fee is calculated according to the following formula for each trade:

The broker can set 'lower_fee', 'upper_fee', 'multiplier' and 'additive' parameters using the command SetBrokerFeeParamNextSession. Parameters can be set for an individual client and for the entire brokerage firm. The parameters set for the BF are used in the calculation for all of its clients. The set parameters will be applied in the next trading session. The set parameters are broadcast in the gateway in the stream FORTS_BROKER_FEE_PARAMS_REPL.

For example, the broker always takes half the exchange fee - then 'multiplier' = 0.5, 'additive' = 0, 'lower_fee' = 0.01, 'upper_fee' = inf. Or the broker always takes 2 rubles for any contract - then 'multiplier' = 0, 'additive' = 2, 'lower_fee' = 2, 'upper_fee' = 2.

The brokerage fee is broadcast in the gateway in the table 'part' of the stream FORTS_PART_REPL (total by client) and in the stream FORTS_BROKER_FEE_REPL (by trades).

Starting from this release SPECTRA supports negative prices, i. e. correct system behavior if futures prices and options strikes fall below zero during trades or as the result of clearing. There are two different modes for every underlying asset:

Mode and option pricing model are set on underlying contract level and are effective for all instruments of this underlying contract. Modes and option pricing models can be switch during the clearing session. To set the mode and risk model the following parameter of underlying contract is used:

Current parameter values is published in the 'fut_vcb'/'opt_vcb' tables of FORTS_REFDATA_REPL data stream in the gateway.

In the prohibition mode of negative prices (negative_prices = 0), if the NCC decides accordingly, there is a possibility to manually set indicative current market price, which is published in FORTS_COMMON_REPL data stream. This price affects indicative current variation margin translated in FORTS_VM_REPL stream and current theoretical options price published in FORTS_VOLAT_REPL stream. To indicate that current market price for futures is set manually the following parameter is used:

Fields of the trading interface tables, where negative values may appear in the negative prices mode ('negative_prices' = 1):

In the positive prices mode ('negative_prices' = 0), in the case of an appropriate decision by the NCC, it is possible:

Negative and zero values in the instruments trading codes are displayed as follows:

The codes with strike "-10":

The codes with strike "0":

Inside SPECTRA, Clearing Member is represented by a Clearing FIrm; the Clearing Firm itself may act either as Clearing Member, or as an entity representing both Clearing Member + Trading Member.

A Trading member is represented by Brokerage firms of a Clearing Firm which belongs to the appropriate Clearing Member. Also:

For a Brokerage Firm, Trading Member may be either of the same entity as Clearing Member (CM=TM), or of different entities (CM!=TM).

If a Clearing Firm acts as Clearing Member, it may have only those Brokerage Firms where Trading Member and Clearing Member are of different entities (CM!=TM). If a Clearing Firm act as Clearing Member + Trading Member (CM+TM), it may have Brokerage Firms where Trading Members either of the same entity as Clearing Member, or of a different entity.

Figure 2. Hierarchy

Following the separation of Clearing and Trading Member entities, the Member's rights are also separated for the Clearing Member and Trading Member. Therefore, different Members are granted with different rights to view data in and perform operations.

The basic rights granted to Trading Member (and not available to Clearing Members) include possibility to add/cancel exchange orders and perform trades based on the added orders. Clearing Member, on their side, is also able to perform actions with orders indirectly via submitting requests to NCC, while NCC will add orders acting on behalf of the Clearing Member, and cancel other orders (for details see 2.7.3. Reconciliation of unfulfilled obligations).

The basic rights granted to Clearing Member (and not available to Trading Members) include possibility to manage collateral (i.e. withdraw collateral, and transfer collateral between settlement accounts), and also manage risks for Trading Members (when risk occurs for trades performed by the Trading Member), where by risk management we mean setting limits for the Trading Member, and ability to reduce (troubled) positions of the Trading Member.

The Members' rights are separated for different the SPECTRA logins. Therefore, the following rights are granted to the logins:

Below there is the list of rights for 'Login CM':

Below there is the list of rights for 'Login TM':

'Login CM+TM' is granted with rights of both Clearing and Trading Members, excluding the rights to submit requests to NCC which are exclusively reserved for 'Login CM'.

Clearing Member may obtain logins of the following levels:

Trading Member may obtain logins of the following levels:

Depending on the login level, its rights may vary as follows:

If Clearing Member is not of the same entity as Trading Member, they may manage their clients (client accounts) in accordance with two different models. By managing here we mean ability to view various data regarding the clients (assets, limits, individual risk settings, etc), as well as ability to set limits, prohibitions, expiration rules, etc. The two models of managing clients are as follows:

The appropriate model can be selected by adding a special flag for the BF, i.e. 'Clients are managed by TM'/'Clients are managed by CM'.

Below there is a couple of examples of each model usage:

Figure 3. Examples

Below there is a list of rights for managing client accounts. Please note that these rights will be granted to the logins with their login types ('Login CM'/'Login TM') corresponding with the appropriate BF model ('Clients are managed by Clearing Member'/'Clients are managed by Trading Member').

The rights listed above are also available to login type 'Login CM+TM'.

A Clearing Member is not able to add and cancel orders directly in the trading system. However, a Clearing Member is able to submit requests to NCC in order to manage unfulfilled obligations of of Trading Member against Clearing Member, also in case of collateral insufficiency of the Trading Member. The request may be submitted by Clearing member for any of the client accounts of the Trading Member. According to this request, NCC will add either an anonymous, or a negotiated order, based on on which trades will be performed to fulfill the obligations.

Technically, the request will be submitted as a standard market order with the special flag 'Request to NCC for performing trades with Trading Member'. The request may be submitted either as anonymous, or a negotiated order. Each order with the flag 'Request to NCC...' have bit NCCRequest (0x4000000000) active in its bitmask. The same bit will be active also in trades performed based on these requests.

In order to avoid position insufficiency, a Clearing Member is able to cancel orders added by a Trading Member. To do this, the Clearing Member may execute command 'DelOrdersByBFLimit' with 'MassCancelRequestType=Z' to NCC for collateral verification of Brokerage Firms under the Trading Members, that are served by the Clearing Member; if a Brokerage Firm experiences negative free cash limit, all active orders on all client accounts served by the given Brokerage Firm will be cancelled. Each of the cancelled orders will have bit NCCBulkDeleteOperation (0x8000000000) active in its bitmask.

In synthetic matching, three orders for different trading instruments can be matched to a trade if the prices of these instruments are linked by a certain ratio. For example, the price of a calendar spread is equal to the difference between the price of the far leg and the price of the near leg. Then buy order on the calendar spread RTS-9.18-12.18 at the price 1000 (participant "A"), buy order on the futures RTS-9.18 at the price 114000 (participant "B") and sell order on the futures RTS-12.18 at the price 115,000 (participant "C") can be performed simultaneously. As a result, participant "B" will get a long futures position RTS-9.18 at a price 114000. Participant "C" will get a short futures position RTS-12.18 at a price 115000. Participant "А" will get two positions: a short futures position RTS-9.18 at a price 114000 and a long futures position RTS-12.18 at a price 115000, at what their prices are related by the ratio 115000 - 114000 = 1000. Thus, all three orders can be satisfied correctly.

On the Moscow Exchange, trades are performed with a central counterparty (NCC). In this example, three trades will be performed:

In the process of synthetic matching, orders are automatically generated submitted on behalf of the NCC in the trading system core. Such orders are called synthetic. Synthetic order - an order created by the core during synthetic matching when the conditions for orders matching are met. A synthetic order is a real order submitted by a central counterparty and appears in trades generated during synthetic matching. In anonymous and user's orders streams, synthetic orders have the special attribute 'Synthetic' (0x200000000000) in 'xstatus' field.

In this example, the following synthetic orders are generated on behalf of NCC:

Figure 4. Calendar spread order-book

A synthetic order is generated by the trading system on the basis of two real orders submitted by participants for two other instruments. In our example, the system generated a synthetic sell order for the calendar spread RTS-9.18-12.18 at a price 1000 based on a buy order for the RTS-9.18 futures at a price 114000 (from participant “B”) and a sell order for the RTS-12.18 futures on price 115000 (from participant "C").

Two main scenarios of synthetic matching:

Case 1: The orders for futures generate a synthetic order for calendar spread.

Example (see Figure 4, “Calendar spread order-book”):

Case 2: Calendar spread order and futures-leg order generate a synthetic order for the second leg of this calendar spread.

Example (see Figure 4, “Calendar spread order-book”):

Six synthetic matching variant are possible depending on the incoming active order:

The first priority of matching is price. Regardless of the order type (synthetic or real), the active one matches with the passive one with the best price. If the prices of passive synthetic and passive real orders are the same, then first the active order is matched with the one received earlier. Since a calendar spread has two legs adding at different times, the time of such spread is determined by the time of the last leg received. In each order-book (calendar spread, near and far futures), the trade price is determined by the passive order price, as in the current implementation.

In aggregated order-books, by default, the depth of five price levels is generated, formed by indicative synthetic orders. An indicative synthetic order is a “virtual order” used to form an aggregated order-book reflecting the available synthetic liquidity. The matching of such an order leads to the trade performing by synthetic matching.

Example

Synthetic liquidity is broadcast in the aggregates stream (FORTS_AGGR##_REPL) together with liquidity on real orders. If inside one price level there are both real orders and indicative synthetic volumes, then in addition to the total volume ('volume' field), a synthetic volume ('synth_volume' field) is broadcast in a separate field.

Consider an example where synthetic liquidity is added to a standard aggregated order-book. There are aggregated order-books for calendar spread and its legs with natural liquidity.

Figure 5. Aggregated order-books for calendar spread

The same order-books, but taking into account synthetic liquidity, look as follows.

Figure 6. Aggregated order-books with synthetic liquidity

These order-books show all the calculated synthetic liquidity without taking into account the limit on the number of levels of aggregated order-book of synthetic liquidity. Price levels with synthetic liquidity are highlighted in red.

Synthetic liquidity for calendar spread significantly narrowed the price spread and made the order-book of calendar spread more attractive for traders. This is the purpose of synthetic matching - to show traders the best available price and potentially greater volume of execution of their orders at the best average execution price.

In the order-book for the far leg, the situation has not changed so much. Although here, if a client adds a buy order with volume 15 contracts at price 66212, he will make trades not only with orders for the same instrument (levels 5 on 66200, 1 on 66202, 3 on 66210, which execute 9 contracts from 15) , but also he will make a trade in synthetic matching for the 6 remain contracts at price 66211. This synthetic matching uses 6 contracts for the sale of Si-6.19-9.19 at 860 and 6 contracts for the sale of Si-6.19 at 65351.

In the order-book for the near leg, synthetic liquidity remains in the background, since the near leg is the most liquid instrument with the lowest price spread.

Synthetic liquidity in aggregated order-books is updated with the frequency of updating aggregated order-books themselves. The frequency of updating aggregated order-books is lower than the frequency of trading events in the trading system, so the synthetic liquidity in the order-book is not updated for each order or trade. A participant who wants to evaluate the full depth of synthetic liquidity (more than 5 price levels) and its change at each trading event (transaction) must independently calculate the available synthetic liquidity based on information in the public orders_log.

In public orders_log, synthetic orders appear only at the time of synthetic matching in the amount necessary to conclude a transaction, i.e. synthetic orders are fully executed within the transaction in which they are generated. Therefore, if the user makes the order-books by orders_log (without synthetics) and checks it, for example, with the data broadcasted in FORTS_AGGR##_REPL, then these order-books will differ - the order-book from FORTS_AGGR##_REPL may contains prices that are “not visible” in the order-book made by orders_log.

In the stream FORTS_COMMON_REPL, the fields with the best prices and volumes at the best price are calculated taking into account synthetic liquidity, wherein the old fields (such as 'best_buy', 'best_sell', 'xamount_buy', 'xamount_sell', etc.) contain the sum of natural and synthetic liquidity, and new fields (with postfix '_native') contain synthetic liquidity.

The flag of settlement trades is broadcast in the gateway in the tables of yours orders 'orders_log' and 'multileg_orders_log' ('reason' field) and trades 'user_deal' and 'user_multileg_deal' ('reason_buy' and 'reason_sell' fields), and also in reports: 'f04', 'f04cl', 'o04', 'o04cl'.

In the 'f04', 'f04cl', 'o04', 'o04cl' reports, the reason for settlement trades is in the 'Type' field.

Futures trades reports 'f04', 'f04cl':

Options trades reports 'o04', 'o04cl':

For settlement trades, a penalty is charged from the Defaulting Clearing Member instead of a commission. The amount of the penalty for concluding the closing Derivatives contracts is equal to the sum of 5 exchange fees established by Moscow Exchange and 5 clearing commissions from the amount of the closing Derivatives contracts.The penalty is calculated for each settlement trade and is accounted for the 7-digit section of the Clearing Member specified in the settlement trade.

Information about penalties is broadcast in the gateway in the 'penalty' field of the 'part' table in the FORTS_PART_REPL stream(in total for 7-digit section), and also in the 'penalty' table of the FORTS_FEE_REPL stream (in the context of trades).

Fines and commissions for concluding settlement trades on behalf of the Non-Defaulting Clearing Member (balancing Derivatives contracts entered into with the Non-defaulting Clearing Member without submitting orders) are not charged.

Fines for the conclusion of closing Derivatives contracts with Defaulting Clearing Member are not charged:

Information on these locks is broadcast in the gateway in the 'clearing_members' table of the FORTS_REFDATA_REPL stream.

Settlement trades for which no fines were charged due to cancellation of the license to carry out professional activities in the Securities Market are marked in the tables of trades in the 'xstatus_sell' and 'xstatus_buy' fields with a special sign:

Information on the amount of the fine is included as a new type of payment in 'pay' reports on the date of debiting. Fines are taken into account in the report in the state of the current money position. Reports:

As new options are equity-style options, special rules for the settlement of claims and obligations apply to them. In the first clearing session after the trade execution, the settlement of premiums is made. This means that they are settled "immediately", without the daily transfer of variation margin as is the case with futures-style options.

Equity-style options have a value and (at the request of participants) will be used as portfolio collateral and will also affect the amount of free cash (FreeMoney). The 'FreeMoney' adjustment will be available through a new 'NetOptionValue' (NOV) parameter, which will be calculated at the next clearing session as the sum of the products of the book values and the volumes of the corresponding option positions in the portfolio, taking into account the sign:

NetOptionValue ('net_option_value' field of the 'part' and 'part_sa' tables in the 'FORTS_PART_REPL' stream) is determined for each position recording level (7CC, BF, SA). The NOV value is always equal to zero for futures and futures-style options on futures.

Since there is no variation margin for equity-style options, VM values generated by TS will always be zero for such instruments. As such, a new premium indicator appears (the 'premium' field in the 'opt_vm' table of the 'FORTS_VM_REPL' stream) reflecting a value of the premium payable/receivable in the nearest clearing session. The calculated value does not include the financial result of exercising the option position on the expiration date of the equity options. This value is indicative calculated for information purposes only. As far as settlements can be made not only in RUB, the premium in the currency of settlement is transmitted in a separate 'premium_in_settl_currency' field of the 'opt_vm' table in the 'FORTS_VM_REPL' stream.

When accruing or debiting a currency premium, the trading limit will change for 7CC and BF (with the option of free limit management). The amount of the change in the limit is equal to the volume of the premium in foreign currency, converted into rubles at the exchange rate fixed at the time of clearing.

To make mutual settlements at expiration, the prices of UA (shares) are needed, which are derived from the 'LCLOSEPRICE' field of 'SECURITIES' table of the Equity Market trading gateway. Obtaining this data entails shifting the start of the evening clearing session to 18:50 Moscow time and the end of the clearing session to 19:05 Moscow time. Shift in the evening clearing session entails a shift in the start of the evening trading session to 19:05 Moscow time.

Since the equity options to be introduced are European and cash-settled, only options that are 'in the money' will be automatically exercised and no exercise/withdrawal requests will be accepted for such options.

As stated above, the underlying asset price obtained from the 'LCLOSEPRICE' field of 'SECURITIES' table of the Equity Market trading gateway is used to determine the strike price of the option on the expiration date. This price is fixed in the collateral instrument dimension in the 'underlying_price' field of the 'option_series_settl' table of the FORTS_CLR_REPL stream. On other days, this field contains the collateral price determined at the time of clearing according to the settlement price methodology.

The premium for option contracts with settlements in rubles, received/written off in intraday clearing, is broadcast in the gateway in the ‘premium‘ field in the ‘opt_intercl_info’ table of 'FORTS_REFDATA_REPL' stream. The value includes the financial result of exercising the option position on the expiration date of the equity options. The premium for option contracts with settlements in in foreign currency, received/written off in intraday clearing, is broadcast in a separate 'premium_in_settl_currency' field in the 'opt_intercl_info' table of the 'FORTS_REFDATA_REPL' stream.This field is filled with zero for settlements in rubles. Similarly, the ruble premium (‘premium’ field) is zero for settlements in a currency.

The premium for option contracts with settlements in rubles, received/written off in the evening clearing session, is broadcast in the 'premium' field in the 'opt_pos' and 'opt_pos_sa' tables of the 'FORTS_CLR_REPL' stream. The broadcast value includes the financial result of exercising the option position on the expiration date of the equity options. For option contracts with settlements in the currency, premium received/written off in the evening clearing session, is broadcast in the 'premium_in_settl_currency ' field in the 'opt_pos' and 'opt_pos_sa' tables of the 'FORTS_CLR_REPL' stream. This field is filled with zero for settlements in ruble Similarly, the ruble premium (‘premium’ field) is zero for settlements in a currency.

Since the underlying asset of equity options is a collateral futures (in physical terms, a spot asset), its risk parameters, unlike real futures traded, contain nothing but market risk. Therefore, all of the necessary values (risk-free interest rate, interest rate mismatch and dividend risk rates) are taken into account directly when setting margin requirements for the options themselves. Expiration risks are not calculated for European equity-style options because the contracts are cash-settled, not deliverable.

A new level of IM - an option series - appears in the margining hierarchy of the collateral calculation system. Previously, the minimum level was the futures and its risks were netted against the risks of all linked option series.

There are additional fields for describing underlying asset and option series, the values from which will be used in option pricing formulas. To calculate the theoretical prices of options, two pricing models are used: Black-Scholes and Bachelier. In normal operation, the Bachelier model is not applied to equity-style options, since negative prices for such UAs are not assumed. The Black-Scholes model with discrete dividend payout is used to calculate theoretical prices for equity options. As dividends are divided into forecasted and declared, the cash flow contains two types of information. The first type includes the amount of expected discounted dividends and the second type includes the amount of declared dividends.

Due to the fact that all equity option series (within the same UA) will be started not on different futures, but on a single collateral one, it is impossible to prohibit trading in groups of OS, since in the current release it is possible to set certain restrictions only on all options within one futures at once. Therefore, it is possible to set prohibitions on all equity options on the same UA at once - a prohibition on options with the isin of the collateral futures (opt_sess_contents.fut_isin_id). Or complete prohibition on options - group_mask = 0x80000000 (options).

The SPECTRA Plaza-2 gate consists of the following software components: