Table of Contents
Date | Changes |
---|---|
08.07.2024 | Changes applied:
|
12.04.2024 | Changes applied:
|
18.03.2024 | Changes applied:
|
01.12.2023 | Changes applied:
|
04.09.2023 | Changes applied:
|
02.06.2023 | Changes applied:
|
27.03.2023 | Changes applied:
|
09.11.2022 | Changes applied:
|
15.09.2022 | Changes applied:
|
17.05.2022 | Changes applied:
|
05.04.2022 | Changes applied:
|
20.10.2021 | Changes applied:
|
23.07.2021 | Changes applied:
|
14.05.2021 | Changes applied:
|
25.02.2021 | Changes applied:
|
12.01.2021 | Changes applied:
|
19.10.2020 | Changes applied:
|
17.08.2020 | Changes applied:
|
19.06.2020 | Changes applied:
|
15.01.2020 | Changes applied:
|
10.12.2019 | Changes applied:
|
12.09.2019 | Changes applied:
|
31.08.2019 | Changes applied:
|
20.06.2019 | Changes applied:
|
14.01.2019 | Changes applied:
|
05.12.2018 | Changes applied:
|
26.09.2018 | New error code added (4208). |
25.09.2018 | Added section '3.3.7. SMA Login (Sponsored Market Access)'. |
03.08.2018 | Field 'aspref' deleted from table 'orders' of stream 'FORTS_ORDBOOK_REPL'. |
01.08.2018 | Tables 'sma_master', 'sma_pre_trade_check' deleted from stream FORTS_INFO_REP |
31.07.2018 | Stream 'FORTS_INFO_REPL' now contains table 'option_series_params'. |
30.07.2018 | Field 'coeff_out' deleted from table 'opt_vcb' of stream 'FORTS_OPTINFO_REPL'. |
27.07.2018 | Changes applied:
|
26.07.2018 | New error code added (4220). |
26.07.2018 | Changes applied:
|
18.07.2018 | Add commands 'SetSmaPreTradeCheck, 'DelSmaPreTradeCheck', 'UserKillSwitch'. |
25.06.2018 | New error codes added (76, 4167, 4200 - 4207). |
21.06.2018 | Added section '3.3.6. Replication stream sets for different login subtypes'. |
19.06.2018 | Removed unused fields ’limit_pledge’, ‘coeff_liquidity’ of command FutChangeClientMoney. |
21.05.2018 | Field 'signs' added into table 'diler' of stream 'FORTS_FUTINFO_REPL'. |
11.04.2018 | Changed message type for messages 'OptChangeExpiration', 'FutTransferClientPosition', 'OptTransferClientPosition'. Also, changed type of the field 'amount' in these messages. |
30.03.2018 | Table 'part_sa' of stream 'FORTS_PART_REPL' now contains a new field 'money_old'. |
22.03.2018 | Changes applied:
|
28.02.2018 | Table 'part_forecast' deleted from stream 'FORTS_FORECASTIM_REPL'. |
26.02.2018 | Changes applied:
|
21.02.2018 | Added new error codes: 4148, 4149. |
20.02.2018 | Changes applied:
|
31.01.2018 | Changes applied:
|
26.12.2017 | Changes applied:
|
21.12.2017 | Added new error codes (4160 - 4166). |
16.11.2017 | Description change for parameter 'code_vcb' of method 'FutDelUserOrders'. |
25.10.2017 | Changes applied:
|
24.10.2017 | Changes applied:
|
28.08.2017 | Changed message type for messages 'OptChangeExpiration', 'FutTransferClientPosition', 'OptTransferClientPosition'. Also, changed type of the field 'amount' in these messages. |
23.06.2017 | Deletion of stream RTS_INDEXLOG_REPL. |
02.06.2017 | Changes applied:
|
18.05.2017 | Changes applied:
|
15.05.2017 | Changes applied:
|
05.05.2017 | Changes applied:
|
24.03.2017 | Changes applied:
|
28.12.2016 | Changes applied:
|
21.12.2016 | In accordance with decommission policy, starting from December 5, 2016, P2ClientGate API and Plaza2 libraries v.198 or below are no longer supported. The client software using Plaza2 libraries version 198 and below, or P2ClientGate API will no longer be able to connect to the trading system. |
30.08.2016 | Changed list of synchroevents in table sys_events of streams FORTS_PART_REPL, FORTS_CLR_REPL, FORTS_INFO_REPL. |
18.05.2016 | Changes applied:
|
14.10.2015 | Added description of 'CODHeartbeat' method. |
14.10.2015 | Table 'fut_sess_contents' now contains 2 new fields: 'pctyield_coeff' and 'pctyield_total'. |
12.08.2015 | Added new error codes (200 - 208). |
23.01.2015 | 'Trading gate description' now contains section 'Handling abnormal situations'. |
22.01.2015 | Added section "Cancel on Disconnect". |
16.12.2014 | Edited list of error codes. |
29.09.2014 | Added details of table 'prohibition' of stream 'FUTINFO'. |
18.08.2014 | Added ASTS error codes. |
24.07.2014 | Tables 'fut_MM_info' and 'opt_MM_info' of stream 'FORTS_MM_REPL' now have contains market-makers obligations accurate to 7-symbol client code. Formats of mesages 'FutTransferClientPosition' and 'OptTransferClientPosition' are now equal. Table 'fut_ts_cons' deleted from stream 'FORTS_FUTINFO_REPL'. |
17.07.2014 | Field 'client_code' deleted from table 'ORDERS' of stream 'FORTS_ORDBOOK_REPL'. |
25.04.2014 | Stream 'FORTS_MM_REPL' now contains new table 'mm_agreement': table with numbers and types of contracts for the provision of marketmaking services. |
15.04.2014 | Added new commands:
|
14.01.2014 | Added new fields:
into tables 'fut_MM_info', 'opt_MM_info' of stream 'FORTS_MM_REPL'. |
31.05.2013 | New field added:
into table 'clr_rate' of field 'FORTS_CLR_REPL'. |
18.04.2013 | Added anonymous stream 'orderbook':
Added field:
into table 'money_clearing' of stream 'FORTS_CLR_REPL' Deleted stream 'FORTS_CLMONEY_REPL'. |
12.04.2013 | New field added:
into table 'fut_sess_contents' of stream 'FORTS_FUTINFO_REPL'. |
10.04.2013 | New field added:
into table 'opt_sess_contents' of stream 'FORTS_OPTINFO_REPL'. |
26.03.2013 | New field added:
into tables 'fut_vcb' and 'opt_vcb' of streams 'FORTS_FUTINFO_REPL' and 'FORTS_OPTINFO_REPL' Replication stream added:
Added new table:
into stream 'FORTS_FUTINFO_REPL'. |
27.11.2012 | Changed description of table 'user_deal'. |
01.11.2012 | Added descriptions of two events for table 'sys_events'. |
30.10.2012 | Some changes applied:
|
22.10.2012 | Some changes applied:
|
10.02.12 | Some changes applied:
|
09.02.2012 | New field added:
into tables:
of streams:
|
24.01.2012 | Table 'orders' of streams:
now contains fields:
|
23.01.2012 | Event table 'sys_events' added into streams:
|
17.01.2012 | Field 'exch_pay_spot_repo' containing Exchange fee value on repo added into table 'fut_vcb' of field 'FORTS_FUTINFO_REPL'. |
12.01.2012 | Added new replication stream:
|
02.11.2011 | New fields added:
into tables:
|
25.11.2011 | Added section 'Usage of test examples'. |
7.11.2011 | Completed sections 'Introduction' and 'Trading gate description'. Added section 'System SPECTRA overview'. |
20.10.2011 | Fields added:
Event table 'sys_events' added into streams:
|
4.10.2011 | Added replication streams:
Changed numbers of trading commands for complete processing time monitoring possibility (including the final link to the client transmission time). |
14.09.2011 | Corrected errors in default values of some commands. Now all string parameters' values are quoted by default. |
15.04.2011 | Added fields:
Changes applied to commands structure:
|
28.03.2011 | Table 'multileag_deal' of stream 'FORTS_FUTTRADE_REPL' now contains field 'buyback_amount' - buyback amount for repo trades. |
24.03.2011 | Added stream 'RTS_INDEXLOG_REPL', which transmits history of RTS indexes changes. |
01.02.2011 | For command 'FutChangeClientVcb', parameter 'code_vcb' type has changed from 'c4' to 'c25'. The new command format now has message code 33. The return code for the command has not changed. Added list of return codes. |
27.01.2011 | An error corrected in description of parameter 'check_limit' of commands 'OptAddOrder' and 'OptMoveOrder'. The correct values are the following: 0 - do not verify, 1 - verify. |
24.12.2010 | Corrected some errors in command fields names along with default values of some commands:
. |
26.11.2010 | Aggregated orderbooks no more contain field 'price2'. Field 'price' now has different meaning depending on the instrument flag 0x1000 (field 'signs' of table 'fut_sess_contents' of stream 'FORTS_FUTINFO_REPL') presense. If the flag is applied, the field 'price' contains rate value, otherwise it contains swap-price value. |
15.10.2010 | Added new instrument flags (field 'signs' of table 'fut_sess_contents' of stream 'FORTS_FUTINFO_REPL'):
Flag of multileg instruments 'multileg_type' (table 'fut_sess_contents' of stream 'FORTS_FUTINFO_REPL') value is now 2 for RTS Money swaps. Aggregated orderbooks now have a new field 'price2', which contains swap-price value. |
14.09.2010 | Streams 'FORTS_FUTCOMMON_REPL' and 'FORTS_OPTCOMMON_REPL' now contain opening price values and closing price values (fields 'open_price' and 'close_price'). Stream 'RTS_INDEX_REPL' now contains cap value and indexes volume value (fields 'cap' and 'volume'). |
07.07.2010 | Table 'session' of stream 'FORTS_FUTINFO_REPL' now contains info on position transfer interval (fields 'pos_transfer_begin' and 'pos_transfer_end'). Added tables:
|
15.06.2010 | Corrected an error in command 'FutAddMultiLegOrder' description: parameter 'isin_id' is now i4. |
In table 'delivery_report' of stream 'FORTS_FUTINFO_REPL', fields 'oblig_uni' and 'fulfil_uni', type i4, are replaced with fields 'oblig_qty' and 'fulfil_qty', type i8. | |
31.05.2010 | Tables 'fut_sess_contents' and 'fut_instruments' of stream 'FORTS_FUTINFO_REPL' now contain field 'step_price_curr'. Table 'common' of streams 'FORTS_FUTCOMMON_REPL' and 'FORTS_OPTCOMMON_REPL' now contains fields with aggregated bid and offer values: 'orders_sell_qty', 'orders_sell_amount', 'orders_buy_qty', 'orders_buy_amount'. |
17.05.2010 | Added info on instruments parameters:
Added field 'step_price_clr' of table 'fut_sess_contents' of stream 'FORTS_FUTINFO_REPL', containing info on instrument price tick value during the evening clearing session. Added field 'step_price_interclr' of table 'fut_sess_contents' of stream 'FORTS_FUTINFO_REPL', containing info on instrument price tick value during the intermediate clearing session. |
19.04.2010 | Changes applied to many fields types, including but not limited to:
Table 'money_clearing' is relocated from stream 'FORTS_FUTINFO_REPL' into stream 'FORTS_CLMONEY_REPL'. Objects renamed:
Added:
Deleted:
|
16.03.2010 | Changed description of command 'FutAddRepo': instead of parameter 'swap_price', parameter 'repo_rate' is now used. |
24.02.2010 | Added:
|
18.01.2010 |
|
15.01.2010 |
|
25.11.2009 | Corrected some mistakes in commands descriptions |
03.11.2009 | Now it is possible to specify BF codes when sending messages |
30.10.2009 | Added commands for setting client limits |
10.08.2009 | Added dictionary on option instruments |
15.07.2009 | Added description of reference replication streams |
17.06.2009 | Added descriptions of commands for managing futures and options orders. |
27.03.2009 | Added description of replication streams 'common'. |
20.03.2009 | Initial version of the document |
This document is aimed to overview all the details which users may demand to architect and develop software applications for accessing the derivatives market using the PLAZA II gateway software (SPECTRA). The following parts are available in this document:
The SPECTRA system general overview, including overview of trading instruments, trading participants, trading operations, risk management, limiting of operations, etc.
Configuration, installation and setup of the PLAZA II gateway software in the form of user manuals on software installation and setup with information on minimum hardware and software requirements. Also, some general references on using the PLAZA II gateway software are added.
Information on the structure of transmitted data, including description of replication streams and transmitted tables.
List of commands.
Help information.
This document is intended for business-analysts, system architects and developers, taking part in architecting and developing software for accessing the derivatives market using the PLAZA II gateway software.
The following abbreviations may be used in the Document:
Abbreviation | Description |
---|---|
ASTS | Trading and clearing system of the FX Market of the Moscow Exchange |
BF | Brokerage Firm (trading member) |
CF | Clearing Firm (clearing member) |
CM | Clearing Member |
COD | Service 'Cancel On Disconnect' |
EDM | Electronic Document Management |
MM | Market Maker |
NCC | National Clearing Centre |
SMA | Service 'Sponsored Market Access' |
TM | Trading Member |
TS | Trading System |
VM | Variation Margin |
Trading Membership may be subdivided to the following:
Clearing Members (Clearing Firms)
Trading Members (Brokerage Firms)
Trading Member's clients and Clearing Member's clients.
Traditionally, Clearing Member and Trading Member belong to the same entity, i.e. the entity which perform trades and act as a counterparty for the performed trades. The information below is provided regarding exactly this kind of Trading Membership. However, effective SPECTRA version 6.2, the Derivatives Market rolls out a new model, with Trading Member and Clearing Member represented by two separate entities (for details see 2.7. Separate entities of Clearing Member and Trading Member). Please also note that the new model will in no way affect the existing trading members!
Clearing firms are firms which incur liabilities for risks and cover risks of their clients and sub-brokers.
Clearing firms are authorized to:
Perform trades on behalf of themselves and at for their own accounts;
Perform trades on behalf of themselves and for their clients' accounts;
Perform settlement directly with National Clearing Centre.
Service their clients, including brokers;
Exercise control over their clients and brokers during trading sessions.
Clearing firms are obliged to:
Become members of Derivatives Market Section;
Pay fees to Guarantee Fund;
Provide collaterals for their own trades and for their clients' trades.
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:
Perform trades on behalf of themselves;
Perform trades on behalf of their clients;
Place orders in the Trading system via the client terminal application
Exercise control over their clients during trading sessions.
Brokerage firms are obliged to:
Provide guarantees for their own trades and for their clients' trades.
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
XX — indicates a clearing firm
YY — indicates a brokerage firm
ZZZ — indicates a client
The 00 brokerage firm code indicates state of account of the clearing firm.
Example 1.
Q100 — indicates the Q1 clearing firm
Q1DU — indicates the DU sub-broker of the Q1 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:
Clearing firm login. Users connected with this login are allowed to view data and perform trading operations on behalf of any brokerage firm or of any client of the clearing firm (please note that performing trading actions is only allowed when the user has sufficient rights!). Users also allowed to set limits for clients and sub-brokers by calling the appropriate operations.
Brokerage firm login. Users connected with this login are allowed to view data and perform trading operations on behalf of all broker's clients within the clearing firm, and also set limits for the broker's clients.
Client login. Users connected with this login are allowed to perform trading operations on behalf of a certain client of a brokerage firm and view data in accordance with the client login rights.
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.
The SPECTRA instruments are structured hierarchically. Below you will find descriptions of the SPECTRA instruments starting from the root level.
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:
Trade section name;
Various commision fees rates.
Delivery type according to the contract (for details, see Delivery of assets and expiration of options):
Delivery of the asset itself;
Settlement type. The margin between the opening price and the closing price is the single amount of money to be paid after the trade is closed.
Price step calculation currency. Now it can be one of the following:
RUR — when cost of price step is indicated in Russian roubles. The cost of price step is not typically a subject to change during the life of contract;
USR — when cost of price step is indicated in Russian roubles. The cost is converted into USD by using a special Moscow Exchange method of conversion (for details, see http://moex.com/n6126). Step price is a subject to change twice a day, i. e. during the main clearing session and during the intermediate clearing session taking place at 2 PM daily.
Types of trading, where two types are existing: collateralized and non-collateralized. For the collateralized trading, a part of deposit can be pledged by transferring shares and other securities in accordance with the authorized list.
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:
PricePoints — indicates price in points;
step_price — indicates cost of minimum price step
min_step — indicates minimum price step in points.
Three more fields are required to fill when it comes about future contracts quoted in USR:
Cost of price step in initial currency, i.e. in USD;
Cost of price step in Russian roubles, which is fixed upon intermediate clearing session opening;
Cost of price step in Russian roubles, which is fixed upon the main clearing session opening.
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:
'FORTS_REFDATA_REPL' stream, 'fut_sess_contents' table. This is the main table, which contains a list of futures contract available on the current trade session;
'FORTS_REFDATA_REPL' stream, 'fut_instruments' table. The table contains limited data amount about all future contracts put into the system, including non-tradable contracts.
'FORTS_INFO_REPL' stream, 'futures_params' table. This table contains data about futures contracts. According to the data format the table can be loaded by the SpectraIM client application for calculating risks.
There are futures in the Spectra TS, which differ somewhat from the common ones in their behavior - these are one-day futures contract with automatic prolongation. CFD (Contract For Difference), as well as NDF (Non-Deliverable Forward) may be as an analogue of such contracts on the market.
The underlying assets of daily futures are foreign currency rates against the Russian ruble, indices calculated by Moscow Exchange, commodities (precious metals) and shares of Russian issuers.
The main features of the such instruments:
Daily futures have no exercise date. Technically, the last trading date will be set far in the future.
Settlement prices are formed on the basis of market data from the FX and Securities Markets of the Moscow Exchange
The variation margin of the evening clearing is determined taking into account an additional component: the funding rate when the contract price deviates from the underlying asset price more than the level specified on the contract (SwapRate). The rate value is published in the gateway in the 'fut_sess_settl' table of the 'FORTS_CLR_REPL' stream in the 'swap_rate' field.
For the indicative variation margin, funding rate is calculated separately and published in the gateway in the 'common' table of the 'FORTS_COMMON_REPL' stream in the 'swap_rate' field.
For perpetual futures on the index or the stock-equities, the evening clearing variation margin is calculated with the dividend amendment, which compensates for the change in the value of the index or stock-equities prices due to dividend ex-dates. The dividend amendment is taken into account on the record date for the position for the previous evening clearing session and for trades in the evening trading session. Dividend amendment for trades during the morning and main trading sessions is not taken into account. If the record date falls on a non-trading day, then the amendment is taken into account on the nearest trading day before the record date. The amendment value is published in the gateway in the 'fut_sess_settl' table of the 'FORTS_CLR_REPL' stream in the 'index_div' field.
Formulas and detailed description can be found in contract specifications.
In the directory of trade instruments, daily futures are marked with a special sign: bit 0x4000 (CFD) in ‘signs’ field of ‘fut_sess_contents’ table of FORTS_REFDATA_REPL stream.
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, indexes, 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 American deliverable futures-style options on futures and European cash-settled equity-style options on spot assets (shares, indexes, currencies, etc.) and 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:
'FORTS_REFDATA_REPL' stream, 'opt_sess_contents' table. This is the main table, which contains a list of contracts available on the current trade session.
'FORTS_REFDATA_REPL' stream, 'opt_vcb' table. This table contains a directory of underlying contracts for options.
'FORTS_REFDATA_REPL' stream, 'sess_option_series' table. This table contains a list of option series.
'FORTS_INFO_REPL' stream, 'options_params' table. This table contains data about option contracts. According to the data format the table can be loaded by the SpectraIM client application.
'FORTS_INFO_REPL' stream, 'option_series_params' table. This table contains parameters of options series.
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.
The SPECTRA system has four fields to identify each instrument:
'isin_id' field, which contains the unique numeral code for each instrument.
'isin' field, which contains the instrument's symbol code.
'short_isin' field, which contains short symbol code for using in order books etc.
'name' field, which contains a long 'humanized' instrument's description.
Example 3. Futures on RTS index value, to exercise in December 2010.
isin_id=
isin = RTS-12.10
short_isin = RIZ0
name = Futures contract on the RTS index value, to exersice on 15, December 2010.
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:
'comment field' - a 20-symbol string;
'ext_id field' - a 4-byte number to store order's ID in the client application.
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:
For a client login - records about all orders, placed on behalf of this client;
For brokerage firm or clearing firm login - records about all orders placed on behalf of clients of these firms.
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:
Add an order;
Delete an order according to its code in the SPECTRA system;
Move an order (the 'MoveOrder' command). Moving of an order is implemented in two steps: deleting an 'old' order and adding a new one into the system (with a new code, which is sent to user after the order was added). Thus, at least two records (about deleting an order and adding a new one) will be added in the 'orders_log' table. You can move two orders at time by adding parameters ('order_id1', 'order_id2') to the 'MoveOrder' command, which can be useful for market-makers' needs. If you move only one order, then you should specify the 'order_id1' parameter only.
Delete orders by mask. The following masks can be applied:
Direction of operation: buying or selling;
Order type: negotiated order or system order;
Client's code;
Underlying asset's code;
Order's ID in the client system ('ext_id');
Instrument's code;
Instrument's group: futures, options, multi-leg instruments.
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:
Negotiated orders may be added only by a BF’s login, with the Brokerage Firm as the only allowed counterparty.
For specifying a counterpart, the counterpart's RTS code is used in orders in 'broker_to' field. The brokerage firms which do not have the RTS code act as counterparts for negotiated orders.
Instead of moving, negotiated orders can only be deleted and listed anew manually.
Negotiated orders cannot indicate the order expiration date, i.e. they cannot be multi-day (GTD).
Negotiated orders can only be exercised when the value of the 'match_ref' field of one order exactly matches the value of another (description of the field see Method AddOrder - Adding orders). Negotiated orders can also be exercised partly.
In this mode participants add negotiated orders with the ‘match_ref’ field filled in as mandatory and the NCC code (company code with flag dealer.status 0x10000 – NCC) indicated in the ‘broker_to’ field. In the ‘match_ref’ field a unique sequence of symbols is set, which the sides separately (outside the trading system) agree to use in their orders. Orders are matched by the 'match_ref' field value. Counterparties confirm their consent for the trade settlement on terms specified in the trade by using matching code value of the 'match_ref' field. In the "Negotiated mode with matching by a unique code" the counterparty is hidden at all stages of concluding and processing of a trade (order, matching, trade, reports).
And for the rest negotiated orders in this trading mode have the same restrictions as regular negotiated orders. To differentiate such orders from regular negotiated orders, the 'NegotiatedMatchByRef (0x80000000)' flag is set additionally to the 'Address (0x4000000)' flag.
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:
'Allow cross-trades' - allows cross-trades for negotiated orders. This flag must be set on both sides of the trade for a successful cross-trade. In anonymous mode, cross-trading is always prohibited.
'Cancel a passive order in a cross-trade' - allows to cancel a passive order instead of an active one for a cross-trade. A passive order cancellation implies the continuation of the active order matching within the transaction. If the transaction cannot be completed successfully during the matching process, then the canceled passive orders are recovered.
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:
Active order type | The flag in the client account - the author of the passive order | Scenarios |
---|---|---|
Quote order (Day) | 'Cancel a passive order in a cross-trade'=NO | Passive: Remains in the orderbook. Active: In the matching process, it comes to an order with the same TIN, then rolls back for all previously matched orders. |
'Cancel a passive order in a cross-trade'=YES | Passive: Canceled. Active: In the matching process, it comes to an passive order with the same TIN, initiates the cancellation of a passive one, continues of matching further in the orderbook or remains as a quote order in the orderbook.If further in the transaction the matching of the active order cannot be completed successfully (for example, due to a meeting with another cross-order for which there is no permission to cancel it), then all orders, including the cross-passive one, will be recovered. | |
IOC order | 'Cancel a passive order in a cross-trade'=NO | Passive: Remains in the orderbook. Active: In the matching process, it reaches an order with the same TIN, then the remainder is removed. |
'Cancel a passive order in a cross-trade'=YES | Passive: It is cancelled only if the active order can matches at least once with the next in queue after the cross-order. Active: Within one transaction, it reaches the passive one with the same TIN, initiates a preliminary cancellation of the passive order, then continues matching with the next orders in the orderbook queue.If after the passive order cancel, within this transaction, no matching has occurred, then the remainder of the active IOC-order is removed, and the passive order is recovered. | |
Fill-or-Kill (FOK) order | 'Cancel a passive order in a cross-trade'=NO | Passive: Remains in the orderbook. Active: In the matching process, it reaches an order with the same TIN, then rolls back on all pre-matched orders. |
'Cancel a passive order in a cross-trade'=YES | Passive: It is cancelled only if the active order can be matched completely. Active: Within one transaction, it reaches the passive one with the same TIN, initiates a preliminary cancellation of the passive order, continues matching in the orderbook.If the active order cannot be completely matched, then all previously matched and canceled passive orders are recovered back to the orderbook. |
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:
Prices in OrderBook can be ranked in two directions: straight or reverse.
When listing the multi-leg order, a client is obliged to buy or sell two or more components. Therefore, calculation of collateral for such positions should be made in the appropriate way.
Multi-leg orders cannot be moved.
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:
Iceberg order can be on-exchange only. In terms of lifetime, iceberg orders can be ordinary and multi-day. According to the types of iceberg orders, they are divided into quote (Day) and Book-or-Cancel orders.
When adding an iceberg order, it additionally indicates the parameters for calculating the size of the pop-up (visible) part. The pop-up part consists of a constant part ('disclose_const_amount') and a randomly calculated addition. The addition value is a random variable with a uniform distribution from the range [-Round(disclose_const_amount * variance_amount/100, 0); Round(disclose_const_amount * variance_amount/100, 0)], where 'variance_amount' - variance amplitude from the constant part volume .Accordingly, when adding an iceberg order, two parameters are indicated in it:
'disclose_const_amount' - volume of the constant popup part. This parameter cannot be larger than the entire iceberg. A disclose volume cannot be less than the minimum lot for this instrument (values are published on the exchange website).
'variance_amount' - the value of the random deviation of the visible iceberg part (optional). The parameter value can be from zero to the value published on the exchange website. By default, the parameter is not set.
All specified parameters can take only integer positive values.
Сollateral is blocked for the full volume of the iceberg, not for the visible part only.
When changing an iceberg order, only the price can be changed, the volume is not available for change.
When deleting or changing an iceberg order, the entire iceberg is deleted or changed, including the visible part.
In the tables of your orders and trades, iceberg orders and trades are marked with a special attribute in the fields
In the tables of your orders and trades, iceberg orders and trades are marked with a special sign "Iceberg" (0x800000000000) in the 'xstatus' and 'xstatus_sell / xstatus_buy' fields.
An iceberg order consists of two parts: public - this is the visible part of the iceberg order, and private - the entire iceberg order, including the visible part. Accordingly, there are two sets of fields in the tables of your orders and trades (order ID, quantity in operation, rest, action, etc.):
Public data are broadcast in the fields with the prefix "public_":
Tabs 'orders_log' and 'multileg_orders_log':
public_order_id - ID of the visible part of the iceberg order.
public_amount - The number of contracts in the operation for the visible part of the iceberg order.
public_amount_rest - The remaining number of contracts in the visible part of the iceberg order.
public_action - Type of operation with the visible part of the iceberg order.
Tabs 'user_deal' and 'user_multileg_deal':
public_order_id_buy - ID of the visible part of the buyer's iceberg order.
public_order_id_sell - ID of the visible part of the seller's iceberg order.
Private data are broadcast in the fields with the prefix "private_":
Tabs 'orders_log' and 'multileg_orders_log':
private_order_id - ID of the entire iceberg order.
private_amount - The number of contracts in the operation for the entire iceberg order.
private_amount_rest - The remaining number of contracts in the entire iceberg order.
private_action - Type of operation with the entire iceberg order.
Tabs 'user_deal' and 'user_multileg_deal':
private_order_id_buy - ID of the entire buyer's iceberg order.
private_order_id_sell - ID of the entire seller's iceberg order.
Below is an example of entry in the stream for adding and matching of iceberg order with amount=1000 and visible amount=100 (without filtering):
public_ order_id | public_ amount | public_ amount_ rest | public_ action | price | moment | dir | client_ code | private_ order_id | private_ amount | private_ amount_ rest | private_ action | comment |
---|---|---|---|---|---|---|---|---|---|---|---|---|
101 | 100 | 100 | 1 | 312 | 2019-01-11 11:55:58 | 1 | OD01123 | 101 | 1000 | 1000 | 1 | Add Iceberg |
102 | 1 | 1 | 1 | 312 | 2019-01-11 14:56:58 | 1 | PJ99888 | 102 | 1 | 1 | 1 | Add standard Order |
103 | 250 | 250 | 1 | 310 | 2019-01-11 16:58:58 | 2 | FS01020 | 103 | 250 | 250 | 1 | Add standard Order |
101 | 100 | 0 | 2 | 312 | 2019-01-11 16:58:58 | 1 | OD01123 | 101 | 100 | 900 | 2 | Match Iceberg |
103 | 100 | 150 | 2 | 310 | 2019-01-11 16:58:58 | 2 | FS01020 | 103 | 100 | 150 | 2 | Match standard Order |
102 | 1 | 0 | 2 | 312 | 2019-01-11 16:58:58 | 1 | PJ99888 | 102 | 1 | 0 | 2 | Match standard Order |
103 | 1 | 149 | 2 | 310 | 2019-01-11 16:58:58 | 2 | FS01020 | 103 | 1 | 149 | 2 | Match standard Order |
104 | 100 | 100 | 1 | 312 | 2019-01-11 16:58:58 | 1 | OD01123 | 101 | 100 | 900 | 3 | Pop-up Iceberg |
104 | 100 | 0 | 2 | 312 | 2019-01-11 16:58:58 | 1 | OD01123 | 101 | 100 | 800 | 2 | Match Iceberg |
103 | 100 | 49 | 2 | 310 | 2019-01-11 16:58:58 | 2 | FS01020 | 103 | 100 | 49 | 2 | Match standard Order |
105 | 100 | 100 | 1 | 312 | 2019-01-11 16:58:58 | 1 | OD01123 | 101 | 100 | 800 | 3 | Pop-up Iceberg |
105 | 49 | 51 | 2 | 312 | 2019-01-11 16:58:58 | 1 | OD01123 | 101 | 49 | 751 | 2 | Match Iceberg |
103 | 49 | 0 | 2 | 310 | 2019-01-11 16:58:58 | 2 | FS01020 | 103 | 49 | 0 | 2 | Match standard Order |
105 | 51 | 0 | 0 | 312 | 2019-01-11 17:00:58 | 1 | OD01123 | 101 | 751 | 0 | 0 | Cancel Iceberg |
Explanations for the table:
Client OD01123 adds iceberg order with entire amount 1000 and visible part amount 100. New order with 'private_order_id'=101 (order ID), 'private_amount'=1000 (entire iceberg amount) and 'public_amount'=100 (visible part) is added to the system ('private_action'=1).
Clients PJ99888 and FS01020 consistently add their standard orders to the system. Moreover, the order of client FS01020 is an opposite order that satisfies the price of two previous orders.
Visible part of iceberg order and opposite order of client FS01020 are matched ('private_action'=2), size of the remaining iceberg 'private_amount_rest'=900.
Then the standard orders of clients PJ99888 and FS01020 are matched.
The next portion of the iceberg order pops up ('private_action'=3), which immediately is matched ('private_action'=2) with the remaining part of the order of client FS01020, size of the remaining iceberg 'private_amount_rest'=800.
The next portion of the iceberg order pops up ('private_action'=3) and is matched with the remaining part of the order of client FS01020, size of the remaining iceberg 'private_amount_rest'=751.
Then client OD01123 canceled iceberg order.
Please note that when the next portion of the iceberg order pops up, it's visible part has number ('public_order_id') different from the identifier of the iceberg order itself ('private_order_id')!
For standard orders, private and public fields are filled with the same values and contain the usual values for ID, quantity in operation, remaining quantity and order operation code. Explanations for the filling of the fields from the example above:
public_ order_id | public_ amount | public_ amount_ rest | public_ action | id_ord | xamount | xamount_ rest | action | private_ order_id | private_ amount | private_ amount_ rest | private_ action | comment |
---|---|---|---|---|---|---|---|---|---|---|---|---|
101 | 100 | 100 | 1 | 101 | 1000 | 1000 | 1 | 101 | 1000 | 1000 | 1 | Add Iceberg |
102 | 1 | 1 | 1 | 102 | 1 | 1 | 1 | 102 | 1 | 1 | 1 | Add Order |
103 | 250 | 250 | 1 | 103 | 250 | 250 | 1 | 103 | 250 | 250 | 1 | Add Order |
101 | 100 | 0 | 2 | 101 | 100 | 900 | 2 | 101 | 100 | 900 | 2 | Match Iceberg |
103 | 100 | 150 | 2 | 103 | 100 | 150 | 2 | 103 | 100 | 150 | 2 | Match Order |
102 | 1 | 0 | 2 | 102 | 1 | 0 | 2 | 102 | 1 | 0 | 2 | Match Order |
103 | 1 | 149 | 2 | 103 | 1 | 149 | 2 | 103 | 1 | 149 | 2 | Match Order |
104 | 100 | 100 | 1 | 101 | 100 | 900 | 3 | 101 | 100 | 900 | 3 | Pop-up Iceberg |
104 | 100 | 0 | 2 | 101 | 100 | 800 | 2 | 101 | 100 | 800 | 2 | Match Iceberg |
103 | 100 | 49 | 2 | 103 | 100 | 49 | 2 | 103 | 100 | 49 | 2 | Match Order |
105 | 100 | 100 | 1 | 101 | 100 | 800 | 3 | 101 | 100 | 800 | 3 | Pop-up Iceberg |
105 | 49 | 51 | 2 | 101 | 49 | 751 | 2 | 101 | 49 | 751 | 2 | Match Iceberg |
103 | 49 | 0 | 2 | 103 | 49 | 0 | 2 | 103 | 49 | 0 | 2 | Match Order |
105 | 51 | 0 | 0 | 101 | 751 | 0 | 0 | 101 | 751 | 0 | 0 | Cancel Iceberg |
Anonymous streams of orders and trades contain only public fields, in which there is always the visible part of icebergs only.
The following operations are possible for iceberg orders.
Add order (command IcebergAddOrder).
Delete order (command IcebergDelOrder). The command can work both on 'public_order_id' and on 'private_order_id'.
Move order (command IcebergMoveOrder). The command can work both on 'public_order_id' and on 'private_order_id'.
Please note, that the 'IcebergMoveOrder' and 'cebergDelOrder' commands will work on 'public_order_id' only if the visible part with such a number is still in the system (has not been matched), otherwise an error will be returned about the absence of an order with such a number. Therefore, we recommend working with iceberg orders on 'private_order_id'.
When an iceberg order is added, its ID of the visible part ('public_order_id') is the same as ID of the entire iceberg order ('private_order_id'). When a new part pops up, a new ID ('public_order_id') is assigned to it, the ID of the entire iceberg order does not change. When an iceberg order is changed (move), a new 'private_order_id' is set for it.
When multi-day (GTD) iceberg orders are replaced in the evening clearing, a new iceberg order with a new 'private_order_id' is set. This new order has 'the private_order_id' of the first iceberg order as the initial order (field 'id_ord1').
An example of changing order IDs during an iceberg order operations:
Operation | public_order_id | public_action | private_order_id | private_action | id_ord1 |
---|---|---|---|---|---|
Add | 100 | 1 | 100 | 1 | |
Matching into a trade | 100 | 2 | 100 | 2 | |
New part pops up | 105 | 1 | 100 | 3 | |
Replace in the evening clearing | 1106 | 1 | 1106 | 1 | 100 |
Move | 1106 | 0 | 1106 | 0 | 100 |
1200 | 1 | 1200 | 1 |
Explanations for the table:
Add - iceberg order is added ('private_action'=1) with ID 'private_order_id'=100 and ID of visible part 'public_order_id'=100.
Matching into a trade - matching the visible part of the iceberg order ('private_action'=2) with the counter direction order.
New part pops up - when a new part pops up ('private_action'=3), a new ID 'public_order_id'=105 is assigned to it, the ID of the entire iceberg order does not change.
Replace in the evening clearing - a new iceberg order ('private_action'=1) with a new 'private_order_id'=1106 is set in the evening clearing,. This new order has 'the private_order_id' of the first iceberg order as the initial order (field 'id_ord1'=100).
Move - old iceberg order is deleted (private_action=0) and new order with new 'private_order_id'=1200 is added (private_action=1).
Values of 'public_action':
0 - Order cancelled
1 - Order added
2 - Order exercised in a trade
Values of 'private_action':
0 - Order cancelled
1 - Order added
2 - Order exercised in a trade
3 - New visible part pops up
There are three types of futures exist in terms of deliveries:
Non-deliverable futures: upon expiration, only the amount of difference between the contract price and the current price of the asset will be delivered. The delivery is performed as technical closing of the position, and is marked with a special sign in the 'xstatus_sell' and 'xstatus_buy' fields of the appropriate table containing trades data (for details see Flags applied to orders and trades).
Commodity futures: upon expiration, the assets and money are delivered. The delivery is performed as technical closing of the position, and is marked with a special sign in the 'xstatus_sell' and 'xstatus_buy' fields of the appropriate table containing trades data.
Stock futures: upon settlement, the position for futures turns into a position on the T+ market (Moscow Exchange Main Market). The settlement is processed as a technical position closing trade on the derivatives market (the trade is marked with special flag in the 'xstatus_sell' and 'xstatus_buy' fields of the appropriate table containing trades data), and position opening trade on T+ market (added into the ASTS system of derivatives market). For more information see the section below.
All deliverable futures contracts are settled via the automatic matching procedure for T+2 trades in the Main market section of Moscow Exchange (ASTS trading and clearing system).
In the SPECTRA clearing system, each Brokerage firm in order to make settlement is obtained with the firm code along with the trading-and-clearing account (TCA), both registered in the Trading and clearing system of the securities market. These two entities are used to perform the T+2 trades in order to fulfill obligations for the futures contracts. The client's account of the positions account register may have a separate TCA and client's code registered in the ASTS Securities Market.
Three trading-clearing accounts of different types (so called favorite TCAs, where one favorite TCA is used one for accruing own obligations, another one is used for accruing clients' obligations, and the third one is intended for Trust Management obligations) must be signed up within SPECTRA in advance in accordance with the Clearing Participant's application. Each of the three favorite TCAs will be assigned to the appropriate Brokerage Firm set by default.
The T+2 trades are matched on the ASTS Securities Market in a separate trading mode (SPEQ), with the settlement code Y2. The trades are matched between the National Clearing Centre and Securities Market Participants, with no additional confirmation from the Securities Market Participants.
If a T+2 trade cannot be performed due to the absence/incorrect details of the assigned Brokerage Firm/TCE, a Participant should assign a valid TCE of Securities Market to the appropriate Brokerage Firm not later than 3 PM Moscow time. If the Participant is unable to assign a valid TCE, than starting 3 PM Moscow time the T+2 trades will be performed using a favorite TCE of the appropriate type (own, client, Trust Management). If the T+2 trades cannot be performed using a favorite TCA due to its absence/incorrect details, then the Clearing Participant's obligation on equity futures delivery will be considered as non-fulfilled for the given Brokerage Firm, and the appropriate fee in accordance with the amount of collateral on unfulfilled futures will be imposed.
After the settlement for securities has been fulfilled on the securities marked (in case of sufficient collateral amount), the futures position in SPECTRA system closes, and the collateral for this position releases. If the collateral amount is insufficient for the T+2 market position, then the futures position and its collateral remain blocked in the SPECTRA system until the margin request is executed on the T+2 market.
After the futures for securities are settled, the technical trades for closing futures positions appear in the trades table, marked with the 'Futures settlement trade' value in the 'xstatus_sell' and 'xstatus_buy' fields (for details see Flags applied to orders and trades). The technical trades for closing futures positions will also appear in the derivatives market reports 'f04.csv' and 'fut_deal.csv'.
For more information see http://moex.com/s1262.
At present, the SPECTRA system supports American deliverable futures options and European cash-settled options on the spot assets (shares, indexes, currencies, etc.) and futures.
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 'xstatus_sell' and 'xstatus_buy' of the appropriate table containing trades data (for details see Flags applied to orders and trades.
There are two types of exercise available:
Prescheduled exercise, processed according to a participant's request. A buyer is allowed, at any time, put the corresponding request into the system (for details see Method OptChangeExpiration - Request for the exercise of options). The requests are accepted during the whole trading session, while exercised only twice a day: during the intraday clearing session and the evening clearing sessions.
Automatic exercise, on the option expiration date. On the expiration date, each options that are 'in the money' (call whose strike is strictly less than the futures settlement price, and put, which strike is strictly more than the futures settlement price) exercises automatically.
For 'at 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.
Automatic exercise can be carried out both in intraday and evening clearing sessions (set at the level of the option series).
You can turn off the automatic exercise feature by adding a negative amount of option contracts into the 'OptChangeExpiration' request (field 'amount'). The amount of option contracts specified will not exercise automatically.
For options that are European and cash-settled, only automatic exercise is provided. On the last day of circulation, only options that are 'in the money' are exercised. Accordingly, requests for exercise/refusal of exercise is not accepted by the system.
Current initial margin calculation algorithm can cause sudden collateral increase for clients. For more flexible management, new parameters allowing the broker to set IM calculation algorithm for clients, will be added into the trading system.
Expiration scenario parameters:
exp_clearings_bf - this parameter is set by NCC globally which defines quantity of clearing sessions before expiration for series of options. During those clearing sessions IM calculated on expiration model"s basis will be blocked for Broker. Starting from (exp_clearings_bf/2) days before the expiration date volatility model will be used. This is applied only during evening or intermediate clearing session. Can differ for different underlying assets.
exp_clearings_sa - number of clearing sessions before expiration with expiration scenario applied for Settlement Account. The setting is applied and changed by NCC for the whole market during the intraday and evening clearing sessions.
exp_weight - weight of risk profile in accordance with expiration scenario.
exp_weight (client): The setting may be applied by a Brokerage Firm by sending a non-trading transaction OptChangeRiskParametersNextSession for each client, will be applied during the nearest clearing session.
exp_weight (broker): The setting may be applied by a Clearing Firm via the EDM system, by sending command 'ChangeBFParametersNextSession'. The setting 'exp_weight (broker)' will be used to calculate collateral value for a Brokerage Firm with the nett margining mode enabled.
exp_weight_client_default: The setting may be applied by a Clearing Firm via the EDM system by sending command 'ChangeBFClientDefaultParametersNextSession'. The setting 'exp_weight_client_default' will be applied for all BF's clients with non-specified setting ‘exp_weight (client)’, as the default setting.
If the Broker does not set weights of risk-profile, for all his clients NCC default parameters will be applied.
exp_clearings_cc - this parameter is set by NCC per all clearing participants and defines quantity of clearing sessions during which risk profile weight exp_weight might be applied for clients. Can be applied only after evening or intermediate clearing session.
num_clr_2delivery (broker) - the setting may be applied by a Brokerage Firm via sending a non-trading gateway transaction 'ChangeBFParametersNextSession'. The value stands for the number of clearing sessions before expiration, with risk profile weight applied to calculate collateral value for BF with the nett margining mode enabled. This setting overrides the NCC-applied setting ‘exp_clearings_bf’ if value ‘num_clr_2delivery (broker)’ is less than that of ‘exp_clearings_bf’.
num_clr_2delivery_client_default - the setting may be applied by a Clearing Firm via the EDM system by sending command 'ChangeBFClientDefaultParametersNextSession'. The setting is applied for all BF’s clients with non-specified setting ‘num_clr_2delivery’, as the default setting.
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:
PerpetualFuturesExecutionVoluntary (0x10000000000000) - the technical trade as a result of voluntary exiting a perpetual futures (based on the submitted requests);
PerpetualFuturesExecutionForced (0x400000000000000) - the technical trade as a result of forced exiting a perpetual futures (realization of unsatisfied demand);
PerpetualFuturesExecution (0x800000000000000) - the technical trade with linked instrument as a result of exiting a perpetual futures.
TAS (Trade at Settlement) service provides option to buy or sell futures contract on the forward settlement price of the current trading day plus a certain spread acceptable for the participant to pay additionally or bend on the settlement price of the contract. A forward settlement price of the current trading day is calculated during the evening clearing session. Counterparties should agree on the spread value and specify this value as the price of TAS order. In the trading system TAS is technically implemented as futures on futures: ordinary futures contract is based on the desired futures contract. Therefore, the desired futures contract serves as an underlying asset (UA-futures). The participant receives a TAS-futures position by making a trade based on the order with TAS spread.
Trades based on orders with TAS spread are settled during the evening clearing session. After the trade was settled, TAS-futures position is replaced by UA-futures position with a technical trade of position closing on the TAS-futures at a price of 0 and a trade of position opening on the UA-futures at the settlement price of the UA-futures. Trades in the trades table are marked with TASSettlement 0x10000 bit (Trade settlement based on an order indicating the TAS spread) in the 'xstatus_sell' and 'xstatus_buy' fields.
Flags applied to orders and trades:
Flag name | Bit mask | Description |
---|---|---|
Market orders | ||
Auction | 0x1 | Day order. |
Opposite | 0x2 | Immediate-or-Cancel order (IOC). |
FOK | 0x80000 | Fill-or-Kill order. |
BOC | 0x1000000000000000 | Book-or-Cancel order. |
Clearing trades | ||
NonQuote | 0x4 | Sign of an order/trade that is not included in the calculation of quotes. Applied to negotiated orders/trades, technical trades, clearing trades, multi-leg trades and RFS trades. |
Exec | 0x20 | A trade resulting from the exercise of an option. The flag is set for option trades and for futures trades that appeared as a result of the exercise of options. |
Expiration | 0x80 | Instrument, futures, or option expiration. |
DUFlow | 0x800 | Technical trade of position transfer between trust managing BFs of Clearing Firms. |
TASSettlement | 0x10000 | Trade Settlement TAS. (Not available in the current version) |
OptionLapse | 0x800000 | Option expiration trade |
ClearingTrade | 0x2000000 | Off-book clearing trade. Applied to all clearing trades. |
FuturesExecution | 0x40000000 | Futures exercise trade. |
CollateralInstrument | 0x400000000 | Collateral instrument trade. |
PerpetualFuturesExecutionVoluntary | 0x10000000000000 | The technical trade executed as a result of exiting a perpetual futures (based on the submitted requests). |
PerpetualFuturesExecutionForced | 0x400000000000000 | The technical trade executed as a result of forced exiting a perpetual futures (realization of unsatisfied demand). |
PerpetualFuturesExecution | 0x800000000000000 | The technical trade with linked instrument executed as a result of exiting a perpetual futures. |
Negotiated orders/trades | ||
TransferClientPosition | 0x8 | Position transfer between BFs. |
Address | 0x4000000 | Negotiated order, negotiated trade, indicative trade (RFS), or an order resulting from matched indicative quotes. |
NegotiatedMatchByRef | 0x80000000 | Negotiated order or trade matched by reference. |
TransferSource | 0x200000000 | Donor BF side in position transfer between BFs. |
Multi-leg orders/trades | ||
REPOBack | 0x4000 | Far leg transaction. |
Strategy | 0x8000000 | Multi-leg order/trade. Applied to all multi-leg transactions. |
Other | ||
DontCheckMoney | 0x10 | Do not verify collateral for client accounts. |
ExternalUseEveningExecution | 0x100 | A sign of an order or trade in the evening trading session. |
DontCheckLimits | 0x200 | Do not verify limits for options. |
Charge | 0x400 | End of logical transaction. The flag is set by the core on orders so that the number (and limits) of transactions can be obtained from the order log, that is, the sequence of orders generated by one transaction. |
LastRec | 0x1000 | Sign of the last entry in the matching transaction. |
DueToCrossCancel | 0x2000 | Sign of canceling a passive order in a cross-trade. |
MoveOperation | 0x100000 | Sign of moving the order. |
DeleteOperation | 0x200000 | Deleting one order. |
BulkDeleteOperation | 0x400000 | Mass deletion of orders. |
OppositeOrderTailDeleteDueToCrossTrade | 0x20000000 | Deleting the remainder of the Immediate-or-Cancel order due to a cross-trade. |
CODBulkDeleteOperation | 0x100000000 | Sign of the operation for deleting the order by the 'Cancel On Disconnect' service. |
FineOperation | 0x1000000000 | Applied on order cancellation due to an RFS fee. |
UKSBulkDeleteOperation | 0x2000000000 | Orders are cancelled by UserKillSwitch |
NCCRequest | 0x4000000000 | Operation resulting from request to NCC. |
NCCBulkDeleteOperation | 0x8000000000 | Orders are cancelled by DelOrdersByBFLimit |
LiqNettingRF | 0x10000000000 | Orders and trades formed in the process of liquidation netting |
ActiveSide | 0x20000000000 | The active side in the trade. The order that led to the trade when added to the order-book. |
PassiveSide | 0x40000000000 | The passive side in the trade. The order from the order-book involved in the trade. |
Synthetic | 0x200000000000 | Sign of a synthetic order and the side of the trade corresponding to this synthetic order. |
RFSOrder | 0x400000000000 | Order from the RFS system. |
Iceberg | 0x800000000000 | Iceberg order/trade. |
OperatorInputSA | 0x1000000000000 | A sign of an order or trade formed in SA blocking mode. |
DontFineRF | 0x80000000000000 | No penalty for settlement transactions. |
MorningSession | 0x100000000000000 | Sign of trade made during the morning trading session. |
SyntheticPassive | 0x200000000000000 | Sign of a passive synthetic order. |
DuringDiscreteAuction | 0x4000000000000000 | Sign of an order or trade in the opening auction. |
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 II 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 II.
The 'ExternalUseEveningExecution' and 'MorningSession' bits are broadcast only in reports.
Since version 7.9, the following signs of orders and trades, are not currently used, will be redefined and used for other purposes:
SpotTransfer (0x8000);
REPO (0x20000);
IQSOrder (0x800000000).
Trade types, created upon execution and expiration of futures and options are listed in the table below:
Operation type | Position closing trade | Position opening trade | Date and time of trades availability in reports and in the gateway |
---|---|---|---|
Exercise of deliverable futures |
| No. | On the execution day, in the morning. |
Exercise of cash-settled futures |
| No. | On the execution day, in the evening. |
Exercise of a deliverable option |
|
|
Depending on time of applying the option (the next clearing session after applying). |
Exercise of a cash-settled option |
| No. |
|
Expiration of option |
| No. | On the futures execution day, in the evening. |
Segregated Brokerage Firm position transfer |
|
| During the evening clearing session. |
Voluntary exiting a perpetual futures (based on the submitted request) |
|
| In the evening on the day of the exercise request submission |
Forced exiting a perpetual futures (realization of unsatisfied demand) |
|
| In the evening on the day of the exercise request submission |
Trade Settlement TAS (Not available in the current version) |
|
| On the execution day, in the evening. |
Trades are shown as following:
Operation type | Operations info |
---|---|
Stock futures trade based on a negotiated order |
|
Stock futures trade based on a system order |
|
Stock futures option trade based on a negotiated order |
|
Stock futures option trade based on a system order |
|
Position transfer trade |
|
Technical trade based on the negotiated multi-leg order (near leg) |
|
Technical trade based on the negotiated multi-leg order (far leg) |
|
Technical trade based on the system multi-leg order (near leg) |
|
Technical trade based on the system multi-leg order (far leg) |
|
Equity futures trade based on indicative trade in RFS |
|
Option on equity futures trade based on indicative trade in RFS |
|
Technical trade for the near leg of a multi-leg order based on indicative trade in RFS |
|
Technical trade for the far leg of a multi-leg order based on indicative trade in RFS |
|
In the SPECTRA system, the trading session is subdivided into two parts (not related to the astronomical day!), which are:
Evening additional trading session — takes place from 7.05 PM till 11.50 PM (Moscow time).
Morning additional trading session — takes place from 9 AM till 10 AM (Moscow time).
Main trading session — takes place from 10 AM till 6.50 PM (Moscow time).
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 settling prices of the instruments traded in the evening/morning session and in the first half of the main session. The new and the previous prices are displayed in the special fields of the 'fut_sess_contents' and 'opt_sess_contents' tables of the 'FORTS_REFDATA_REPL' stream.
Clients' amounts of funds after the variation margins (premium) were calculated and transferred. The transferred variation margins (premium) values are displayed in the appropriate field of the 'part' and 'part_sa' tables of the 'FORTS_PART_REPL' stream.
The following values are not changed during the intermediate clearing:
Trading instruments limitation values.
The trading instruments list. Deleting of expired instruments and adding of new ones is taking place during the main clearing session.
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:
Calculation and fixation of settling prices in accordance with the trading session results.
Calculation and transferring of variation margins (premium) between members.
Deletion of expired instruments and adding new ones.
Renewing information on clients, brokerage and clearing firms by deleting obsolete data and loading newly calculated data.
After the main clearing session has finished, the corresponding reports are generated and sent out.
When a new trading session is assigned, the data in the tables linked to the session number are loaded anew. For the tables that are not linked to the session number, new records are added in accordance with the new data available in the trading session; the records which do not correspond the actual trading session data will be deleted. The reference data are sent out within the tables of the 'FORTS_REFDATA_REPL' stream. As a result, the new record with a new session number is added into the 'session' table.
When a trade session changes, the data on funds, limitations and clients positions are updated as following: only the records which have been modified are subject to change (including the 'FORTS_PART_REPL', 'FORTS_POS_REPL' and 'FORTS_INFO_REPL' streams).
The main trading data (the FORTS_TRADE_REPL, 'FORTS_ORDLOG_REPL' and 'FORTS_DEALS_REPL' streams) i.e. the orders and trades which were made until 7:05 PM of the currrent trading session are available in the system till 12:00 PM on the current day.
Upon changing the trading session, the multi-day orders are relisted automatically except those which are expired. The relisting is made by deleting an old order and adding a new one with a new number, with no data added into the 'orders_log' table. Therefore, the client system should act as following: after finding a new trading session number in the 'session' table, the client system should 'forget' all the orders stored in memory by the moment and 'listen' to the replication stream for new orders with the new trading session number.
When switching the trading sessions, the system deletes expired trading instruments and adds new ones, which cannot be traded during the evening and morning trading sessions; however, these new instruments appear in the system and are transmitted in the replication stream. They are also marked with a special sign in the 'fut_sess_contents' and 'opt_sess_contents' tables.
The replication streams can be closed and then reopen again by the trading system servers, yet some streams may transmit notification about changing the life number of a scheme.
For now, the following streams can be reopen without changing life numbers:
'FORTS_COMMON_REPL' — general market data.
'FORTS_VOLAT_REPL' — the current volatility values.
'FORTS_VM_REPL' — the current variation margin (premium) value
The following streams are not subjects to reopen:
'FORTS_REFDATA_REPL' — reference data
'FORTS_TRADE_REPL' — trading data
'FORTS_USERORDERBOOK_REPL' — snapshots of order books
Streams with aggregated order books.
'RTS_INDEX_REPL' — exchange indices
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:
All data for a new trading session are loaded and calculated (~18:54-18:55, Moscow time zone)
Intraday clearing session has started (14:00, Moscow time zone)
Funds have been recalculated after intraday clearing session (~14:01:30, Moscow time zone)
All clearing procedures has finished for intraday clearing session (~14:02, Moscow time zone)
Main clearing session has started (~18:50, Moscow time zone)
All data after the main clearing session are recalculated (~18:54, Moscow time zone)
Limits have been extended (during the trading session)
The start of accepting orders in the opening auction (~8.50 AM, Moscow time)
The finish of accepting orders in the opening auction (~8.59 AM, Moscow time)
The 'sys_events' table is translated in the replication streams in order to inform outer systems about the events occurred
Field | Type | Description |
---|---|---|
replID | i8 | Replication subsystem service field |
replRev | i8 | Replication subsystem service field |
replAct | i8 | Replication subsystem service field |
event_id | i8 | Unique event ID |
sess_id | i4 | Session number |
event_type | i4 | Event type |
message | c64 | Description of the event |
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:
1 (session_data_ready) - all data from the clearing system have been loaded into the trading system; this type of event is transmitted in all streams containing 'sys_events' table, except the 'FORTS_CLR_REPL' stream
2 (intraday_clearing_finished) - all clearing procedures have been finished in the intraday clearing session; this type of event is transmitted in all streams containing 'sys_events' table, except the 'FORTS_CLR_REPL' stream
3 (clearing_data_ready) - data are ready after the main clearing session; this type of event is transmitted only in the 'FORTS_CLR_REPL' stream
4 (intraday_clearing_started) - intraday clearing session has started; this type of event is transmitted in all streams containing 'sys_events' table, except the 'FORTS_CLR_REPL' stream
5 (clearing_started) - main clearing session has started; this type of event is transmitted in all streams containing 'sys_events' table, except the 'FORTS_CLR_REPL' stream
6 (extension_of_limits_finished) - limits have been extended; this type of event is transmitted in all streams containing 'sys_events' table, except the 'FORTS_CLR_REPL' stream
8 (broker_recalc_finished) - Funds have been recalculated after intraday clearing session; this type of event is transmitted in all streams containing 'sys_events' table, except the 'FORTS_CLR_REPL' stream
23 (discrete_auction_add_order_started) - the start of accepting orders in the opening auction; this type of event is transmitted in the 'FORTS_TRADE_REPL', 'FORTS_ORDLOG_REPL', 'FORTS_DEALS_REPL' and 'FORTS_REFDATA_REPL' streams
24 (discrete_auction_add_order_finished) - the finish of accepting orders in the opening auction; this type of event is transmitted in the 'FORTS_TRADE_REPL', 'FORTS_ORDLOG_REPL', 'FORTS_DEALS_REPL' and 'FORTS_REFDATA_REPL' streams
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:
The identity of service fields values (the 'replID' and 'replRev' fields) cannot be guaranteed for the same event in the different replication streams. You should view the 'event_id' value instead.
The notification for the 'sys_event' table arrives AFTER all other data. It means that working in on-line mode, the system receives the newest data available, for example, instruments or the multi-day orders rolled over from the previous session, before adding records into the 'sys_events' table.
Data consistency is not guaranteed in snapshot mode. Replication protocol does not remember the order of retrieving records between different tables in a stream and data are distributed in the order of description of tables in the schema, that is why snapshot recordings will not arrive in the order in which they arrived in on-line mode. For example, the 'session_data_ready' event at the moment of receiving a snapshot does not mean at all that the data is ready, because the 'session_data_ready' event may refer to the previous trading session. Therefore, you can use the notifications received in 'sys_events' to assess the consistent state of data in the system in online mode only.
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:
Evening trading session: 4:00 PM - 10:00 PM.
Morning trading session: 06:00 AM - 08:55 AM.
Main trading session: 09:00 AM - 3:45 PM.
Intraday clearing session: 1:00 PM - 1:05 PM.
Clearing session: 3:45 PM - 4:00 PM.
Test systems T0 and T+1 schedule:
Evening trading session: 2:15 PM - 11:50 PM.
Morning trading session: 06:00 AM - 06:14 AM.
Main trading session: 06:15 AM - 1:45 AM.
Intraday clearing session: 11:00 PM - 11:04 PM.
X-points: 1:00 PM, 1:15 PM.
Delivery: 1:30 PM - 2:00 PM.
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:
Only futures, including perpetual futures, can participate in the opening auction. There are no calendar spreads and options. The sign of admission of the instrument to participate in the opening auction is set at the underlying asset level and applies to all instruments of this underlying asset.
During the period of collecting orders, only exchange quotation orders (‘Day’ type), including icebergs, can be placed in the opening auction. BOOK, FOK, IOC orders are not allowed.
Control of cross-orders: the intersection of the price levels of opposite orders with the same TIN is not allowed (a later application is removed), while the settings "Allow cross-trades" and "Cancel a passive order in a cross-trade" are not taken into account.
The orders prices must be within the limits of the price corridor of the instrument.
Restrictions on placing orders in the early session at the BF level also apply to the opening auction.
Exchange orders from the evening session participate in the opening auction (including icebergs and Book-or-Cancel orders).
During the period of collecting orders, you can place and cancel orders (if this is allowed for the instruments of this UA in this auction), the moving of orders is prohibited in the opening auction.
The start time for collecting orders is 10 minutes before the start of the early trading session – 8.50 AM Moscow time. This moment in the system corresponds to the arrival of the 'discrete_action_add_order_started' synchro event in the sys_events table of the FORTS_TRADE_REPL and FORTS_REFDATA_REPL streams.
The end time for collecting orders is random for all instruments in the interval specified in the 'discrete_auction.add_order_finish_from' and 'discrete_auction.add_order_finish_till' fields of the discrete_auction table in the FORTS_REFDATA_REPL stream. This moment in the system corresponds to the arrival of the 'discrete_action_add_order_finished' synchro event in the sys_events table of the FORTS_TRADE_REPL and FORTS_REFDATA_REPL streams.
After the completion of the application collection phase and before the end of the auction, operations with applications, including deletion, are not allowed.
After the auction and the conclusion of trades at the opening price, the remaining orders are matched, taking into account synthetic liquidity from calendar spreads. The trades prices taking into account synthetic matching may differ from the opening price. At this stage, orders for calendar spreads can be canceled if the crossness conditions are violated.
Orders that are not matched during the opening auction are placed in the main trading session.
Information about opening auctions in the tables of the trading interface:
Information about the schedule of the opening auctions is contained in the discrete_auction and discrete_auction_base_contract tables of the FORTS_REFDATA_REPL stream of the trading interface.
The opening auction price is transmitted in the gateway in the 'opening_auction_price' field of the common table of the FORTS_COMMON_REPL stream during the morning and main trading session. In the evening trading session, the opening auction price is zero.
Information about the trading status of the instrument is transmitted in the state field (values 6, 7) in the fut_sess_contents table of the FORTS_REFDATA_REPL stream.
All orders and trades in the opening auction have a special sign that is broadcast in the tables of orders and trades - DuringDiscreteAuction (0x4000000000000000).
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:
own - trades are covered with clearing participant's assets;
client - trades are covered with direct clients and clearing participant's 2nd-level clients' assets;
Asset management - trades are covered with assets managed by a clearing participant.
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.
Margining of calendar spreads on futures (multi-leg orders), and opposite direction positions with different exercise dates for the same underlying asset (intermonth spread) may proceed in two modes:
half nett - IM value will be calculated based upon the larger IM of the instruments in the spread;
nett - IM value will be calculated based upon price variable rate value of the instruments in the spread.
For a Settlement Account, the solely available margining mode is the nett mode.
For a Brokerage Firm, it is possible to change calendar spread margining mode only if IM value for the Brokerage Firm proceeds in the nett mode. To change the calendar spread margining mode, please use setting 'calendar_spread_margin_type' of command ChangeBFParametersNextSession.
To change the calendar spread margining mode for a Client Account, please use setting 'calendar_spread_margin_type' of command ChangeClientParametersNextSession.
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:
Set up/change/delete trading limits;
The client's trading results will be automatically applied for limits in the next trading session.
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.
If a Settlement Account belongs to Unified Collateral Pool (UCP), then, instead of collateral assets, clearing system of SPECTRA recognizes asset profiles transferred to its sub-accounts (Brokerage Firms, SBF) from clearing systems of Securities Market and FX Market. The asset profiles are transferred based upon the clearing participant's requests applied to the clearing entity via the appropriate electronic document management system. Please note that it is impossible to transfer IM to a Brokerage Firm of a Settlement Account belonging to UCP. Please also note, that it is impossible to transfer profiles between Brokerage Firms of different Settlement Accounts belonging to the Unified Collateral Pool.
An asset profile is recognized in SPECTRA trading system as imputed value of the asset according to its profile sign (+/-, to change the trading limit accordingly), and as position for a separate instrument (excluding Russian Ruble related profile), at the same time. The position for a separate instrument will be added either onto the Brokerage Firm's client account (if the profile transferred onto the same client account), or onto a Separate Brokerage Firm (with the client code '000'; if the profile transferred with no client account specified for this transfer transaction). There is a dedicated instrument (name suffixed with '_CLT') in SPECTRA for every asset eligible for profile transfer, the one is restricted to add orders and perform trades for. The only method to change a position opened for that dedicated instrument is to transfer the appropriate profile to/from SPECTRA clearing system. The IM calculation at participant's accounts/sub-accounts for the dedicated instrument position is similar to that of a futures position for the same underlying asset, i.e. the position will be margined exactly the same way.
All other specifics of managing the IM value and trading limits for sub-accounts of Unified Collateral Pool are similar to that of the standard Settlement Accounts.
The SPECTRA system provides an opportunity to introduce additional restrictions on client's trading operations, which are formulated in the system as prohibitions.
The SPECTRA system allows to prohibit a client (a group of clients) to do some transactions for a trading instrument or a group of instruments. General principles of the prohibitions mechanism:
Prohibitions apply to a standard subset of accounts: CF, BF, clients. Please note that there are currently no prohibitions applied for CF.
Prohibitions apply to the following subsets of trading instruments:
a single future or all options on the same underlying instrument;
instruments with a common underlying asset;
trading section instruments;
all instruments.
Prohibitions can be used not only by trading administrators, but also by participants who have the appropriate authority. Automatic prohibitions are also provided.
Prohibitions take effect immediately after setting. There is no way to set the interval for prohibitions application.
Prohibitions attributes
Attribute | Description |
---|---|
xprohibition_id | The unique ID of the prohibition. |
client_code | Client code. It may contain 2, 4 or 7 characters depending on which subset of accounts the prohibition apply to. |
initiator | Initiator of the prohibition. The value depends on the login level that set the prohibition. It can take the following values:
The parameter is used to determine whether the prohibition applies to the login submitting the transaction. The table below shows the matrix of the impact of prohibitions from different initiators on different levels of logins submitting a transaction. Please note that all prohibitions set by the user using gateway commands (see below) have an initiator - '1 - CF Chief trader'. |
section | Section ID. It is used to set a prohibition of trading all instruments in the section. It can take the following values:
|
base_contract_code | Underlying asset code. The prohibition is set for instruments based on this underlying asset only. |
isin_id | Instrument unique ID. It is used to prohibit trading for a specific instrument. |
priority | Priority of prohibition. Automatically calculated from the prohibition parameters (see below). |
group_mask | Bitmask of groups for which there is a prohibition. It can take the following values:
|
type | Type of prohibition. It can take the following values:
Prohibition types 0-3 are ordered by severity as follows: 2 > 1 > 3 > 0. |
is_legacy | Sign of a user prohibition. It can take the following values:
|
Table 1. The matrix of the influence of prohibitions
Login level / Initiator | CF Chief trader | CC Administrator | TS Administrator |
---|---|---|---|
Client | + | + | + |
BF | + | + | + |
CF, Trader | + | + | + |
CF, Chief trader | - | + | + |
Prohibitions priorities
Transaction parameters can satisfy several prohibitions. To determine the effective prohibition, all prohibitions are sorted in order of priority and the prohibition with the highest priority is selected as effective. Priorities are fixed and determined by a combination of prohibition parameters, the more detailed the prohibition, the higher its priority. Priorities are automatically calculated by the system based on the prohibition parameters. The following priorities are provided (listed in order from highest to lowest priority):
Priority | Account group | Instrument group |
---|---|---|
9 | Client code | instrument, isin_id != 0 |
8 | Client code | underlying asset, base_contract_code != 0 |
7 | Client code | all instruments |
6 | BF code | instrument, isin_id != 0 |
5 | BF code | underlying asset, base_contract_code != 0 |
4 | BF code | all instruments |
3 | CF code | instrument, isin_id != 0 |
2 | CF code | underlying asset, base_contract_code != 0 |
1 | CF code | all instruments |
Applying of prohibitions
The following is a very brief description of the algorithm for finding an effective prohibition for an order:
For each initiator that affects the login from which the order was added (see the description of the 'initiator' parameter above), all prohibitions related to the instrument and the seven-digit client section specified in the order are selected.
Among this set of prohibitions, the prohibitions with the highest priority are selected, and among them the strictest prohibition is selected (see the description of the 'type' parameter above).
Among the prohibitions selected for each initiator, the most strict prohibition is selected, without regard to priority.
Thus, since the prohibitions are intended to restrict operations, the most strict one is selected among the prohibitions of different initiators. That is, even an administrator will not be able to overcome the prohibition on orders set for all instruments on the BF (priority 4) by some BF level login, or the prohibition on orders set for all instruments on the CF by the Chief trader (priority 1). Because the prohibition on orders is the most strict prohibition. If it was set by another initiator, then the prohibition can be canceled (or overcome for a specific instrument and / or client) by this initiator only.
Interfaces
Prohibitions are broadcast in the gateway in 'prohibition' table in 'FORTS_PROHIBITION_REPL' stream.
In the gateway, 'FutChangeClientProhibit' and 'OptChangeClientProhibit' commands are provided to manage prohibitions. It is possible to forbid opening positions and placing orders for a specific client (for all clients), instrument (for all instruments) or underlying asset (for all UAs).
Setting prohibitions (prohibition configuration examples)
To set prohibitions, the commands mentioned above are provided in the gateway. When setting prohibitions, special attention should be paid to their correct configuration. An incorrectly constructed prohibition can lead to an unreasonably large number of prohibitions in the system, which, in turn, negatively affects the performance of the entire prohibition management system as a whole, and above all for the user himself who has set an incorrect prohibition (brakes when opening streams and sending control commands for prohibitions). For example, instead of setting many prohibitions for almost every client of the BF, it is much more efficient to set one general prohibition for the BF, and set the appropriate permissions for the necessary clients. The following are examples of configuring prohibitions in various situations. The configurations provided in the scenarios allow minimizing the total number of prohibitions.
Examples of setting prohibitions when all clients have the same rights.
Prohibit all operations for n UA (list of prohibited underlying assets). n < 0.5*M, where М – total number of UA.
Set n BF prohibitions on UA. Prohibition type - state=2 (prohibition on placing any orders), prohibition priority - priority=5 (BF code/ UA, base_contract_code != 0).
The addition of a new UA included in the list of prohibited UA requires an explicit prohibition.
The addition of a new UA that is not included in the list of prohibited UA does not require setting a new prohibition.
Prohibit all operations for n UA (list of prohibited UA). n > 0.5*M, where М – total number of UA. The scenario differs from the previous one in the ratio between the number of prohibited and allowed UA.
Set BF prohibition on all UA. Prohibition type - state=2 (prohibition on placing any orders), prohibition priority - priority=4 (BF code/ all instruments).
Set М-n BF permissions on allowed UA (inverse set to prohibited UA). Prohibition type - state=0 (no prohibitions), prohibition priority - priority=5 (BF code/ UA, base_contract_code != 0).
The addition of a new UA included in the list of prohibited UA does not requires setting prohibition.
The addition of a new UA that is not included in the list of prohibited UA requires setting a permission for it.
Examples of setting prohibitions when clients are divided into two groups: qualified investors and non-qualified investors.
Number of qualified investors = m. Number of non-qualified investors = n.
Non-qualified investors should have access to UA in group L only . Qualified investors have access to all UA.
Allow unqualified investors to trade on UA from L group only and prohibit on other UA. Allow qualified investors to trade on all UA. m < n - fewer qualified investors.
Set BF prohibition on all UA. Prohibition type - state=2 (prohibition on placing any orders), prohibition priority - priority=4 (BF code/ all instruments).
Set BF prohibitions on UA from L group. Prohibition type - state=0 (no prohibitions), prohibition priority - priority=5 (BF code/ UA, base_contract_code != 0). That is, it will be allowed to all clients of the BF.
Set permissions to qualified BF investors on all UA. Prohibition type - state=0 (no prohibitions), prohibition priority - priority=7 (Client code/ all instruments). That is, it will be allowed to all qualified BF investors only.
The addition of a new qualified investor requires setting a permission for him.
The addition of a new non-qualified investor does not require changes to the prohibitions.
Allow unqualified investors to trade on UA from L group only and prohibit on other UA. Allow qualified investors to trade on all UA. m >= n - more qualified investors. The scenario differs from the previous one in the ratio between the number of qualified and non-qualified investors.
Set prohibitions to non-qualified BF investors on UA that are not included in L group. Prohibition type - state=2 (prohibition on placing any orders), prohibition priority - priority=8 (Client code / UA, base_contract_code != 0).
The addition of a new qualified investor does not require changes to the prohibitions.
The addition of a new non-qualified investor requires setting a prohibition for him.
Prohibitions with custom priority
The system provides an opportunity to set prohibitions with the custom priority , and this priority will be higher than those that are set by the system automatically (priority from '1' to '9'). This feature allows to configure prohibitions configuration scenarios more flexible. The following priorities are provided:
10 – low custom priority;
11 – medium custom priority;
12 – high custom priority;
New 'client_priority' (i4) field was added to FutChangeClientProhibit and OptChangeClientProhibit commands for settings prohibitions with custom priorities. This field takes the value '10', '11' or '12' (low, medium, high). If the 'client_priority' field contains the value '10', '11' or '12', then a prohibition is set with the specified user priority. If the custom priority is not specified (the value is '0'), the priority will be set automatically, in accordance with the prohibition parameters.
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:
When the condition is set to pause trading for a certain underlying asset, then the trading pauses for this asset.
The trading administrators calculate the new extended limits of prices fluctuations.
The amount of collateral is recalculated for every position, which includes the underlying asset (if the limits extend, then the amount grows)
After the collateral is recalculated, the trading still pauses, allowing participants to delete orders.
The trading resumes in the standard mode.
The corresponding notifications are sent on every action listed above (see the 'sys_message' table of the 'FORTS_REFDATA_REPL' stream):
Warning about the upcoming trading pausing for a certain instrument if the prices remain unchanged.
Notification about pausing the trading.
Notification about successful recalculation of collateral (orders can now be deleted).
Notification about resuming the trading.
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:
At the time interval of 1 minute, the market condition is being analyzed for instruments due to which the limit extension procedure may, or will be performed (once an instrument's price value stays close to a specified limit for more than X minutes).
Once such instruments are detected, the Initial Margin will be recalculated for client portfolios. The new risk parameters will be applied for the instruments, according to the new limit values set after extension.
The recalculated funds are transmitted within the table part_sa_forecast of the replication stream FORTS_FORECASTIM_REPL.
Once the limit extension risk is over due to the market condition change, or when the limits have been already extended before, the service halts recalculation and transmitting of the Initial Margin value. All the previously received data will be declared as non-valid (all forecasted data in the appropriate table will be cleared at receiving command CLEARDELETED with the maximum possible revision value).
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:
N – number of contracts per trade;
lower_fee – minimum brokerage fee per contract;
upper_fee – maximum brokerage fee per contract;
multiplier – multiplier to the amount of exchange and clearing fees;
ex_fee – clearing and exchange fees per trade;
additive – constant addition per contract.
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 in which futures prices and options strikes are not limited. Negative and zero futures prices and options strikes are allowed in this mode. In this case options prices, volatility and risks are calculated based on Bachelier model or modified Black-Scholes model, which takes into account only intrinsic value of an option in negative range.
Mode in which futures prices and options strikes are limited to be positive. In this mode prices cannot fall below zero during or as the result of trades. Option prices are calculated based on Black-Scholes model (Bachelier model may be used as alternative). However, this mode allows manual negative exercise price and /or indicative current market price setting in case of corresponding NCC decision. Nevertheless futures prices and options strikes have positive limits.
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:
negative_prices: 1 – futures prices and options strikes are not limited; 0 - futures prices and options strikes are limited to be positive only.
option_model: 1 – Bachelier model; 0 - Black-Scholes model.
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:
price_assigned_by_admin – attribute of manual current market price setting by trades Administrator.
Fields of the trading interface tables, where negative values may appear in the negative prices mode ('negative_prices' = 1):
Stream | Table | Field | Description |
---|---|---|---|
FORTS_TRADE_REPL | orders_log | price | Price of the order |
FORTS_TRADE_REPL | orders_log | deal_price | Price of the trade |
FORTS_TRADE_REPL | user_deal | price | Price of the trade |
FORTS_ORDLOG_REPL | orders_log | price | Price of the order |
FORTS_ORDLOG_REPL | orders_log | deal_price | Price of the trade |
FORTS_USERORDERBOOK_REPL | orders | price | Price of the order |
FORTS_ORDBOOK_REPL | orders | price | Price of the order |
FORTS_COMMON_REPL | common | best_buy | Best bid |
FORTS_COMMON_REPL | common | best_sell | Best offer |
FORTS_COMMON_REPL | common | open_price | Opening price |
FORTS_COMMON_REPL | common | close_price | Closing price |
FORTS_COMMON_REPL | common | price | Price of the last trade |
FORTS_COMMON_REPL | common | min_price | The low price |
FORTS_COMMON_REPL | common | max_price | The high price |
FORTS_COMMON_REPL | common | avr_price | Average weighted price |
FORTS_COMMON_REPL | common | settlement_price_open | Settlement price of the previous session |
FORTS_COMMON_REPL | common | market_price | Current market price |
Streams of the aggregated order-books FORTS_AGGRXX | orders_aggr | price | Price level |
FORTS_POS_REPL | position | waprice | Volume-weighted average price |
FORTS_POS_REPL | position_sa | waprice | Volume-weighted average price |
FORTS_REFDATA_REPL | fut_sess_contents | limit_up | Upper price limit |
FORTS_REFDATA_REPL | fut_sess_contents | limit_down | Lower price limit |
FORTS_REFDATA_REPL | fut_sess_contents | settlement_price_open | Settlement price at the start of the session |
FORTS_REFDATA_REPL | fut_sess_contents | settlement_price | Settlement price after the last clearing session |
FORTS_REFDATA_REPL | fut_instruments | settlement_price_open | Settlement price at the start of the session |
FORTS_REFDATA_REPL | fut_instruments | settlement_price | Settlement price after the last clearing session |
FORTS_REFDATA_REPL | opt_sess_contents | strike | Exercise price |
FORTS_MM_REPL | fut_MM_info | price_edge_sell | Price of the worst sell order included in the spread |
FORTS_MM_REPL | fut_MM_info | price_edge_buy | Price of the worst buy order included in the spread |
FORTS_CLR_REPL | fut_sess_settl | settl_price | Settlement price |
FORTS_INFO_REPL | futures_params | risk_range_center | Risk calculation center |
FORTS_INFO_REPL | futures_params | settlement_price | Settlement price after the last clearing session |
FORTS_INFO_REPL | options_params | strike | Exercise price |
FORTS_REJECTEDORDERS_REPL | rejected_orders | price | Price of the order |
In the positive prices mode ('negative_prices' = 0), in the case of an appropriate decision by the NCC, it is possible:
use of negative futures exercise price;
broadcast of a negative value as an indicative current market price set by the Trading Administrator ('price_assigned_by_admin' = 1) in the 'market_price' field.
Negative and zero values in the instruments trading codes are displayed as follows:
The codes with strike "-10":
Contract short code ('short_isin'): "BR-10BF0".
Long contract code ('isin'): "BR-7.20M250620СA-10".
The codes with strike "0":
Contract short code ('short_isin'): "BR0BF0".
Long contract code ('isin'): "BR-7.20M250620СA0".
SMA, i.e. Sponsored Market Access is a method of providing trading participants' clients with technical access to the trading and clearing system of the Derivatives Market of Moscow Exchange. Using SMA, a client is able to send requests to the trading participant (i.e. the sponsoring entity) for adding orders directly into the trading system under control and responsibility of the client.
In order to gain access to the trading system, each trading participant's client is granted with a personal ID, i.e. SMA login, using which a client is able to add orders directly to the trading system via gateways PLAZA II, FIX, and TWIME.
In order to control the client's transactions performed via their SMA login, each SMA login is bound to the trading participant's login called MASTER login. Using their MASTER login, a trading participant is able to connect to the trading system, add orders and carry control of performing orders. A trading participant is able to use a single MASTER login for more than one SMA login. Also, each SMA login can be bound to more than one MASTER login. All logins are available via gateways in table 'user' of stream FORTS_REFDATA_REPL, where SMA logins are flagged with 1 in 3rd bit of bitmask 'sma_flags'. All SMA-MASTER login bindings are available via gateways in table 'sma_master' of stream FORTS_REFDATA_REPL.
In order to obtain their SMA login, a trading participant should file an application containing their MASTER login into the Client Centre of Moscow Exchange in order to carry control over transactions performed via SMA login.
The following risk management services are provided by the Moscow Exchange in order to prevent erroneous orders from being added into the trading system:
Pre-Trade control - some settings to carry additional control over adding orders;
Cancel On Drop-Copy Disconnect - the service guarantees that all orders added from an SMA login are available in the trading system only when the appropriate MASTER login is connected and active. Every order added via an SMA login contain references to the MASTER login (field 'aspref' of tables 'orders_log' and 'multileg_orders_log');
UserKillSwitch - forced deactivation of SMA login by a trading participant.
Pre-Trade control service provides some additional restrictions/verifications which can be imposed/applied on adding orders from an SMA login. The verifications can be applied for selected SMA logins, instruments, or client codes, where instruments are:
<Underlying asset>: <Derivative type>, where <Derivative type> = {Futures, Option, Calendar Spread} - Instrument*
<Underlying asset>: <Derivative type>, where <Derivative type> = {Futures, Option} - Instrument**
The following verifications can be applied:
Verification number | Verification details | Binding | Unit of measure | Applied |
---|---|---|---|---|
1 | Price fluctuation against the current price | SMA login or SMA login x Instrument** | Percent | Immediately |
2 | Maximum volume of order | SMA login or SMA login x Instrument* | Number of contracts | Immediately |
3 | Disallow negotiated mode | SMA login | Yes/No | Immediately |
4 | Maximum volume of order in Russian Ruble | SMA login or SMA login x Instrument* | Russian Ruble | Immediately |
5 | Maximum volume of all orders per trading day (gross) | SMA login or SMA login x Instrument* | Russian Ruble | Immediately |
6 | Maximum position (long) in contracts | SMA login x Instrument** x Client code | Number of contracts | Immediately |
7 | Maximum position (short) in contracts | SMA login x Instrument** x Client code | Number of contracts | Immediately |
To apply/cancel the verifications, the gateway methods SetSmaPreTradeCheck and DelSmaPreTradeCheck can be used, appropriately. Information on the already applied verifications is available via gateways in table 'sma_pre_trade_check' of field FORTS_REFDATA_REPL.
Cancel On Drop-Copy Disconnect - the service guarantees that all orders added from an SMA login are available in the trading system only when the appropriate MASTER login is connected and active.
When an order is being added from an SMA login, the service verifies whether there is at least a single MASTER login bound to the given SMA login. If there is no MASTER login detected, the order will be rejected, and the appropriate error message will be issued. If there is at least one bound MASTER login connected and alive, the order will be processed, and a reference to the given MASTER login (MASTER login ID) will be added into field 'aspref'.
The service constantly verifies in real-life mode (similar to that of the Cancel On Disconnect service) if MASTER logins are alive. If there is no transactional activity detected from a MASTER login, the MASTER login will be deactivated. Once there is no any MASTER login remains connected for an SMA login, all orders added via the given SMA login will be cancelled.
All active orders added via an SMA login will be cancelled automatically on technological break in the end of the trading day if the Cancel On Drop-Copy Disconnect service is enabled for these SMA logins.
In order to get access to the Cancel On Drop-Copy Disconnect service, the appropriate application should be filed to the Client Centre of Moscow Exchange.
Method UserKillSwitch allows trading participants manually deactivate (and activate again) an SMA login, with the supported possibility to automatically cancel all active orders of the given SMA login. Once deactivated, an SMA login is no more able to perform trading transactions till the end of the trading day. The SMA login will be activated again after the trading system restart due to technological break, or due to a failure.
Effective SPECTRA version 6.2, the Derivatives Market rolls out a new model, with Trading Member and Clearing Member represented by two separate entities, in order to allow clients to have access for trading without necessity to be Clearing Member. On the other hand, to perform their obligations regarding the trades performed on the Derivatives Market, a Clearing Member may not be a Trading Member. Therefore, a member in the Trading System SPECTRA may be of one of the following categories:
Clearing Member (CM). Clearing Member may serve one or more Trading Members acting as a counterparty for the trades performed by these Trading Members.
Trading Member (TM). Trading Member is eligible to perform trades on auction. However, obligations and requirements regarding the trades performed by the Trading Member will be fulfilled by a Clearing Member that serves the given Trading member.
Clearing Member + Trading Member (CM+TM). Before SPECTRA version 6.2), all members on the Derivatives Market belong to this category. The members are eligible to perform trades on auction, and act as NCC counterparties for the performed trades. For these members, the trading and clearing procedures remain the same as they have been before.
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:
a single Trading Member may be served by several Brokerage Firms, each belonging to the same Clearing Firm (Clearing Member);
a single Trading Member may be served by several Brokerage Firms belonging to different Clearing Firms (different Clearing Members);
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.
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:
'Login CM' - login granted with rights of Clearing Member.
'Login TM' - login granted with rights of Trading Member.
'Login CM+TM' - login granted with rights of both Clearing and Trading Members.
Below there is the list of rights for 'Login CM':
Transaction | Available commands |
---|---|
Set limits for BF | ChangeBFMoney |
Set BF trading limits for BF | ChangeBFLimit |
Transfer of funds between two BFs of the same SA | ExchangeBFMoney |
Set risk parameters for BF | ChangeBFParametersNextSession |
Transfer positions between two BFs (only CF login) | TransferClientPosition |
Submit requests to NCC for performing trades with Trading Member. Technically, the request will be submitted as a standard market order with the special flag. | AddOrder |
Cancel requests to NCC for performing trades with Trading Member. Technically, the request will be submitted as cancelling a standard market order with the special flag. | DelOrder |
Change requests to NCC for performing trades with Trading Member. The request is technically implemented as changing an order with special flag. | MoveOrder |
Request to NCC for collateral sufficiency verification of BF. | DelOrdersByBFLimit |
Add/cancel orders to early Option exercise. | OptChangeExpiration |
Submission of request for early exercise of options, for cancellation of automatic exercise of options. | FuturesExecutionRequest |
Manage SMA logins. | SetSmaPreTradeCheck; DelSmaPreTradeCheck; UserKillSwitch |
Recalculate central strike. | OptRecalcCS |
Below there is the list of rights for 'Login TM':
Transaction | Available commands |
---|---|
Add trading orders. | AddOrder; IcebergAddOrder |
Cancel trading orders. | DelOrder; DelUserOrders; IcebergDelOrder |
Change trading orders. | MoveOrder; IcebergMoveOrder |
Add/cancel orders to early Option exercise. | OptChangeExpiration |
Submission of request for early exercise of options, for cancellation of automatic exercise of options.. | FuturesExecutionRequest |
Manage SMA logins. | SetSmaPreTradeCheck; DelSmaPreTradeCheck; UserKillSwitch |
Recalculate central strike. | OptRecalcCS |
'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:
Clearing Firm.
Brokerage Firm.
Client.
Trading Member may obtain logins of the following levels:
Brokerage Firm.
Client.
Depending on the login level, its rights may vary as follows:
For BF with CM=TM, both Clearing Firm and Brokerage Firm level logins will be granted with 'Login CM+TM' rights;
For BF with CM!=TM, Clearing Firm level login will be granted with 'Login CM' rights;
For BF with CM!=TM, Brokerage Firm level login will be granted with rights in accordance with flag [ 'Login CM' | 'Login TM' ];
For any Brokerage Firm, a client level login is granted with 'Login TM' rights.
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:
Clients are managed by Trading Member. The Trading Member manages client accounts belonging to their Brokerage Firms (default model). According to this model, Clearing Member does not have access to data on Trading Members' clients, i.e. assets, limits and individual risk settings for each client; the client management commands are also unavailable to the Clearing Member.
Clients are managed by Clearing Member. The client accounts belonging to the Trading Member's Brokerage Firms are managed by the Clearing Member via an agency contract.
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:
In order to provide clients with access for trading, a regional brokerage firm signs an agreement with a Clearing Member to be served by the clearing broker model. To perform their obligation against the regional broker, the Clearing Member establishes a Brokerage Firm and register the regional broker as a Trading Member at the Exchange. According to that, it is the regional broker's clients who will trade at the Exchange, therefore, the broker itself wishes to manage these clients; that is why the model 'Clients are managed by Trading Member' will be applicable here.
In order to provide clients with access for trading, a non-resident company submit a request to NCC to become a Clearing Member. After that, this non-resident company signs an agency contract for managing their clients with a Brokerage Firm (either a Russian subsidiary of the non-resident company, or a large CM+TM company). According to that, it is the non-resident company's clients who will trade at the Exchange, and the non-resident wishes to manage them by itself; that is why the model 'Clients are managed by Clearing Member' will be applicable here.
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').
Transaction | Available commands, tables |
---|---|
Set limits for client accounts | ChangeClientMoney |
Set risk settings for client accounts | ChangeClientParameters; ChangeClientParametersNextSession; ChangeBFClientDefaultParametersNextSession |
Set transactional prohibitions for client accounts. | FutChangeClientProhibit; OptChangeClientProhibit |
Set risk settings for Options. | OptChangeRiskParametersNextSession |
Transfer client positions. Available only for BF logins with type 'Login CM'. | TransferClientPosition |
View data on client accounts: amount of collateral and individual risk settings. | FORTS_PART_REPL.part; FORTS_CLR_REPL.money_clearing; FORTS_CLR_REPL.pledge_details |
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.
Synthetic matching - the trades formation on the basis of orders from different order-books (order-books of different instruments). The purpose of synthetic matching is to increase the instruments liquidity by combining several order-books. For example, synthetic matching allows match calendar spread orders not only with a counter order inside this instrument order-book, but also with orders from order-books of its futures-legs. Thus, the calendar spread order takes into account the counter interest from other order-books of their legs.
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:
for calendar spread RTS-9.18-12.18 between participant А and NCC
for futures RTS-9.18 between participant B and NCC
for futures RTS-12.18 between participant C and NCC
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:
sell order for calendar spread RTS-9.18-12.18 at a price 1000 (opposite order to participant А order)
sell order for futures RTS-9.18 at a price 114000 (opposite order to participant B order)
buy order for futures RTS-12.18 at a price 115000 (opposite order to participant C order)
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”):
In order-book for calendar spread RTS-9.18-12.18, a buy order is received with amount 20 at price 1000 from participant "A".
Participant "B" sets buy order for RTS-9.18 (order-book for near leg) with amount 12 at price 114000.
Participant "C" sets sell order for RTS-12.18 (order-book for far leg) with amount 10 at price 115000 (incoming active order). At this point, the matching begins.
Based on orders for near and far legs, a sell synthetic order for calendar spread RTS-9.18-12.18 appears with amount 10 (the minimum amount of three orders participating in the matching) at price 1000 (115000-114000: i.e. price of the far leg minus price of the middle leg) in order-book for calendar spread. A synthetic order is set on behalf of the NCC and is executed to the trade with an order for a calendar spread from participant "A".
A sell synthetic order for RTS-9.18 with volume 10 and at price 114000 on behalf of the NCC appears in order-book for the near leg, and is matched with the order from participant "B" to the trade. A buy synthetic order for RTS-12.18 with volume 10 and at price 115000 on behalf of the NCC appears in order-book for the far leg, and is matched with the order from participant "C" to the trade.
Thus, three trades are formed: for near futures (counterparties: “B” and NCC) at price 114000, for far futures (counterparties: “C” and NCC) at price 115000 and for calendar spread (counterparties: “A” and NCC) at price 1000. Also, two technical trades are formed, they display the movement for legs of calendar spread. For both technical trades, counterparties are “A” and NCC.
Two orders left: for RTS-9.18-12.18 with volume 10 and for RTS-9.18 with volume 2.
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”):
Participant "B" sets buy order for RTS-9.18 (order-book for near leg) with amount 12 at price 114000.
In order-book for calendar spread RTS-9.18-12.18, a buy order is received with amount 20 at price 1000 from participant "A".
Participant "C" sets sell order for RTS-12.18 (order-book for far leg) with amount 10 at price 115000 (incoming active order). At this point, the matching begins.
Based on orders for near leg and calendar spread, a buy synthetic order for far leg RTS-12.18 appears with amount 10 at price 115000. A synthetic order is set on behalf of the NCC and is executed to the trade with an order from participant "C".
A sell synthetic order for RTS-9.18 with volume 10 and at price 114000 on behalf of the NCC appears in order-book for the near leg, and is matched with the order from participant "B" to the trade. A sell synthetic order for RTS-9.18-12.18 with volume 10 and at price 1000 on behalf of the NCC appears in order-book for the calendar spread, and is matched with the order for calendar spread from participant "A" to the trade.
Thus, three trades are formed: for near futures (counterparties: “B” and NCC) at price 114000, for far futures (counterparties: “C” and NCC) at price 115000 and for calendar spread (counterparties: “A” and NCC) at price 1000. Also, two technical trades are formed, they display the movement for legs of calendar spread. For both technical trades, counterparties are “A” and NCC.
Two orders left: for RTS-9.18-12.18 with volume 10 and for RTS-9.18 with volume 2.
Six synthetic matching variant are possible depending on the incoming active order:
Active order | Counter real order | Formation of a counter (passive) synthetic order | Counter passive synthetic order price |
---|---|---|---|
Buy near futures | Sell near futures | Sell far futures + Buy calendar spread | Far futures price - Сalendar spread price |
Sell near futures | Buy near futures | Buy far futures + Sell calendar spread | Far futures price - Сalendar spread price |
Buy far futures | Sell far futures | Sell near futures + Sell calendar spread | Near futures price + Сalendar spread price |
Sell far futures | Buy far futures | Buy near futures + Buy calendar spread | Near futures price + Сalendar spread price |
Buy calendar spread | Sell calendar spread | Buy near futures + Sell far futures | Far futures - Near futures |
Sell calendar spread | Buy calendar spread | Sell near futures + Buy far futures | Far futures price - Near futures price |
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
There are three empty order-books RTS-9.18, RTS-12.18, RTS-9.18-12.18.
In order-book for RTS-9.18 (order-book 1), participant "A" adds a buy order with amount 12 contracts at price 114000. Then in order-book for RTS-12.18 (order-book 2), participant "B" adds a sell order with amount 10 contracts at price 115000.
As a result, in order-book for RTS-9.18-12.18 calendar spread (order-book 3), a sell indicative synthetic order appears at price 115,000 - 114,000 = 1000 with amount 10 contracts, formed from orders added by participants "A" and "B".
Participant "C" can buy RTS-9.18-12.18 calendar spread in order-book 3 at price 1000 with amount 10 contracts.
Based on orders from participants "A" and "B" (in order-books 1 and 2), a sell synthetic order for RTS-9.18-12.18 calendar spread with amount 10 at price 1000 appears in order-book 3. A synthetic order is set on behalf of the NCC and is executed to the trade with an order on calendar spread from participant "C".
A sell synthetic order for RTS-9.18 with volume 10 and at price 114000 on behalf of the NCC appears in order-book 1, and is matched with the order from participant "A" to the trade. A buy synthetic order for RTS-12.18 with volume 10 and at price 115000 on behalf of the NCC appears in order-book 2, and is matched with the order from participant "B" to the trade.
Thus, three trades are formed: for near futures (counterparties: “A” and NCC) at price 114000, for far futures (counterparties: “B” and NCC) at price 115000 and for calendar spread (counterparties: “C” and NCC) at price 1000. Also, two technical trades are formed, they display the movement for legs of calendar spread. For both technical trades, counterparties are “A” and NCC.
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.
The same order-books, but taking into account synthetic liquidity, look as follows.
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.
Settlement trades are concluded by NCC on behalf of and at for settlement account (SA) of the Clearing Member.
If a Clearing Member fails to fulfill its obligations in time, then NCC considers such a participant to be a Defaulting Clearing Member (DCM). NCC, on behalf of and for settlement account of the Defaulting Clearing Member, concludes trades that lead to a reduction in position and fulfillment of obligations. The purpose of such trades is to eliminate the insufficient of collateral for obligations with a maturing and non-maturing execution date. The procedure is described in more detail in the Clearing Rules in the "Procedure for Margin Calls and default funds Margin Calls" section.
NCC concludes settlement trade on behalf of and according to the pre-agreed settlement account of the Non-defaulting Clearing Member, if the settlement trade with Defaulting Clearing Member cannot be concluded via the order book. The procedure is described in more detail in the Clearing Rules in the "Procedure for the closing and/or balancing trades execution" section. Commissions (fines) are not charged for trades with Non-defaulting Clearing Member.
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'.
Field value 'reason/ reason_buy/ reason_sell' | Reason | Member |
---|---|---|
0 | Common trade. | Clearing Member |
4 | Balancing Derivatives Contracts entered into with the Non-defaulting Clearing Member without submitting orders. | Non-defaulting Clearing Member |
6 | Closing Derivatives Contracts entered into under the cross-default procedure. | Defaulting Clearing Member |
7 | Closing Derivatives Contracts entered into upon non-fulfillment of the Margin Call. | Defaulting Clearing Member |
8 | Closing Derivatives Contracts entered into in into upon non-fulfillment of the Delivery Obligation on the deliverable Derivatives Contracts for precious metals. | Defaulting Clearing Member |
100 | Other | Defaulting Clearing Member |
In the 'f04', 'f04cl', 'o04', 'o04cl' reports, the reason for settlement trades is in the 'Type' field.
Futures trades reports 'f04', 'f04cl':
"3" - for balancing Derivatives contracts entered into with the Non-defaulting Clearing Member without submitting orders;
"21" - for closing Derivatives сontracts entered into under the cross-default procedure;
"22" - for closing Derivatives contracts entered into upon non-fulfillment of the Margin Call;
"23" - for closing Derivatives сontracts entered into in into upon non-fulfillment of the Delivery Obligation on the deliverable Derivatives contracts for precious metals.
Options trades reports 'o04', 'o04cl':
"3" - for balancing Derivatives contracts entered into with the Non-defaulting Clearing Member without submitting orders;
"6" - for closing Derivatives сontracts entered into under the cross-default procedure;
"7" - for closing Derivatives contracts entered into upon non-fulfillment of the Margin Call.
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:
if the Clearing Member is under the Liquidation Netting procedure;
if the Clearing Member is in the status "Suspension of clearing services for the Clearing Member due to cancellation of the license to carry out professional activities in the Securities Market".
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:
DontFineRF (0x80000000000000) - No penalty for settlement trades.
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:
payXXYY.csv;
payclXXYY.csv.
Since version 7.0, new derivative instruments, equity options have appeared on the Derivatives Market. Their feature is their underlying asset (UA) which is a share, not the futures. That is, logically there appears a direct connection of an option series (OS) directly with the UA, bypassing the futures. However, OS for such options will be technically recorded as a special futures (collateral). This instrument is already available at Trading System Spectra and is used to transfer asset profiles to sub-accounts of the Unified Pool settlement codes. Thus, the hierarchical structure of the instruments does not change and, with respect to equity options, remains fully identical to options on options.
In the first stage, only European equity-style cash-settled equity options are intended to be introduced.
Since it is planned to launch options not only on Russian, but also on international shares, the settlement with respect to premiums and gains/losses at option exercise can be made in the relevant foreign currency. Therefore, the quotation currency ('curr' field) and the settlement currency (new 'settlement_currency' field) in the table 'opt_vcb' of the 'FORTS_REFDATA_REPL' stream should be distinguished.
Please note that as a result of the evening clearing , negative currency balances may form on the collateral accounting sections (pledge_details) belonging to the SA (Settlement Account), which are not included in the Unified Pool. In this regard, the ruble revaluation of the collateral for such settlement accounts and BF with the sign 'limit_tied_to_money' = 1, will be carried out according to the formula: COLLATERAL_VOLUME_IN_CURRENCY * CURRENCY_RATE - abs(COLLATERAL_VOLUME_IN_CURRENCY * CURRENCY_RATE * CURRENCY_RISK).
An equity option is defined by the following attributes:
An equity option series is linked to a collateralized futures instrument: the 'underlying_id' field of the corresponding record from the 'FORTS_REFDATA_REPL:sess_option_series' table contains futures identifier, which can be found in the 'FORTS_REFDATA_REPL:fut_sess_contents' table by the 'isin_id' field; in the received record the bit '0x40000' (collateral instrument attribute) should be set in the 'signs' field;
The underlying asset for the collateralized futures instrument shall be a share: the 'asset_class' field of the 'FORTS_REFDATA_REPL:fut_vcb' table entry, linked with 'FORTS_REFDATA_REPL:fut_sess_contents' by the 'base_contract_code' field, shall contain the value 1 - "Share". The share code is contained in the 'SECCODE' field of the FORTS_REFDATA_REPL:fut_vcb table.
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:
voli – position volume in the ith option contract by the end of the current clearing session;
RCi – estimated price of the ith option contract by the end of the current clearing session.
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 PLAZA II gateway consists of the following software components:
The 'P2MQRouter' module. This module provides the following services:
Establishing TCP-connections to the Exchange servers.
Normally, the PLAZA II gateway uses four TCP-connections to the Exchange servers:
Connection for sending requests and commands
Connection for receiving the main market data such as aggregated order-books streams and the streams 'FORTS_ORDLOG_REPL', 'FORTS_DEALS_REPL', 'FORTS_TRADE_REPL' and 'FORTS_COMMON_REPL'.
Connection for receiving auxiliary and reference streams
Connection for receiving snapshots (at the first connection or when recovering after loss of connection)
'P2MQRouter' software handles all TCP-connections, with settings specified in the INI files where connection 'Other Data' is specified as the default outcoming connection and the other connections are specified as outcoming direct connections. This structure is used as the standard to establish connection directly to the Exchange server farm, but connection via a Brokerage Firm server server may require a different structure; in this case, clients should apply to the server's owners for more details about connection.
Receiving/sending P2-messages.
Encrypting data sent by participants and decrypting data received from the Exchange.
Authentication of participants in the Exchange network.
'cgate' - the gateway library.
The library is the official software interface, provided to trading participants along with their clients as well as to software developers. The interface provides availability to create and send messages into the trading system and receive trading data from the trading system (data replication). There are x32 and x64 versions available for Windows systems, as well as a version for Linux OS.
PLAZA II system libraries.
Software development kit, including additional utilities, command files, documentation and test examples.
Hardware requirements may vary depending on usage of the PLAZA II gate.
The minimum system requirements for individual login without disk saving option are as follows:
CPU: Core 2 duo 1 Ghz or better
Memory: 2 GB or more for x32 systems, 4 GB or more for x64 systems.
The minimum system requirements for brokerage firm login without disk saving option are as follows:
CPU: Intel Xeon 53xx 2 cores or better (or a similar AMD CPU 2 cores or better)
Memory: 24 GB or more
Separate SAS controller. Minimum 2 hard drives in RAID1. Two partitions, 30 GB each.
The minimum system requirements for brokerage firm login with disk saving option are as follows:
CPU: Intel Xeon 53xx 2 cores or better (or a similar AMD CPU 2 cores or better)
Memory: 4 GB or more
Separate SAS controller powered with the write-back cache policy. Minimum 4 hard disks in RAID10. Two partitions, 30 GB each.
The following operation systems are supported by the gateway software:
Microsoft Windows 10 (both 32 bit and 64 bit OS versions are supported)
Microsoft Windows Server 2016/2019 (both 32 bit and 64 bit OS versions are supported)
Linux RedHat/CentOS 7, AstraLinux SE v. 1.7, RedOS v. 7.3, AltLinux workstation 10.1. It is also possible to use other distributions
Download the latest gateway software version from https://ftp.moex.com/pub/ClientsAPI/Spectra/CGate/. The installation file's name is 'setup_SpectraCGate_x64_vx.x.x.msi', where x.x.x is the software version number, for example 7.0.0.
Run 'setup_SpectraCGate_x64_vx.x.x.msi'. The installation wizard will guide you through the installation process:
Click the 'Далее' button to continue with installation:
The default destination folder is C:\Moscow Exchange\SpectraCGate\. To confirm installation using the default folder and continue to the next step, click the 'Далее' button.
To change the destination folder, click the 'Изменить...' button. A new window appears in the screen; in this window, select a new destination folder using the "Поиск в папке" button; to move one level up in the folder tree use the button. Also, you can create a new destination folder using the button, or select an already existing one by manually typing the path in the "Имя папки" entry box in the lower part of the window. Click 'OK' to apply the changes you have made and close the current window. In the "Папка назначения" window, press the "Далее" button to continue to the next step.
Please be known that you will only be able to change the destination folder upon the initial installation, or when you are re-installing the software anew. In all other cases, you will not be able to change the destination folder (the 'Изменить...' button will be disabled).
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 'Далее' button to continue with installation:
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 'Далее' button to continue with installation:
Select the trading system to which you want to connect (production, test, game, etc), or enter your parameters for connection to the exchange servers. The connection parameters are stored in a separate configuration file for each connection option. A configuration files are in the '\links' directory of the installation directory.
Connection option | Configuration file | Details |
---|---|---|
Выделенный канал | links_public.prod.ini | Connect to Spectra - production system |
Резервный канал | links_public.rezerv.ini | Connect to Spectra - reserve system |
Тестовая система для разработчиков T0 | links_public.t0.ini | Connect to Spectra - public testing system - current version |
Тестовая система для разработчиков T1 | links_public.t1.ini | Connect to Spectra - public testing system - future version |
Игровая система | links_public.game.ini | Connect to Spectra - gaming system |
Свои параметры соединения | links_public.custom.ini | User defined connection |
After the installation complete, a link to the corresponding file with connection parameters will be added to the ini-file of the 'P2MQRouter' module in the 'connections_ini' parameter. To change the connection type, just restart the installer and select the desired option. Please note that if you reinstall or uninstall the system, the '\links' directory and the file with user connection settings (links_public.custom.ini) are not deleted.
The fields in the user settings section display:
if initial installation - default values (for example, parameters from links_public.t1.ini).
if reinstalling - user connection options from links_public.custom.ini or client_router.ini. If there are no files, the default values are displayed.
For selecting the proper connection type, you should contact your brokerage firm and/or the Exchange technical support service.
Click the 'Далее' button to continue with installation:
Enter username and password for the connection selected in the previous step. Please note that usernames and passwords differ for each connection type (production, testing and gaming).
After the installation complete, the username and password will be added to a separate configuration file 'auth_client.ini', which will be created in the '\auth' directory of the installation directory, and a link to this file will be added to the 'auth_ini' parameter of the 'P2MQRouter' module ini-file.
When reinstalling, the username and password values specified in 'auth_client.ini' or 'client_router.ini' files are displayed in the form fields. Please note that if you reinstall or uninstall the system, the '\auth' directory and the file with identification data (auth_client.ini) are not deleted.
Click the 'Далее' button to continue with the installation:
If you need to install the Router as Windows service, check the appropriate checkbox and click the 'Далее' 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.
Click 'Установить' to begin installation.
Click 'Готово' to finish the installation.
The distribution kit consists of installation script
('install.sh') and archive file ('tar.gz'); the archive file contains
loadable modules 'cgate' and 'cgate_java', files 'include',
documentation files and test examples. The distribution kit can be
downloaded at https://ftp.moex.com/pub/ClientsAPI/Spectra/CGate/
.
Installation order:
Execute the command:
chmod 755 ./install.sh
Execute the command:
./install.sh ./cgate_linux_amd64-7.12.0.103.zip
Please note that the archive file name depends on the software version, and may differ from the one shown above!
When you receive 'Please, enter cgate install path', specify the full path to the folder to decompress the cgate software.
When you receive 'Please, enter P2 login', specify the user's login.
When you receive 'Please, enter P2 password', specify the user's password.
The next installation steps may vary depending on the Linux OS software version installed:
Debian 6:
Install 'ant'
Install 'openjdk-6-jdk' (java examples compilation)
Install g++ (C++ examples compilation).
CentOS 6:
Install 'gcc'
Install 'gcc-c++' (C++ examples compilation)
Install 'ant' (java examples compilation).
Installation steps:
Download and install the gateway package by running:
dpkg -i cgate_<version>_amd64.deb
in case of installation from a deb package, or by running:
rpm -U cgate-<version>.x86_64.rpm
in case of installation from an rpm package.
'<version>' - distribution version number
Installation location:
Installation location | Description |
---|---|
/opt/moex/cgate | Binaries, schematics, gateway documentation |
/etc/opt/moex/cgate | Configuration files, auth.ini - files |
/var/opt/moex/cgate | Logging directory, trace files |
/usr/share/doc | Copyright, installation documentation |
Open the '/etc/opt/moex/cgate/auth' directory and specify the login/password for connection in the corresponding ini file:
prod.ini - to connect to the production system
t1.ini - to connect to the public test system T1
t0.ini - to connect to the public test system T0
game.ini - to connect to the gaming system
Please note that if the package is upgraded, the '\auth' directory and files with connection settings are not deleted, so you do not need to reconfigure the login/password!
Start the service (router) with the command:
systemctl start cgate@<profile>
'<profile>' - connection option. Available options:
prod - connection to production system
rezerv - connection to reserve system
t1 - connection to public test system T1
t0 - connection to public test system T0
game - connection to gaming system
rfs.prod - connecting to a production system with additional access to RFS
rfs.rezerv - connecting to a reserve system with additional access to RFS
rfs.t1 - connection to public test system T1 with additional access to RFS
rfs.t0 - connection to public test system T0 with additional access to RFS
Please note that when you upgrade a package, the running service stops, so after the upgrade, the service must be restarted!
In order to verify the installation accuracy you can compile and run the test examples included into the distribution kit.
The examples can be found either in folder Moscow Exchange\SpectraCGate\SDK\samples for Windows OS, or /usr/share/doc/cgate-examples (/opt/moex/cgate/samples) for Linux OS. To compile examples, you should run the special scripts, which may vary depending on the operation system and programming language used. For Linux OS, it is recommended to copy the examples into your login directory to compile them.
Description of examples:
Example 'aggrspy'
'aggrspy' is an example which is used to build aggregated orderbook for to buy and sell a fixed instrument for the stream 'FORTS_AGGR50_REPL'. Press 'Enter' to display the orderbook snapshot.
Execute:
aggrspy ISIN_ID depth outfile [r]
Input arguments:
'isin_id' - instrument's ID;
'depth' - depth of orderbook (up to 50);
'outfile' - orderbook file for printing;
'r' - reverse the sorting order (for instrument with reversed sorting order).
Example 'repl'
'repl' is an example which is used for receiving replication data and printing all incoming messages into a log-file. When disconnected, the replica transfer process starts anew from the beginning. No input parameters required.
Example 'repl_resume'
'repl_resume' is an example very similar to 'repl'. When disconnected, it allows to resume replica transfer process starting from the last message 'TN_COMMIT'. No input parameters required.
Example 'send'
'send' is used to add order into the SPECTRA and write incoming replies into the trading system log. No input parameters required.
Example 'orderbook'
'orderbook' is an example which is used to build aggregated orderbook for to buy and sell a fixed instrument for the online stream 'FORTS_ORDLOG_REPL' along with the snapshot stream 'FORTS_USERORDERBOOK_REPL'. It is recommended to use it for developing 'late join', and also for minimizing inactivity time when archival data is being downloaded. Press 'Enter' to display the orderbook snapshot.
Execute:
orderbook ISIN_ID depth outfile [r]
Input arguments:
'isin_id' - instrument's ID;
'depth' - depth of orderbook (up to 50);
'outfile' - orderbook file for printing;
'r' - reverse the sorting order (for instrument with reversed sorting order).
Example 'p2sys'
'p2sys' is an example, which is used for authorising the Router from cgate side. The following actions are executed cyclically:
Send erroneous login/pwd pair, get the 'logon failed' in reply;
Send the correct login/pwd pair;
Receive an 'authorisation successful' message, send 'logout' request;
Go back to the beginning.
Example 'send_mt'
'send_mt' is an example of multi-thread order adding. (Please note, that only C++11compilers are supported!). Thread 1 is used for adding orders, while thread 2 is used for processing 'reply' messages received.
Before executing the examples, please make sure that 'P2MQRouter' has started and connected to the PLAZA II network (with touter massages analyzed), the INI files are accessible for the example file, as well as the PLAZA II libraries (it may be necessary to add 'Moscow Exchange\SpectraCGate\bin' folder into the PATH environment variable or specify Moscow Exchange\SpectraCGate\bin for your development environment).
Note: The examples above are not intended to be used with data other than test data! It is strictly prohibited to use these examples for working with the real logins!
The 'cgate' application and the 'P2MQRouter' module can be distributed to different computers. To distribute the modules in the brokerage firm network, you should do the following: a) install the 'Router 'module to the computer connected to the Exchange network; b) install 'cgate' to the client computer with the client application installed; c) specify the following settings:
On the client side:
Specify the 'Host 'and 'Port' settings in accordance with that of your corporate network router.
Specify the Password settings (the local AppName application password for the router, which must be applied every time the application connects router from outside of the same computer). Please note that the local connection password is not the same as the PLAZA II authentication password!
On the router side:
Add the '<AppName>=<local password>' string into the 'router.ini' file, [AS:Local] section, where 'AppName' (the application name) and 'Password' (the local password) should match the parameters transmitted by the client application.
Users should copy the file set from the installation folder (Moscow Exchange\SpectraCGate\bin), as well as data and messages schemes (Moscow Exchange\SpectraCGate\SDK\scheme) into the folder containing user application. All these software parts should be distributed together.
It is not allowed to use different versions of 'P2MQRouter' and 'cgate' due to incompatibility. Before installing user application, please make sure that the 'P2MQRouter' version matches the one used in developing.
This section describes the structure of information sent by PLAZA II gateway.
All transmitted data is divided into the following logical groups:
Reference information
Trade information
Recovery information
Funds and limits information
Clearing information
Rates and indices information
Auxiliary data streams
The reference information includes the following data:
Trading session status and schedule
Trading session time information and all its components: intermediate clearing, evening clearing, evening and morning session time are available in 'session' table of the 'FORTS_REFDATA_REPL' stream. You can find trading session status in the same table, that helps to track current session status.
Instruments and underlying assets dictionary, properties
Futures Instruments assigned to the trading session are available in the 'fut_sess_contents' table of the 'FORTS_REFDATA_REPL' stream. Compound istruments are also listed in the table. Options instruments are sent in the 'opt_sess_content' table of the 'FORTS_REFDATA_REPL' stream. Dictionary of the futures' underlying assets is represented by the 'fut_vcb' table of the 'FORTS_REFDATA_REPL' stream.
These directories can be updated during the trading session, for example, as a result of the suspension of trading on any instrument or during the price limit enlargement procedure
Companies and clients references
Are sent in the 'dealer' and 'investor' tables from the 'FORTS_REFDATA_REPL' stream. Personal clients' information is available in these references.
Bond references
Bonds are desribed by a set of tables from the 'FORTS_REFDATA_REPL' stream: spot asset parameters references 'fut_bond_registry', bond's instruments references 'fut_bond_isin', ACI (Accrued Coupon Income) for coupon payment dates 'fut_bond_nkd', nominal payout value for a bond 'fut_bond_nominal'.
Parametric volatility curve parameters
Are sent in the 'volat_coeff' tables of the 'FORTS_RISKINFOBLACK_REPL' and 'FORTS_RISKINFOBACH_REPL' streams.
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:
Sessions' schedule (session)
Instruments dictionary (fut_sess_contents, opt_sess_contents)
Trade information includes:
Aggregate orderbooks
Are generated on the basis of user system requests by adding up the volume for each instrument, the price level and the direction of an order. Updated online and comes to be the main way to get information by current prices and volumes. User can select the desired depth of an orderbook from 5, 20 or 50 of price levels in each direction; this choice is made when configuring a login and can not be changed during the trading session.
Orderbooks are sent by multiple PLAZA II replication streams: 'FORTS_AGGR5_REPL', 'FORTS_AGGR20_REPL' and 'FORTS_AGGR50_REPL'.
Market activity
The best bid/ask price,opening price, closing price, current settlement prices, etc are sent as a part of market activity information. This information is sent in the 'FORTS_COMMON_REPL' stream.
User's orders log (and full orders log in the trade system)
The entire history of user's operarions with orders is sent in user's orders log. User's orders logs are available in 'orders_log' table of the 'FORTS_TRADE_REPL' stream for futures and options; the 'multileg_orders_log' table of the 'FORTS_TRADE_REPL' stream for and multileg instruments.
In case the user configures his login with option to receive "full orders log", he will receive the complete log of all operations with orders on market (including own operations with orders) in anonymous mode. The log will be available in the table 'orders_log' of the stream FORTS_ORDLOG_REPL.
User's deals log
It contains a list of user's committed deals in the current session. User's deals log are available in the 'user_deal' table of the 'FORTS_TRADE_REPL' stream for futures and options; the table 'user_multileg_deal' of the 'FORTS_TRADE_REPL' stream contains logs for multileg instruments deals.
All trade system deals log
It contains a list of all committed deals from all users in the current session. Information of somebody else's deals is presented in anonymous mode. User's deals logs are available in the 'deal' table of the 'FORTS_DEALS_REPL' stream for futures and options; the table 'multileg_deal' contains logs for multileg instruments deals.
To ensure fast recovery of trade information receiving after losing connection with SPECTRA, and same with late start scenario connecting to exchange, PLAZA II 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 2 minute interval in 'FORTS_USERORDERBOOK_REPL' stream.
Includes the following:
Position information
Positions information
Is sent in form of time snaps in the 'FORTS_POS_REPL' stream and last deal ID, included in position calculation by each position value, is available.
User's funds and limits information
Is sent in form of time snaps in the 'FORTS_PART_REPL' stream. Money amount (both money and pledge), money amount at the beginning of the trade session, also current and reserved funds - all of them are available for each value of the client's account.
Clearing information, sent by PLAZA II gateway, includes the following data:
Clearing settlement prices
Are formed by the time of evening clearing and available in the 'fut_sess_settl' table of the 'FORTS_CLR_REPL' stream. The table with settlement prices also includes the instruments whose validity period has ended allowing this table to be used to receive right prices when delivery comes.
Intermediate clearing's variation margin and premium
Intermediate clearing's variation margin and premium is available in the 'fut_intercl_info' and 'opt_intercl_info' tables of the 'FORTS_REFDATA_REPL' stream for futures and options, respectively.
Registries, containing orders rejected during the clearing session.
Contain the orders, which were not replaced during the clearing session due to lack of funds. The registry is transmitted in the 'rejected_orders' table of the 'FORTS_REJECTEDORDERS_REPL' stream.
Client funds based on clearing results
Include information on the amount of funds in the accounts, account activity, fees, total initial and variation margin by the time of clearing. Are sent in the 'FORTS_CLR_REPL' stream.
Option execution orders
The following information is sent as a part of this group:
Current values of RTS indices
Includes current values of RTS index, as well as all Exchange indices values. The values in this table are updated with 15 seconds intervals. The composition of the index information includes of USD rate value, which is used in index calculation. The data is sent in the 'RTS_INDEX_REPL' stream.
Currencies rates values
Contain rates of currencies used in the trading system for processing contracts, calculated in a currency other than rubles. The currencies values are available in the 'curr_online' table of the 'MOEX_RATES_REPL' stream.
That group includes the streams providing the following additional functions:
Current values of the variation margin and premium indicative
Are sent in the 'FORTS_VM_REPL' stream in the context of the positions of clients and SA.
Current volatility values and theoretical prices for options
Are sent in the 'FORTS_VOLAT_REPL' stream.
Each replicated table contains three fields of the fixed type i8 in the top, which are used for replication purpose:
replID — the unique record ID. When a new record appears in the table, the record is assigned with a unique ID. Even though a table may already have a primary ID-key, the one and only ID for replication purpose is the ID contained in the field 'replID'.
replRev — when there is a change made in the table such as record insert, record edit or record deletion, this record will be assigned with a new value in the field 'replRev' (maximum previous 'replRev' value + 1).
replAct — flag of a deleted record. If 'replAct' contains a value other than 0, then the record has been deleted. If 'replAct' contains 0, then the record is active.
To send a command, you should create a publisher with parameters 'NAME = FORTS_SRV', 'category = 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' (msgid=100) message in return.
Field | Type | Description |
---|---|---|
code | i4 | Return code |
message | c255 | Message body |
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. (but not more than 3000) 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 1000 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 msgid=99 and has the following structure:
Field | Type | Description |
---|---|---|
queue_size | i4 | Number of messages for a single user |
penalty_remain | i4 | Time in milliseconds after which the next message from this user will be successfully received. |
message | c128 | Error text message |
Please pay attention to the two details:
The number of messages for the elapsed second is estimated while receiving every single message. Thus, if a user constantly sends requests with the frequency greater than it is allowed, then his messages will not be processed at all.
A reject message with 99 type can be sent in a reply to any user's message.
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:
If the 'COD' mode is enabled for the client, the system monitors the client's activity on transaction layer. Each and every client's command or message registered by the Trading System is considered as activity, no matter whether it was complete or not.
If the client does not send a single message, or does not reconnect to the Trading System after loosing connection within the time period specified (now is 20 seconds), all they active orders are automatically cancelled.
The order cancellation conditions are as following:
A client has not sent any transaction within the specified time limit.
Client application has lost connection to the Router. Orders will be cancelled after reaching the specified time limit.
Router has lost connection to the Access Server. Active orders will be cancelled after reaching the specified time limit.
Access Server has lost connection to the Trading System or become unable to operate properly due to an error. All active orders of all clients connected to this Access Server will be cancelled after reaching the specified time limit.
There may occur an issue when FIX server or an API clients access server connected to the Trading System via gateway becomes unable to operate properly: it loses connections to a client but does not inform the Trading System about it. The Trading System cannot handle such issues; if occurs, the issue should be resolved on the client side.
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 (msgid=10000) into the Trading System at least once per at least once per 10 seconds. The command structure is as following:
Field | Type | Details |
---|---|---|
seq_number | i4 | Heartbeat-message number (not used in the current version). |
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'.
Depending on the user login subtype (main, viewing, transactional), there are different sets of replication streams each login receives.
Replication streams set for the main login subtype:
FORTS_CLR_REPL - Clearing information
FORTS_FEERATE_REPL - Precise Exchange fee rates
FORTS_BROKER_FEE_PARAMS_REPL - Parameters for calculating the brokerage fee
FORTS_BROKER_FEE_REPL - Brokerage fees
FORTS_FEE_REPL - Exchange fees and penalties
FORTS_PROHIBITION_REPL - Prohibitions
FORTS_REFDATA_REPL - Reference and session information
FORTS_TRADE_REPL - User's orders and trades
FORTS_MM_REPL - Information on MM's obligations
FORTS_USERORDERBOOK_REPL - User orders: order book snapshot
FORTS_FORECASTIM_REPL - Risk forecast after limits extension
FORTS_INFO_REPL - Reference information
FORTS_PART_REPL - Information about funds and limits
FORTS_POS_REPL - Information on positions
FORTS_TNPENALTY_REPL - Information about Transaction fees
FORTS_VM_REPL - Variation margin and premium
FORTS_DEALS_REPL - Anonymous trades
FORTS_COMMON_REPL - Market fundamentals
FORTS_VOLAT_REPL - Online volatility information
MOEX_RATES_REPL - Online currency rates
RTS_INDEX_REPL - Online indices
FORTS_RISKINFOBLACK_REPL - Risk parameters for the Black-Scholes model
FORTS_RISKINFOBACH_REPL - Risk parameters for the Bachelier model
FORTS_USER_REPL - Users
FORTS_REJECTEDORDERS_REPL - Register of orders rejected during the clearing
Additional replication streams received (market data source: aggregated orderbook):
FORTS_AGGR5_REPL, FORTS_AGGR20_REPL, FORTS_AGGR50_REPL - Aggregated order-book streams
Additional replication streams received (market data source: full orderbook):
FORTS_ORDLOG_REPL - Anonymous orders
FORTS_ORDBOOK_REPL - Depersonalized order book snapshot
Replication streams set for viewing login subtype:
FORTS_CLR_REPL - Clearing information
FORTS_FEERATE_REPL - Precise Exchange fee rates
FORTS_BROKER_FEE_PARAMS_REPL - Parameters for calculating the brokerage fee
FORTS_BROKER_FEE_REPL - Brokerage fees
FORTS_FEE_REPL - Exchange fees and penalties
FORTS_PROHIBITION_REPL - Prohibitions
FORTS_REFDATA_REPL - Reference and session information
FORTS_TRADE_REPL - User's orders and trades
FORTS_MM_REPL - Information on MM's obligations
FORTS_USERORDERBOOK_REPL - User orders: order book snapshot
FORTS_FORECASTIM_REPL - Risk forecast after limits extension
FORTS_INFO_REPL - Reference information
FORTS_PART_REPL - Information about funds and limits
FORTS_POS_REPL - Information on positions
FORTS_TNPENALTY_REPL - Information about Transaction fees
FORTS_VM_REPL - Variation margin and premium
FORTS_DEALS_REPL - Anonymous trades
FORTS_COMMON_REPL - Market fundamentals
FORTS_VOLAT_REPL - Online volatility information
MOEX_RATES_REPL - Online currency rates
RTS_INDEX_REPL - Online indices
FORTS_RISKINFOBLACK_REPL - Risk parameters for the Black-Scholes model
FORTS_RISKINFOBACH_REPL - Risk parameters for the Bachelier model
FORTS_USER_REPL - Users
FORTS_REJECTEDORDERS_REPL - Register of orders rejected during the clearing
Additional replication streams received (market data source: aggregated orderbook):
FORTS_AGGR5_REPL, FORTS_AGGR20_REPL, FORTS_AGGR50_REPL - Aggregated order-book streams
Additional replication streams received (market data source: full orderbook):
FORTS_ORDLOG_REPL - Anonymous orders
FORTS_ORDBOOK_REPL - Depersonalized order book snapshot
Replication streams set for the transactional login subtype:
FORTS_CLR_REPL - Clearing information
FORTS_FEERATE_REPL - Precise Exchange fee rates
FORTS_BROKER_FEE_PARAMS_REPL - Parameters for calculating the brokerage fee
FORTS_BROKER_FEE_REPL - Brokerage fees
FORTS_FEE_REPL - Exchange fees and penalties
FORTS_PROHIBITION_REPL - Prohibitions
FORTS_REFDATA_REPL - Reference and session information
FORTS_TRADE_REPL - User's orders and trades
FORTS_MM_REPL - Information on MM's obligations
FORTS_USERORDERBOOK_REPL - User orders: order book snapshot
FORTS_FORECASTIM_REPL - Risk forecast after limits extension
FORTS_INFO_REPL - Reference information
FORTS_PART_REPL - Information about funds and limits
FORTS_POS_REPL - Information on positions
FORTS_TNPENALTY_REPL - Information about Transaction fees
FORTS_VM_REPL - Variation margin and premium
FORTS_USER_REPL - Users
FORTS_REJECTEDORDERS_REPL - Register of orders rejected during the clearing
A user is able to change their authentication password for the Trading System by one of the following methods:
using utility change_password (described below);
create their own application for changing authentication password (for details, see the appropriate API object description in cgate_en.pdf, section 'Password change protocol objects') and send message ChangePassword (for details, see here) into the Trading System.
Utility 'change_password'
The 'change_password' utility is designed to change the user's password in the trading system. The utility receives the old and new password of the user, sends them to the TS Spectra, and receives a response about the successful (or not) change of the user's password in the trading system. The utility uses a protocol that provides secure data transmission, the password and user login in clear text are not transmitted over the network.
The utility is a console application launched from the command line using the 'change_password.exe' executable file. Location: for Windows environment - C:\Moscow Exchange\SpectraCGate\bin\change_password.exe; for Linux environment - \opt\moex\cgate\bin\change_password.
Possible parameters to run the utility:
Application name. Optional setting;
Password for the local connection to the router. Optional setting;
Router IP address. Optional setting, the default value is 127.0.0.1
Router port. Optional setting, the default value is 4001
INI file containing logging settings. Optional setting. If no INI file specified, the data will be output to console.
Command line example:
C:\Moscow Exchange\SpectraCGate\bin\change_password.exe --port=4001
To change the password, follow these steps:
Run the utility.
Enter old and new password from console.
Press 'Enter'.
The utility returns '0' if the password change succeed, and '1' in case of any error.
Please note that receiving a successful response means changing the user's password in the trading system, while the authorization of the current router connection does not change. To authorize the router with a new password, you need to change the password in the ini-file of the router and restart the router.
TS SPECTRA supports division (partitioning) of the traded instruments into groups and trading them separately on several independent orders matching modules. Wherein each matching module processes its own group of instruments.The belonging of an instrument to a group (matching) is determined by the underlying asset code (base_contract_code) of the instrument.
Broadcast trading data is also separate and independent, own replication streams are assigned to each of the matching modules. Matching affiliation of the replication streams is determined by the postfix _MATCH $ {id} in the stream name, where $ {id} is the ID of the matching module. For example, the 'FORTS_TRADE_REPL_MATCH1' stream is the user's orders and trades on futures instruments that are processed on MATCH1.
These streams are broadcast separately for each matching (have postfix _MATCH${id}):
The table 'instr2matching_map' is broadcasted to determine the correspondence between the instrument and the matching on which it is processed, in 'FORTS_REFDATA_REPL' stream. The table 'instr2matching_map' has following fields:
base_contract_id - underlying contract ID;
matching_id - matching ID.
Binding of instruments to matchings may change when trading session changes.
New algorithm for receiving trade data
Define 'base_contract_code' for 'isin_id' according to the tables 'fut_sess_contents' / 'opt_sess_contents'.
Define 'base_contract_id' for 'base_contract_code' according to the tables 'fut_vcb' / 'opt_vcb'.
Define matching ID by 'base_contract_id' in the table 'instr2matching_map'.
Open streams with matching _MATCH${id} for getting instrument trade data.
There is only one orders matching module In the TS SPECTRA version 6.3,and old replication streams (without partitioning by matchings) are left for backward compatibility. But old streams will be deleted in future versions of the system, So, we recommend that users rebuild their systems to work with new data streams. Also two new commands 'MoveOrder' (msgid=438) and 'DelOrder' (msgid=436) was added to TS version 6.3. These commands should be used to move and delete orders for futures and options in the trading system with several matchings.
Types of data streams:
'Reliable' (R) - The data published in such streams is relevant, reliable and not subject to change. Any change is a force majeure related to an emergency situation on the Exchange. The trading member can fully rely on data from such flows when making decisions.
'Almost Reliable' (AR) - Data requires reconciliation with reports. Usually data in such streams is not subject to change, but there may be rare situations where the final values published in the reports differ from online data. For example, the settlement price can be adjusted by the NCC (this situation is provided for by regulatory documents). The trading member can rely on data from such flows, taking into account that it may be necessary to adjust the data obtained on the basis of automatic reconciliation with reports.
'Informational' (I) - Data that the trading member cannot rely on as the sole source when he makes a decision. Data from such flows should be used with caution, if possible, by conducting a weighted comparison with similar data obtained in another way. An example of such data is volatility data, which is estimates and depends on the model used and calculation methodology.
The table below shows the gradation of streams by type:
Stream name | Description | Type |
---|---|---|
FORTS_TRADE_REPL | User's orders and trades | R |
FORTS_ORDLOG_REPL | Anonymous orders | R |
FORTS_DEALS_REPL | Anonymous trades | R |
FORTS_USERORDERBOOK_REPL | User orders: order-book snapshot | R |
FORTS_ORDBOOK_REPL | Depersonalized order-book snapshot | R |
FORTS_PROHIBITION_REPL | Prohibitions | R |
FORTS_REFDATA_REPL | Reference and session information | R |
RTS_INDEX_REPL | Online indices | R |
FORTS_INFO_REPL | Reference information | R |
FORTS_USER_REPL | Users | R |
FORTS_REJECTEDORDERS_REPL | Register of orders rejected during the clearing | R |
FORTS_FEE_REPL | Exchange fees and penalties | AR |
FORTS_FEERATE_REPL | Precise Exchange fee rates | AR |
FORTS_CLR_REPL | Clearing information | AR |
FORTS_COMMON_REPL | Market fundamentals | I |
FORTS_AGGR##_REPL | Aggregated order-book | I |
FORTS_POS_REPL | Information on positions | I |
FORTS_PART_REPL | Information about funds and limits | I |
FORTS_MM_REPL | Information on MM's obligations | I |
FORTS_VM_REPL | Variation margin and premium | I |
FORTS_VOLAT_REPL | Online volatility information | I |
FORTS_TNPENALTY_REPL | Information about transaction fees | I |
MOEX_RATES_REPL | Online currency rates | I |
FORTS_FORECASTIM_REPL | Risk forecast after limits extension | I |
FORTS_RISKINFOBLACK_REPL | Risk parameters for the Black-Scholes model | I |
FORTS_RISKINFOBACH_REPL | Risk parameters for the Bachelier model | I |
The system has a limit on the number of simultaneous subscriptions to one PLAZA II (Cgate) stream from one gateway login - no more than 20. If this limit is exceeded, each subsequent attempt to subscribe to a stream will end with the error code ERROR:TOO MANY CONNECTIONS, which is reflected in the Cgate operation log.
In the standard configuration of PLAZA II gate, there are four TCP-connections to the Exchange servers:
Connection for sending requests and commands
Connection for receiving the main market data such as aggregated order-books streams and the streams 'FORTS_ORDLOG_REPL', 'FORTS_DEALS_REPL', 'FORTS_TRADE_REPL' and 'FORTS_COMMON_REPL'.
Connection for receiving auxiliary and reference streams
Connection for receiving snapshots (at the first connection or when recovering after loss of connection)
In order to obtain stability, the trading system uses load balancing method to connect clients to the least loaded server at the moment.
P2MQRouter software handles all TCP-connections, with settings specified in the INI file where connection 'Other Data' is specified as the default outcoming connection and the other connections are specified as outcoming direct connections. This structure is used as the standard to establish connection directly to the Exchange server farm, but connection via a Brokerage Firm server server may require a different structure; in this case, clients should apply to the server's owners for more details about connection.
The P2MQRouter software also handles connection recovery in case of loss of connection. After disconnecting, P2MQRouter starts attempting to reestablish the connection periodically in accordance with the specified time value, while the client software is not able to interfere with the process. P2MQRouter status then changes from 'ROUTER_CONNECTED' to 'ROUTER_RECONNECTING' by receiving the appropriate notifications from object 'connection', and this is a way for client to check whether connection is still active or not.
The CGate library acts in the following way:
When the loss of connection to the incoming request processing gateway occurs, it is detected directly on the moment of receiving the TCP-connection error. All the 'publisher' objects concerned go to the error state.
When the loss of connection for receiving the main market data occurs, it is detected within 30 seconds. All the 'listener' objects concerned go to the error state.
All object in error state should be released. After that, it is necessary to try to reopen them anew periodically, for example, once in a few seconds.
When working with a 'p2mq' type publisher and 'p2mqreply' listener, client code can receive a 'CG_MSG_P2MQ_TIMEOUT' response code. This code signals that response has not been received to the message, a link to which is transmitted along with the response code within a user-specified time period. Response of "timeout" type indicates connection problems or other infrastructural problems on the user or the exchange side. This situation causes uncertainty: it is impossible to recognize whether the sent message was successfully processed by the system or not. To minimize the emergence of uncertainties, it is necessary to set large timeouts in the code - about 60 seconds.
When "timeout" response receiving, it is recommended to have a procedure for verifying the sent message:
It is recommended to verify that the 'p2mq' publisher and 'p2mqreply' listener pair have not went into an error state. If the publisher or the listener stay failed, perform their closure and deletion, then reinitialize them.
It is recommended to always specify the external order number (ext_id parameter) for order management commands. In case of "timeout" sent in response to the 'AddOrder' or 'MoveOrder' command, a possible safe reaction is to delete the order using the 'DelUserOrders' command with 'ext_id' specified.
If "timeout" occurred when deleting/canceling an order, it is assumed that the order was NOT deleted. It is necessary to repeat the deletion after the connection is re-established or use a CS connected to the alternative data center.
Analyze the data of 'orders_log' table of 'FORTS_TRADE_REPL' stream for availability or non-availability orders or cancelled orders.
In case of "timeout" sent in response to a non-trading command, it is recommended to analyze for applied changes a corresponding table state in the replication stream.
In general, the connection recovery algorithm is as follows:
After start-up, try to open connection to P2MQRouter periodically;
When the router is reconnected to the PLAZA II network, the object 'connection' will go to the ACTIVE state;
Open the necessary streams. To make it faster, it is recommended to receive data starting from the last update. When opening a stream, you should use the 'repl state' value received on closing the stream; also, you can directly specify revision numbers for tables and scheme life number by using that of the last received data.
Recover the list of active orders (see below)
Register 'publisher' for orders and commands.
The table below contains the recommended methods for recovering data depending on the stream:
Stream (table) name | Information type | Recovery method |
---|---|---|
FORTS_TRADE_REPL
| Own orders activity log (futures and options) | List of active orders:
Orders activity log:
|
FORTS_TRADE_REPL
| Own orders activity log (multileg orders) | Orders activity log:
|
FORTS_ORDLOG_REPL
| Complete anonymous orders activity log (futures and options) | List of active orders:
Orders activity log:
|
FORTS_ORDLOG_REPL
| Complete anonymous orders activity log (multileg orders) | Orders activity log:
|
FORTS_DEALS_REPL
FORTS_TRADE_REPL
| Orders log (futures, options, multileg instruments) | Reopen the appropriate stream using the last received revision number or 'repl state' value received on closing the stream. |
FORTS_COMMON_REPL | General market information (futures and options) | Reopen the stream anew |
FORTS_AGGR##_REPL | Order books for futures and options. (### - depth of order book) | Reopen the appropriate stream anew |
FORTS_REFDATA_REPL | Reference and session information | Quick method:
Allowable method:
|
FORTS_PART_REPL | Information on limits | Reopen the stream anew |
FORTS_POS_REPL | Information on positions | Reopen the stream anew |
FORTS_VM_REPL | Information on variation margin and premium | Reopen the stream anew |
FORTS_VOLAT_REPL | Information on volatility and theoretical prices on options | Reopen the stream anew |
RTS_INDEX_REPL | Exchange indices values | Reopen the stream anew |
Upon recovery, it is very important to receive the lists of the client's current orders:
List of orders which are active during the recovery procedure period
Orders activity log during the connection loss period.
For the first case, you should receive the order-book snapshot ('FORTS_USERORDERBOOK_REPL'). The orders missed in the snapshot have been either already matched or cancelled during the connection loss period.
For the second case, you should receive your own orders activity log (the table 'orders_log' of the streams 'FORTS_TRADE_REPL', also, the table 'multileg_orders_log' of the stream 'FORTS_TRADE_REPL') covering the connection loss period. To do this, you should open the appropriate stream using revision number of the last record actually received before the loss of connection occurred. Every order activity happened during the connection loss period will be recorded in these tables. Changing the stream state to 'ONLINE' indicates that all orders activity data have been successfully received.
Note: The recovering procedure described above can be also used for the late start connection.
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.
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.
In case of any routine maintenance, normal or abnormal service restarts on the Exchange side, or after reestablishing connection to a client, the publishing services send out notifications about obsolete data cleanup before sending the current snapshot to clients.
There are two types of data cleanup notifications:
CG_MSG_P2REPL_CLEARDELETED - by every table, with use of revision number. The notification gives client the order to cleanup all records with the 'replRev' value smaller than the one in notification. In order to optimise data transfer, the notification may have a revision number value as 'MAX(int64)'. This means that client should cleanup all data from the specified table, as the entire table will be transferred anew.
CG_MSG_P2REPL_LIFENUM - for the entire replication stream, using the new stream life number. This notification means, that data have been significantly changed since the last connection. Client should cleanup all data in all tables. All data will be transferred anew.
In normal work mode, including routine works at non-trading time, when opening or reopening any replication stream except those related to history of orders and trades ('FORTS_TRADE_REPL', 'FORTS_ORDLOG_REPL' and 'FORTS_DEALS_REPL'), a client may receive both 'CG_MSG_P2REPL_CLEARDELETED' or 'CG_MSG_P2REPL_LIFENUM' notification types, and should process them correctly.
In normal work mode, for the streams related to history of orders and trades (see above), the notification CG_MSG_P2REPL_LIFENUM' is sent only in case of system version change, after the testing-mode trades, in order to make clients cleanup the user data. The notification 'CG_MSG_P2REPL_CLEARDELETED' has the 'replRev' value for the first available order or trade at the moment.
A 'CG_MSG_P2REPL_LIFENUM' with a new stream life number during a trading session indicates a severe failure in the Trading System, so the system is to resend data on orders and trades which could be already delivered to clients.
Additionally, there are some other information channels (the Exchange web site, etc.), where information about possible data issues (whether the data already delivered to clients were affected by the last data correction or not) will be posted. This includes information about possible system rollback to the state it was before the failure, along with the last number of order and trade available to client after the system restart.
Tables:
Table 2. Fields of table orders_log
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
public_order_id | i8 | Order ID (for iceberg order – ID of its visible part) |
sess_id | i4 | Trading session ID |
isin_id | i4 | Instrument unique ID |
public_amount | i8 | The number of contracts in the operation (for iceberg order - the number of contracts in the operation for its visible part) |
public_amount_rest | i8 | The remaining number of contracts in the order (for iceberg order – the remaining number of contracts in its visible part) |
id_deal | i8 | Deal ID for this operation |
xstatus | i8 | Extended order's status |
xstatus2 | i8 | Extension for orders statuses (in addition to the ‘xstatus’ field) |
price | d16.5 | Price |
moment | t | Order status changing time |
moment_ns | u8 | Order status changing time, nanoseconds since Unix epoch, UTC |
dir | i1 | Direction |
public_action | i1 | Type of operation with the order (for iceberg order – type of operation with its visible part) |
deal_price | d16.5 | Price of the deal |
client_code | c7 | Client code |
login_from | c20 | Login of the user who has entered the order |
comment | c20 | Trader's comment |
ext_id | i4 | External ID number. It is added to orders, trades |
broker_to | c7 | SPECTRA code of the company to whom the negotiated order is addressed |
broker_to_rts | c7 | RTS code of the company to whom the negotiated order is addressed |
broker_from_rts | c7 | RTS code of the company who has entered the order |
date_exp | t | Order's expiration date |
id_ord1 | i8 | ID number of the first order |
aspref | i4 | Client ID. For orders added by SMA login - MASTER login ID. |
private_order_id | i8 | Order ID (for iceberg order – ID of the entire order) |
private_amount | i8 | The number of contracts in the operation (for iceberg order - the number of contracts in the operation for the entire order) |
private_amount_rest | i8 | The remaining number of contracts in the order (for iceberg order – the remaining number of contracts in the entire order) |
variance_amount | i8 | Variance amplitude for a random addition for the pop-up part (in contracts) |
disclose_const_amount | i8 | Number of instrument units in the pop-up part of the iceberg order |
private_action | i1 | Type of operation with the order (for iceberg order – type of operation with the entire order) |
reason | i4 | The flag (reason) of the order submitted for the making of the settlement trade of obligations. |
match_ref | c10 | Identical text values entered by both trading parties to match negotiated orders |
compliance_id | c1 | Order adding method |
Notes:
Field xstatus is a bit mask. For the complete list of all possible values of field 'status' please refer to section Flags applied to orders and trades.
Field dir can take the following values:
Buy
Sell
Field public_action can take the following values
Order cancelled
Order added
Order is exercised in the trade
Field id_ord1 contains the initial order ID number, i.e. the ID number which was assigned to order before the order has once been relisted
Field 'private_action' ('action') can take the following values:
Order cancelled
Order added
Order is exercised in the trade
The order was added by appearance of a new visible part of the iceberg
Field 'reason' can take the following values:
Regular order
Balancing Derivatives contracts entered into with the Non-defaulting Clearing Member without submitting orders
Closing Derivatives сontracts entered into under the cross-default procedure
Closing Derivatives Contracts entered into upon non-fulfillment of the Margin Call
Closing Derivatives сontracts entered into in into upon non-fulfillment of the Delivery Obligation on the deliverable Derivatives contracts for precious metals.
Other
Field 'compliance_id' can take the following values:
Not filled in/Not specified
Manual input
As a result of the conditional request (stop-loss order)
As a result of the robot algorithm work
As a result of the auto-following algorithm
Covering a position as a result of an unexecuted Margin Call
Table 3. Fields of table multileg_orders_log
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
public_order_id | i8 | Order ID (for iceberg order – ID of its visible part) |
sess_id | i4 | Trading session ID |
isin_id | i4 | Multileg instrument ID |
public_amount | i8 | The number of contracts in the operation (for iceberg order - the number of contracts in the operation for its visible part) |
public_amount_rest | i8 | The remaining number of contracts in the order (for iceberg order – the remaining number of contracts in its visible part) |
id_deal | i8 | Deal ID for this operation |
xstatus | i8 | Extended order's status |
xstatus2 | i8 | Extension for orders statuses (in addition to the ‘xstatus’ field) |
price | d16.5 | Price. The field is not used. |
moment | t | Order status changing time |
moment_ns | u8 | Order status changing time, nanoseconds since Unix epoch, UTC |
dir | i1 | Direction |
public_action | i1 | Type of operation with the order (for iceberg order – type of operation with its visible part) |
deal_price | d16.5 | First leg price of a filled trade |
rate_price | d16.5 | Rate price. The field is not used. |
swap_price | d16.5 | Swap price |
client_code | c7 | Client code |
login_from | c20 | Login of the user who has entered the order |
comment | c20 | Trader's comment |
ext_id | i4 | External ID number. It is added to orders, trades |
broker_to | c7 | SPECTRA code of the company to whom the negotiated order is addressed |
broker_to_rts | c7 | RTS code of the company to whom the negotiated order is addressed |
broker_from_rts | c7 | RTS code of the company who has entered the order |
date_exp | t | Order's expiration date |
id_ord1 | i8 | ID number of the first order |
aspref | i4 | Client ID. For orders added by SMA login - MASTER login ID. |
private_order_id | i8 | Order ID (for iceberg order – ID of the entire order) |
private_amount | i8 | The number of contracts in the operation (for iceberg order - the number of contracts in the operation for the entire order) |
private_amount_rest | i8 | The remaining number of contracts in the order (for iceberg order – the remaining number of contracts in the entire order) |
variance_amount | i8 | Variance amplitude for a random addition for the pop-up part (in contracts) |
disclose_const_amount | i8 | Number of instrument units in the pop-up part of the iceberg order |
private_action | i1 | Type of operation with the order (for iceberg order – type of operation with the entire order) |
reason | i4 | The flag (reason) of the order submitted for the making of the settlement trade of obligations. |
match_ref | c10 | Identical text values entered by both trading parties to match negotiated orders |
compliance_id | c1 | Order adding method |
Notes:
Field xstatus is a bit mask. For the complete list of all possible values of field 'status' please refer to section Flags applied to orders and trades.
Field dir can take the following values:
Buy
Sell
Field public_action can take the following values
Order cancelled
Order added
Order exercised in a trade
Field 'private_action' ('action') can take the following values:
Order cancelled
Order added
Order is exercised in the trade
The order was added by appearance of a new visible part of the iceberg
Field 'reason' can take the following values:
Regular order
Balancing Derivatives contracts entered into with the Non-defaulting Clearing Member without submitting orders
Closing Derivatives сontracts entered into under the cross-default procedure
Closing Derivatives Contracts entered into upon non-fulfillment of the Margin Call
Closing Derivatives сontracts entered into in into upon non-fulfillment of the Delivery Obligation on the deliverable Derivatives contracts for precious metals.
Other
Field 'compliance_id' can take the following values:
Not filled in/Not specified
Manual input
As a result of the conditional request (stop-loss order)
As a result of the robot algorithm work
As a result of the auto-following algorithm
Covering a position as a result of an unexecuted Margin Call
Table 4. Fields of table user_deal
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
sess_id | i4 | Trading session ID |
isin_id | i4 | Instrument unique ID |
id_deal | i8 | Deal ID number |
id_deal_multileg | i8 | Deal ID number for multileg deals |
id_repo | i8 | Deal ID number of the other leg |
xpos | i8 | Number of positions in the instrument in the market after the trade |
xamount | i8 | Volume, number of units of the instrument |
public_order_id_buy | i8 | The buyer's order ID (for iceberg order – ID of its visible part) |
public_order_id_sell | i8 | The seller's order ID (for iceberg order – ID of its visible part) |
price | d16.5 | Price |
moment | t | Time when the deal was made |
moment_ns | u8 | Time when the deal was made, nanoseconds since Unix epoch, UTC |
nosystem | i1 | Sign of non-system deal |
xstatus_buy | i8 | Status of the trade from the buyer's side |
xstatus_sell | i8 | Status of the trade from the seller's side |
xstatus2_buy | i8 | Extension for trades statuses (in addition to the ‘xstatus_buy’ field) |
xstatus2_sell | i8 | Extension for trades statuses (in addition to the ‘xstatus_sell’ field) |
ext_id_buy | i4 | External ID number from the buyer's order |
ext_id_sell | i4 | External ID number from the seller's order |
code_buy | c7 | Buyer's code |
code_sell | c7 | Seller's code |
comment_buy | c20 | Comment from the buyer's order |
comment_sell | c20 | Comment from the seller's order |
fee_buy | d26.2 | Fee of the buyer's deal |
fee_sell | d26.2 | Fee of the seller's deal |
login_buy | c20 | Login of the buyer user |
login_sell | c20 | Login of the seller user |
code_rts_buy | c7 | RTS code of the buyer company |
code_rts_sell | c7 | RTS code of the seller company |
private_order_id_buy | i8 | The buyer's order ID (for iceberg order – ID of the entire order) |
private_order_id_sell | i8 | The seller's order ID (for iceberg order – ID of the entire order) |
reason_buy | i4 | The flag(reason) of the buyer's settlement trade. |
reason_sell | i4 | The flag(reason) of the seller's settlement trade. |
Notes:
Fields code_sell, comment_sell, ext_id_sell, login_sell, code_rts_sell, fee_sell, code_buy, comment_buy, ext_id_buy, login_buy, code_rts_buy, fee_buy, are filled with info only for "own" deals.
Fields xstatus_sell and xstatus_buy are bit masks (for details see Flags applied to orders and trades)
For technical trades that are results of trades with multileg instruments filed nosystem always equals 1, regardless the fact whether the trade is regular or negotiated one. To define whether the initial trade is regular the sign of the field nosystem should correspond to the record in the table multileg_deal.
The field id_repo contains the deal ID of the other leg. It contains deal ID of the second leg for the first leg, and deal ID of the first leg for the second one.
Field id_deal_multileg contains code of the trade with multileg intrument, if this record is about technical trade. the field equals 0 if the trade is with an ordinary instrument.
For all other (not client-related) trades, fields ‘xstatus_buy’ and ‘xstatus_sell’ may contain flags ‘NonQuote’, ‘ClearingTrade’, ‘Address’, ‘Strategy’.
In exercise trades, field private_order_id_buy contains the request ID (option call). In exercise trades, field private_order_id_sell contains the request ID (option put).
The fields fee_buy and fee_sell contain the estimated size of the limit blocked for the trade fee. Fee size must be viewed in the FORTS_FEE_REPL stream.
The reason_buy and reason_sell fields can take the following values:
Regular trade
Balancing Derivatives contracts entered into with the Non-defaulting Clearing Member without submitting orders
Closing Derivatives сontracts entered into under the cross-default procedure
Closing Derivatives Contracts entered into upon non-fulfillment of the Margin Call
Closing Derivatives сontracts entered into in into upon non-fulfillment of the Delivery Obligation on the deliverable Derivatives contracts for precious metals.
Other
Table 5. Fields of table user_multileg_deal
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
sess_id | i4 | Trading session ID |
isin_id | i4 | Multileg instrument ID |
isin_id_rd | i4 | Instrument ID of the first leg |
isin_id_rb | i4 | Instrument ID of the second leg |
duration | i4 | The difference in calendar days between the dates of execution of two futures |
id_deal | i8 | Deal ID number for multileg deals |
id_deal_rd | i8 | Deal ID of the first leg |
id_deal_rb | i8 | Deal ID of the second leg |
public_order_id_buy | i8 | The buyer's order ID (for iceberg order – ID of its visible part) |
public_order_id_sell | i8 | The seller's order ID (for iceberg order – ID of its visible part) |
xamount | i8 | Volume, number of units of the instrument |
price | d16.5 | Price of the first part of multileg trade |
rate_price | d16.5 | Rate price |
swap_price | d16.5 | Swap price |
moment | t | Time when the deal was made |
moment_ns | u8 | Time when the deal was made, nanoseconds since Unix epoch, UTC |
nosystem | i1 | Sign of non-system deal |
xstatus_buy | i8 | Extended status of the trade from the buyer's side |
xstatus_sell | i8 | Extended status of the trade from the seller's side |
xstatus2_buy | i8 | Extension for trades statuses (in addition to the ‘xstatus_buy’ field) |
xstatus2_sell | i8 | Extension for trades statuses (in addition to the ‘xstatus_sell’ field) |
ext_id_buy | i4 | External ID number from the buyer's order |
ext_id_sell | i4 | External ID number from the seller's order |
code_buy | c7 | Buyer's code |
code_sell | c7 | Seller's code |
comment_buy | c20 | Comment from the buyer's order |
comment_sell | c20 | Comment from the seller's order |
login_buy | c20 | Login of the buyer user |
login_sell | c20 | Login of the seller user |
code_rts_buy | c7 | RTS code of the buyer company |
code_rts_sell | c7 | RTS code of the seller company |
private_order_id_buy | i8 | The buyer's order ID (for iceberg order – ID of the entire order) |
private_order_id_sell | i8 | The seller's order ID (for iceberg order – ID of the entire order) |
reason_buy | i4 | The flag(reason) of the buyer's settlement trade. |
reason_sell | i4 | The flag(reason) of the seller's settlement trade. |
Notes:
Fields code_sell, comment_sell, ext_id_sell, code_rts_sell, fee_sell, code_buy, comment_buy, ext_id_buy, code_rts_buy, fee_buy, are filled with info only for "own" deals.
Field rate_price contains 0 for the instruments traded in swap-price.
The reason_buy and reason_sell fields can take the following values:
Regular trade
Balancing Derivatives contracts entered into with the Non-defaulting Clearing Member without submitting orders
Closing Derivatives сontracts entered into under the cross-default procedure
Closing Derivatives Contracts entered into upon non-fulfillment of the Margin Call
Closing Derivatives сontracts entered into in into upon non-fulfillment of the Delivery Obligation on the deliverable Derivatives contracts for precious metals.
Other
Records in this table are added periodically by the trading system's core. It can be used for synchronization purposes (e.g. to check whether all the trades were received at specified moment of time). The table is insert-only, no modifications or deletions occur during trading session.
Table 7. Fields of table sys_events
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
event_id | i8 | Unique ID of the event |
sess_id | i4 | Session number |
event_type | i4 | Type of the event |
message | c64 | Description of the event |
Notes:
Possible types of events
event_type = 1
message = "session_data_ready"
All data from the clearing system have been loaded into the trading system
event_type = 2
message = "intraday_clearing_finished"
All clearing procedures have been finished in the intraday clearing session
event_type = 4
message = "intraday_clearing_started"
Intraday clearing session has started
event_type = 5
message = "clearing_started"
Main clearing session has started
event_type = 6
message = "extension_of_limits_finished"
Limits have been extended
event_type = 8
message = "broker_recalc_finished"
Funds have been recalculated after intraday clearing session
event_type = 23
message = "discrete_auction_add_order_started"
The start of accepting orders in the opening auction
event_type = 24
message = "discrete_auction_add_order_finished"
The finish of accepting orders in the opening auction
Tables:
Table 8. Fields of table orders_log
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
public_order_id | i8 | Order ID (for iceberg order – ID of its visible part) |
sess_id | i4 | Trading session ID |
isin_id | i4 | Instrument unique ID |
public_amount | i8 | The number of contracts in the operation (for iceberg order - the number of contracts in the operation for its visible part) |
public_amount_rest | i8 | The remaining number of contracts in the order (for iceberg order – the remaining number of contracts in its visible part) |
id_deal | i8 | Deal ID for this operation |
xstatus | i8 | Extended order's status |
xstatus2 | i8 | Extension for orders statuses (in addition to the ‘xstatus’ field) |
price | d16.5 | Price |
moment | t | Order status changing time |
moment_ns | u8 | Order status changing time, nanoseconds since Unix epoch, UTC |
dir | i1 | Direction |
public_action | i1 | Type of operation with the order (for iceberg order – type of operation with its visible part) |
deal_price | d16.5 | Price of the deal |
Notes:
Field xstatus is a bit mask. For the complete list of all possible values of field 'status' please refer to section Flags applied to orders and trades.
Field dir can take the following values:
Buy
Sell
Field public_action can take the following values
Order cancelled
Order added
Order is exercised in the trade
Table 9. Fields of table multileg_orders_log
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
public_order_id | i8 | Order ID (for iceberg order – ID of its visible part) |
sess_id | i4 | Trading session ID |
isin_id | i4 | Instrument unique ID |
public_amount | i8 | The number of contracts in the operation (for iceberg order - the number of contracts in the operation for its visible part) |
public_amount_rest | i8 | The remaining number of contracts in the order (for iceberg order – the remaining number of contracts in its visible part) |
id_deal | i8 | Deal ID for this operation |
xstatus | i8 | Extended order's status |
xstatus2 | i8 | Extension for orders statuses (in addition to the ‘xstatus’ field) |
price | d16.5 | Price. The field is not used. |
moment | t | Order status changing time |
moment_ns | u8 | Order status changing time, nanoseconds since Unix epoch, UTC |
dir | i1 | Direction |
public_action | i1 | Type of operation with the order (for iceberg order – type of operation with its visible part) |
deal_price | d16.5 | First leg price of a filled trade |
rate_price | d16.5 | Rate price. The field is not used. |
swap_price | d16.5 | Swap price |
Notes:
Field xstatus is a bit mask. For the complete list of all possible values of field 'status' please refer to section Flags applied to orders and trades.
Field dir can take the following values:
Buy
Sell
Field public_action can take the following values
Order cancelled
Order added
Order exercised in a trade
Records in this table are added periodically by the trading system's core. It can be used for synchronization purposes (e.g. to check whether all the trades were received at specified moment of time). The table is insert-only, no modifications or deletions occur during trading session.
Table 11. Fields of table sys_events
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
event_id | i8 | Unique ID of the event |
sess_id | i4 | Session number |
event_type | i4 | Type of the event |
message | c64 | Description of the event |
Notes:
Possible types of events
event_type = 1
message = "session_data_ready"
All data from the clearing system have been loaded into the trading system
event_type = 2
message = "intraday_clearing_finished"
All clearing procedures have been finished in the intraday clearing session
event_type = 4
message = "intraday_clearing_started"
Intraday clearing session has started
event_type = 5
message = "clearing_started"
Main clearing session has started
event_type = 6
message = "extension_of_limits_finished"
Limits have been extended
event_type = 8
message = "broker_recalc_finished"
Funds have been recalculated after intraday clearing session
event_type = 23
message = "discrete_auction_add_order_started"
The start of accepting orders in the opening auction
event_type = 24
message = "discrete_auction_add_order_finished"
The finish of accepting orders in the opening auction
Tables:
Table 12. Fields of table deal
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
sess_id | i4 | Trading session ID |
isin_id | i4 | Instrument unique ID |
id_deal | i8 | Deal ID number |
xpos | i8 | Number of positions in the instrument in the market after the trade |
xamount | i8 | Volume, number of units of the instrument |
public_order_id_buy | i8 | The buyer's order ID (for iceberg order – ID of its visible part) |
public_order_id_sell | i8 | The seller's order ID (for iceberg order – ID of its visible part) |
price | d16.5 | Price |
moment | t | Time when the deal was made |
moment_ns | u8 | Time when the deal was made, nanoseconds since Unix epoch, UTC |
nosystem | i1 | Sign of non-system deal |
xstatus_buy | i8 | Status of the trade from the buyer's side |
xstatus_sell | i8 | Status of the trade from the seller's side |
xstatus2_buy | i8 | Extension for trades statuses (in addition to the ‘xstatus_buy’ field) |
xstatus2_sell | i8 | Extension for trades statuses (in addition to the ‘xstatus_sell’ field) |
Notes:
In exercise trades, field public_order_id_sell contains the request ID (option trade). In exercise trades, field public_order_id_buy contains the request ID (futures trade for option call). In exercise trades, field public_order_id_sell contains the order ID (futures trade for option put).
Fields xstatus_sell and xstatus_buy are bit masks (for details see Flags applied to orders and trades)
Table 13. Fields of table multileg_deal
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
sess_id | i4 | Trading session ID |
isin_id | i4 | Multileg instrument ID |
id_deal | i8 | Deal ID number |
public_order_id_buy | i8 | The buyer's order ID (for iceberg order – ID of its visible part) |
public_order_id_sell | i8 | The seller's order ID (for iceberg order – ID of its visible part) |
xamount | i8 | Volume, number of units of the instrument |
price | d16.5 | Price of the first part of multileg trade |
rate_price | d16.5 | Rate price |
swap_price | d16.5 | Swap price |
moment | t | Time when the deal was made |
moment_ns | u8 | Time when the deal was made, nanoseconds since Unix epoch, UTC |
nosystem | i1 | Sign of non-system deal |
xstatus_buy | i8 | Status of the trade from the buyer's side |
xstatus_sell | i8 | Status of the trade from the seller's side |
xstatus2_buy | i8 | Extension for trades statuses (in addition to the ‘xstatus_buy’ field) |
xstatus2_sell | i8 | Extension for trades statuses (in addition to the ‘xstatus_sell’ field) |
Notes:
Fields xstatus_sell and xstatus_buy are bit masks (for details see Flags applied to orders and trades)
Records in this table are added periodically by the trading system's core. It can be used for synchronization purposes (e.g. to check whether all the trades were received at specified moment of time). The table is insert-only, no modifications or deletions occur during trading session.
Table 15. Fields of table sys_events
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
event_id | i8 | Unique ID of the event |
sess_id | i4 | Session number |
event_type | i4 | Type of the event |
message | c64 | Description of the event |
Notes:
Possible types of events
event_type = 1
message = "session_data_ready"
All data from the clearing system have been loaded into the trading system
event_type = 2
message = "intraday_clearing_finished"
All clearing procedures have been finished in the intraday clearing session
event_type = 4
message = "intraday_clearing_started"
Intraday clearing session has started
event_type = 5
message = "clearing_started"
Main clearing session has started
event_type = 6
message = "extension_of_limits_finished"
Limits have been extended
event_type = 8
message = "broker_recalc_finished"
Funds have been recalculated after intraday clearing session
event_type = 23
message = "discrete_auction_add_order_started"
The start of accepting orders in the opening auction
event_type = 24
message = "discrete_auction_add_order_finished"
The finish of accepting orders in the opening auction
Tables:
Table 16. Fields of table adjusted_fee
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
id_deal | i8 | Deal ID number |
moment | t | Time when the deal was made |
moment_ns | u8 | Time when the deal was made, nanoseconds since Unix epoch, UTC |
code_buy | c7 | Buyer's code |
code_sell | c7 | Seller's code |
initial_fee_buy | d26.2 | Initial fee of the buyer's deal |
initial_fee_sell | d26.2 | Initial fee of the seller's deal |
adjusted_fee_buy | d26.2 | Adjusted fee of the buyer's deal |
adjusted_fee_trade_buy | d26.2 | Adjusted exchange fee of the buyer's deal |
adjusted_fee_clearing_buy | d26.2 | Adjusted clearing fee of the buyer's deal |
adjusted_fee_sell | d26.2 | Adjusted fee of the seller's deal |
adjusted_fee_trade_sell | d26.2 | Adjusted exchange fee of the seller's deal |
adjusted_fee_clearing_sell | d26.2 | Adjusted clearing fee of the seller's deal |
id_deal_multileg | i8 | Deal ID number for multileg deals |
Table 17. Fields of table penalty
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
sess_id | i4 | Session number |
id_deal | i8 | Deal ID number |
id_deal_multileg | i8 | Deal ID number for multileg deals |
moment | t | Time when the deal was made |
moment_ns | u8 | Time when the deal was made, nanoseconds since Unix epoch, UTC |
code_buy | c7 | Buyer's code |
code_sell | c7 | Seller's code |
penalty_buy | d26.2 | Penalty of the buyer's deal |
penalty_sell | d26.2 | Penalty of the seller's deal |
Table 18. Fields of table sys_events
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
event_id | i8 | Unique ID of the event |
sess_id | i4 | Session number |
event_type | i4 | Type of the event |
message | c64 | Description of the event |
Notes:
Possible types of events
event_type = 1
message = "session_data_ready"
All data from the clearing system have been loaded into the trading system
event_type = 2
message = "intraday_clearing_finished"
All clearing procedures have been finished in the intraday clearing session
event_type = 4
message = "intraday_clearing_started"
Intraday clearing session has started
event_type = 5
message = "clearing_started"
Main clearing session has started
event_type = 6
message = "extension_of_limits_finished"
Limits have been extended
event_type = 8
message = "broker_recalc_finished"
Funds have been recalculated after intraday clearing session
Tables:
option_rate - fee rates on option contracts
Table 19. Fields of table futures_rate
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
isin_id | i4 | Instrument unique ID |
sess_id | i4 | Session number |
exchange_fee_negdeal | d26.2 | Precise exchange fee rate for negotiated trade |
exchange_fee | d26.2 | Precise exchange fee rate for anonymous trade |
clearing_fee_negdeal | d26.2 | Precise clearing fee rate for negotiated trade |
clearing_fee | d26.2 | Precise clearing fee rate for anonymous trade |
exp_clearing_fee | d26.2 |
Precise clearing fee rate for contract exercising. |
Table 20. Fields of table option_rate
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
isin_id | i4 | Instrument unique ID |
sess_id | i4 | Session number |
exchange_fee_negdeal | d26.2 | Precise exchange fee rate for negotiated trade |
exchange_fee | d26.2 | Precise exchange fee rate for anonymous trade |
clearing_fee_negdeal | d26.2 | Precise clearing fee rate for negotiated trade |
clearing_fee | d26.2 | Precise clearing fee rate for anonymous trade |
exp_clearing_fee | d26.2 |
Precise clearing fee rate for contract exercising. |
Table 21. Fields of table sys_events
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
event_id | i8 | Unique ID of the event |
sess_id | i4 | Session number |
event_type | i4 | Type of the event |
message | c64 | Description of the event |
Notes:
Possible types of events
event_type = 1
message = "session_data_ready"
All data from the clearing system have been loaded into the trading system
event_type = 2
message = "intraday_clearing_finished"
All clearing procedures have been finished in the intraday clearing session
event_type = 4
message = "intraday_clearing_started"
Intraday clearing session has started
event_type = 5
message = "clearing_started"
Main clearing session has started
event_type = 6
message = "extension_of_limits_finished"
Limits have been extended
event_type = 8
message = "broker_recalc_finished"
Funds have been recalculated after intraday clearing session
Tables:
Table 22. Fields of table broker_fee
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
sess_id | i4 | Session number |
id_deal | i8 | Deal ID number |
moment | t | Time when the deal was made |
moment_ns | u8 | Time when the deal was made, nanoseconds since Unix epoch, UTC |
code_buy | c7 | Buyer's code |
code_sell | c7 | Seller's code |
broker_fee_buy | d26.2 | Brokerage fee of the buyer's deal |
broker_fee_sell | d26.2 | Brokerage fee of the seller's deal |
id_deal_multileg | i8 | Deal ID number for multileg deals |
Table 23. Fields of table sys_events
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
event_id | i8 | Unique ID of the event |
sess_id | i4 | Session number |
event_type | i4 | Type of the event |
message | c64 | Description of the event |
Notes:
Possible types of events
event_type = 1
message = "session_data_ready"
All data from the clearing system have been loaded into the trading system
event_type = 2
message = "intraday_clearing_finished"
All clearing procedures have been finished in the intraday clearing session
event_type = 4
message = "intraday_clearing_started"
Intraday clearing session has started
event_type = 5
message = "clearing_started"
Main clearing session has started
event_type = 6
message = "extension_of_limits_finished"
Limits have been extended
event_type = 8
message = "broker_recalc_finished"
Funds have been recalculated after intraday clearing session
Tables:
Table 24. Fields of table 'broker_fee_params'
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
sess_id | i4 | Session number |
client_code | c7 | Client code (broker code) |
lower_fee | d26.2 | Minimum possible amount of brokerage fee per contract |
upper_fee | d26.2 | Maximum possible amount of brokerage fee per contract |
multiplier | d26.2 | Multiplier to the amount of exchange and clearing fees |
additive | d26.2 | Constant addition per contract |
Notes:
The 'client_code' field may contain the client code or BF code. If a client code is specified, then the specified parameters are used to calculate the brokerage fee for the trades of this client. If a broker code is specified, then the parameters are used to calculate the brokerage fee for all BF clients.
Field 'sess_id' can take the following values:
Current calculation parameters.
Adding new calculation parameters. Parameters will be applied in the next trading session.
Deletion of current calculation parameters. Parameters will be deleted in the next trading session.
Table 25. Fields of table sys_events
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
event_id | i8 | Unique ID of the event |
sess_id | i4 | Session number |
event_type | i4 | Type of the event |
message | c64 | Description of the event |
Notes:
Possible types of events
event_type = 1
message = "session_data_ready"
All data from the clearing system have been loaded into the trading system
event_type = 2
message = "intraday_clearing_finished"
All clearing procedures have been finished in the intraday clearing session
event_type = 4
message = "intraday_clearing_started"
Intraday clearing session has started
event_type = 5
message = "clearing_started"
Main clearing session has started
event_type = 6
message = "extension_of_limits_finished"
Limits have been extended
event_type = 8
message = "broker_recalc_finished"
Funds have been recalculated after intraday clearing session
The following data is published in the stream every 2 minutes: snapshot of active orders and a record in the 'info' table with the revision of the last processed transaction from 'orders_log', the stream's life number and the publication state of the snapshot ('publication_state' field). The 'publication_state' field is set to '0' in snapshot publication moment. After the snapshot is published, 'publication_state' field is set to '1'. The data in the 'orders' table may be inconsistent until 'publication_state' = 1.
Tables:
Table 26. Fields of table orders
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
public_order_id | i8 | Order ID (for iceberg order – ID of its visible part) |
sess_id | i4 | Trading session ID |
client_code | c7 | Client code |
moment | t | Order status changing time |
moment_ns | u8 | Order status changing time, nanoseconds since Unix epoch, UTC |
xstatus | i8 | Extended order's status |
xstatus2 | i8 | Extension for orders statuses (in addition to the ‘xstatus’ field) |
public_action | i1 | Type of operation with the order (for iceberg order – type of operation with its visible part) |
isin_id | i4 | Instrument unique ID |
dir | i1 | Direction |
price | d16.5 | Price |
public_amount | i8 | The number of contracts in the operation (for iceberg order - the number of contracts in the operation for its visible part) |
public_amount_rest | i8 | The remaining number of contracts in the order (for iceberg order – the remaining number of contracts in its visible part) |
comment | c20 | Trader's comment |
ext_id | i4 | External ID number. It is added to orders, trades |
login_from | c20 | Login of the user who has entered the order |
broker_to | c7 | SPECTRA code of the company to whom the negotiated order is addressed |
broker_to_rts | c7 | RTS code of the company to whom the negotiated order is addressed |
date_exp | t | Order's expiration date |
id_ord1 | i8 | ID number of the first order |
broker_from_rts | c7 | RTS code of the company who has entered the order |
aspref | i4 | Client ID. For orders added by SMA login - MASTER login ID. |
private_order_id | i8 | Order ID (for iceberg order – ID of the entire order) |
private_amount | i8 | The number of contracts in the operation (for iceberg order - the number of contracts in the operation for the entire order) |
private_amount_rest | i8 | The remaining number of contracts in the order (for iceberg order – the remaining number of contracts in the entire order) |
variance_amount | i8 | Variance amplitude for a random addition for the pop-up part (in contracts) |
disclose_const_amount | i8 | Number of instrument units in the pop-up part of the iceberg order |
private_action | i1 | Type of operation with the order (for iceberg order – type of operation with the entire order) |
private_init_moment | t | Placement order time (for iceberg order – placement time of the entire order) |
private_init_amount | i8 | The initial number of contracts in the order (for iceberg order - the initial number of contracts in the entire order) |
reason | i4 | The flag (reason) of the order submitted for the making of the settlement trade of obligations. |
public_init_moment | t | Placement order time (for iceberg order – placement time of its visible part) |
public_init_amount | i8 | The initial number of contracts in the order (for iceberg order - the initial number of contracts in its visible part) |
compliance_id | c1 | Order adding method |
Notes:
Field xstatus is a bit mask. For the complete list of all possible values of field 'status' please refer to section Flags applied to orders and trades.
Field dir can take the following values:
Buy
Sell
Field public_action can take the following values:
Order cancelled
Order added
Order is exercised in the trade
Field 'private_action' ('action') can take the following values:
Order cancelled
Order added
Order is exercised in the trade
The order was added by appearance of a new visible part of the iceberg
Field 'reason' can take the following values:
Regular order
Balancing Derivatives contracts entered into with the Non-defaulting Clearing Member without submitting orders
Closing Derivatives сontracts entered into under the cross-default procedure
Closing Derivatives Contracts entered into upon non-fulfillment of the Margin Call
Closing Derivatives сontracts entered into in into upon non-fulfillment of the Delivery Obligation on the deliverable Derivatives contracts for precious metals.
Other
Field 'compliance_id' can take the following values:
Not filled in/Not specified
Manual input
As a result of the conditional request (stop-loss order)
As a result of the robot algorithm work
As a result of the auto-following algorithm
Covering a position as a result of an unexecuted Margin Call
Table 27. Fields of table info
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
infoID | i8 | Unique key |
logRev | i8 | Last processed revision at the time of snapshot creation |
lifeNum | i4 | Stream life number |
moment | t | Snapshot time |
publication_state | i1 | State of the snapshot publication |
Notes:
Field publication_state can take the following values:
in progress
done
The following data is published in the stream every 2 minutes: snapshot of active orders and a record in the 'info' table with the revision of the last processed transaction from 'orders_log', the stream's life number and the publication state of the snapshot ('publication_state' field). The 'publication_state' field is set to '0' in snapshot publication moment. After the snapshot is published, 'publication_state' field is set to '1'. The data in the 'orders' table may be inconsistent until 'publication_state' = 1.
Tables:
Table 28. Fields of table orders
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
public_order_id | i8 | Order ID (for iceberg order – ID of its visible part) |
sess_id | i4 | Trading session ID |
moment | t | Order status changing time |
moment_ns | u8 | Order status changing time, nanoseconds since Unix epoch, UTC |
xstatus | i8 | Extended order's status |
xstatus2 | i8 | Extension for orders statuses (in addition to the ‘xstatus’ field) |
public_action | i1 | Type of operation with the order (for iceberg order – type of operation with its visible part) |
isin_id | i4 | Instrument unique ID |
dir | i1 | Direction |
price | d16.5 | Price |
public_amount | i8 | The number of contracts in the operation (for iceberg order - the number of contracts in the operation for its visible part) |
public_amount_rest | i8 | The remaining number of contracts in the order (for iceberg order – the remaining number of contracts in its visible part) |
public_init_moment | t | Placement order time (for iceberg order – placement time of its visible part) |
public_init_amount | i8 | The initial number of contracts in the order (for iceberg order - the initial number of contracts in its visible part) |
Notes:
Field xstatus is a bit mask. For the complete list of all possible values of field 'status' please refer to section Flags applied to orders and trades.
Field dir can take the following values:
Buy
Sell
Field public_action can take the following values
Order added
Order is exercised in the trade
Table 29. Fields of table info
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
infoID | i8 | Unique key |
logRev | i8 | Last processed revision at the time of snapshot creation |
lifeNum | i4 | Stream life number |
moment | t | Snapshot time |
publication_state | i1 | State of the snapshot publication |
Notes:
Field publication_state can take the following values:
in progress
done
Tables:
The table contains market fundamentals data (best buy/sell orders, opening/closing price values, etc).
Table 30. Fields of table common
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
sess_id | i4 | Trading session ID |
isin_id | i4 | Instrument unique ID |
best_buy | d16.5 | Best bid (subject to the synthetic liquidity) |
xamount_buy | i8 | Size of the best bid (subject to the synthetic liquidity) |
orders_buy_qty | i4 | Number of bid orders (subject to the synthetic liquidity) |
xorders_buy_amount | i8 | Total number of contracts in bid (subject to the synthetic liquidity) |
best_sell | d16.5 | Best offer (subject to the synthetic liquidity) |
xamount_sell | i8 | Size of the best offer (subject to the synthetic liquidity) |
orders_sell_qty | i4 | Number of offer orders (subject to the synthetic liquidity) |
xorders_sell_amount | i8 | Total number of contracts in offer (subject to the synthetic liquidity) |
open_price | d16.5 | Opening price |
close_price | d16.5 | Closing price |
opening_auction_price | d16.5 | Opening auction price |
price | d16.5 | Price of the last trade |
trend | d16.5 | Price trend (difference between the prices of the last two trades) |
xamount | i8 | Size of the last trade |
deal_time | t | Date and time of the last trade |
deal_time_ns | u8 | Date and time of the last trade, nanoseconds since Unix epoch, UTC |
min_price | d16.5 | The low price |
max_price | d16.5 | The high price |
avr_price | d16.5 | Average weighted price |
xcontr_count | i8 | Total number of contracts in the trades (volume).Takes into account all trades (negotiated and addressless). |
capital | d26.2 | Total volume of trades in Russian rubles (turnover). Shown without taking into account negotiated trades. |
total_premium_volume | d26.2 | Total volume of option premium |
deal_count | i4 | Number of trades |
settlement_price_open | d16.5 | Settlement price at the start of the session. |
xpos | i8 | Current open interest |
mod_time | t | Date and time of changing the entry in the table |
mod_time_ns | u8 | Date and time of changing the entry in the table, nanoseconds since Unix epoch, UTC |
market_price | d16.5 | Current market price. |
price_assigned_by_admin | i1 | Attribute of manual current market price setting by trades Administrator. |
local_time | t | Time stamp for monitoring purposes |
best_buy_native | d16.5 | Best bid (excluding synthetic liquidity) |
xamount_buy_native | i8 | Size of the best bid (excluding synthetic liquidity) |
xorders_buy_amount_native | i8 | Total number of contracts in bid (excluding synthetic liquidity) |
best_sell_native | d16.5 | Best offer (excluding synthetic liquidity) |
xamount_sell_native | i8 | Size of the best offer (excluding synthetic liquidity) |
xorders_sell_amount_native | i8 | Total number of contracts in offer (excluding synthetic liquidity) |
swap_rate | d16.5 | Indicative funding rate (for perpetual futures) |
Notes:
Field open_price contains the price of the first transaction in the current session, and if not, then 0.
Field close_price contains a price value of the last trade in the appropriate trading session. Before the trading session closes, the field contains 0. After the session closes (7 PM till 10 AM), the field close_price contains a price value of the last trade, or 0, if there were no trades during the last trading session.
Field 'price_assigned_by_admin' can take the following values:
The value of the current market price in the 'market_price' field is set by the Trading Administrator.
The value of the current market price in the 'market_price' field is calculated by the system.
Table 31. Fields of table sys_events
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
event_id | i8 | Unique ID of the event |
sess_id | i4 | Session number |
event_type | i4 | Type of the event |
message | c64 | Description of the event |
Notes:
Possible types of events
event_type = 1
message = "session_data_ready"
All data from the clearing system have been loaded into the trading system
event_type = 2
message = "intraday_clearing_finished"
All clearing procedures have been finished in the intraday clearing session
event_type = 4
message = "intraday_clearing_started"
Intraday clearing session has started
event_type = 5
message = "clearing_started"
Main clearing session has started
event_type = 6
message = "extension_of_limits_finished"
Limits have been extended
event_type = 8
message = "broker_recalc_finished"
Funds have been recalculated after intraday clearing session
There are several streams of aggregated order-books with different depths.
FORTS_AGGR50_REPL – with a depth of 50 price levels
FORTS_AGGR20_REPL – with a depth of 20 price levels
FORTS_AGGR5_REPL – with a depth of 5 price levels
The ability to receive particular stream depends on user account rights.
Tables:
Aggregated order-books are formed by summing up volumes of active orders with the same instrument, price and direction.
Modes of using the table depending on the modes of operation of the trading system:
Night period - the tables contain data at the time of the end of the evening session
Trading session before intraday clearing - the table is updated by active orders
Intraday clearing - the table is not updated and contains data at the time of the intraday clearing
Trading session after intraday clearing - the table is updated by active orders
Main clearing - the table is cleared
Evening trading session - the table is updated with active orders from the evening session
Table 32. Fields of table orders_aggr
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
isin_id | i4 | Instrument unique ID |
price | d16.5 | Price level |
volume | i8 | The volume subject to the synthetic liquidity |
moment | t | Moment of the last record update |
moment_ns | u8 | Moment of the last record update, nanoseconds since Unix epoch, UTC |
dir | i1 | Direction |
synth_volume | i8 | The volume of synthetic liquidity |
Note:
The order-book for an instrument may contain records with zero values. This means that the number of orders for the instrument (price levels) is not enough to fill the entire fixed depth of the order-book. Such records should be ignored. Records with zeros can be updated with values with a new price level, when new orders for the instrument appearance in the system.
The records in the order-book for an instrument can be updated (change price/volume/dir). This means that the previous price level "out" the order-book, and the new one "come in" the order-book.
Zeroing (volume = 0) of an existing record in the order-book means that the price level has "out" the order-book (for example, the only order that formed the price level was deleted), and there are no other hidden price levels (orders) for the instrument in the system.
The 'moment' (moment_ns) field value in the table is not monotonically increasing. As 'replRev' increases, records with an earlier value of the 'moment' field may appear in the stream of aggregated order-books. This behavior of the system is expected and can occur in different situations, when the previously formed price level was hidden for some reason, but then began to be displayed. The 'moment' field contains the time of the event that led to the formation of the price level (adding, canceling, exercising an order). Examples of similar system behavior:
The simplest case: in the streams of the aggregated order-books, a price-limited number of liquidity levels is displayed. For example,in FORTS_AGGR20_REPL the top 20 price levels is shown only. A hidden, but already formed level with a price outside the displayed range may appear if one of the displayed price levels "disappeared" (for example, the only order that formed the visible price level was deleted).
A similar, but slightly more complicated situation is associated with indicative synthetic liquidity. In aggregated order-books, regardless of their depth, always no more than 5 price levels formed by indicative synthetic orders are broadcast (see the section called “Synthetic liquidity in aggregated order-books”). If some price levels are represented by indicative synthetic liquidity only, and if such a price level "disappears", the previously hidden price level of indicative synthetic liquidity will be displayed. But if these levels also contain liquidity created by real orders for this instrument, then there will be no such effect. For more information on synthetic matching and indicative synthetic liquidity, see the section called “Synthetic matching”.
An example of building an aggregated order-book:
To simplify, we choose the case when the depth of the glass is equal to 2.
Time 12:00:01. A buy order appeared with a price of 5 and a volume of 10 for a new instrument with isin_id=12345. Four new orders are coming. The order-book was completely filled with zero values.
replID=1 replRev=1 isin_id=12345 price=0 volume=0 moment='12:00:01' dir=1 replID=2 replRev=2 isin_id=12345 price=0 volume=0 moment='12:00:01' dir=1 replID=3 replRev=3 isin_id=12345 price=0 volume=0 moment='12:00:01' dir=2 replID=4 replRev=4 isin_id=12345 price=0 volume=0 moment='12:00:01' dir=2
The record was updated. In one of the records, the price and volume was changed. Note that when a new record added, when null records are searched, the system may choose a random replID, i.e.it can be an update of a record with both replID=1 and replID=2 or some other.
replID=1 replRev=5 isin_id=12345 price=5 volume=10 moment='12:00:01' dir=1
Order-book:
Time 12:00:02. A buy order appeared with a price of 4 and a volume of 10. The record was updated.
replID=2 replRev=6 isin_id=12345 price=4 volume=10 moment='12:00:02' dir=1
Order-book:
Time 12:00:03. A sell order appeared with a price of 8 and a volume of 10. The record was updated.
replID=3 replRev=7 isin_id=12345 price=8 volume=10 moment='12:00:03' dir=2
Order-book:
Time 12:00:04. A sell order appeared with a price of 7 and a volume of 10. The record was updated.
replID=4 replRev=8 isin_id=12345 price=7 volume=10 moment='12:00:04' dir=2
Order-book:
Time 12:00:05. A buy order appeared with a price of 4 and a volume of 5. The record was updated. For an order with a price of 4, i.e. with replID=2, volume was changed .
replID=2 replRev=9 isin_id=12345 price=4 volume=15 moment='12:00:05' dir=1
Order-book:
Time 12:00:06. A buy order with a price of 5 and a volume of 10 was deleted/matched. The record was updated. The price and volume values were zero out for replID=1, as there is no such order anymore.
replID=1 replRev=10 isin_id=12345 price=0 volume=0 moment='12:00:06' dir=1
Order-book:
Time 12:00:07. A buy order appeared with a price of 5 and a volume of 8. The record was updated.
replID=1 replRev=11 isin_id=12345 price=5 volume=8 moment='12:00:07' dir=1
Order-book:
Time 12:00:08. A buy order appeared with a price of 6 and a volume of 10. The record was updated. The entry with price 4 is no longer included in the order-book, it was replaced with price 6.
replID=2 replRev=12 isin_id=12345 price=6 volume=10 moment='12:00:08' dir=1
Order-book:
Time 12:00:09. A buy order with a price of 6 and a volume of 10 was deleted/matched. The record was updated. The order with a price of 6 was deleted, so the order with a price of 4 is returned to the order-book.
replID=2 replRev=13 isin_id=12345 price=4 volume=15 moment='12:00:09' dir=1
Order-book:
Tables:
position_sa - Settlement Account positions
The table contains information on clients and BF positions.
Table 33. Fields of table position
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
client_code | c7 | Client code |
isin_id | i4 | Instrument's unique ID |
xpos | i8 | Current position |
xbuys_qty | i8 | Number of contracts bought during the session |
xsells_qty | i8 | Number of contracts sold during the session |
xopen_qty | i8 | Number of positions at the start of the session |
waprice | d16.5 | Volume-weighted average price |
net_volume_rur | d26.2 | Nett volume per trading session, in Rubles. Positive value indicates credited funds, negative value indicates debited funds |
last_deal_id | i8 | ID of the last deal |
last_quantity | i8 | Position volume as of the end of intraday or evening clearing |
account_type | i1 |
|
The table contains information on Settlement Account positions.
Table 34. Fields of table position_sa
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
client_code | c12 | Settlement Account code |
isin_id | i4 | Instrument's unique ID |
xpos | i8 | Current position |
xbuys_qty | i8 | Number of contracts bought during the session |
xsells_qty | i8 | Number of contracts sold during the session |
xopen_qty | i8 | Number of positions at the start of the session |
waprice | d16.5 | Volume-weighted average price |
net_volume_rur | d26.2 | Nett volume per trading session, in Rubles. Positive value indicates credited funds, negative value indicates debited funds |
last_deal_id | i8 | ID of the last deal |
last_quantity | i8 | Position volume as of the end of intraday or evening clearing |
Table 35. Fields of table sys_events
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
event_id | i8 | Unique ID of the event |
sess_id | i4 | Session number |
event_type | i4 | Type of the event |
message | c64 | Description of the event |
Notes:
Possible types of events
event_type = 1
message = "session_data_ready"
All data from the clearing system have been loaded into the trading system
event_type = 2
message = "intraday_clearing_finished"
All clearing procedures have been finished in the intraday clearing session
event_type = 4
message = "intraday_clearing_started"
Intraday clearing session has started
event_type = 5
message = "clearing_started"
Main clearing session has started
event_type = 6
message = "extension_of_limits_finished"
Limits have been extended
event_type = 8
message = "broker_recalc_finished"
Funds have been recalculated after intraday clearing session
Tables:
The table contains information about funds, limits, and settings for automatic limit changes for clients and brokerage firms.
Table 36. Fields of table part
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
client_code | c7 | Client or brokerage code |
money_free | d26.2 | Amount of free cash in rubles and pledges, discounted to ruble, available for opening positions. (money_free=money_amount + vm_intercl + premium_intercl + net_option_value – money_blocked – vm_reserve – fee – broker_fee – penalty) |
money_blocked | d26.2 | Assets pledged as initial margin. |
vm_reserve | d26.2 | Variation margin on closed positions, and FX risk. |
fee | d26.2 | Debited fee |
limits_set | i1 | Flag of set limits: 1 - limit is set (checked), 0 - limit is not set (not checked) |
money_old | d26.2 | Total amount of rubles and pledges discounted to rubles at the end of the previous session |
money_amount | d26.2 | Total amount of rubles and pledges discounted to rubles |
money_pledge_amount | d26.2 | Total amount of pledges, discounted to rubles |
vm_intercl | d26.2 | Variation margin debited or credited during the intraday clearing |
is_auto_update_limit | i1 | Flag of automatic adjustment of the limit by the amount of income during downloading after clearing: 0-no, 1-adjust. |
broker_fee | d26.2 | Assets blocked as brokerage fees. |
penalty | d26.2 | Penalty for settlement trades made into during the procedure of forced closing of positions of the Defaulting Clearing Member |
premium_intercl | d26.2 | Premium received/withdrawn at intraday clearing. |
net_option_value | d26.2 | Total estimated value of premium options in the portfolio. |
Table 37. Fields of table part_sa
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
settlement_account | c12 | Settlement Account |
money_old | d26.2 | Total amount of rubles and pledges discounted to rubles at the end of the previous session |
money_amount | d26.2 | Total amount of rubles and pledges discounted to rubles |
money_free | d26.2 | Amount of free cash in rubles and pledges, discounted to ruble, available for opening positions. (money_free=money_amount + vm_intercl + premium_intercl + net_option_value – money_blocked – vm_reserve – fee – blocked_tax) |
money_blocked | d26.2 | Assets pledged as initial margin. |
money_pledge_amount | d26.2 | Total amount of pledges, discounted to rubles |
vm_reserve | d26.2 | Variation margin on closed positions, and FX risk. |
vm_intercl | d26.2 | Variation margin withdrawn or deposited during the intraday clearing session |
fee | d26.2 | Debited fee |
blocked_tax | d26.2 | Assets blocked for tax payments. |
premium_intercl | d26.2 | Premium received/withdrawn at intraday clearing. |
net_option_value | d26.2 | Total estimated value of premium options in the portfolio. |
Table 38. Fields of table sys_events
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
event_type | i4 | Type of the event |
event_id | i8 | Unique ID of the event |
sess_id | i4 | Session number |
message | c64 | Description of the event |
Notes:
Possible types of events
event_type = 1
message = "session_data_ready"
All data from the clearing system have been loaded into the trading system
event_type = 2
message = "intraday_clearing_finished"
All clearing procedures have been finished in the intraday clearing session
event_type = 4
message = "intraday_clearing_started"
Intraday clearing session has started
event_type = 5
message = "clearing_started"
Main clearing session has started
event_type = 6
message = "extension_of_limits_finished"
Limits have been extended
event_type = 8
message = "broker_recalc_finished"
Funds have been recalculated after intraday clearing session
Tables:
Table 39. Fields of table prohibition
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
section | c50 | Section name |
base_contract_code | c25 | Underlying asset code. |
isin_id | i4 | Instrument unique ID |
group_mask | i8 | Bitmask of groups for which there is a prohibition |
xprohibition_id | i8 | Number of prohibition |
section_id | i4 | Section ID |
initiator | i4 | Prohibition originator |
base_contract_id | i4 | Underlying contract ID |
client_code | c7 | Client code |
is_legacy | i1 | Prohibition originator type |
priority | i4 | Priority of prohibition |
type | i4 | Type of prohibition |
Notes:
Field 'initiator' - Initiator of the prohibition:
CF Chief trader;
CC Administrator;
TS Administrator.
Field 'type' - Prohibition type
No prohibitions. Used for pinpoint permission in case of a broader prohibition;
Prohibited to open positions;
Prohibited to add any orders;
Prohibited to open sell positions;
BF prohibition to add requests for exercising;
Chief Trader prohibition to add requests for exercising; but to himself - it is possible;
Prohibition of requests without auto-confirmation (RFS);
Prohibition to request liquidity stream (RFS);
Prohibition to perform trades with insufficient number of quotes (RFS);
Prohibition to request liquidity stream with limited lifetime of quotes (RFS).
Field 'group_mask' - Instrument type bitmask:
Futures.
Options.
Field 'priority' - From high to low
12
11
10
9
8
7
6
5
4
3
2
1
Field 'section' - Section name:
Securities
Commodities
Money
Mosenergo exchange, MOSENEX
Exchange of St. Petersburg, SPBEX
SPBEX_OAO
NAMEX
Field 'is_legacy' - Prohibition originator type:
indicates the prohibition set by the Trading Administrator/Clearing Administrator; these prohibitions cannot be changed by traders.
indicates the prohibition set by a trader; these prohibitions can be changed by traders.
Table 40. Fields of table sys_events
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
event_id | i8 | Unique ID of the event |
sess_id | i4 | Session number |
event_type | i4 | Type of the event |
message | c64 | Description of the event |
Notes:
Possible types of events
event_type = 1
message = "session_data_ready"
All data from the clearing system have been loaded into the trading system
event_type = 2
message = "intraday_clearing_finished"
All clearing procedures have been finished in the intraday clearing session
event_type = 4
message = "intraday_clearing_started"
Intraday clearing session has started
event_type = 5
message = "clearing_started"
Main clearing session has started
event_type = 6
message = "extension_of_limits_finished"
Limits have been extended
event_type = 8
message = "broker_recalc_finished"
Funds have been recalculated after intraday clearing session
Tables:
Table 41. Fields of table rates
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
rate_id | i4 | Payment currency identifier |
curr_base | c15 | Base currency code |
curr_coupled | c15 | Linked currency code |
radius | d16.5 | Price indicator change radius (in percent) |
The table contains dictionary of instruments which are traded in specified trading session.
Table 42. Fields of table fut_sess_contents
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
sess_id | i4 | Trading session ID |
isin_id | i4 | Instrument unique ID |
short_isin | c25 | Short symbol code of the instrument for information systems |
isin | c25 | Symbol code of the instrument |
name | c75 | Instrument name |
inst_term | i4 | Shift from spot instruments |
base_contract_code | c25 | Underlying asset code. |
limit_up | d16.5 | Upper price limit |
limit_down | d16.5 | Lower price limit |
settlement_price_open | d16.5 | Settlement price at the start of the session. |
buy_deposit | d16.2 | Collateral of the buyer |
sell_deposit | d16.2 | Collateral of the seller |
roundto | i4 | Number of decimal places after the decimal point for the price |
min_step | d16.5 | Minimum price increment |
lot_volume | i4 | Lot, i.e. number of units of the underlying asset in the instrument |
step_price | d16.5 | Value of the minimum price increment |
last_trade_date | t | Expiration date. |
is_spread | i1 | Flag of the futures contract’s being part of an intermonth spread 1 – spread; 0 – no spread. |
d_exp_start | t | Opening date of instrument exercise |
percent_rate | d6.2 | Variation margin rate for interest rate futures |
settlement_price | d16.5 | Settlement price after the last clearing session. |
signs | i4 | Flags field |
is_trade_evening | i1 | Flag of being traded during the additional trading session (evening/morning) |
ticker | i4 | Unique ID number of the primary RTS standard instruments |
state | i4 | State of trading in the instrument |
multileg_type | i4 | Type of multileg instrument |
legs_qty | i4 | Number of instruments for multileg instrument |
step_price_clr | d16.5 | Value of the minumum increment for the clearing session |
step_price_interclr | d16.5 | Value of the minumum increment for the intraday clearing session |
step_price_curr | d16.5 | Value of the minimum increment in currency. Used for contracts with settlements in foreign currency, for ruble contracts the value is the same as 'step_price'. |
pctyield_coeff | d16.5 | Coef. for yield calculation on percent rates futures |
pctyield_total | d16.5 | Sum of rates for yield calculation on percent rates futures |
d_exp_end | t | Closing date of instrument exercise |
enforce_ims_half_netting | i1 | Flag - consider the risks of intermonth spread according to the "half-netto" rule: "1" - yes; "0" - no. |
tas_base_fut_isin_id | i4 | The UA-futures identifier (isin_id) for the TAS-futures. (Not available in the current version) |
Notes:
Trading session state has priority over instrument state. That is, if a session is in "suspended" or "finished" state, then all instruments can't be traded regardless their states.
Field state can take the following values:
Session for this instrument is scheduled. One can cancel orders for this instrument
Session for this instrument is running. One can both add and cancel orders for this instrument.
Trading in all instruments has been suspended. One can cancel orders for each instrument.
Session for this instrument has been closed compulsorily. Orders can be neither added nor cancelled
Session for this instrument has been completed because the time is up. Orders can be neither added nor cancelled
Trading in this instrument has been suspended. One can cancel orders for this instrument
The opening auction for this instrument started. You can put and delete orders for this instrument.
The opening auction for this instrument is completed
Session for this instrument is running. You can put orders to close position for this instrument.
The opening auction for this instrument is running. You can put orders to close position for this instrument.
Field signs is a bit mask and defines the following values:
The instrument is traded in the additional trading session (evening/morning)
Sign of anonymous trading
Sign of non-anonymous trading
Sign of trading in the main session
Sign of multileg-instrument
Daily futures contract with automatic prolongation (CFD - Contract for difference)
Calendar Spread
Collateral
Exercise in evening or intraday clearing session:
0 - evening clearing session
1 - intraday clearing session
TAS futures (Not available in the current version)
Field multileg_type can take the following values:
Ordinary instrument, not the multileg one
The instrument is calendar futures spread
Field is_trade_evening is bit mask:
Instrument is not traded
Instrument is traded in the evening trading session
Instrument is traded in the main trading session
Field roundto. For this field, the number of decimal places in its value may differ for expiration technical trades. The number of decimal places for expiration price value is determined according to contract specification.
The table contains directory of base contracts for instruments.
Table 43. Fields of table fut_vcb
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
base_contract_code | c25 | Underlying asset code. |
name | c75 | Name |
exec_type | c1 | Settlement type |
curr | c3 | Quotation currency |
trade_scheme | c1 | Trading mode |
section | c50 | Market section. 'Securities', 'Commodities', 'Money' |
rate_id | i4 | Rate ID |
base_contract_id | i4 | Underlying contract ID |
SECCODE | c12 | Code 'SECCODE' of table 'SECURITIES' of ASTS. Default value is NULL. |
signs | i4 | Flags field |
negative_prices | i1 | Sign of restriction of negative prices. |
option_model | i1 | Options pricing model. |
asset_class | i4 | Underlying asset type. |
board_md | с4 | 'SECBOARD' trading board ID from ASTS gateway. |
Notes:
Field exec_type can take the following values:
Cash-settled
Delivery via ASTS
Delivery by other way (not used)
Field trade_scheme can take the following values:
With 100% collateral
With pledge
Field signs is a bit mask and defines the following values:
Exercise in evening or intraday clearing session: 0 - evening clearing session; 1 - intraday clearing session
Foreign instrument: 0 - not foreign; 1 - foreign
TAS futures: 0 - not TAS futures; 1 - TAS futures (Not available in the current version)
Field negative_prices can take the following values:
Futures prices, price limits and options strikes are limited to be positive only.
Futures prices and options strikes are not limited.
Field option_model can take the following values:
Black-Scholes model.
Bachelier model.
Field 'asset_class' may contain the following values:
Share
Currency
Bond
Index
Commodity
Interest rate
Table 44. Fields of table fut_instruments
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
isin_id | i4 | Instrument unique ID |
short_isin | c25 | Short symbol code of the instrument for information systems |
isin | c25 | Symbol code of the instrument |
name | c75 | Instrument name |
inst_term | i4 | Shift from RTS standard instruments |
base_contract_code | c25 | Underlying asset code. |
settlement_price_open | d16.5 | Settlement price at the start of the session. |
roundto | i4 | Number of decimal places after the decimal point for the price |
min_step | d16.5 | Minimum price increment |
lot_volume | i4 | Lot, i.e. number of units of the underlying asset in the instrument |
step_price | d16.5 | Value of the minimum price increment |
last_trade_date | t | Expiration date. |
is_spread | i1 | Flag of the futures contract’s being part of an intermonth spread '1' – spread; '0' – no spread. |
d_exp_start | t | Start date of instrument exercise. |
percent_rate | d6.2 | Variation margin rate for interest rate futures |
settlement_price | d16.5 | Settlement price after the last clearing session. |
signs | i4 | Flags field |
multileg_type | i4 | Type of multileg instrument |
legs_qty | i4 | Number of instruments for multileg instrument |
step_price_clr | d16.5 | Value of the minumum increment for the clearing session |
step_price_interclr | d16.5 | Value of the minumum increment for the intraday clearing session |
step_price_curr | d16.5 | Value of the minimum increment in currency. Used for contracts with settlements in foreign currency, for ruble contracts the value is the same as 'step_price'. |
pctyield_coeff | d16.5 | Coef. for yield calculation on percent rates futures |
pctyield_total | d16.5 | Sum of rates for yield calculation on percent rates futures |
series_type | c1 | Futures maturity type. 'M' - monthly; 'Q' - quarterly. |
enforce_ims_half_netting | i1 | Flag - consider the risks of intermonth spread according to the "half-netto" rule: '1' - yes; '0' - no. |
tas_base_fut_isin_id | i4 | The UA-futures identifier (isin_id) for the TAS-futures. (Not available in the current version) |
Notes:
Field roundto. For this field, the number of decimal places in its value may differ for expiration technical trades. The number of decimal places for expiration price value is determined according to contract specification.
Table 45. Fields of table fut_bond_registry
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
bond_id | i4 | Spot asset unique ID. |
small_name | c25 | Spot asset symbol code |
short_isin | c25 | ISIN code of share/bond issue/currency code |
name | c75 | Spot asset name |
date_redempt | t | Bond’s maturity date (NULL for others) |
nominal | d16.5 | Bond/share par value |
bond_type | i4 | Type: share/bond/currency |
year_base | i2 | Calculation base (conditional number of days in a year) |
Notes:
Field bond_type is a bit mask and defines the following values:
Share
Bond
Amortized bond
Currency
Table 46. Fields of table dealer
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
client_code | c7 | Client code |
name | c200 | Company name |
rts_code | c50 | RTS code of the company |
signs | i4 | Lock mode. 4 - locked by the Trading System Administrator. 8 - locked by Clearing Firm's Chief Trader. |
status | i4 | Sign of segregated account |
transfer_code | c7 | Account code for position transfer |
exp_weight | d3.2 | Expiration scenario weight for BF, in total collateral. Applied during the evening clearing session. |
num_clr_2delivery | i4 | Number of clearing sessions before expiration to start BF expiration scenarios calculation. Applied during the evening clearing session. |
margin_type | i1 | Margin type, according to BF's sections, applied
during the evening clearing session:
|
calendar_spread_margin_type | i1 | Margin type for calendar spreads, for BF portfolio,
applied during the evening clearing session:
|
num_clr_2delivery_client_default | i4 | Number of clearing sessions before expiration to start clients expiration scenarios calculation (default value). Applied during the evening clearing session. |
exp_weight_client_default | d3.2 | Expiration scenario weight for clients, in total collateral (default value). Applied during the evening clearing session. |
coeff_im | d16.5 | Total collateral ratio value, for BF. Applied during the evening clearing session. |
check_limit_on_withdrawal | i1 | Verify collateral sufficiency, for BF, upon funds
depositing/withdrawal, applied during the evening clearing
session:
|
limit_tied_money | i1 | BF trading limit accordance with the BF's total
funds amount (all sections):
|
limits_set | i1 | Verify collateral sufficiency, for BF, upon adding
orders:
|
no_fut_discount | i1 | Discount on futures for BF portfolio, applied
during the evening clearing session:
|
no_fut_discount_client_default | i1 | Discount on futures for BF's clients, default
value:
Applied during the evening clearing session. |
firm_id | c12 | Trading Member's code for Derivatives Market |
tm_name | c200 | Trading Member's name |
short_option_minimum_charge_ratio | d5.3 | Individual coefficient of SOMC scenario weight. |
ics_margin_type | i1 | Margin type for cross-contract
spreads:
|
order_allowed_in_morning_session | i1 | Access to trading during the morning trading session. |
Notes:
Status field is a bit mask:
0x01 - Brokerage Firm (Trust Management type)
0x02 - Segregated Brokerage Firm
0x100 - BF for a client - legal entity
0x200 - BF for non-resident client
0x10000 - NCC
0x20000 – Own Brokerage Firm
0x40000 – Client Brokerage Firm
0x80000 - Special Brokerage Firm
Other bits contain technical information
Field order_allowed_in_morning_session can take the following values:
Access to trading during the morning trading session is limited. Trading operations are prohibited, except for orders cancellation operations.
Access to trading during the morning trading session is allowed.
Table 47. Fields of table sys_messages
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
msg_id | i4 | Unique message ID |
lang_code | c8 | Message language |
type_id | i4 | Message type |
moment | t | Message date and time |
text | c255 | Short text |
urgency | i1 | Urgency |
status | i1 | Message status |
message_body | c4000 | Full text |
Message types:
type_id | Message template text |
---|---|
4 | Dear Clients, please note that if #БФ# futures price remains at the current level during the next #ShiftTimeMin# minutes, trading will be halted for the #НомерРасширения# expansion of #ГРАНИЦА# bound of the price band and #РИСКОВ#. |
5 | Trading in #БФ# futures has been halted for the #НомерРасширения# expansion of #ГРАНИЦА# bound of the price band and #РИСКОВ#. |
6 | Trading in #БФ# futures has been resumed. New #ГРАНИЦА# bounds of the price band: #UpCotir/DownCotir#, new #NEWRATE#. |
7 | Initial margin are #AmountGO# #valuta#, change to the previous day #DiffAmountGO# #valuta#. |
8 | Trading in #БФ# futures has been halted. |
9 | Trading in #БФ# futures has been resumed. |
11 | Contacts for liquidity providers and block trade enabling Brokers - https://www.moex.com/s3005 |
12 | Please, pay attention that today is the last trading day of #ТЕКУЩМЕСЯЦ# #НЕДЕЛЬНЫЕ?weekly##АМЕРИКАНСКИХ/ЕВРОПЕЙСКИХ# #МАРЖИРУЕМЫХ/ПРЕМИАЛЬНЫХ# #РАСЧЕТНЫХ/ПОСТАВОЧНЫХ# equity options (#БФ#). |
13 | Orders can be cancelled now. |
14 | Technical break begins at 14:00. |
15 | Trading will resume at 14:05. Orders can be cancelled now. |
17 | Currency rates for the Variation margin and the Initial margin calculation during the intraday clearing session: CAD=51.88280, CHF=76.18050, EUR=75.59800, GBP=84.79190, HKD=9.03970, JPY=0.53061, TRY=3.75870, USR=71.83600. |
18 | Currency rates for the Variation margin and the Initial margin calculation during the evening clearing session: CAD=51.88280, CHF=76.18050, EUR=76.22500, GBP=84.79190, HKD=9.03970, JPY=0.53061, TRY=3.75870, USR=72.08270. |
19 | Exercise price calculated… |
20 | Attention! To be exercised during the today's intraday clearing session… |
500 | Free form text field for standard messages |
501 | Free form text field for non-standard messages |
The table contains dictionary of instruments which are traded in specified trading session.
Table 48. Fields of table opt_sess_contents
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
sess_id | i4 | Trading session ID |
isin_id | i4 | Instrument unique ID |
isin | c25 | Symbol code of the instrument |
short_isin | c25 | Short symbol code of the instrument for information systems |
name | c75 | Instrument name |
base_contract_code | c25 | Underlying asset code. |
fut_isin_id | i4 | ID of the futures instrument |
settlement_price_open | d16.5 | Settlement price (theoretical price of the option) at the start of the session. |
base_im_covered_sell | d16.2 | Basic size of the collateral to be posted on one open position of the option writer (Russian rubles). |
base_im_sell | d16.2 | Basic size of collateral to be posted on one unsecured position of the option writer (Russian rubles). |
put | i1 | Option’s type. 0 - Call option, 1 - Put option |
strike | d16.5 | Strike price |
roundto | i4 | Number of decimal places after the decimal point for the price |
last_trade_date | t | Expiration date. |
signs | i4 | Flags field |
settlement_price | d16.5 | Settlement price (theoretical price of the option) after the last clearing session. |
base_im_buy | d16.2 | Basic size of Collateral requested in order to buy a futures-style option. |
option_series_id | i4 | Series of Options ID |
state | i4 | The state of trading for the instrument. |
Notes:
Field signs is a bit mask and defines the following values:
The instrument is traded in the additional trading session (evening/morning)
Sign of anonymous trading
Sign of non-anonymous trading
Sign of trading in the main session
Field state can take the following values:
Session for this instrument is scheduled. One can cancel orders for this instrument
Session for this instrument is running. One can both add and cancel orders for this instrument
Trading in all instruments has been suspended. One can cancel orders for each instrument.
Session for this instrument has been closed compulsorily. Orders can be neither added nor cancelled
Session for this instrument has been completed because the time is up. Orders can be neither added nor cancelled
Trading in this instrument has been suspended. One can cancel orders for this instrument
The opening auction for this instrument started. You can put and delete orders for this instrument.
The opening auction for this instrument is completed
Session for this instrument is running. You can put orders to close position for this instrument.
The opening auction for this instrument is running. You can put orders to close position for this instrument.
The table contains dictionary of underlying contracts for instruments.
Table 49. Fields of table opt_vcb
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
base_contract_code | c25 | Underlying asset code. |
name | c75 | Name |
exec_type | c1 | Settlement type |
curr | c3 | Quotation currency |
trade_scheme | c1 | Trading mode |
rate_id | i4 | Rate ID |
base_contract_id | i4 | Underlying contract ID |
negative_prices | i1 | Sign of restriction of negative prices. |
option_model | i1 | Options pricing model. |
settlement_currency | c3 | Settlement currency |
Notes:
Field negative_prices can take the following values:
Futures prices, price limits and options strikes are limited to be positive only.
Futures prices and options strikes are not limited.
Field option_model can take the following values:
Black-Scholes model.
Bachelier model.
Table 50. Fields of table multileg_dict
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
sess_id | i4 | Trading session ID |
isin_id | i4 | Multileg instrument ID |
isin_id_leg | i4 | ID of the instrument which is a component of specified multileg instrument |
qty_ratio | i4 | Quantity ratio |
leg_order_no | i1 | Leg order in a multileg instrument. The default value is 0. |
Notes:
The meaning of the filed qty_ratio is specifying the number and direction of the multileg instrument: If the value equals qty_ratio > 0 then this instrument is a multileg instrument with the same direction with which is the multileg order, if qty_ratio < 0 – with opposite. Absolute value of qty_ratio specifies the coefficient by which the number of multileg instruments in the order should be multiplied in order to get the number of instruments isin_id_leg.
Table 51. Fields of table fut_intercl_info
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
isin_id | i4 | Instrument unique ID |
client_code | c7 | Client code |
vm_intercl | d16.2 | Variation margin debited or credited during the intraday clearing |
Table 52. Fields of table opt_intercl_info
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
isin_id | i4 | Instrument unique ID |
client_code | c7 | Client code |
vm_intercl | d16.2 | Variation margin debited or credited during the intraday clearing |
premium | d16.5 | Ruble premium under the option received/withdrawn at intraday clearing. Include the financial result of exercising the position. |
premium_in_settl_currency | d16.5 | Currency premium under the option received/withdrawn at intraday clearing. Include the financial result of exercising the position. |
Table 53. Fields of table opt_exp_orders
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
exporder_id | i8 | ID of the request to exercise the options |
client_code | c7 | Client code |
isin_id | i4 | Instrument unique ID |
xamount | i8 | Number of expiring positions |
sess_id | i4 | Trading session ID |
date | t | Date and time |
xamount_apply | i8 | Number of positions detailed in requests as of intraday clearing |
Table 54. Fields of table fut_bond_nkd
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
bond_id | i4 | ID of the bond |
date | t | Coupon payment date |
nkd | d16.7 | Accrued interest as of the coupon payment date |
is_cupon | i1 | Flags: 0 - accrued interest as of the bond futures contract settlement date, 2 - accrued interest as of the bond settlement date |
Table 55. Fields of table fut_bond_nominal
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
bond_id | i4 | ID of the bond |
date | t | Coupon payment date |
nominal | d16.5 | payment of bonds’ face value |
face_value | d16.5 | Payment of bonds’ rest face value |
coupon_nominal | d8.5 | Coupon value in % of face value |
is_nominal | i1 | Type of record in the table: 0 - Remaining face value as of bond futures contract expiration date, 2 - Remaining face value as of bond settlement date |
Table 57. Fields of table user
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
login | c20 | Trading participant's login |
start_date | t | Login start time |
end_date | t | Login end time |
client_code | c7 | 7-symbol client code |
operation_mask | i4 | Bitmask:
|
lang | i2 | Message language code |
sma_flags | i4 | Bitmask (see Notes below):
|
sma_status | i4 | Bitmask (see Notes below):
|
aspref | i4 | Client ID. For orders added by SMA login - MASTER login ID. |
user_level | i1 | User login level:
|
password_expiration_date | t | Password expiration date. |
Notes:
Field 'sma_flags' is bitmask:
1st bit: 0 - Cancel on Disconnect is disabled for the login, 1 - Cancel on Disconnect is enabled for the login
2nd bit: 0 - Cancel on Drop-Copy Disconnect is disabled for the login, 1 - Cancel on Drop-Copy Disconnect is enabled for the login
3rd bit: 0 - SMA mode is disabled for the login, 1 - SMA mode is enabled for the login.
Field 'sma_status' is bitmask::
1st bit: 0 - trading transactions are enabled for the login, 1 - trading transactions are disabled for the login
2nd bit: 0 - do not cancel orders when trading transactions are disabled for the login, 1 - cancel orders when trading transactions are disabled for the login.
Table 58. Fields of table sess_option_series
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
series_id | i4 | Series of Options ID |
underlying_id | i4 | Futures ID |
base_contract_id | i4 | Underlying contract ID |
expiration_date | t | Expiration period closing date |
expiration_anchor_date | t | Anchor date (expiration date of series of Options) |
days_to_expiration | i4 | Number of business days (local calendar) before expiration date |
years_to_expiration | f | Time before Option expiration date in fractions of year (calendar days before exercise date/number of days in year) |
series_type | c1 | Option maturity type . W-weekly; M-monthly; Q-quarterly. |
small_name | c25 | Symbol code |
strike_step | d16.5 | Strike step |
use_null_volat | i1 | 1 - Zero volatility calculation mode is on, 0 - Off |
sub_risk | i1 | 1 - Risk accounting by risk sub-points mode is on, 0 - Off |
volat_min | d20.15 | Minimum volatility limit |
volat_max | d20.15 | Maximum volatility limit |
volatility_risk | f | Current volatility risk rate, in fractions |
volatility_mismatch_risk | f | Current volatility mismatch risk rate, in fractions |
signs | i4 | Flags field |
a_black | f | Volatility curve calculation parameter for Black-Scholes model. |
b_black | f | Volatility curve calculation parameter for Black-Scholes model. |
c_black | f | Volatility curve calculation parameter for Black-Scholes model. |
d_black | f | Volatility curve calculation parameter for Black-Scholes model. |
e_black | f | Volatility curve calculation parameter for Black-Scholes model. |
s_black | f | Volatility curve calculation parameter for Black-Scholes model. |
a_bach | f | Volatility curve calculation parameter for Bachelier model. |
b_bach | f | Volatility curve calculation parameter for Bachelier model. |
c_bach | f | Volatility curve calculation parameter for Bachelier model. |
d_bach | f | Volatility curve calculation parameter for Bachelier model. |
e_bach | f | Volatility curve calculation parameter for Bachelier model. |
s_bach | f | Volatility curve calculation parameter for Bachelier model. |
m_bach | f | Volatility curve calculation parameter for Bachelier model. |
r | f | Risk-free interest rate. |
fixed_spot_discount | f | Sum of discounted values of declared cash flows. |
projected_spot_discount | f | Sum of discounted values of forecasted cash flows. |
margin_style | i4 | Option margin method. 0 - Futures-style option; 1 - Equity-style option. |
settlement_type | i4 | Option type. 0 - Сash-settled; 1 - Deliverable. |
exercise_style | i4 | Exercise style of option. 0 - American; 1 - European. |
min_step | d16.5 | The minimum price movement. |
step_price | d16.5 | Price step cost. |
lot_coefficient | i4 | Coefficient indicating the volume of the underlying asset in the contract quote and strikes of option series. |
interest_rate_risk_up | f | Interest rate mismatch rate in the scenario of rate movement ‘r’ upward. |
interest_rate_risk_down | f | Interest rate mismatch rate in the downward rate movement scenario ‘r’. |
step_price_curr | d16.5 | Price step cost in currency. Used for contracts with settlements in foreign currency, for ruble contracts the value is the same as 'step_price'. |
underlying_price | d16.5 | The current spot price of the instrument, or on expiration date, the price of the underlying asset according to which the options will be exercised (see the relevant contract specification for details). |
lot_volume | i4 | Lot, i.e. number of units of the underlying asset in the instrument. |
sess_id | i4 | Trading session ID |
step_price_clr | d16.5 | The cost of the evening clearing price step. |
step_price_interclr | d16.5 | The cost of the intraday clearing price step. |
r2 | f | Risk-free interest rate FX2 of the currency pair FX2/FX1 (for premium options on the currency ); dividend yield rate ‘q’ (for premium options on the index ). |
interest_rate2_risk_up | f | Interest rate mismatch rate in the scenario of rate movement ‘r2’ upward. |
interest_rate2_risk_down | f | Interest rate mismatch rate in the downward rate movement scenario ‘r2’. |
Notes:
Field signs is a bit mask and defines the following values:
Exercise in evening or intraday clearing session: 0 - evening clearing session; 1 - intraday clearing session
Table 59. Fields of table investor
Field | Type | Description |
---|---|---|
replID | i8 | Service field of the replication subsystem |
replRev | i8 | Service field of the replication subsystem |
replAct | i8 | Service field of the replication subsystem |
client_code | c7 | Client code. |
name | c200 | Client name. |
calendar_spread_margin_type | i1 | Margin type for client calendar spread, applied
during the evening clearing session:
|
is_blank | i4 | The account-blank flag for online registration |
short_option_minimum_charge_ratio | d5.3 | Individual coefficient of SOMC scenario weight. |
ics_margin_type | i1 | Mar |