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 Insurance 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 'diler' table of the 'FORTS_FUTINFO_REPL' stream, and the list of clients is stored in the 'investr' table of the 'FORTS_FUTINFO_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 EACH 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 any message. 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_FUTINFO_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.

The date of delivery is specified with 3-months interval for every future contract, i.e. mid-March, mid-June, mid-September and mid-December. 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 typically quoted in price points; however, the future contracts for interest rates and bonds are quoted in annual percentage rate.

The price in roubles for the futures quoted in price points is calculated as following:

, where:

The price in roubles for the futures quoted in annual percentage rate is calculated as following:

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

When a trading instrument is put into system, it becomes available only upon opening of the evening trading session (for more info, see Trading and clearing schedule).

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

At present, the SPECTRA system supports American futures options. These options can be divided into two types: 1) so called futures-style margining options type, when variable margin to be paid is based on the settling price, which is calculated twice per trade session; 2) premium options type, when seller receives option premium upon exercising of the option.

Once an option is exercised, its position turns into a futures position which the option was initially linked to.

There are various expiration dates for various options. Unlike futures, there may exist "short" option positions, aimed to be exercised in the middle of the next month. Once the option is exercised, its position turns into a 3-months futures position.

At opening, an amount of strike price values is specified for each option. These strike price values are dispersed near the price value of the futures contract, which the option was initially linked to.

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_FUTINFO_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_FUTINFO_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 exercise time is unique and 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. Unlike 'isin', the 'short_isin' field can change.

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: private 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: quoted, offsetting, and fill-or-kill orders. A quoted order remains in queue after it has been fully or partly exercised. An offsetting 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 offsetting orders which can only be exercised fully.

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:

Orders data are stored in the 'orders_log' tables of the 'FORTS_FUTTRADE_REPL', 'FORTS_OPTTRADE_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 streams FORTS_FUTTRADE_REPL and FORTS_OPTTRADE_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 private order. Unlike system orders, the private orders have some limitations for users in managing orders and selecting counterparts, namely the following:

In the SPECTRA trading system, trades are settles if an instrument price in one order meets the instrument price in an opposite order, i.e. selling or buying one for the same instrument. The price of order settled first is the price of the trade. There are two types of trades: private 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 the user_deal and user_multileg_deal tables of the 'FORTS_FUTTRADE_REPL' and 'FORTS_OPTTRADE_REPL' streams. The data on all trades in the system are distributed among all users via table deal of the stream 'FORTS_DEALS_REPL' in accordance with the following rules: a user gets access only to his/her own part of the trade (buyer's or seller's). If a user acts on behalf of a brokerage firm or a clearing firm, and both buyer and seller are the clients of the same firm, the user gets access to the data concerning both parts of the trade.

Along with records regarding common trades, some additional records are stored in the deal table. These records cannot be classified as trades legally, but still they show some operations in the system, which influence the participant's status. These are:

These trades are called 'technical trades'. You can tell trading trades from the technical ones by values in the fields status_sell and status_buy of the tables user_deal and user_multileg_deal of the streams 'FORTS_FUTTRADE_REPL' and 'FORTS_OPTTRADE_REPL', or by the flag nosystem in the table deal of the stream 'FORTS_DEALS_REPL' (for details see Trade types, created upon exercising and expiration of futures and options).

The SPECTRA system supports multileg 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 trading multileg instruments:

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

At present, the SPECTRA system supports American futures options. When exercising, the option position turns into a futures position with the price equal to strike of the exercising option contract. The exercise is processed during clearing session, and, technically, consists of closing of the option position and opening a futures position. Both of the positions are marked with a special flag in the fields 'status_sell' and 'status_buy' (for details see Trade types, created upon exercising and expiration of futures and options.

There are two types of exercise available:

For on the money option contracts (the call and put ones with their strike prices strictly equal to the appropriate futures settlement prices), automatic exercise is processed for the half of the open option position with the specified strike price. If the open position value is uneven, then rounding up (where 0.5=1) is applied for options call and rounding down is applied for options put (0.5=0) to calculate the settlement position value.

You can turn off the automatic exercise feature by adding a negative amount of option contracts into the 'Option contract exercise' request ('OptChangeExpiration', field 'amount'). The amount of option contracts specified will not exercise automatically.

There is an another scenario applied when calculating amount of collateral for non quarterly option 2 clearing sessions before exercise. Exercise scenarios are used along with volatility change scenarios for risk evaluation procedure. A portfolio equal to what generates on automatic exercise of on the money option contracts (or non-exercise of out of the money option contracts) is modelled for every exercise scenario, along with calculation of risk profile. A Brokerage Firm may turn on an exercise scenario calculation for their client in advance by using a non-trading order 'FutChangeClientMoney', field 'num_clr_2delivery (i4)', where the number of clearing sessions to turn on automatic exercise is specified. Value of the field 'num_clr_2delivery (i4)' is translated in the table 'part' of the stream .FORTS_PART_REPL'.

Bitmask of signs of the user_deal table, the 'FORTS_FUTTRADE_REPL' and 'FORTS_OPTTRADE_REPL' streams (the 'status_buy' and 'status_sell' fields):

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

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 also a technical possibility available to set up one more trading session in the morning (not used for now).

There is a gap in the main trade session (2 PM - 2.03 PM, Moscow time), during which the intermediate clearing session takes place. It is used to fix new prices for instruments and transfer variable margins to participants.

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.45 PM till 7 PM (Moscow time). The following operations are performed:

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

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 calculation algorithm.

One of the key features of the SPECTRA system is the calculating collaterals 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 collateral is always checked 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 trade participants are subdivided into three groups:

According to the implemented solution, risks and amount of collateral are calculated separately for each group: clearing firms, brokerage firms and clients. This makes the solution unique and guarantees that clients will never exceed the limits they had been set for.

Trading limitations of clearing firms and brokerage firms are the firms' funds allocated on trading accounts of the RTS Clearing Center. The brokerage firm's funds is the sum all its clients' funds, while the clearing firm's funds is the sum of all its brokerage firms and include the funds of the clearing firm itself. A clearing firm is eligible to transfer funds between its brokerage firms and also between the brokerage firms and the clearing firm directly; the amount of clearing firm's funds remains unchanged.

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

The trading limitations for clients are set up by brokerage firm or by clearing firm and are called the client trading limit. If there is any funds limitation set for a client, then, after the client order has been put into the system, the system checks if there are enough funds available on the client's account. In case there is no limitation has been set, the system checks funds availability on the accounts of brokerage firm and its clearing firm. Generally, an order will be listed only if there are enough funds available on all three accounts: the client's, brokerage firm's and clearing firm's.

There are only two types of funds available in the SPECTRA trading system: money and pledges. The pledges may consist of securities or of currencies, which the RTS Clearing Center accepts as collateral. Funds and non-monetary pledges are accepted in non-equal shares: the share of pledge cannot exceed 50% of the whole funds amount.

There is the 'FutChangeClientMoney (Setting up the client limits)' method available, which is used for setting up the client limits. It provides the following possibilities:

The 'FutChangeBFMoney (Setting up the brokerage firms limits)' method is used for setting up the brokerage firms limits. The method allows only to set up or change trading limits.

Separated accounting of money and positions has been implemented in order to have Brokerage firms (BFs) used for the following purposes:

A separate accounting code of the National Clearing Centre is used to account funds (roubles and other currencies) of the same type. Also, each Participant is able to create some additional accounting codes (for example, it is possible to create its own accounting code for each Brokerage firm).

The SPECTRA system allows to set up the additional limits on client trading operations, i.e. prohibitions, when it is possible to prohibit opening positions and placing orders for a certain client (or for all clients), a certain instrument (or for all instruments) or a certain underlying asset (or for all underlying assets). The following methods are used: FutChangeClientProhibit method — Changing client limits for futures and OptChangeClientProhibit method — Changing client limits for options.

The SPECTRA system provides two technical instruments (not trading instruments, juridically) which allow to manage risks. The instruments are 'EURRUB_RSK' and 'USDRUB_RSK', and they have the special status in their 'signs 0х20000' fields.

In the TCS of the FX Market, these instruments are added into the RSKC board.

In the SPECTRA Clearing system, each Brokerage Firm (BF) has its own Settlement code, registered in the TCS of the FX Market.

In order to change the single limit for FX market, a Participant (Brokerage Firm) should add negotiated order without confirmation containing a risk-managing instrument name (for example,'EURRUB_RSK'), with their own name as the counterpart's name. The order should not contain any price value (instead, the current settlement price for the risk-managing instrument is used).

After the order has added, the negotiated order with the National Clearing Centre as the counterparty appears in the system. Then, the order passes the standard risk management procedures. After the order has been verified for collateral sufficiency, it matches into trade, and the single limit recalculates. The trade is accounted at the current central rate, and no guarantee transfers accrue.

A risk transfer technical trade appears in the SPECTRA trading system. The trade is visible in the gateway interfaces in the table 'deals' with the flag 'nosystem=1', and is added into reports with ‘type=16’.

As a result of the trade, a permanent position appears. It can be closed by performing an opposite trade for the same instrument.

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 with the special status for ('status_buy==status_sell==0x4/0x8/0x4000000') for the donor account and recipient account. Juridically, it is not a trade. 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_FUTINFO_REPL' stream):

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

Figure 2. Gateway architecture

Download the latest gateway software version from ftp://ftp.moex.com/pub/FORTS/Plaza2/CGate/. The installation file's name is 'setup_SpectraCGate_x86_vx.x.x .exe' ('setup_SpectraCGate_x64_vx.x.x .exe'), where х.х.х is the software version number, for example 1.3.10.

Run 'setup_SpectraCGate_x86_vx.x.x.exe' ('setup_SpectraCGate_x64_vx.x.x.exe'). The installation wizard will guide you through the installation process:

Figure 3. Installation start

Click the 'Next' button to continue with installation:

Figure 4. Select components to install

Select the installation mode you want to use, full or custom. The full install mode will install all the gateway components including module P2MQRouter, library cgate, additional utilities and the software development kit. The custom install mode allows you to manually select software components to install.

Click the 'Next' button to continue with installation:

Figure 5. Custom install

Select the software components you need to install and the destination folder. The destination folder should be selected in accordance with the administrative recommendations.

Click the 'Next' button to continue with installation:

Figure 6. Select an address to connect

For selecting the proper connections you should contact your brokerage firm and/or the Exchange technical support service.

Click the 'Next' button to continue with installation:

Figure 7. Enter username and password

Enter a username and a password to get access to the SPECTRA trading system. After the installation complete, the username and the password will be added to the ini-file of the 'P2MQRoutel' module for automatic authentication in the Exchange network on next login. Please note that usernames and passwords differ for each connection type (real, testing and gaming).

Click the 'Next' button to continue with the installation:

Figure 8. Registering router as OS service

If you need to install the Router as Windows service, check the appropriate checkbox and click the 'Next' button to continue with the installation.

If you do not register the P2MQRouter as an OS service, you can do it later manually using the command file 'install_router.cmd (uninstall_router.cmd)'. The file is a part of distribution kit.

Figure 9. Starting installation

Click 'Install' to begin installation.

Figure 10. Finishing installation

Click 'Finish' to finish the installation.

The distribution kit for Linux OS consists of installation script ('install.sh') and archive file 'tar.gz' (for example, 'cgate-1.3.9.8.x86_64.tar.gz'); the archive file contains loadable modules 'cgate' and 'cgate_java', files 'include', documentation files and test examples. The distribution kit can be download at ftp://ftp.moex.com/pub/FORTS/Plaza2/CGate/.

Installation order:

The reference information includes the following data:

To carry out operations on all of the SPECTRA trading system markets user's system should receive at least the following reference information on-line:

Trade information includes:

To ensure fast recovery of trade information receiving after losing connection with SPECTRA, and same with late start scenario connecting to exchange, Plaza-2 gateway receives periodic snapshots from recent orderbooks in a non-aggregated form. This helps to receive the recent status of personal orders (in case when the 'full orders log' option is set - all orders in the trade system) at the current time.

Snapshots of active orders are sent with 1 minute interval in 'FORTS_FUTORDERBOOK_REPL' for futures and 'FORTS_OPTORDERBOOK_REPL' for options. Repo orders are currently not present due to the fact that the volume of transmitted data by such an instruments is small and allows the recovery with the use of the trade information stream.

Includes the following:

Position information

Clearing information, sent by Plaza-2 gateway, includes the following data:

The following information is sent as a part of this group:

That group includes the streams providing the following additional functions:

Each replicated table contains three fields of the fixed type i8 in the top, which are used for replication purpose:

To send a command, you should create a publisher with parameters 'NAME = FORTS_SRV', 'catеgory = FORTS_MSG'. If you need to receive replies to the messages sent, you should specify the flag 'CG_PUB_NEEDREPLY ' within the message sending function and create a type 'p2mqreply' listener.

In case of the message delivery and handling errors, the client receives either sending message function error or the 'system error' message in return.

Please note that the 'system error' message can be received in reply to any business-logic command.

The control system of clients' application flood control is functioning in the SPECTRA trade system. It restricts client's application to send more transactions per time unit (for single login on SPECTRA) than it is stated in the connection agreement. At present moment you can acquire login on SPECTRA with 30, 60, 90, etc. trading transactions per second. Trade operations are all transactions associated with order managing. Amount of non-trade (all the rest) operations for any type of login is limited in 500 transactions per second.

If you exceed the limit of messages, the control system does not transmit a message into the trade system core, and sends the user a reply message with the notification of denial of service. It is P2_Type = 99 and has the following structure:

Please pay attention to the two details:

There is a possibility in P2ClientGate to automatically monitor data distribution latencies by marking a period of time between sending a message and receiving a reply message or a replication record; the time difference between two marks allows to calculate the latency. The data collected are available for further analysis by the SPECTRA centralized monitoring system. Please note that you should install the Plaza2 software and use the new messages scheme versions compatible with SPECTRA 3.8.2 and later; otherwise, there will be no possibility of usage the latency monitoring feature. The string below (can be found in the message description) points to the new message schemes:

LocalTimeField=<field
  name>

Please also note that using the new message schemes with old Plaza2 binary modules will cause problems, and is strictly not recommended!

The Trading System SPECTRA provides a client connection control feature ('Cancel On Disconnect' or 'COD'). This option allows to automatically cancel some client's orders (anonymous orders without specified expiration time) on disconnect.

To enable/disable the 'COD' option, a trading participant should apply the appropriate request to the Client Center. The 'COD' option will be enabled for the ID (p2login) belonging to the trading participant.

When an ID connects to the trading system having the 'Cancel On Disconnect' option enabled, the trading system starts to monitor its connection activity in the 'COD' mode.

The connection activity monitoring algorithm is as following:

The order cancellation conditions are as following:

All orders added by clients with COD-mode enabled are cancelled when the evening trading session ends and when the Trading System has been restored after a failure.

The orders cancelled via the 'Cancel On Disconnect' option are marked with a special status (field 'xstatus') in the table.

If clients need to simulate their transaction activity, they should sent command ‘CODHeartbeat (P2_Type=10000) into the Trading System at least once per at least once per 10 seconds. The command structure is as following:

The command is not included into transaction fee.

The connection control service does not send replies to the Heartbeat messages, so that clients should set 0 (no reply expected) when calling the message sending function: (cg_pub_post(pub, msgptr, 0). Any attempt to call the function 'cg_pub_post' with 'CG_PUB_NEEDREPLY' on sending a Heartbeat message will result the error 'CG_MSG_P2MQ_TIMEOUT'.

In the standard configuration of Plaza 2 gate, there are four TCP-connections to the Exchange servers:

Figure 11. Connection scheme

In order to obtain stability, the trading system uses load balancing method to connect clients to the least loaded server at the moment.

General recommendations

In general case, to minimize possibility of loss of connection, the Exchange recommends to do the following:

• establish alternative connections

• obtain two client's IDs for the gateway, with the same user rights in order to have possibility to receive the same data by running two client applications simultaneously. Therefore, in case of any failure, you will be able to switch between two applications.

Alternatively, it is recommended to enable a feature in your application allowing to switch to another connection (a P2MQRouter connected to the Exchange servers using an alternative connection) in case of any failure.

Figure 12. Channel duplication scheme

By the Exchange infrastructure failure we mean failures on the Exchange side caused by the Trading System kernel errors, or by errors in market data generating services. Then, as a rule, the services halt and restart.

Tables:

Tables:

Tables:

Tables:

Tables:

Tables: