PLAZA II gateway (version 7.21)


Table of Contents

A. History of changes
Introduction
Document purpose
Target audience
Abbreviations
SPECTRA system overview
Trading Membership
Clearing firms
Brokerage firms
Clients
System code pattern
Disclosure of data on participants
Users. How a user is linked to a trading participant
Instruments
Underlying assets
Futures
Daily futures contract with automatic prolongation
Options
Multi-leg instruments
Identification of instruments
Trading operations
Orders — general information
Negotiated orders
Negotiated mode with matching by an unique code
Trades
Cross-trades
Specifics of trading multi-leg instruments
Iceberg orders
Iceberg orders in the system information streams
Iceberg order operations
Change of order ID during iceberg orders operations
Delivery of assets and exercise of options
Deliveries on futures
Settlement of futures contracts of derivatives market for stock market (T+2 mode)
Option exercise
Exercise of futures options
Exercise of options on spot assets
Option risk calculation before exercise
Termination of obligations under daily futures contracts with auto-prolongation (‘perpetual’ futures)
Trade Settlement TAS
Flags applied to orders and trades
Trade types, created upon exercising and expiration of futures and options
Trading and clearing schedule
Trading schedule. Trading sessions.
Intermediate clearing session
Main clearing session
How different entities act on assigning a new trading session
Reference data and session data
Funds and positions
Orders and trades
Instruments
Replication streams
Event-sensitive scheme for data synchronizing
Game and test mode trading schedule
Opening auction
Risk management and limitation of trading operations
Collaterals
Margining of calendar spreads
Trading limits
Unified Collateral Pool
Limitations on trading operations and opening positions for clients
Prohibitions - general information
Automatic prohibitions
Position (obligation) transfer
Pausing trading session for extending limits of trading prices fluctuations
Risk parameters forecast information for trading participants
Blocking the brokerage part of the client fee
Negative prices support in SPECTRA
SMA Login (Sponsored Market Access)
Separate entities of Clearing Member and Trading Member
Who belongs to whom: a view inside SPECTRA
Separation of Members' rights
Management of a Trading Member obligations by a Clearing Member
Synthetic matching
Synthetic orders
Synthetic liquidity in aggregated order-books
Settlement trades
Reasons for settlement trades
Fines and fees
Equity Options
Changes in the calculation of free cash for equity options
New indicator - amount of the premium payable/receivable at the nearest clearing session
Change of the schedule of clearing sessions
Exercise of equity options
Margining of equity options
Prohibitions on equity options
Trading gate description
PLAZA II gateway. Components, installation and setup.
Components and architecture
Hardware and software requirements
Hardware requirements
Software requirements
Installation for Windows
Installation for Linux
Installation from zip archive
Installation from a deb package or rpm package
Developer guidelines
Usage of test examples
Distributed configurations
Recommendations for third-party companies on including the Moscow Exchange runtimes into user application when distributing the user software
Market data structure
Reference information
Trade information
Recovery information
Funds and limits information
Clearing information
Indices and rates information
Auxiliary information streams
Gateway usage specifics
Service replication fields
Commands
Flood control
Cancel On Disconnect
Replication stream sets for different login subtypes
Changing user password for the Trading System
Partitioning of the matching
Stream types
Limiting the number of simultaneously open replication streams from one PLAZA II connection
Handling abnormal situations
Recovery on loss of connection with Exchange servers
Connection loss detection
Recovery algorithm
General recommendations
Recovery in case of the Exchange infrastructure failure
Data cleanup by streams
Possible data change in case of abnormal work of publishing services
Replication scheme FORTS_PUBLIC
Stream FORTS_TRADE_REPL - User's orders and trades (Type=R)
Data scheme
Table orders_log: Log of operations with orders
Table multileg_orders_log: Log of operations with multileg orders
Table user_deal: User trades
Table user_multileg_deal: User’s multileg orders trades
Table heartbeat: Server times table
Table sys_events: table of events
Stream FORTS_ORDLOG_REPL – anonymous orders (Type=R)
Data scheme
Table orders_log: Log of operations with orders
Table multileg_orders_log: Log of operations with multileg orders
Table heartbeat: Server times table
Table sys_events: table of events
Stream FORTS_DEALS_REPL – anonymous trades (Type=R)
Data scheme
Table deal: Trades
Table multileg_deal: Multileg trades
Table heartbeat: Server times table
Table sys_events: table of events
Stream FORTS_FEE_REPL - exchange fees and penalties (Type=AR)
Data scheme
Table adjusted_fee: exchange fees
Table penalty: penalties
Table sys_events: table of events
Stream FORTS_FEERATE_REPL - Precise Exchange fee rates (Type=AR)
Data scheme
Table futures_rate: fee rates on futures and multi-leg instruments
Table option_rate: fee rates on option contracts
Table sys_events: table of events
Stream FORTS_BROKER_FEE_REPL - Brokerage fees (Type=I)
Data scheme
Table broker_fee: brokerage fee
Table sys_events: table of events
Stream FORTS_BROKER_FEE_PARAMS_REPL - Parameters for calculating the brokerage fee (Type=I)
Data scheme
Table broker_fee_params: Parameters for calculating the brokerage fee
Table sys_events: table of events
Stream FORTS_USERORDERBOOK_REPL - User orders: order-book snapshot (Type=R)
Data scheme
Table orders: Current futures and options order-book
Table info: Order-book snapshots information
Stream FORTS_ORDBOOK_REPL - Depersonalized order-book snapshot (Type=R)
Data scheme
Table orders: Current order-book
Table info: Order-book snapshots information
Stream FORTS_COMMON_REPL - Market fundamentals (Type=I)
Data scheme
Table common: Market fundamentals
Table sys_events: table of events
Aggregated order-book streams (Type=I)
Data scheme
Table orders_aggr: Aggregated order-books
Stream FORTS_POS_REPL - information on positions (Type=I)
Data scheme
Table position: Client positions
Table position_sa: Settlement Account positions
Table sys_events: table of events
Stream FORTS_PART_REPL - information about funds and limits (Type=I)
Data scheme
Table part: Funds and limits of clients and brokerage firms
Table part_sa: Funds and limits for Settlement Account
Table sys_events: table of events
Stream FORTS_PROHIBITION_REPL - Prohibitions (Type=R)
Data scheme
Table prohibition: Prohibitions
Table sys_events: table of events
Stream FORTS_REFDATA_REPL - Reference and session information (Type=R)
Data scheme
Table rates: Currency rates dictionary
Table fut_sess_contents: Traded instruments directory (futures)
Table fut_vcb: Traded assets directory (futures)
Table fut_instruments: Instruments dictionary
Table fut_bond_registry: Spot asset parameters directory
Table dealer: Companies directory
Table sys_messages: Trading system messages
Table opt_sess_contents: Traded instruments directory (options)
Table opt_vcb: Traded assets directory (options)
Table multileg_dict: Multileg instruments dictionary
Table fut_intercl_info: Information on the variation margin on futures, calculated based on the results of intraday clearing
Table opt_intercl_info: Information on variation margin and premium on options calculated based on the results of intraday clearing
Table opt_exp_orders: Register of requests for exercise of option
Table fut_bond_nkd: Accrued interest as of the bond futures contract expiration date
Table fut_bond_nominal: Payment of bonds’ face value
Table fut_bond_isin: Guide on bond instruments
Table user: System users
Table sess_option_series: Option series by session
Table investor: Clients directory
Table fut_margin_type: Type of margining
Table fut_settlement_account: Settlement Account
Table sma_master: SMA login binding to MASTER login
Table sma_pre_trade_check: SMA login pre-trade verification settings
Table clearing_members: Clearing Members
Table instr2matching_map: Instrument binding to Matching ID
Table fut_exec_orders: Exercise requests of daily futures contracts with auto-prolongation
Table discrete_auction: Parameters of assigned opening auctions
Table discrete_auction_base_contract: Underlying contracts assigned to the opening auction
Table session: Information about a trading session
Table brokers_base_contracts_params: Individual coefficient of IM in the context of the underlying contract and BF
Table sys_events: table of events
Stream FORTS_MISCINFO_REPL - miscellaneous information (Type=I)
Data scheme
Table volat_coeff: Parametric volatility curve's parameters
Stream FORTS_MM_REPL - information on MM's obligations (Type=I)
Data scheme
Table mm_agreement_filter: Table numbers and types of contracts for the provision of market-making services
Table fut_MM_info: MM's obligations in futures
Table opt_MM_info: MM's obligations in options
Table cs_mm_rule: Instruments for recalculating the central strike price.
Stream FORTS_CLR_REPL - clearing information (Type=AR)
Data scheme
Table money_clearing: Status of clients’ cash accounts after clearing
Table clr_rate: Currency and Index rates
Table fut_pos: Positional state in futures as a result of evening clearing session
Table opt_pos: Positional state in options as a result of evening clearing session
Table fut_sess_settl: Futures settlement prices
Table opt_sess_settl: Options settlement prices
Table pledge_details: Pledgs details table
Table money_clearing_sa: Status of clients’ cash accounts after clearing
Table fut_pos_sa: Positional state of SA on futures as a result of evening clearing session
Table opt_pos_sa: Positional state of SA on options as a result of evening clearing session
Table option_series_settl: Settlement prices for option series
Table sys_events: table of events
Stream RTS_INDEX_REPL - online indices (Type=R)
Data scheme
Table rts_index: Indices
Stream FORTS_VM_REPL - Variation margin and premium (Type=I)
Data scheme
Table fut_vm: Variation margin on futures by positions of clients
Table opt_vm: Variation margin and premium on options in the context of client positions
Table fut_vm_sa: Variation margin on futures in the context of SA positions
Table opt_vm_sa: Variation margin for options
Table sys_events: Table of events
Stream FORTS_VOLAT_REPL - online volatility information (Type=I)
Data scheme
Table volat: Volatility
Table sys_events: Table of events
Stream FORTS_RISKINFOBLACK_REPL - Risk parameters for Black-Scholes model (Type=I)
Data scheme
Table volat_coeff: Risk parameters for Black-Scholes model
Stream FORTS_RISKINFOBACH_REPL - Risk parameters for Bachelier model (Type=I)
Data scheme
Table volat_coeff: Risk parameters for Bachelier model
Stream FORTS_INFO_REPL - additional reference information (Type=R)
Data scheme
Table currency_params: FX parameters
Table base_contracts_params: Base contracts parameters
Table futures_params: Futures parameters
Table option_series_params: Parameters for series of options
Table options_params: Options parameters
Table investor: Clients directory
Table dealer: Companies directory
Table multileg_dictionary: Multileg instruments dictionary
Table common_params: Collateral calculation parameters
Table brokers_base_contracts_params: Individual coefficient of IM in the context of the underlying contract and BF
Table sys_events: Table of events
Stream FORTS_TNPENALTY_REPL - information about Transaction fees (Type=I)
Data scheme
Table fee_tn: Detailed information on the number of incorrect transaction
Table fee_all: Information on the number of points accrued
Table heartbeat: Server times table
Stream MOEX_RATES_REPL - online currency rates (Type=I)
Data scheme
Table curr_online: Currency rates values
Stream FORTS_FORECASTIM_REPL - Risk forecast after limits extension (Type=I)
Data scheme
Table part_sa_forecast: Free funds for SA volume forecast
Stream FORTS_USER_REPL - Users (Type=R)
Data scheme
Table user: System users
Table sma_master: SMA login binding to MASTER login
Table sma_pre_trade_check: SMA login pre-trade verification settings
Table sys_events: Table of events
Stream FORTS_REJECTEDORDERS_REPL - Register of orders rejected during the clearing (Type=R)
Data scheme
Table rejected_orders: Register of orders rejected during the clearing
Commands description
Method AddOrder - Adding orders
Method DelOrder - Deletion of orders
Method DelUserOrders - Mass cancel orders
Method MoveOrder - Modify orders
Method IcebergAddOrder - Adding iceberg orders
Method IcebergDelOrder - Deletion of iceberg orders
Method IcebergMoveOrder - Modify iceberg orders
Method ChangeClientMoney - Change client limits
Method ChangeBFMoney - Change brokerage firm limits
Method OptChangeExpiration - Request for the exercise of options
Method FuturesExecutionRequest - Exercise requests of daily futures contracts with auto-prolongation
Method FutChangeClientProhibit - Modify client's restrictions for futures
Method OptChangeClientProhibit - Modify client's restrictions for options
Method ExchangeBFMoney - Transfer of funds between two BFs of the same SA
Method OptRecalcCS - Recalculate central strike request
Method TransferClientPosition - Transfer client positions
Method OptChangeRiskParametersNextSession - Risk parameters settings for options
Method ChangeBFParametersNextSession - Change BF's parameters by a clearing member
Method ChangeClientParameters - Change parameters of client account
Method ChangeClientParametersNextSession - Change parameters of client account in clearing session
Method ChangeBFClientDefaultParametersNextSession - Change default parameters of client sections
Method ChangeBFClientBaseContractParametersNextSession - Changing the parameters of BF clients for the basic contract
Method ChangeBFLimit - Change BF trading limits
Method CODHeartbeat - Heartbeat message for Cancel on Disconnect Service
Method SetSmaPreTradeCheck - Enable pre-trade verification mode for SMA login orders
Method DelSmaPreTradeCheck - Disable pre-trade verification mode for SMA login orders
Method UserKillSwitch - Disable transactions for trading member login
Method SetBrokerFeeParamNextSession - Setting parameters for calculating the brokerage fee
Method DelOrdersByBFLimit - Request to NCC for collateral sufficiency verification of Brokerage Firm
Method ChangePassword - Change user password for the Trading System
B. PLAZA II data types
C. List of return codes

A. History of changes

DateChanges
22.01.2024Changes applied:
  • Added section '2.4.4. Trade Settlement TAS'.

  • In the section '2.4.5. Flags applied to orders and trades' a description of new flags is added:

    • 'TASSettlement (0x10000)' - Trade Settlement TAS.

  • Stream 'FORTS_TRADE_REPL':

    • The 'compliance_id' field has been added to the 'orders_log' and 'multileg_orders_log' tables.

  • Stream 'FORTS_USERORDERBOOK_REPL':

    • The 'compliance_id' field has been added to the 'orders' table.

  • Stream 'FORTS_REFDATA_REPL':

    • A new bit has appeared in the 'fut_sess_contents' table for the 'signs' field: 0x100000 - TAS futures.

    • A new bit has appeared in the 'fut_vcb' table for the 'signs' field: 0x4 - TAS futures.

    • A new bit has appeared in the 'dealer' table for the 'status' field: 0x10000 - NCC.

    • Table 'sys_messages' now contains field 'type_id'.

    • Removed deprecated 'fut_rejected_orders' and 'opt_rejected_orders' tables. Instead of these tables, you must use the 'rejected_orders' table of the 'FORTS_REJECTEDORDERS_REPL' stream.

  • Starting from version 7.21, the 'FORTS_FUTINFO_REPL' stream is deprecated and will be deleted in version 7.27. Instead, the 'FORTS_RISKINFOBLACK_REPL' and 'FORTS_RISKINFOBACH_REPL' streams should be used.

  • Stream 'FORTS_INFO_REPL':

    • Table 'futures_params' now contains field 'tas_base_fut_isin_id'.

    • A new bit has appeared in the 'futures_params' table for the 'attribute' field: 0x100000 - TAS futures.

  • Changes applied to command scheme repository:

    • The 'compliance_id' (c1) field has been added to the 'AddOrder' message. Added new message type 'AddOrder (msgid=474)'.

    • The 'compliance_id' (c1) field has been added to the 'IcebergAddOrder' message. Added new message type 'IcebergAddOrder (msgid=475)'.

    • The 'compliance_id' (c1) field has been added to the 'MoveOrder' message. Added new message type 'AddOrder (msgid=476)'.

    • The 'compliance_id' (c1) field has been added to the 'IcebergMoveOrder' message. Added new message type 'IcebergAddOrder (msgid=477)'.

01.12.2023Changes applied:
  • The name of the document has been changed: instead of 'SPECTRA Plaza-2 gate' it became 'PLAZA II gateway'.

  • Added section '2.3.2.1. Negotiated mode with matching by a unique code'.

  • In the section '2.4.4. Flags applied to orders and trades' a description of new flags is added:

    • The obsolete 'InternalHalfTrade (0x80000000)' bit has been renamed to 'NegotiatedMatchByRef (0x80000000)' - Negotiated order or trade matched by reference.

  • Added a new stream 'FORTS_REJECTEDORDERS_REPL' - Register of orders rejected during the clearing. Tables:

    • rejected_orders - Register of orders rejected during the clearing. The table is used instead of the deprecated 'fut_rejected_orders' and 'opt_rejected_orders' tables of the 'FORTS_REFDATA_REPL' stream.
  • Stream 'FORTS_COMMON_REPL':

    • Removed deprecated 'type' field from 'sys_events' table. Use the 'event_type' field instead.

  • Stream 'FORTS_REFDATA_REPL':

    • Removed deprecated 'opt_sess_id' field from 'session' table. Use the 'sess_id' field instead.

    • Starting with version 7.18, the 'fut_rejected_orders' and 'opt_rejected_orders' tables are deprecated and will be removed in version 7.21. Instead of these tables, you must use the 'rejected_orders' table of the 'FORTS_REJECTEDORDERS_REPL' stream.

  • Stream 'RTS_INDEX_REPL':

    • Removed deprecated 'value' field from 'rts_index' table. Use the 'value_highprec' field instead.

  • Changes applied to command scheme repository:

    • Removed slow versions of the 'ChangeClientMoney' command (command versions with ID in = 4, 60, 63, 67, 409, 425 / Reply ID out = 104), previously deprecated. Use the faster version of the 'ChangeClientMoney' command with ID in = 458 / Reply ID out = 187.

04.09.2023Changes applied:
  • Section '3.1.4. Installation for Linux' was split into two sections:

    • '3.1.4.1. Installation from zip archive'.

    • '3.1.4.2. Installation from a deb package or rpm package'.

  • Added a new stream 'FORTS_USER_REPL' - Users. Tables:

  • Stream 'FORTS_PROHIBITION_REPL':

    • Removed value '0x20000000 (Spots)' for 'group_mask' field in 'prohibition' table.

  • Stream 'FORTS_REFDATA_REPL':

    • The deprecated 'option_series' table has been deleted. Instead of this table, use the 'sess_option_series' table.

    • Table 'sess_option_series' now has fields 'interest_rate_risk_up', 'interest_rate_risk_down', 'r2', 'interest_rate2_risk_up', 'interest_rate2_risk_down'.

    • Removed deprecated 'state' field from 'sess_option_series' table. Use the 'state' field from the 'opt_sess_contents' table instead.

    • Removed deprecated 'status' field from 'investor' table. Use the 'xstatus' field instead.

  • Stream 'FORTS_CLR_REPL':

    • The 'sbor_nosys' field has been added to the 'fut_pos', 'opt_pos', 'fut_pos_sa' and 'opt_pos_sa' tables.

    • Table 'fut_sess_settl' now contain field 'index_div'.

  • Stream 'FORTS_VM_REPL':

    • Added the 'sys_events' event table.

  • Stream 'FORTS_VOLAT_REPL':

    • Added the 'sys_events' event table.

  • Stream 'FORTS_INFO_REPL':

    • Table 'option_series_params' now has fields 'r2', 'interest_rate2_risk_up', 'interest_rate2_risk_down'.

  • Stream 'FORTS_TNPENALTY_REPL':

    • Table 'fee_tn' now contain field 'num_orders'.

  • Removed error codes: 9999.

02.06.2023Changes applied:
  • Stream 'FORTS_COMMON_REPL':

    • Table 'sys_events' now contain field 'event_type'.

    • Starting with version 7.12, the 'type' field from the 'sys_events' table is deprecated and will be removed in version 7.18. Use the 'event_type' field instead.

  • Stream 'FORTS_REFDATA_REPL':

    • Removed deprecated 'd_exec_beg' and 'd_exec_end' fields from 'opt_sess_contents' table. The 'expiration_date' field from the 'sess_option_series' table should be used instead.

    • Removed deprecated 'step_price' field from 'opt_sess_contents' table. Use the 'step_price' field from the 'sess_option_series' table instead.

    • Starting with version 7.12, the 'opt_sess_id' field from the 'session' table is deprecated and will be removed in version 7.18. Use the 'sess_id' field instead.

    • Table 'sess_option_series' now has fields 'step_price_clr', 'step_price_interclr'.

  • Stream 'FORTS_CLR_REPL':

    • Removed 'vat_ex' and 'vat_cc' fields from 'fut_pos', 'opt_pos', 'fut_pos_sa' and 'opt_pos_sa' tables.

  • Stream 'RTS_INDEX_REPL':

    • Starting with version 7.12, the 'value' field from the 'rts_index' table is deprecated and will be removed in version 7.18. Use the 'value_highprec' field instead.

  • Changes applied to command scheme repository:

    • Slow versions of the 'ChangeClientMoney' command (versions of commands with ID in = 4, 60, 63, 67, 409, 425 / Reply ID out = 104 ) starting from version 7.12 are deprecated and will be removed in version 7.18. Use the faster version of the 'ChangeClientMoney' command with ID in = 458 / Reply ID out = 187.

  • In version 7.12, the system introduced a limit on the number of simultaneous subscriptions to one Plaza2 (Cgate) stream from one gateway login - no more than 20 (for more details, see the section "3.3.9. Limiting the number of simultaneously open replication streams from one Plaza2 connection").

27.03.2023Changes applied:
  • In the section '2.4.4. Trade types, created upon exercising and expiration of futures and options' a description of new flags is added:

    • The obsolete 'eREPOCCStatus (0x2000)' bit has been renamed to 'DueToCrossCancel (0x2000)' - Sign of canceling a passive order in a cross trade.

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

  • Stream 'FORTS_COMMON_REPL':

    • Table 'common' now contain field 'swap_rate'.

    • Added the 'sys_events' event table.

  • Stream 'FORTS_PROHIBITION_REPL':

    • Table 'prohibition' now has fields 'section_id', 'base_contract_id'.

    • As of version 7.9, the value '0x20000000 (Spots)' for the 'group_mask' field in the 'prohibition' table is deprecated and will be removed in version 7.15.

  • Stream 'FORTS_REFDATA_REPL':

    • Removed deprecated 'is_percent' field from 'fut_sess_contents' and 'fut_instruments' tables.Use the 'asset_class' field from the 'fut_vcb' table instead.

    • Table 'investor' now contain field 'xstatus'. The 'xstatus' field differs from the existing 'status' field by the extended type i8 and the transmitted of two additional flags in it:

      • 0x10000000000 - Qualified investor

      • 0x40000000000 - Cancel a passive order in a cross trade

    • Starting with version 7.9, the 'status' field from the 'investor' table is deprecated and will be removed in version 7.15. Use the 'xstatus' field instead.

    • Added table 'brokers_base_contracts_params'.

    • Table 'opt_sess_contents' now contain field 'state'.

    • Starting with version 7.9, the 'state' field from the 'option_series' and 'sess_option_series' tables is deprecated and will be removed in version 7.15. Use the 'state' field from the 'opt_sess_contents' table instead.

  • Stream 'FORTS_INFO_REPL':

    • Removed deprecated 'is_percent' field from 'base_contracts_params' table. The 'asset_class' field should be used instead.

    • Added table 'brokers_base_contracts_params'.

  • Changes applied to command scheme repository:

    • Added command 'ChangeBFClientBaseContractParametersNextSession ' (msgid=1057) - Changing the parameters of BF clients for the basic contract.

09.11.2022Changes applied:
  • New order type Book-or-Cancel (BOC) was added to section "2.3.1. Orders — general information".

  • Section '2.4.4. Trade types, created upon exercising and expiration of futures and options' was split into two sections:

    • '2.4.4. Flags applied to orders and trades'.

    • '2.4.5. Trade types, created upon exercising and expiration of futures and options'.

  • In the section '2.4.4. Flags applied to orders and trades' a description of new flags is added:

    • DuringDiscreteAuction (0x4000000000000000) - Sign of an order or trade in the opening auction.

    • BOC (0x1000000000000000) - Book-or-Cancel order.

  • Added section '2.5.7. Opening auction'.

  • Stream 'FORTS_TRADE_REPL':

    • The 'xstatus2' field has been added to the 'orders_log' and 'multileg_orders_log' tables.

    • The 'xstatus2_buy' and 'xstatus2_sell' fields have been added to the 'user_deal' and 'user_multileg_deal' tables.

  • Stream 'FORTS_ORDLOG_REPL':

    • The 'xstatus2' field has been added to the 'orders_log' and 'multileg_orders_log' tables.

  • Stream 'FORTS_DEALS_REPL':

    • The 'xstatus2_buy' and 'xstatus2_sell' fields have been added to the 'deal' and 'multileg_deal' tables.

  • Stream 'FORTS_USERORDERBOOK_REPL':

    • The 'xstatus2' field has been added to the 'orders' table.

  • Stream 'FORTS_ORDBOOK_REPL':

    • The 'xstatus2' field has been added to the 'orders' table.

  • Stream 'FORTS_COMMON_REPL':

    • Table 'common' now contain field 'opening_auction_price'.

  • Stream 'FORTS_REFDATA_REPL':

    • Added 'sess_option_series', 'discrete_auction' and 'discrete_auction_base_contract' tables.

    • The fields 'europe', 'min_step', 'lot_volume' were removed from the 'opt_sess_contents' table.

    • Table 'user' now contain field 'user_level'.

    • Starting with version 7.6, the 'option_series' table is deprecated and will be removed in future versions. Instead of this table, use the 'sess_option_series' table.

  • Stream 'FORTS_CLR_REPL':

    • The 'pos_exec' and 'charge_exec' fields were added to the 'fut_pos', 'opt_pos', 'fut_pos_sa' and 'opt_pos_sa' tables.

    • Starting with version 7.6, the 'vat_ex' and 'vat_cc' fields in the 'fut_pos', 'opt_pos', 'fut_pos_sa' and 'opt_pos_sa' tables are deprecated and will be removed in version 7.12.

  • Stream 'FORTS_INFO_REPL':

    • The 'subrisk_step' field was removed from the 'base_contracts_params' table.

    • The 'subrisk' field was removed from the 'futures_params' table.

  • Changes applied to command scheme repository:

    • The 'type' (i4) field has been added to the 'IcebergAddOrder' message. Added new message type 'IcebergAddOrder (msgid=472)'.

  • Added new error codes: 82, 85, 90, 95, 100, 105, 110, 115, 120, 125, 130, 135, 3002, 4300-4305

  • Changed texts of error codes: 62

15.09.2022Changes applied:
  • Added section '2.3.4. Cross-trades'.

  • Added section '2.4.3. Termination of obligations under daily futures contracts with auto-prolongation (‘perpetual’ futures)'.

  • In the section '2.4.4. Trade types, created upon exercising and expiration of futures and options' a description of new flags is added:

    • ePerpetualFuturesExecutionVoluntary (0x10000000000000) - The technical trade as a result of exiting a perpetual futures (based on the submitted requests).

    • ePerpetualFuturesExecutionForced (0x400000000000000) - The technical trade as a result of forced exiting a perpetual futures (realization of unsatisfied demand).

    • ePerpetualFuturesExecution (0x800000000000000) - The technical trade with linked instrument as a result of exiting a perpetual futures.

  • Stream 'FORTS_FEE_REPL':

    • Table 'adjusted_fee' now contains fields 'adjusted_fee_trade_buy', 'adjusted_fee_clearing_buy', 'adjusted_fee_trade_sell', 'adjusted_fee_clearing_sell'.

  • Stream 'FORTS_PROHIBITION_REPL':

    • Added the 'sys_events' event table.

  • Stream 'FORTS_REFDATA_REPL':

    • The deprecated 'prohibition' table has been deleted. Instead of this table, use the 'prohibition' table of the 'FORTS_PROHIBITION_REPL' stream.

    • Added table 'fut_exec_orders'.

    • Starting with version 7.3, the 'is_percent' field from the 'fut_sess_contents' and 'fut_instruments' tables is deprecated and will be removed in version 7.9. Use the 'asset_class' field from the 'fut_vcb' table instead.

    • Starting from version 7.3, the 'd_exec_beg' and 'd_exec_end' fields in the 'opt_sess_contents' table are deprecated and will be removed in version 7.9. The 'expiration_date' field from the 'option_series' table should be used instead.

  • Stream 'FORTS_INFO_REPL':

    • The 'signs' field was removed from the 'currency_params' table.

    • Starting with version 7.3, the 'is_percent' field in the 'base_contracts_params' table is deprecated and will be removed in version 7.9. The 'asset_class' field should be used instead.

  • Changes applied to command scheme repository:

    • The 'client_priority' (i4) field has been added to the 'FutChangeClientProhibit' and 'OptChangeClientProhibit' messages. New types of 'FutChangeClientProhibit' (msgid=469) and 'OptChangeClientProhibit' (msgid=468) messages have been added.

    • Added command 'FuturesExecutionRequest ' (msgid=470) - Exercise requests for daily futures contracts with auto-prolongation.

    • In the 'OptChangeExpiration' message, the 'order_id' field type has been changed to 'i8'. Added new message type 'OptChangeExpiration (msgid=471)'.

  • Added new error codes: 4283, 5052-5055, 5061-5065, 5069, 5071-5073.

  • Changed texts of error codes: 4050-4055, 4060-4067, 4069, 4070.

  • Removed error codes: 300-307, 4068.

17.05.2022Changes applied:
  • Added section '2.11. Equity Options'.

  • Changed section '2.2.3. Options'.

  • Changed section '2.4.2. Option exercise'.

  • In the section '2.4.3. Trade types, created upon exercising and expiration of futures and options' a description of new flags is added:

    • eSyntheticPassive (0x200000000000000) - 'Sign of a passive synthetic order'.

  • Changed section '2.5. Trading and clearing schedule'.

  • Changed section '2.6.3. Limitations on trading operations and opening positions for clients'.

  • Stream 'FORTS_TRADE_REPL':

    • Removed 'id_ord', 'xamount', 'xamount_rest', 'action' fields from 'orders_log' and 'multileg_orders_log' tables.

    • Removed 'id_ord_buy' and 'id_ord_sell' fields from 'user_deal' and 'user_multileg_deal' tables.

  • Stream 'FORTS_USERORDERBOOK_REPL':

    • The fields 'id_ord', 'xamount', 'xamount_rest', 'action', 'init_moment', 'xinit_amount' were removed from the 'orders' table.

  • Stream 'FORTS_POS_REPL':

    • The 'last_quantity' field was added to the 'position' and 'position_sa' tables.

  • Stream 'FORTS_PART_REPL':

    • The 'premium_intercl' and 'net_option_value' fields were added to the 'part' and 'part_sa' tables.

  • Stream 'FORTS_PROHIBITION_REPL':

    • The 'prohib_id' field was removed from the 'prohibition' table.

  • Stream 'FORTS_REFDATA_REPL':

    • Table 'option_series' now contains fields 'margin_style', 'settlement_type', 'exercise_style', 'min_step', 'step_price', 'lot_coefficient', 'r', 'interest_rate_risk_up', 'interest_rate_risk_down', 'fixed_spot_discount', 'projected_spot_discount', 'step_price_curr', 'underlying_price', 'lot_volume','state'.

    • The 'base_isin_id' field was removed from the 'opt_sess_contents' table.

    • Starting with version 7.0, the 'europe' field in the 'opt_sess_contents' table is deprecated and will be removed in version 7.6. Use the 'exercise_style' field from the 'option_series' table instead.

    • Starting with version 7.0, the 'min_step' field in the 'opt_sess_contents' table is deprecated and will be removed in version 7.6. Use the 'min_step' field from the 'option_series' table instead.

    • Starting with version 7.0, the 'lot_volume' field in the 'opt_sess_contents' table is deprecated and will be removed in version 7.6. Use the 'lot_volume' field from the 'option_series' table instead.

    • Starting with version 7.0, the 'step_price' field in the 'opt_sess_contents' table is deprecated and will be removed in version 7.6. Use the 'step_price' field from the 'option_series' table instead.

    • Table 'fut_vcb' now has fields 'asset_class', 'board_md'.

    • In the 'fut_vcb' table, the value for the 'asset_class' field has been removed: '7' - Precious metal.

    • Table 'opt_intercl_info' now has fields 'premium', 'premium_in_settl_currency'.

    • Table 'opt_vcb' now contains field 'settlement_currency'.

    • The 'prohib_id' field was removed from the 'prohibition' table.

    • Removed deprecated table 'usd_online'.

    • The fields 'A', 'B', 'C', 'D', 'E', 'S' were removed from the 'option_series' table.

  • Stream 'FORTS_CLR_REPL':

    • The 'premium' and 'premium_in_settl_currency' fields were added to the 'opt_pos' and 'opt_pos_sa' tables.

    • Added table 'option_series_settl'.

  • Stream 'FORTS_VM_REPL':

    • The 'premium' and 'premium_in_settl_currency' fields were added to the 'opt_vm' and 'opt_vm_sa' tables.

  • Stream 'FORTS_INFO_REPL':

    • Starting with version 7.0, the 'subrisk_step' field in the 'base_contracts_params' table is deprecated and will be removed in version 7.6. Use the 'strike_step' field from the 'option_series_params' table instead.

    • Table 'base_contracts_params' now has fields 'asset_class', 'cf_risk'.

    • In the 'base_contracts_params' table, the value for the 'asset_class' field has been removed: '7' - Precious metal.

    • Starting with version 7.0, the 'subrisk' field in the 'futures_params' table is deprecated and will be removed in version 7.6. Use the 'sub_risk' field from the 'option_series_params' table instead.

    • Table 'option_series_params' now contains fields 'sub_risk', 'spread_aspect', 'enforce_half_netting', 'min_step', 'step_price', 'lot_coefficient', 'r', 'interest_rate_risk_up', 'interest_rate_risk_down', 'fixed_spot_discount', 'projected_spot_discount'.

    • The fields 'a', 'b', 'c', 'd', 'e', 's' were removed from the 'option_series_params' table.

  • Changed texts of error codes: 4067.

05.04.2022Changes applied:
  • Added section '2.2.2.1. Daily futures contract with automatic prolongation'.

  • The section '3.3.4. Latency monitoring by the client side', which is outdated, has been removed.

  • Stream 'FORTS_REFDATA_REPL':

    • A new bit has appeared in the 'fut_sess_contents' table for the 'signs' field: 0x4000 - Daily futures contract with automatic prolongation (CFD - Contract for difference).

  • Stream 'FORTS_CLR_REPL':

    • Table 'fut_sess_settl' now contain field 'swap_rate'.

20.10.2021Changes applied:
  • Updating the utility for changing the password (change_password.exe):

    • The 'app_name' parameter (application name) has been added to the command string.

    • The 'local_pass' parameter (password for the local connection to the router) has been added to the command string.

    • The 'key' parameter has been removed from the valid command string parameters.

  • Added a new stream 'FORTS_PROHIBITION_REPL' - Prohibitions. The 'prohibition' table is broadcast in a separate stream.

  • Stream 'FORTS_REFDATA_REPL':

    • Starting with version 6.15, the 'prohibition' table is deprecated and will be removed in version 7.3. Instead of this table, use the 'prohibition' table of the 'FORTS_PROHIBITION_REPL' stream.

  • Stream 'FORTS_INFO_REPL':

    • Starting with version 6.15, the 'signs' field in the 'currency_params' table is deprecated and will be removed in version 7.3.

  • Added new error codes: 81, 4280-4282.

  • Changed texts of error codes: 4160.

  • Removed error codes: 4168.

23.07.2021Changes applied:
  • Added section '2.10. Settlement trades'.

  • Stream 'FORTS_PART_REPL':

    • The 'balance_money' field was removed from the 'part' table.

  • Stream 'FORTS_REFDATA_REPL':

    • The 'enforce_ims_half_netting' field was added to the 'fut_sess_contents' and 'fut_instruments' tables.

  • Stream 'FORTS_INFO_REPL':

    • Table 'futures_params' now contains field 'enforce_ims_half_netting'.

    • Table 'option_series_params' now contain fields 'margin_style', 'settlement_type', 'exercise_style'.

  • Stream FORTS_FEERATE_REPL:

    • Tables 'futures_rate', 'option_rate' now contain 'exp_clearing_fee' field. In version 6.12, the field will always contain "0.0". In version 6.15, this field will be filled with rate values.

  • Removed error codes: 4120, 4121.

  • Added new error codes: 80.

14.05.2021Changes applied:
  • In the section '2.4.3. Trade types, created upon exercising and expiration of futures and options' a description of new flags is added:

    • eDontFineRF (0x80000000000000) - 'No penalty for settlement transactions'.

  • Removed 'FORTS_FUTTRADE_REPL' and 'FORTS_OPTTRADE_REPL' streams. Use the 'FORTS_TRADE_REPL' stream instead.

  • Removed 'FORTS_FUTORDERBOOK_REPL' and 'FORTS_OPTORDERBOOK_REPL' streams. Use the 'FORTS_USERORDERBOOK_REPL' stream instead.

  • Removed 'FORTS_FUTCOMMON_REPL' and 'FORTS_OPTCOMMON_REPL' streams. Use the 'FORTS_COMMON_REPL' stream instead.

  • Removed 'FORTS_FUTINFO_REPL' and 'FORTS_OPTINFO_REPL' streams. Use the 'FORTS_REFDATA_REPL' stream instead.

  • Removed the streams 'FORTS_FUTAGGR5_REPL', 'FORTS_FUTAGGR20_REPL', 'FORTS_FUTAGGR50_REPL', 'FORTS_OPTAGGR5_REPL', 'FORTS_OPTAGGR20_REPL' and 'FORTS_OPTAGGR50_REPL'. Use the 'FORTS_AGGR5_REPL', 'FORTS_AGGR20_REPL', and 'FORTS_AGGR50_REPL' streams instead.

  • Stream 'FORTS_TRADE_REPL':

    • Removed 'local_stamp' field from 'orders_log' and 'multileg_orders'_log tables.

    • The 'reason' field has been added to the 'orders_log' and 'multileg_orders_log' tables.

    • The 'reason_buy' and 'reason_sell' fields have been added to the 'user_deal' and 'user_multileg_deal' tables.

  • Stream 'FORTS_FEE_REPL':

    • Added table 'penalty'.

  • Stream 'FORTS_USERORDERBOOK_REPL':

    • Table 'orders' now contain field 'reason'.

  • Stream 'FORTS_PART_REPL':

    • Table 'part' now contain field 'penalty'.

    • Table 'part_sa' now contain field 'blocked_tax'.

  • Stream 'FORTS_REFDATA_REPL':

    • Removed the 'd_start' field from the 'fut_sess_contents', 'fut_instruments' and 'opt_sess_contents' tables.

    • Table 'prohibition' now contain field 'xprohibition_id'.

    • Starting with version 6.9, the 'prohib_id' field in the 'prohibition' table is deprecated and will be removed in version 6.15.

    • Starting with version 6.9, the 'usd_online' table is deprecated and will be removed in version 6.15. Instead of this table, use the 'curr_online' table of the 'MOEX_RATES_REPL' stream.

  • Stream 'FORTS_CLR_REPL':

    • Table 'money_clearing_sa' now contain field 'blocked_tax'.

  • Changes applied to command scheme repository:

    • The 'local_stamp' field has been removed from the 'AddOrder', 'MoveOrder', 'DelOrder', 'DelUserOrders', 'IcebergAddOrder','IcebergMoveOrder', and 'IcebergDelOrder' messages. Added new message types: 'AddOrder' (msgid = 465), 'MoveOrder' (msgid = 460), 'DelOrder' (msgid = 461), 'DelUserOrders' (msgid = 466), 'IcebergAddOrder' (msgid = 462), 'IcebergMoveOrder' (msgid = 463) and 'IcebergDelOrder' (msgid = 464).

    • The deprecated message 'FutTransferRisk.' was removed.

  • Added new error codes: 3001.

  • Changed texts of error codes: 4017.

25.02.2021Changes applied:
  • Stream 'FORTS_PART_REPL':

    • Starting from version 6.8, the 'balance_money' field in the 'part' table is deprecated and will be removed in version 6.12.

12.01.2021Changes applied:
  • Stream 'FORTS_REFDATA_REPL':

    • Table 'dealer' now contain field 'order_allowed_in_morning_session'.

  • Stream 'FORTS_INFO_REPL':

    • Table 'dealer' now contain field 'order_allowed_in_morning_session'.

  • Changes applied to command scheme repository:

    • Since version 6.7, the 'FutTransferRisk' procedure is deprecated and will be removed in future versions.

  • Added new error codes: 4226.

19.10.2020Changes applied:
  • Changed section '2.5. Trading and clearing schedule'.

  • Changed section '2.4.3. Trade types, created upon exercising and expiration of futures and options'.

  • Stream 'FORTS_TRADE_REPL':

    • In the 'orders_log' and 'multileg_orders_log' tables, the 'local_stamp' field is deprecated and will be removed in version 6.9.

  • Stream 'FORTS_DEALS_REPL':

    • Table 'deal' now has fields 'xstatus_buy', 'xstatus_sell'.

    • Table 'multileg_deal' now has fields 'xstatus_buy', 'xstatus_sell'.

  • Stream 'FORTS_USERORDERBOOK_REPL':

    • Table 'info' now contain field 'publication_state'.

  • Stream 'FORTS_ORDBOOK_REPL':

    • Table 'info' now contain field 'publication_state'.

  • Stream 'FORTS_REFDATA_REPL':

    • Table 'user' now contain field 'password_expiration_date'.

  • Changes applied to command scheme repository:

    • Updated command for setting client limits 'ChangeClientMoney' (msgid=458).

    • Removed the following deprecated commands: 'FutAddOrder', 'OptAddOrder', 'FutAddMultilegOrder', 'FutDelOrder', 'OptDelOrder', 'FutMoveOrder', 'OptMoveOrder', 'FutDelUserOrders', 'OptDelUserOrders', 'FutChangeClientMoney', 'FutChangeBFMoney', 'FutExchangeBFMoney', 'FutTransferClientPosition', 'OptTransferClientPosition', 'FutChangeBFLimit'.

    • The command 'OptChangeRiskParameters' renamed to 'OptChangeRiskParametersNextSession'.

    • In commands, the 'local_stamp' field is deprecated and will be removed in version 6.9.

  • Added new error codes: 300-307, 4175.

  • Changed texts of error codes: 4006-4011, 4017.

17.08.2020Changes applied:
  • Added section '2.3.5. Iceberg orders'.

  • In the section '2.4.3. Trade types, created upon exercising and expiration of futures and options' a description of new flags is added:

    • eIceberg (0x800000000000) - sign of an iceberg order, trade on an iceberg order

    • eSynthetic (0x200000000000) - sign of synthetic order

    • eOperatorInputSA (0x1000000000000) - blocking by Settlement Account

  • Changed section '2.6.9. Negative prices support in SPECTRA'.

  • Added section '2.9. Synthetic matching '.

  • Added new stream 'FORTS_TRADE_REPL'. Combines 'FORTS_FUTTRADE_REPL' and 'FORTS_OPTTRADE_REPL' streams.

  • The 'FORTS_FUTTRADE_REPL' and 'FORTS_OPTTRADE_REPL' streams in SPECTRA 6.5 are deprecated, the changes should be found in the 'FORTS_TRADE_REPL' stream description.

  • Stream 'FORTS_TRADE_REPL':

    • Table 'orders_log' now contain fields 'public_order_id', 'public_amount', 'public_amount_rest', 'public_action', 'private_order_id', 'private_amount', 'private_amount_rest', 'variance_amount', 'private_action', 'disclose_const_amount'.

    • Table 'multileg_orders_log' now contain fields 'public_order_id', 'public_amount', 'public_amount_rest', 'public_action', 'private_order_id', 'private_amount', 'private_amount_rest', 'variance_amount', 'private_action', 'disclose_const_amount'.

    • Table 'user_deal' now contain fields 'public_order_id_buy', 'public_order_id_sell', 'private_order_id_buy', 'private_order_id_sell'.

    • Table 'user_multileg_deal' now contain fields 'public_order_id_buy', 'public_order_id_sell', 'private_order_id_buy', 'private_order_id_sell'.

  • Added new stream 'FORTS_USERORDERBOOK_REPL'. Combines 'FORTS_FUTORDERBOOK_REPL' and 'FORTS_OPTORDERBOOK_REPL' streams.

  • The 'FORTS_FUTORDERBOOK_REPL' and 'FORTS_OPTORDERBOOK_REPL' streams in SPECTRA 6.5 are deprecated, the changes should be found in the 'FORTS_USERORDERBOOK_REPL' stream description.

  • Stream 'FORTS_USERORDERBOOK_REPL':

    • Table 'orders' now contain fields 'public_order_id', 'public_amount', 'public_amount_rest', 'public_action', 'private_order_id', 'private_amount', 'private_amount_rest', 'variance_amount', 'private_action', 'disclose_const_amount', 'public_init_moment', 'public_init_amount', 'private_init_moment', 'private_init_amount'.

  • In the 'orders_log' and 'multileg_orders_log' tables of the 'FORTS_ORDLOG_REPL' stream:

    • The 'id_ord' field is renamed to 'public_order_id'.

    • The 'xamount' field is renamed to 'public_amount'.

    • The 'xamount_rest' field is renamed to 'public_amount_rest'.

    • The 'action' field is renamed to 'public_action'.

  • In the 'deal' and 'multileg_deal' tables of the 'FORTS_DEALS_REPL' stream:

    • The 'id_ord_buy' field is renamed to 'public_order_id_buy'.

    • The 'id_ord_sell' field is renamed to 'public_order_id_sell'.

  • In the 'orders' table of the 'FORTS_ORDBOOK_REPL' stream:

    • The 'id_ord' field is renamed to 'public_order_id'.

    • The 'xamount' field is renamed to 'public_amount'.

    • The 'xamount_rest' field is renamed to 'public_amount_rest'.

    • The 'action' field is renamed to 'public_action'.

    • The 'init_moment' field is renamed to 'public_init_moment'.

    • The 'xinit_amount' field is renamed to 'public_init_amount'.

  • Added new stream 'FORTS_COMMON_REPL'. Combines 'FORTS_FUTCOMMON_REPL' and 'FORTS_OPTCOMMON_REPL' streams.

  • The 'FORTS_FUTCOMMON_REPL' and 'FORTS_OPTCOMMON_REPL' streams in SPECTRA 6.5 are deprecated, the changes should be found in the 'FORTS_COMMON_REPL' stream description.

  • Stream 'FORTS_COMMON_REPL':

    • Description of the 'best_buy', 'xamount_buy', 'orders_buy_qty', 'xorders_buy_amount', 'best_sell', 'xamount_sell', 'orders_sell_qty', 'xorders_sell_amount' fields has been changed in the 'common' table.

    • Table 'common' now contain fields 'best_buy_native', 'xamount_buy_native', 'xorders_buy_amount_native', 'best_sell_native', 'xamount_sell_native', 'xorders_sell_amount_native'.

    • The 'old_kotir' and 'cur_kotir' fields have been removed from the 'common' table.

  • Aggregated order-book stream:

    • Added new streams 'FORTS_AGGR5_REPL', 'FORTS_AGGR20_REPL', 'FORTS_AGGR50_REPL'. Combining relevant futures and options streams.

    • Table 'orders_aggr' now contain field 'synth_volume'.

    • Description of the 'volume' field has been changed in the 'orders_aggr' table.

  • Stream 'FORTS_CLR_REPL':

    • The 'share' field have been removed from the 'money_clearing' table.

    • The 'account' field have been removed from the 'fut_pos' table.

    • The 'account' field have been removed from the 'opt_pos' table.

  • Added new stream 'FORTS_REFDATA_REPL'. Combines 'FORTS_FUTINFO_REPL' and 'FORTS_OPTINFO_REPL' streams.

  • The 'FORTS_FUTINFO_REPL' and 'FORTS_OPTINFO_REPL' streams in SPECTRA 6.5 are deprecated, the changes should be found in the 'FORTS_REFDATA_REPL' stream description.

  • Stream 'FORTS_REFDATA_REPL':

    • The 'code_vcb', 'old_kotir', 'd_pg', 'last_cl_quote' fields have been removed from the 'fut_sess_contents' table.

    • The 'code_vcb', 'is_foreign' fields have been removed from the 'fut_vcb' table.

    • The 'code_vcb', 'old_kotir', 'd_pg', 'd_exp', 'exec_name', 'last_cl_quote' fields have been removed from the 'fut_instruments' table.

    • The 'go_ratio' field have been removed from the 'dealer' table.

    • The 'code_vcb' field have been removed from the 'prohibition' table.

    • Table 'fut_margin_type' now contain field 'operator_input'.

    • The 'code_vcb', 'old_kotir', 'd_pg', 'last_cl_quote', 'bgo_c', 'bgo_nc', 'bgo_buy' fields have been removed from the 'opt_sess_contents' table.

    • The 'code_vcb' field have been removed from the 'opt_vcb' table.

    • Table 'option_series' now contain field 'm_bach'.

  • Stream 'FORTS_INFO_REPL':

    • The 'code_vcb' field have been removed from the 'base_contracts_params' table.

    • The 'code_vcb', 'settl_price', 'settl_price_real' fields have been removed from the 'futures_params' table.

    • The 'go_ratio' field have been removed from the 'investor' table.

    • The 'go_ratio' field have been removed from the 'dealer' table.

    • Table 'option_series_params' now contain field 'm_bach'.

  • Stream 'FORTS_PART_REPL':

    • The 'coeff_go', 'no_fut_discount', 'num_clr_2delivery' fields have been removed from the 'part' table.

  • Stream 'FORTS_RISKINFOBACH_REPL':

    • Table 'volat_coeff' now contain field 'm'.

  • Changes applied to command scheme repository:

    • Added command 'AddOrder'. Combines 'FutAddOrder', 'OptAddOrder' and 'FutAddMultilegOrder'.

    • Added command 'DelUserOrders'. Combines 'FutDelUserOrders' and 'OptDelUserOrders'.

    • Added commands 'IcebergAddOrder', 'IcebergDelOrder', 'IcebergMoveOrder'. Commands to manage iceberg orders.

    • The command 'ChangeBFParameters' renamed to 'ChangeBFParametersNextSession'.

    • The command 'ChangeBFClientDefaultParameters' renamed to 'ChangeBFClientDefaultParametersNextSession'.

  • Added new error codes: 4174, 4258, 4259, 4260, 4261, 4262, 4264, 4266, 4268.

19.06.2020Changes applied:
  • Added section '2.6.9. Negative prices support in SPECTRA'.

  • Added new stream 'FORTS_RISKINFOBLACK_REPL - Risk parameters for Black-Scholes model'.

  • Added new stream 'FORTS_RISKINFOBACH_REPL - Risk parameters for Bachelier model'. In release 6.4.20, '0' is translated in the parameters.

  • Stream 'FORTS_FUTCOMMON_REPL':

    • Table 'common' now contain field 'price_assigned_by_admin'.

  • Stream 'FORTS_FUTINFO_REPL':

    • Table 'fut_vcb' now contain fields 'negative_prices', 'option_model'.

  • Stream 'FORTS_OPTINFO_REPL':

    • Table 'opt_vcb' now contain fields 'negative_prices', 'option_model'.

    • Table 'option_series' now contain fields 'a-s_black', 'a-s_bach'.

  • Stream 'FORTS_INFO_REPL':

    • Table 'base_contracts_params' now contain field 'option_model'. The 'has_options' and 'spot_price' fields are deprecated and will be removed in version 6.6.

    • Table 'futures_params' now contain fields 'attribute', 'mr_addon_up', 'mr_addon_down'.

    • Table 'option_series_params' now contain fields 'a-s_black', 'a-s_bach'.

  • Stream 'FORTS_VOLAT_REPL':

    • Table 'volat' now contain field 'option_model'.

15.01.2020Changes applied:
  • Added section '2.6.8. Blocking the brokerage part of the client fee'.

  • Added new stream 'FORTS_BROKER_FEE_REPL - Brokerage fees'.

  • Added new stream 'FORTS_BROKER_FEE_PARAMS_REPL - Parameters for calculating the brokerage fee' .

  • Stream 'FORTS_PART_REPL':

    • Table 'part' now contain field 'broker_fee'.

  • Stream 'FORTS_OPTCOMMON_REPL':

    • Table 'common' now contain field 'total_premium_volume'.

  • Changes applied to command scheme repository:

    • Removed 'FutChangeBFParameters' command.

    • Added command 'SetBrokerFeeParamNextSession - Setting parameters for calculating the brokerage fee'.

  • Added new error codes: 3000.

10.12.2019Changes applied:
  • Modified section '3.1.3. Installation for Windows'.

12.09.2019Changes applied:
  • Added section '3.3.10. Stream types'. Type added to stream descriptions.

31.08.2019Changes applied:
  • Added section '3.3.9. Partitioning of the matching'.

  • The description of two new flags is added to section '2.4.3. Trade types, created upon exercising and expiration of futures and options': eActiveSide (0x20000000000), ePassiveSide (0x40000000000). They are put down in orders and trades.

  • Stream 'FORTS_FUTINFO_REPL':

    • Added table 'instr2matching_map'.

  • Stream 'RTS_INDEX_REPL':

    • Table 'rts_index': deleted fields 'prev_close_value', 'open_value', 'max_value', 'min_value'.

  • Changes applied to command scheme repository:

    • Added commands 'DelOrder', 'MoveOrder', 'ChangeClientParameters'.

    • Field type changed from i4 to i1 for the fields 'calendar_spread_margin_type' and 'ics_margin_type' in the 'ChangeBFParameters' and 'ChangeClientParametersNextSession' commands.

  • Added new error codes: 78, 79, 4269.

20.06.2019Changes applied:
  • Stream 'FORTS_FUTTRADE_REPL':

    • Table 'orders_log': deleted fields 'hedge', 'trust'.

    • Table 'multileg_orders_log': deleted fields 'hedge', 'trust'.

    • Table 'user_deal': deleted fields 'trust_buy', 'trust_sell', 'hedge_buy', 'hedge_sell'.

    • Table 'user_multileg_deal': deleted fields 'isin_id_repo', 'buyback_amount', 'trust_buy', 'trust_sell', 'hedge_buy', 'hedge_sell'.

  • Stream 'FORTS_OPTTRADE_REPL':

    • Table 'orders_log': deleted fields 'hedge', 'trust'.

    • Table 'user_deal': deleted fields 'trust_buy', 'trust_sell', 'hedge_buy', 'hedge_sell'.

  • Field 'buyback_amount ' deleted from table 'multileg_deal' of stream 'FORTS_DEALS_REPL'.

  • Field 'id_repo' deleted from table 'adjusted_fee' of stream 'FORTS_FEE_REPL'.

  • Stream 'FORTS_FUTORDERBOOK_REPL' / 'FORTS_OPTORDERBOOK_REPL':

    • Table 'orders': deleted fields 'hedge', 'trust'.

  • Stream 'FORTS_FUTCOMMON_REPL':

    • Table 'common': deleted field 'cur_kotir_real'. Added fields 'settlement_price_open', 'market_price'.

  • Stream 'FORTS_OPTCOMMON_REPL':

    • Table 'common' now contain field 'settlement_price_open'.

  • Stream 'FORTS_FUTINFO_REPL':

    • Added table 'clearing_members'.

    • Table 'fut_sess_contents': deleted fields 'd_exp', 'price_dir'. Added fields 'base_contract_code', 'settlement_price_open', 'settlement_price', 'last_trade_date'.

    • Table 'fut_vcb' now contain fields 'base_contract_code', 'signs'.

    • Table 'fut_instruments': deleted field 'price_dir'. Added fields 'base_contract_code', 'settlement_price_open', 'settlement_price', 'last_trade_date', 'd_exp_start', 'series_type'.

    • Table 'prohibition' now contain field 'base_contract_code'.

    • Table 'dealer' now contain fields 'coeff_im', 'short_option_minimum_charge_ratio', 'ics_margin_type'.

    • Table 'investor' now contain fields 'is_blank', 'short_option_minimum_charge_ratio', 'ics_margin_type', 'coeff_im', 'no_fut_discount', 'num_clr_2delivery', 'exp_weight'.

  • Stream 'FORTS_OPTINFO_REPL':

    • Table 'opt_sess_contents' now contain fields 'base_contract_code', 'settlement_price_open', 'base_im_covered_sell', 'base_im_sell', 'last_trade_date', 'base_im_buy', 'settlement_price'.

    • Table 'opt_vcb' now contain field 'base_contract_code'.

    • Table 'option_series' now contain field 'signs'.

  • Stream 'FORTS_CLR_REPL':

    • Field 'asset_type' added into tables 'money_clearing', 'money_clearing_sa'.

    • Table 'money_clearing' now contain field 'asset_type'.

    • Table 'fut_pos' now contain field 'account_type'.

    • Table 'opt_pos' now contain field 'account_type'.

    • Table 'pledge_details': deleted field 'com_ensure'.

  • Stream 'FORTS_VM_REPL':

    • Feld 'vm_real' deleted from tables 'fut_vm', 'opt_vm', 'fut_vm_sa', 'opt_vm_sa'

  • Stream 'FORTS_INFO_REPL':

    • Added table 'multileg_dictionary'.

    • Table 'base_contracts_params': deleted field 'is_usd'. Added fields 'base_contract_code', 'window_size'.

    • Table 'futures_params' now contain fields 'base_contract_code', 'settlement_price', 'risk_range_center'.

    • Deleted table 'virtual_futures_params'.

    • Table 'investor' now contain fields 'is_blank', 'coeff_im', 'short_option_minimum_charge_ratio', 'ics_margin_type'.

    • Table 'investor': field 'n_clr_2delivery' renamed to 'num_clr_2delivery'.

    • Table 'dealer' now contain fields 'coeff_im', 'short_option_minimum_charge_ratio', 'ics_margin_type'.

  • Changes applied to command scheme repository:

    • The fields 'du', 'hedge' removed in commands 'FutAddOrder', 'OptAddOrder'.

    • The field 'limit_pledge' removed in command 'FutChangeBFMoney'.

    • The field 'amount_pledge' removed in command 'FutExchangeBFMoney'.

    • The fields ‘price’, ‘hedge’, ‘trust’, ‘trade_mode’ removed in command ‘FutAddMultiLegOrder'. The field 'rate_price' renamed to 'swap_price'.

    • The field 'code_vcb' renamed to 'base_contract_code' in commands 'FutDelUserOrders', 'OptDelUserOrders', 'FutChangeClientProhibit', 'OptChangeClientProhibit'.

    • Added commands 'ChangeClientMoney', 'ChangeBFMoney', 'ExchangeBFMoney', 'ChangeBFLimit', 'ChangeBFParameters', 'ChangeClientParametersNextSession'.

    • The command 'FutChangeBFClientDefaultParameters' renamed to 'ChangeBFClientDefaultParameters'.

    • Command 'OptChangeRiskParameters' now have field 'short_option_minimum_charge_ratio' - Individual coefficient of SOMC scenario weight.

  • Added new error codes: 77, 4225.

14.01.2019Changes applied:
  • Field 'base_contract_id' added into table 'fut_vcb' of stream 'FORTS_FUTINFO_REPL'.

  • Field 'base_contract_id' added into table 'opt_vcb' of stream 'FORTS_OPTINFO_REPL'.

05.12.2018Changes applied:
  • Added sections '2.7. Separate entities of Clearing Member and Trading Member', '3.3.8. Changing user password for the Trading System'.

  • Commands 'FutAddOrder', 'FutAddMultiLegOrder', 'FutDelOrder', 'FutMoveOrder', 'OptAddOrder', 'OptDelOrder', 'OptMoveOrder' now have field ncc_request - flag 'Request to NCC'. The commands now have new IDs.

  • Added commands 'DelOrdersByBFLimit', 'ChangePassword'.

  • Command 'OptRecalcCS': field 'isin_id' replaced with 'option_series_id', the command now has a new ID.

  • Added new error codes: 682, 4168, 4169, 4170, 4171, 4172, 4173, 4221, 4222, 4223, 4224, 4230.

  • Stream 'FORTS_OPTINFO_REPL':

    • added table 'option_series'.

    • table 'opt_sess_contents': deleted fields 'is_limited', 'limit_up', 'limit_down', 'exch_pay', added field 'option_series_id'.

  • Stream 'FORTS_FUTINFO_REPL':

    • deleted tables 'diler', 'investr'.

    • table 'dealer' now has fields 'firm_id', 'tm_name'.

    • table 'fut_sess_contents': deleted fields 'is_limited', 'exch_pay'. Added fields 'd_exp_start', 'd_exp_end'.

    • table 'fut_instruments': deleted fields 'is_limited', 'volat_min', 'volat_max', 'is_limit_opt', 'limit_up_opt', 'limit_down_opt', 'adm_lim', 'adm_lim_offmoney', 'apply_adm_limit'.

  • Stream 'FORTS_MM_REPL':

    • table 'cs_mm_rule': field 'isin_id' renamed to 'option_series_id'.

  • Stream 'FORTS_MISCINFO_REPL':

    • Table 'volat_coeff': field 'isin_id' renamed to 'option_series_id'.

  • Stream 'FORTS_INFO_REPL':

    • table 'option_series_params': field 'isin' renamed to 'small_name', field 'exp_date' renamed to 'expiration_date'. Added fields 'option_series_id', 'underlying_id'.

    • table 'base_contracts_params': deleted field 'currency_volat'.

26.09.2018New error code added (4208).
25.09.2018Added section '3.3.7. SMA Login (Sponsored Market Access)'.
03.08.2018Field 'aspref' deleted from table 'orders' of stream 'FORTS_ORDBOOK_REPL'.
01.08.2018Tables 'sma_master', 'sma_pre_trade_check' deleted from stream FORTS_INFO_REP
31.07.2018Stream 'FORTS_INFO_REPL' now contains table 'option_series_params'.
30.07.2018Field 'coeff_out' deleted from table 'opt_vcb' of stream 'FORTS_OPTINFO_REPL'.
27.07.2018Changes applied:
  • Changed descriptions for fields 'is_cupon' of tables 'fut_bond_nkd', 'fut_bond_nominal'

  • Renamed table 'fut_bond_nkd'.

26.07.2018New error code added (4220).
26.07.2018Changes applied:
  • Stream 'FORTS_CLR_REPL':

    • fields 'pos_beg', 'pos_end' deleted from tables 'fut_pos', 'opt_pos', 'fut_pos_sa', 'opt_pos_sa'

    • fields 'amount_beg', 'pay, amount', 'amount_beg_money', 'pay_money', 'amount_money' deleted from table 'pledge_details'.

  • Stream FORTS_DEALS_REPL:

    • fields 'pos', 'amount' deleted from table 'deal'.

    • field 'amount' deleted from table 'multileg_deal'.

  • Stream 'FORTS_FUTCOMMON_REPL': fields 'amount_buy', 'orders_buy_amount', 'amount_sell', 'orders_sell_amount', 'amount', 'contr_count', 'pos' deleted from table 'common'.

  • Stream FORTS_OPTCOMMON_REPL: fields 'amount_buy', 'orders_buy_amount', 'amount_sell', 'orders_sell_amount', 'amount', 'contr_count', 'pos' deleted from table 'common'.

  • Stream 'FORTS_MM_REPL': fields 'amount_sells', 'amount_buys', 'mm_amount' deleted from tables 'fut_MM_info', 'opt_MM_info'.

  • Stream 'FORTS_OPTINFO_REPL':

    • field 'amount' deleted from table 'opt_rejected_orders'

    • fields 'amount', 'amount_apply' deleted from table 'opt_exp_orders'.

  • Stream 'FORTS_ORDLOG_REPL': fields 'amount', 'amount_rest', 'status' deleted from tables 'orders_log', 'multileg_orders_log'.

  • Stream 'FORTS_POS_REPL': fields 'pos', 'buys_qty', 'sells_qty', 'open_qty' deleted from tables 'position', 'position_sa'.

  • Stream 'FORTS_FUTINFO_REPL':

    • field 'amount' deleted from table 'fut_rejected_orders'.

    • added tables 'user', 'sma_master', 'sma_pre_trade_check'

    • deleted table 'fut_sess_settl'

    • table 'fut_margin_type' now contains field 'type'

    • changed descriptions on fields 'UCP_type', 'prohibit_coeff'.

  • Stream 'FORTS_INFO_REPL':

    • deleted table 'opt_sess_settl'

    • field 'min_vol' deleted from table 'opt_vcb'.

  • Stream 'FORTS_FUTTRADE_REPL':

    • tables 'orders_log', 'multileg_orders_log' now contain field 'aspref'

    • fields 'amount', 'amount_rest', 'status' deleted from tables 'orders_log', 'multileg_orders_log'.

    • fields 'pos', 'amount', 'status_buy', 'status_sell' deleted from table 'user_deal'.

    • fields 'amount', 'status_buy', 'status_sell' deleted from table 'user_multileg_deal'.

  • Stream 'FORTS_OPTTRADE_REPL':

    • table 'orders_log' now contain field 'aspref'

    • fields 'amount', 'amount_rest', 'status' deleted from table 'orders_log'

    • fields 'pos', 'amount', 'status_buy', 'status_sell' deleted from table 'user_deal'.

  • Stream 'FORTS_ORDBOOK_REPL':

    • table 'orders' now contain field 'aspref'

    • fields 'status', 'amount', 'amount_rest', 'init_amount' deleted from table 'orders'.

  • Streams 'FORTS_FUTORDERBOOK_REPL'/'FORTS_OPTORDERBOOK_REPL':

    • table 'orders' now contain field 'aspref'

    • fields s'tatus', 'amount', 'amount_rest', 'init_amount' deleted from table 'orders'.

  • Stream 'RTS_INDEX_REPL': table 'rts_index' now contains fields 'value_highprec', 'prev_close_value_highprec', 'open_value_highprec', 'max_value_highprec', 'min_value_highprec'.

18.07.2018Add commands 'SetSmaPreTradeCheck, 'DelSmaPreTradeCheck', 'UserKillSwitch'.
25.06.2018New error codes added (76, 4167, 4200 - 4207).
21.06.2018Added section '3.3.6. Replication stream sets for different login subtypes'.
19.06.2018Removed unused fields ’limit_pledge’, ‘coeff_liquidity’ of command FutChangeClientMoney.
21.05.2018Field '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.2018Table 'part_sa' of stream 'FORTS_PART_REPL' now contains a new field 'money_old'.
22.03.2018Changes applied:
  • Field 'signs' added into table 'dealer' of stream 'FORTS_FUTINFO_REPL'.

  • Fields 'strike_step', 'exp_clearings_bf' and 'exp_clearings_cc' added into table 'virtual_futures_params' of stream 'FORTS_INFO_REPL'.

  • Field 'lot' added into table 'futures_params' of stream 'FORTS_INFO_REPL'.

  • Fields 'has_options', 'msp_type' and 'currency_id' added into table 'base_contracts_params' of stream 'FORTS_INFO_REPL'.

  • Tables 'currency_params' and 'common_params' added into stream 'FORTS_INFO_REPL'.

28.02.2018Table 'part_forecast' deleted from stream 'FORTS_FORECASTIM_REPL'.
26.02.2018Changes applied:
  • Fields 'client_code', 'exch_pay', 'exch_pay_scalped', 'clear_pay', 'clear_pay_scalped', 'exch_pay_spot', 'exch_pay_spot_repo', 'sell_fee' and 'buy_fee' deleted from table 'fut_vcb' of stream 'FORTS_FUTINFO_REPL'.

  • Fields 'client_code', 'exch_pay', 'exch_pay_scalped', 'clear_pay', 'clear_pay_scalped', 'is_spec', 'spec_spread', 'sell_fee' and 'buy_fee' deleted from table 'opt_vcb' of stream 'FORTS_OPTINFO_REPL'.

21.02.2018Added new error codes: 4148, 4149.
20.02.2018Changes applied:
  • Added description of command 'FutChangeBFLimit'.

  • Fields 'money_blocked' and 'vm_reserve' added into table 'part_sa' of stream 'FORTS_PART_REPL'.

31.01.2018Changes applied:
  • Field 'ext_reserve' deleted from table 'money_clearing' of stream 'FORTS_CLR_REPL' .

  • Field 'coeff' deleted from tables 'fut_sess_contents' and 'fut_instruments' of stream 'FORTS_FUTINFO_REPL'.

  • Table 'fut_bond_registry' of stream 'FORTS_FUTINFO_REPL': field 'bond_type' type changed to i4.

  • Tables 'deal' and 'multileg_deal deleted from stream 'FORTS_FUTTRADE_REPL.

  • Table 'deal' deleted from stream 'FORTS_OPTTRADE_REPL'.

  • Field 'points_num' deleted from table 'base_contracts_params' of stream 'FORTS_INFO_REPL'. Fields 'spot_price', 'mr1', 'mr2', 'mr3', 'lk1', 'lk2', 'risk_points_n' added into table 'base_contracts_params' of stream 'FORTS_INFO_REPL'.

  • Fields 'limit' and 'spot_signs' deleted from table 'futures_params' of stream 'FORTS_INFO_REPL'. Fields 'interest_rate_risk_up', 'interest_rate_risk_down', 'time_to_expiration', 'normalized_spot' added into table 'futures_params' of stream 'FORTS_INFO_REPL'.

  • Fields 'is_net_positive', 'volat_range', 't_squared' and 'max_addrisk' deleted from table 'virtual_futures_params' of stream 'FORTS_INFO_REPL'. Fields 'exp_clearings_sa', 'volatility_risk', 'volatility_risk_mismatch', 'time_to_expiration' added into table 'virtual_futures_params' of stream 'FORTS_INFO_REPL'.

  • Field 'server_time' added into table 'sys_events' of stream 'FORTS_INFO_REPL'.

  • Field 'isin_is_spec' deleted from table 'common' of stream 'FORTS_OPTCOMMON_REPL'.

  • Fields 'pledge_free', 'pledge_blocked', 'coeff_liquidity', 'pledge_old', 'pledge_amount' deleted from table 'part' of stream 'FORTS_PART_REPL'.

  • Fields 'pledge_amount' and 'liquidity_ratio' deleted from table 'part_sa' of stream 'FORTS_PART_REPL' . Fields 'vm_intercl' and 'fee' added into table 'part_sa' of stream 'FORTS_PART_REPL'.

  • Added description of stream 'FORTS_FEERATE_REPL - Precise Exchange fee rates'.

  • Added description of commands 'FutChangeBFParameters', 'FutChangeClientParameters' and 'FutChangeBFClientDefaultParameters'.

  • Fields 'exp_weight', 'num_clr_2delivery', 'margin_type', 'calendar_spread_margin_type', 'num_clr_2delivery_client_default', 'exp_weight_client_default', 'go_ratio', 'check_limit_on_withdrawal', 'limit_tied_money', 'limits_set', 'no_fut_discount', 'no_fut_discount_client_default' added into table 'diler' of stream 'FORTS_FUTINFO_REPL'.

  • Field 'calendar_spread_margin_type' added into table 'investr' of stream 'FORTS_FUTINFO_REPL'.

  • Tables 'dealer' and 'investor' added into stream 'FORTS_FUTINFO_REPL'.

  • Tables 'dealer' and 'investor' added into stream 'FORTS_INFO_REPL'.

26.12.2017Changes applied:
  • Table 'position' of stream 'FORTS_POS_REPL' now contains a new field 'account_type'

  • Stream 'FORTS_POS_REPL' now contains a new table 'position_sa'.

21.12.2017Added new error codes (4160 - 4166).
16.11.2017Description change for parameter 'code_vcb' of method 'FutDelUserOrders'.
25.10.2017Changes applied:
  • Table 'delivery_report' removed from stream FORTS_FUTINFO_REPL

  • Table 'fut_rejected_orders' of stream 'FORTS_FUTINFO_REPL' now contains a new field 'xamount'

  • Tables 'opt_rejected_orders' and 'opt_exp_orders' of stream 'FORTS_OPTINFO_REPL' now contain a new field 'xamount'

  • Table 'opt_exp_orders' of stream 'FORTS_OPTINFO_REPL' now contains a new field 'xamount_apply'.

24.10.2017Changes applied:
  • Table 'fut_MM_info' of stream 'FORTS_MM_REPL' now contain fields 'xamount_sells', 'xamount_buys', 'xmm_amount'

  • Table 'opt_MM_info' of stream 'FORTS_MM_REPL' now contain fields 'xamount_sells', 'xamount_buys', 'xmm_amount'.

28.08.2017Changed message type for messages 'OptChangeExpiration', 'FutTransferClientPosition', 'OptTransferClientPosition'. Also, changed type of the field 'amount' in these messages.
23.06.2017Deletion of stream RTS_INDEXLOG_REPL.
02.06.2017Changes applied:
  • Table 'multileg_dict' of stream 'FORTS_FUTINFO_REPL' now contain field 'leg_order_no'.

  • Table 'fut_margin_type' of stream 'FORTS_FUTINFO_REPL' now contain fields 'UCP_type', 'prohibit_coeff', 'prohibit_type'.

18.05.2017Changes applied:
  • Tables 'fut_pos', 'opt_pos', 'fut_pos_sa' and 'opt_pos_sa' of stream 'FORTS_CLR_REPL' now contain fields 'xpos_beg' and 'xpos_end'.

  • Table 'pledge_details' of stream 'FORTS_CLR_REPL' now contains fields 'xamount_beg', 'xpay', 'xamount', 'xamount_beg_money', 'xpay_money', 'xamount_money'.

15.05.2017Changes applied:
  • Tables 'common' of streams 'FORTS_FUTCOMMON_REPL' and 'FORTS_OPTCOMMON_REPL' now contain fields 'xamount_buy', 'xorders_buy_amount', 'xamount_sel'l, 'xorders_sell_amount', 'xamount', 'xcontr_count', 'xpos'.

  • Tables 'orders' of streams 'FORTS_ORDBOOK_REPL', 'FORTS_FUTORDERBOOK_REPL' and 'FORTS_OPTORDERBOOK_REPL' now contain fields 'xamount', 'xamount_rest', 'xinit_amount'.

  • Table 'position' of stream 'FORTS_POS_REPL' now contains fields 'xpos', 'xbuys_qty', 'xsells_qty', 'xopen_qty'.

05.05.2017

Changes applied:

  • Table 'deal' of stream 'FORTS_DEALS_REPL' now contains fields 'xpos' and 'xamount'.

  • Table 'multileg_deal' of stream 'FORTS_DEALS_REPL' now contains field 'xamount'.

  • Table 'orders_log' of stream 'FORTS_FUTTRADE_REPL' now contains fields 'xamount' and 'xamount_rest'.

  • Table 'multileg_orders_log' of stream 'FORTS_FUTTRADE_REPL' now contains fields 'xamount' and 'xamount_rest'.

  • Table 'deal' of stream 'FORTS_FUTTRADE_REPL' now contains fields 'xpos' and 'xamount'.

  • Table 'multileg_deal' of stream 'FORTS_FUTTRADE_REPL' now contains field 'xamount'.

  • Table 'user_deal' of stream 'FORTS_FUTTRADE_REPL' now contains fields 'xpos' and 'xamount'.

  • Table 'user_multileg_deal' of stream 'FORTS_FUTTRADE_REPL' now contains field 'xamount'.

  • Table 'orders_log' of stream 'FORTS_OPTTRADE_REPL' now contains fields 'xamount' and 'xamount_rest'.

  • Table 'deal' of stream 'FORTS_OPTTRADE_REPL' now contains fields 'xpos' and 'xamount'.

  • Table 'user_deal' of stream 'FORTS_OPTTRADE_REPL' now contains fields 'xpos' and 'xamount'.

  • Table 'orders_log' of stream 'FORTS_ORDLOG_REPL' now contains fields 'xamount' and 'xamount_rest'.

  • Table 'multileg_orders_log' of stream 'FORTS_ORDLOG_REPL' now contains fields 'xamount' and 'xamount_rest'.

24.03.2017

Changes applied:

  • Fields exch_pay, exch_pay_scalped, clear_pay, clear_pay_scalped, sell_fee, buy_fee, exch_pay_spot, exch_pay_spot_repo, client_code of table fut_vcb of stream FORTS_FUTIINFO_REPL contain default values (nulls, empty strings).

  • Fields exch_pay, exch_pay_scalped, clear_pay, clear_pay_scalped, sell_fee, buy_fee, is_spec, spec_spread, client_code of table opt_vcb of stream FORTS_OPTINFO_REPL contain default values (nulls, empty strings).

28.12.2016

Changes applied:

  • Added section 'Stream FORTS_FORECASTIM_REPL - Risk forecast after limits extension'.

  • Field 'exp_weight' deleted from table 'part' of stream 'FORTS_PART_REPL'.

21.12.2016In 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.2016Changed list of synchroevents in table sys_events of streams FORTS_PART_REPL, FORTS_CLR_REPL, FORTS_INFO_REPL.
18.05.2016

Changes applied:

  • Deleted description of methods for working with Spots:

    • 'FutChangeBrokerVcb - Changing BF parameters on Underlying';

    • 'FutChangeClientVcb - Changing client parameters on Underlying';

    • 'FutChangeMoney - Changing limit for bying spots on BF'.

  • Table 'fut_instruments' of stream 'FORTS_FUTINFO_REPL ' now contains field 'exec_name' ( Flag of option maturity).

  • Added description of method 'OptChangeRiskParameters - Risk-parameter management for options'.

  • Field 'num_clr_2delivery' deleted from message 'FutChangeClientMoney - Changing client limits'. If filled in, this field will be ignored in all previous versions of the message.

  • Added description of method 'FutTransferRisk - Risk balancing'.

  • Added return codes: 75, 331, 339, 383, 4127, 4138, 4139, 4150-4155, 9999, 10000, 10001, 10004-10006.

  • Stream 'FORTS_FUTINFO_REPL' now contains tables 'fut_settlement_account' and 'fut_margin_type'.

  • Table 'part_sa' added into stream 'FORTS_PART_REPL'.

  • Tables 'money_clearing_sa', 'fut_pos_sa', 'opt_pos_sa' are added into stream 'FORTS_CLR_REPL'.

  • Tables 'fut_vm_sa' and 'opt_vm_sa' added into stream 'FORTS_VM_REPL'.

  • Table 'part' of stream 'FORTS_PART_REPL' now contains fields 'num_clr_2delivery' and 'exp_weight'.

  • Field 'cal_exp_extra_risk' deleted from table 'part' of stream 'FORTS_PART_REPL'.

  • Table 'virtual_futures_params' of field 'FORTS_INFO_REPL' now contains fields 'exp_clearings_bf' and 'exp_clearings_cc'.

  • Fields 'allow_use_extra_exp_risk' and 'calc_extra_exp_risk' deleted from table 'virtual_futures_params' of stream 'FORTS_INFO_REPL'.

14.10.2015Added description of 'CODHeartbeat' method.
14.10.2015Table 'fut_sess_contents' now contains 2 new fields: 'pctyield_coeff' and 'pctyield_total'.
12.08.2015Added 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:

  • Transfer futures position between BF

  • Transfer option position between BF

14.01.2014

Added new fields:

  • 'fulfil_min' - Minimum percentage of the liabilities for the trading session

    'fulfil_partial' - Percentage of partial fulfillment of the liabilities of the trading session

    'fulfil_total' - Percentage of fulfillment of liabilities of the trading session

    'is_fulfil_min' - Minimum sign of the liabilities for the trading session

    'is_fulfil_partial' - Sign of partial fulfillment of the obligations of the trading

    'is_fulfil_total' - Sign of fulfillment of obligations of the trading session

into tables 'fut_MM_info', 'opt_MM_info' of stream 'FORTS_MM_REPL'.

31.05.2013

New field added:

  • 'rate_id' - Payment currency identifier

into table 'clr_rate' of field 'FORTS_CLR_REPL'.

18.04.2013

Added anonymous stream 'orderbook':

  • 'FORTS_ORDBOOK_REPL'

Added field:

  • 'ext_reserve' - Extra reserve

into table 'money_clearing' of stream 'FORTS_CLR_REPL'

Deleted stream 'FORTS_CLMONEY_REPL'.

12.04.2013

New field added:

  • 'exch_pay' - Exchange fee per 1 contract in Russian rubles.

into table 'fut_sess_contents' of stream 'FORTS_FUTINFO_REPL'.

10.04.2013

New field added:

  • 'exch_pay' - Exchange fee per 1 contract in Russian rubles.

into table 'opt_sess_contents' of stream 'FORTS_OPTINFO_REPL'.

26.03.2013

New field added:

  • 'rate_id' - Payment currency identifier

into tables 'fut_vcb' and 'opt_vcb' of streams 'FORTS_FUTINFO_REPL' and 'FORTS_OPTINFO_REPL'

Replication stream added:

  • 'MOEX_RATES_REPL' - Exchange rates in online mode.

Added new table:

  • 'rates' - Currency exchange rates reference book.

into stream 'FORTS_FUTINFO_REPL'.

27.11.2012Changed description of table 'user_deal'.
01.11.2012

Added descriptions of two events for table 'sys_events'.

30.10.2012Some changes applied:
  • Section 'FutChangeMoney - Changing limit for bying spots on BF' now contains extended description of parameter 'limit_spot_buy'.

  • Sections 'Method FutMoveOrder - Modify order' and 'Method OptMoveOrder - Modify order' now contain extended description of the command 'MoveOrder' logic.

22.10.2012Some changes applied:
  • Modified sections: 'Users. How a user is linked to a trading participant', 'SPECTRA Plaza-2 gateway. Components, installation and setup', 'Recommendations for third-party companies on including the Moscow Exchange runtimes into user application when distributing the user software', 'Recovery and late logon'.

  • Deleted section 'Technical center interface'.

10.02.12Some changes applied:
  • Section 'Gate usage specifics' now contains subsection 'Commands'.

  • Added section 'Pausing trading session for extending limits of trading prices fluctuations'.

  • Corrected an error in futures price calculation formula.

  • Updated the Gate installator description.

09.02.2012

New field added:

  • 'login_from' - Login of a user who added the order

into tables:

  • 'fut_rejected_orders' - Orders rejected during clearing session

  • 'opt_rejected_orders' - Orders rejected during clearing session

of streams:

  • 'FORTS_FUTINFO_REPL' - Futures: Reference and session information

  • 'FORTS_OPTINFO_REPL' - Options: Reference and session information

24.01.2012

Table 'orders' of streams:

  • 'FORTS_FUTORDERBOOK_REPL' - Futures: orderbook snapshot

  • 'FORTS_OPTORDERBOOK_REPL' - Options: orderbook snapshot

now contains fields:

  • 'init_moment' - Time of the order adding

  • 'init_amount' - Initial amount in the order

23.01.2012

Event table 'sys_events' added into streams:

  • 'FORTS_CLMONEY_REPL' - Money in clearing session

  • 'FORTS_CLR_REPL' - Clearing data

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:

  • 'FORTS_ORDLOG_REPL' - the stream transmits anonymized orders events.

02.11.2011

New fields added:

  • 'comment' - Trader's comment

  • 'ext_id' - External number

into tables:

  • 'fut_rejected_orders' - Orders rejected during clearing session

  • 'opt_rejected_orders' - Orders rejected during clearing session

25.11.2011Added section 'Usage of test examples'.
7.11.2011Completed sections 'Introduction' and 'Trading gate description'. Added section 'System SPECTRA overview'.
20.10.2011

Fields added:

  • 'theor_price_limit' - Theoretical option price with limits

  • 'vm_real' - The accumulated variation margin on futures trades calculated based on the current market quote.

Event table 'sys_events' added into streams:

  • 'FORTS_FUTTRADE_REPL' - Futures: orders and trades

  • 'FORTS_OPTTRADE_REPL' - Options: orders and trades

  • 'FORTS_POS_REPL' - Information on positions

  • 'FORTS_PART_REPL' - information on funds and limits

  • 'FORTS_FUTINFO_REPL' - Futures: reference and session information

  • 'FORTS_OPTINFO_REPL' - Options: reference and session information

  • 'FORTS_INFO_REPL' - Additional reference information

4.10.2011

Added replication streams:

  • 'FORTS_CLR_REPL' - Various clearing information.

  • 'FORTS_MM_REPL' - Information on MM's liabilities

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:

  • 'status' of table 'diler' of stream 'FORTS_FUTINFO_REPL' - CF and BF accounts information

  • 'status' of table 'investr' of stream 'FORTS_FUTINFO_REPL' - client accounts information

  • 'vm_order_reserve' of stream 'FORTS_PART_REPL' - Amount reserved for negative variation margin on orders

  • 'waprice' of stream 'FORTS_POS_REPL' - weighted average price

Changes applied to commands structure:

  • NOTE: Changes applied to the format of the following commands: 'FutAddOrder', 'OptAddOrder' and 'FutAddMultilegOrder' - now each of the commands contains parameter 'dont_check_money'. Commands' identifiers have also changed. All prevoius identifiers are still valid with commands in previous format..

  • Added command 'FutExchangeBFMoney' which allows to transfer funds between the accounts of a BF.

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:

  • The new default value of parameter 'ext_id' of command 'FutDelUserOrders' is now 0.

  • The new default value of parameters 'comment', 'hedge', 'broker_to', 'ext_id', 'trust', 'date_exp' of command 'FutAddMultiLegOrder' is now 0 or empty string, depending on the message type.

  • The new default value of parameters 'price1' and 'price2' of command 'OptMoveOrder' is now 0.

  • The new default value of parameter 'no_fut_discount' of command 'FutChangeClientMoney' is now 0.

  • The new default value of parameter 'limit_spot' of command 'FutChangeBrokerVcb' is now -1.

  • The return messages for commands 'FutChangeClientMoney', 'FutChangeBFMoney', 'FutChangeClientVcb' and 'OptChangeExpiration' now have their field 'Message' changed to 'message'.

.

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

  • 0x800 - flag of an RTS Money instrument

  • 0x1000 - flag of basic price for multileg instruments (0 - quoted in swap-price, 1 - quoted in rate).

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:

  • 'fut_sess_settl' of stream 'FORTS_FUTINFO_REPL' containing settlement prices values during the last clearing session.
  • 'opt_sess_settl' of stream 'FORTS_OPTINFO_REPL' containing volatility and option theoretical price values during the clearing session.
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:

  • tables 'base_contracts_params', 'futures_params', 'virtual_futures_params', 'options_params'

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:

  • aggregated orderbook volume d16.5 -> i8
  • order direction i4 -> i1
  • flags of instruments (signs) i1 -> i4

Table 'money_clearing' is relocated from stream 'FORTS_FUTINFO_REPL' into stream 'FORTS_CLMONEY_REPL'.

Objects renamed:

  • table 'repo_orders_log' -> 'multileg_orders_log'
  • table 'repo_deal' -> 'multileg_deal'
  • command 'FutAddRepo' -> 'FutAddMultiLegOrder'

Added:

  • table 'multileg_dict' – multileg instruments dictionary
  • fields 'price_dir', 'multileg_type', 'legs_qty', tables 'fut_sess_contents'
  • fields containing IDs and trade prices are added into tables 'orders_log' of streams 'FORTS_FUTTRADE_REPL' and 'FORTS_OPTTRADE_REPL'
  • fields 'fee_sell', 'fee_buy' of table 'deal' of stream 'FORTS_OPTTRADE_REPL'
  • streams 'FORTS_FUTORDERBOOK_REPL' and 'FORTS_OPTORDERBOOK_REPL', transmitting current orderbooks data
  • table 'broker_params' of stream 'FORTS_INFO_REPL'
  • table 'fut_instruments' of stream 'FORTS_FUTINFO_REPL'
  • tables 'usd_online' of stream 'FORTS_FUTINFO_REPL'

Deleted:

  • field 'state' of table 'opt_sess_contents'

16.03.2010

Changed description of command 'FutAddRepo': instead of parameter 'swap_price', parameter 'repo_rate' is now used.

24.02.2010

Added:

  • description of tables 'repo_orders_log', 'repo_deals'
  • description of orders and repo trades statuses
  • descriptions of new statuses for orders and trades
  • description of command 'FutAddRepo'
  • field 'last_deal_id' of table 'position' of stream 'FORTS_POS_REPL'

18.01.2010

  • Added descriptions of commands: 'FutChangeBrokerVcb', 'FutChangeClientProhibit', 'FutChangeMoney', 'OptChangeClientProhibit'
  • Added field 'limits_set' of table 'part' of stream 'FORTS_PART_REPL'
  • Corrected some mistakes in commands descriptions

15.01.2010

  • Changed ID types of orders and trades (i4 -> i8)
  • Changed status types of orders and trades (i2 -> i4)
  • Corrected some mistakes in commands descriptions

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

Introduction

Document purpose

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.

Target audience

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.

Abbreviations

The following abbreviations may be used in the Document:

AbbreviationDescription
ASTSTrading and clearing system of the FX Market of the Moscow Exchange
BFBrokerage Firm (trading member)
CFClearing Firm (clearing member)
CMClearing Member
CODService 'Cancel On Disconnect'
EDMElectronic Document Management
MMMarket Maker
NCCNational Clearing Centre
SMAService 'Sponsored Market Access'
TMTrading Member
TSTrading System
VMVariation Margin

SPECTRA system overview

Trading Membership

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

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.

Brokerage firms

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.

Clients

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.

System code pattern

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.

Example 2. 

Q1DU000 — indicates state of account of the DU sub-broker of the Q1 clearing firm


Disclosure of data on participants

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.

Users. How a user is linked to a trading participant

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.

Instruments

The SPECTRA instruments are structured hierarchically. Below you will find descriptions of the SPECTRA instruments starting from the root level.

Underlying assets

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

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.

Daily futures contract with automatic prolongation

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 asset of daily futures is the corresponding foreign currencies to the Russian ruble exchange rates and indices calculated by Moscow Exchang.

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 stock index, the evening clearing variation margin is calculated taking into account the dividend amendment (dividend index value), which will compensate holders of a long position for the fall in the index when paying dividends, while, on the contrary, the value of the index will be charged from holders of a short position, since they win from the fall of the index. The adjustment 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

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

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

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

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

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

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

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

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

Options data are stored in the following tables:

Multi-leg instruments

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

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

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

Figure 1. Multileg instruments

Multileg instruments

Identification of instruments

The SPECTRA system has four fields to identify each instrument:

  1. 'isin_id' field, which contains the unique numeral code for each instrument.

  2. 'isin' field, which contains the instrument's symbol code.

  3. 'short_isin' field, which contains short symbol code for using in order books etc.

  4. '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.

Trading operations

Orders — general information

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.

Negotiated orders

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.

Negotiated mode with matching by an unique code

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.

Trades

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-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 typeThe flag in the client account - the author of the passive orderScenarios
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.

Specifics of trading multi-leg instruments

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.

Iceberg orders

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.

Iceberg orders in the system information streams

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

  1. 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.

  2. 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_idpublic_ amountpublic_ amount_ restpublic_ actionpricemomentdirclient_ codeprivate_ order_idprivate_ amountprivate_ amount_ restprivate_ actioncomment
10110010013122019-01-11 11:55:581OD01123101100010001Add Iceberg
1021113122019-01-11 14:56:581PJ99888102111Add standard Order
10325025013102019-01-11 16:58:582FS010201032502501Add standard Order
101100023122019-01-11 16:58:581OD011231011009002Match Iceberg
10310015023102019-01-11 16:58:582FS010201031001502Match standard Order
1021023122019-01-11 16:58:581PJ99888102102Match standard Order
103114923102019-01-11 16:58:582FS0102010311492Match standard Order
10410010013122019-01-11 16:58:581OD011231011009003Pop-up Iceberg
104100023122019-01-11 16:58:581OD011231011008002Match Iceberg
1031004923102019-01-11 16:58:582FS01020103100492Match standard Order
10510010013122019-01-11 16:58:581OD011231011008003Pop-up Iceberg
105495123122019-01-11 16:58:581OD01123101497512Match Iceberg
10349023102019-01-11 16:58:582FS010201034902Match standard Order
10551003122019-01-11 17:00:581OD0112310175100Cancel Iceberg

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_idpublic_ amountpublic_ amount_ restpublic_ actionid_ordxamountxamount_ restactionprivate_ order_idprivate_ amountprivate_ amount_ restprivate_ actioncomment
1011001001101100010001101100010001Add Iceberg
102111102111102111Add Order
103250250110325025011032502501Add Order
1011000210110090021011009002Match Iceberg
103100150210310015021031001502Match Order
102102102102102102Match Order
103114921031149210311492Match Order
104100100110110090031011009003Pop-up Iceberg
1041000210110080021011008002Match Iceberg
103100492103100492103100492Match Order
105100100110110080031011008003Pop-up Iceberg
10549512101497512101497512Match Iceberg
103490210349021034902Match Order
10551001017510010175100Cancel Iceberg

Anonymous streams of orders and trades contain only public fields, in which there is always the visible part of icebergs only.

Iceberg order operations

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'.

Change of order ID during iceberg orders operations

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:

Operationpublic_order_idpublic_actionprivate_order_idprivate_actionid_ord1
Add10011001 
Matching into a trade10021002 
New part pops up10511003 
Replace in the evening clearing1106111061100
Move1106011060100
1200112001 

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

Delivery of assets and exercise of options

Deliveries on futures

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.

Settlement of futures contracts of derivatives market for stock market (T+2 mode)

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.

Option exercise

At present, the SPECTRA system supports American futures options and European options on spot assets (shares, commodities, currencies, etc.).

Exercise of futures options

When exercising, the option position turns into a futures position with the price equal to strike of the exercising option contract. The exercise is processed during clearing session, and, technically, consists of closing of the option position and opening a futures position. Both of the positions are marked with a special flag in the fields '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.

Exercise of options on spot assets

For options on spot assets that are European and settlement, 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 options on spot assets is not accepted by the system.

Option risk calculation before exercise

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 daily futures contracts with auto-prolongation (‘perpetual’ futures)

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.

Trade Settlement TAS

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

Flags applied to orders and trades:

Flag nameBit maskDescription
Market orders
Auction0x1Day order.
Opposite0x2Immediate-or-Cancel order (IOC).
FOK0x80000Fill-or-Kill order.
BOC0x1000000000000000Book-or-Cancel order.
Clearing trades
NonQuote0x4Sign 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.
Exec0x20A 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.
Expiration0x80Instrument, futures, or option expiration.
DUFlow0x800Technical trade of position transfer between trust managing BFs of Clearing Firms.
TASSettlement0x10000Trade Settlement TAS
OptionLapse0x800000Option expiration trade
ClearingTrade0x2000000Off-book clearing trade. Applied to all clearing trades.
FuturesExecution0x40000000Futures exercise trade.
CollateralInstrument0x400000000Collateral instrument trade.
PerpetualFuturesExecutionVoluntary0x10000000000000The technical trade executed as a result of exiting a perpetual futures (based on the submitted requests).
PerpetualFuturesExecutionForced0x400000000000000The technical trade executed as a result of forced exiting a perpetual futures (realization of unsatisfied demand).
PerpetualFuturesExecution0x800000000000000The technical trade with linked instrument executed as a result of exiting a perpetual futures.
Negotiated orders/trades
TransferClientPosition0x8Position transfer between BFs.
Address0x4000000Negotiated order, negotiated trade, indicative trade (RFS), or an order resulting from matched indicative quotes.
NegotiatedMatchByRef0x80000000Negotiated order or trade matched by reference.
TransferSource0x200000000Donor BF side in position transfer between BFs.
Multi-leg orders/trades
REPOBack0x4000Far leg transaction.
Strategy0x8000000Multi-leg order/trade. Applied to all multi-leg transactions.
Other
DontCheckMoney0x10Do not verify collateral for client accounts.
ExternalUseEveningExecution0x100A sign of an order or trade in the evening trading session.
DontCheckLimits0x200Do not verify limits for options.
Charge0x400End 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.
LastRec0x1000Sign of the last entry in the matching transaction.
DueToCrossCancel0x2000Sign of canceling a passive order in a cross-trade.
MoveOperation0x100000Sign of moving the order.
DeleteOperation0x200000Deleting one order.
BulkDeleteOperation0x400000Mass deletion of orders.
OppositeOrderTailDeleteDueToCrossTrade0x20000000Deleting the remainder of the Immediate-or-Cancel order due to a cross-trade.
CODBulkDeleteOperation0x100000000Sign of the operation for deleting the order by the 'Cancel On Disconnect' service.
FineOperation0x1000000000Applied on order cancellation due to an RFS fee.
UKSBulkDeleteOperation0x2000000000Orders are cancelled by UserKillSwitch
NCCRequest0x4000000000Operation resulting from request to NCC.
NCCBulkDeleteOperation0x8000000000Orders are cancelled by DelOrdersByBFLimit
LiqNettingRF0x10000000000Orders and trades formed in the process of liquidation netting
ActiveSide0x20000000000The active side in the trade. The order that led to the trade when added to the order-book.
PassiveSide0x40000000000The passive side in the trade. The order from the order-book involved in the trade.
Synthetic0x200000000000Sign of a synthetic order and the side of the trade corresponding to this synthetic order.
RFSOrder0x400000000000Order from the RFS system.
Iceberg0x800000000000Iceberg order/trade.
OperatorInputSA0x1000000000000A sign of an order or trade formed in SA blocking mode.
DontFineRF0x80000000000000No penalty for settlement transactions.
MorningSession0x100000000000000Sign of trade made during the morning trading session.
SyntheticPassive0x200000000000000Sign of a passive synthetic order.
DuringDiscreteAuction0x4000000000000000Sign 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 exercising and expiration of futures and options

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

Operation typePosition closing tradePosition opening tradeDate and time of trades availability in reports and in the gateway
Exercise of deliverable futures
  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to minimal step price.

  • Technical trade is not a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Expiration, FuturesExecution, ClearingTrade.

No.On the execution day, in the morning.
Exercise of cash-settled futures
  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to the minimal price step.

  • Technical trade is not a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Expiration, FuturesExecution, ClearingTrade.

No.On the execution day, in the evening.
Exercise of option
  • id in gateways and reports is unique and nonzero.

  • Trade price is 0.

  • Technical trade is not a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Exec, ClearingTrade.

  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to 5 places.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Exec, ClearingTrade.

  • At the intermediate clearing session

  • At the evening clearing session

Depending on time of applying the option (the next clearing session after applying).

Expiration of option
  • id in gateways and reports is unique and nonzero.

  • Trade price is 0.

  • Technical trade is not a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Expiration, ClearingTrade, OptionLapse.

No.On the futures execution day, in the evening.
Segregated Brokerage Firm position transfer
  • id in gateways and reports is unique and nonzero.

  • Trade price is 0.

  • Technical trade is not a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Address, TransferClientPosition, ClearingTrade.

  • id in gateways and reports is unique and nonzero.

  • Trade price is 0.

  • Technical trade is not a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Address, TransferClientPosition, TransferSource, ClearingTrade.

During the evening clearing session.
Voluntary exiting a perpetual futures (based on the submitted request)
  • id in gateways and reports is unique and nonzero.

  • The trade price is equal to the settlement price of the perpetual futures.

  • Technical trade is not a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, PerpetualFuturesExecutionVoluntary, ClearingTrade.

  • id in gateways and reports is unique and nonzero.

  • The transaction price is equal to the settlement price of the perpetual futures, multiplied by a coefficient that takes into account the difference in the lot volume of the instruments.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, PerpetualFuturesExecution, ClearingTrade.

In the evening on the day of the exercise request submission
Forced exiting a perpetual futures (realization of unsatisfied demand)
  • id in gateways and reports is unique and nonzero.

  • The trade price is equal to the settlement price of the perpetual futures.

  • Technical trade is not a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, PerpetualFuturesExecutionForced, ClearingTrade.

  • id in gateways and reports is unique and nonzero.

  • The transaction price is equal to the settlement price of the perpetual futures, multiplied by a coefficient that takes into account the difference in the lot volume of the instruments.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, PerpetualFuturesExecution, ClearingTrade.

In the evening on the day of the exercise request submission
Trade Settlement TAS
  • id in gateways and reports is unique and nonzero.

  • Trade price is 0.

  • Technical trade is not a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, ClearingTrade, TASSettlement.

  • id in gateways and reports is unique and nonzero.

  • Trade price is equal to the settlement price of the underlying asset.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, ClearingTrade, TASSettlement.

On the execution day, in the evening.

Trades are shown as following:

Operation typeOperations info
Stock futures trade based on a negotiated order
  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to the minimal price step.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Address.

Stock futures trade based on a system order
  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to the minimal price step.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask):bits value is 0.

Stock futures option trade based on a negotiated order
  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to the minimal price step.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Address.

Stock futures option trade based on a system order
  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to the minimal price step.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask):bits value is 0.

Position transfer trade
  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to 5 places.

  • This trade is not a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Address, TransferClientPosition, TransferSource.

Technical trade based on the negotiated multi-leg order (near leg)
  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to 5 places.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Address, Strategy.

Technical trade based on the negotiated multi-leg order (far leg)
  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to 5 places.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Address, Strategy, REPOBack.

Technical trade based on the system multi-leg order (near leg)
  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to 5 places.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Strategy.

Technical trade based on the system multi-leg order (far leg)
  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to 5 places.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Strategy, REPOBack.

Equity futures trade based on indicative trade in RFS
  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to the minimal price step.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Address, RFSOrder.

Option on equity futures trade based on indicative trade in RFS
  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to the minimal price step.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Address, RFSOrder.

Technical trade for the near leg of a multi-leg order based on indicative trade in RFS
  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to 5 places.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Address, Strategy, RFSOrder.

Technical trade for the far leg of a multi-leg order based on indicative trade in RFS
  • id in gateways and reports is unique and nonzero.

  • Trade price is rounded to 5 places.

  • This trade is a trade legally.

  • Signs in gateways and reports (bitmask): NonQuote, Address, Strategy, REPOBack, RFSOrder.

Trading and clearing schedule

Trading schedule. Trading sessions.

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.

Intermediate clearing session

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.

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.

How different entities act on assigning a new trading session

Reference data and session data

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.

Funds and positions

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).

Orders and trades

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.

Instruments

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.

Replication streams

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:

The following streams are not subjects to reopen:

Event-sensitive scheme for data synchronizing

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

FieldTypeDescription
replIDi8Replication subsystem service field
replRevi8Replication subsystem service field
replActi8Replication subsystem service field
event_idi8Unique event ID
sess_idi4Session number
event_typei4Event type
messagec64Description 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.

Game and test mode trading schedule

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).

Opening auction

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).

Risk management and limitation of trading operations

Collaterals

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

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

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.

Unified Collateral Pool

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.

Limitations on trading operations and opening positions for clients

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

Prohibitions - general information

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

AttributeDescription
xprohibition_idThe unique ID of the prohibition.
client_codeClient 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:

  • 1 - CF Chief trader;

  • 2 - CC Administrator;

  • 3 - TS Administrator.

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:

  • 1 - Securities;

  • 2 - Сommodity;

  • 3 - Money;

  • 4 - Mosenergo exchange, MOSENEX;

  • 8 - Exchange of St. Petersburg, SPBEX;

  • 9 - SPBEX_OAO;

  • 10 - NAMEX.

base_contract_codeUnderlying asset code. The prohibition is set for instruments based on this underlying asset only.
isin_idInstrument unique ID. It is used to prohibit trading for a specific instrument.
priorityPriority 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:

  • 0x40000000 - Futures.

  • 0x80000000 - Options.

type

Type of prohibition. It can take the following values:

  • 0 - No prohibitions. Used for pinpoint permission in case of a broader prohibition;

  • 1 - Prohibited to open positions;

  • 2 - Prohibited to add any orders;

  • 3 - Prohibited to open sell positions;

  • 0x08 - BF prohibition to add requests for exercising;

  • 0x10 - Chief Trader prohibition to add requests for exercising; but to himself - it is possible;

  • 0x20 - Prohibition of requests without auto-confirmation (RFS);

  • 0x40 - Prohibition to request liquidity stream (RFS);

  • 0x80 - Prohibition to perform trades with insufficient number of quotes (RFS);

  • 0x100 - Prohibition to request liquidity stream with limited lifetime of quotes (RFS).

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:

  • 0 - The prohibition set by the Trading Administrator or Clearing Administrator; these prohibition cannot be changed by trader;

  • 1 - The prohibition set by a trader and can be changed by means of the gateway API.

Table 1. The matrix of the influence of prohibitions

Login level / InitiatorCF Chief traderCC AdministratorTS 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):

PriorityAccount groupInstrument group
9Client codeinstrument, isin_id != 0
8Client codeunderlying asset, base_contract_code != 0
7Client codeall instruments
6BF codeinstrument, isin_id != 0
5BF codeunderlying asset, base_contract_code != 0
4BF codeall instruments
3CF codeinstrument, isin_id != 0
2CF codeunderlying asset, base_contract_code != 0
1CF codeall 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.

  1. Examples of setting prohibitions when all clients have the same rights.

    1. 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.

    2. 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.

  2. 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.

    1. 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.

    2. 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.

Automatic prohibitions

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

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

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

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

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

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

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

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

, where

  • Limits_set – Client limit verification setting;

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

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

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

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

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

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

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

Position (obligation) transfer

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).

Pausing trading session for extending limits of trading prices fluctuations

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.

Risk parameters forecast information for trading participants

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.

Blocking the brokerage part of the client fee

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).

Negative prices support in SPECTRA

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

StreamTableFieldDescription
FORTS_TRADE_REPLorders_logpricePrice of the order
FORTS_TRADE_REPLorders_logdeal_pricePrice of the trade
FORTS_TRADE_REPLuser_dealpricePrice of the trade
FORTS_ORDLOG_REPLorders_logpricePrice of the order
FORTS_ORDLOG_REPLorders_logdeal_pricePrice of the trade
FORTS_USERORDERBOOK_REPLorderspricePrice of the order
FORTS_ORDBOOK_REPLorderspricePrice of the order
FORTS_COMMON_REPLcommonbest_buyBest bid
FORTS_COMMON_REPLcommonbest_sellBest offer
FORTS_COMMON_REPLcommonopen_priceOpening price
FORTS_COMMON_REPLcommonclose_priceClosing price
FORTS_COMMON_REPLcommonpricePrice of the last trade
FORTS_COMMON_REPLcommonmin_priceThe low price
FORTS_COMMON_REPLcommonmax_priceThe high price
FORTS_COMMON_REPLcommonavr_priceAverage weighted price
FORTS_COMMON_REPLcommonsettlement_price_openSettlement price of the previous session
FORTS_COMMON_REPLcommonmarket_priceCurrent market price
Streams of the aggregated order-books FORTS_AGGRXXorders_aggrpricePrice level
FORTS_POS_REPLpositionwapriceVolume-weighted average price
FORTS_POS_REPLposition_sawapriceVolume-weighted average price
FORTS_REFDATA_REPLfut_sess_contentslimit_upUpper price limit
FORTS_REFDATA_REPLfut_sess_contentslimit_downLower price limit
FORTS_REFDATA_REPLfut_sess_contentssettlement_price_openSettlement price at the start of the session 
FORTS_REFDATA_REPLfut_sess_contentssettlement_priceSettlement price after the last clearing session
FORTS_REFDATA_REPLfut_instrumentssettlement_price_openSettlement price at the start of the session
FORTS_REFDATA_REPLfut_instrumentssettlement_priceSettlement price after the last clearing session
FORTS_REFDATA_REPLopt_sess_contentsstrikeExercise price
FORTS_MM_REPLfut_MM_infoprice_edge_sellPrice of the worst sell order included in the spread
FORTS_MM_REPLfut_MM_infoprice_edge_buyPrice of the worst buy order included in the spread
FORTS_CLR_REPLfut_sess_settlsettl_priceSettlement price
FORTS_INFO_REPLfutures_paramsrisk_range_centerRisk calculation center
FORTS_INFO_REPLfutures_paramssettlement_priceSettlement price after the last clearing session
FORTS_INFO_REPLoptions_paramsstrikeExercise price
FORTS_REJECTEDORDERS_REPLrejected_orderspricePrice 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 Login (Sponsored Market Access)

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 numberVerification detailsBindingUnit of measureApplied
1Price fluctuation against the current priceSMA login or SMA login x Instrument**PercentImmediately
2Maximum volume of orderSMA login or SMA login x Instrument*Number of contractsImmediately
3Disallow negotiated modeSMA loginYes/NoImmediately
4Maximum volume of order in Russian RubleSMA login or SMA login x Instrument*Russian RubleImmediately
5Maximum volume of all orders per trading day (gross)SMA login or SMA login x Instrument*Russian RubleImmediately
6Maximum position (long) in contractsSMA login x Instrument** x Client codeNumber of contractsImmediately
7Maximum position (short) in contractsSMA login x Instrument** x Client codeNumber of contractsImmediately

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.

Separate entities of Clearing Member and Trading Member

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.

Who belongs to whom: a view inside SPECTRA

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.

Figure 2. Hierarchy

Hierarchy

Separation of Members' rights

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':

TransactionAvailable commands
Set limits for BFChangeBFMoney
Set BF trading limits for BFChangeBFLimit
Transfer of funds between two BFs of the same SAExchangeBFMoney
Set risk parameters for BFChangeBFParametersNextSession
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':

TransactionAvailable 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:

  1. 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.

  2. 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.

Figure 3. Examples

Examples

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

TransactionAvailable commands, tables
Set limits for client accountsChangeClientMoney
Set risk settings for client accountsChangeClientParameters; 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'.

Management of a Trading Member obligations by a Clearing Member

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

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.

Synthetic orders

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)

Figure 4. Calendar spread order-book

Calendar spread order-book

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

Two main scenarios of synthetic matching:

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

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

  • 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 orderCounter real orderFormation of a counter (passive) synthetic orderCounter passive synthetic order price
Buy near futuresSell near futuresSell far futures + Buy calendar spreadFar futures price - Сalendar spread price
Sell near futuresBuy near futuresBuy far futures + Sell calendar spreadFar futures price - Сalendar spread price
Buy far futuresSell far futuresSell near futures + Sell calendar spreadNear futures price + Сalendar spread price
Sell far futuresBuy far futuresBuy near futures + Buy calendar spreadNear futures price + Сalendar spread price
Buy calendar spreadSell calendar spreadBuy near futures + Sell far futuresFar futures - Near futures
Sell calendar spreadBuy calendar spreadSell near futures + Buy far futuresFar 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.

Synthetic liquidity in aggregated order-books

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.

Figure 5. Aggregated order-books for calendar spread

Aggregated order-books for calendar spread

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

Figure 6. Aggregated order-books with synthetic liquidity

Aggregated order-books with synthetic liquidity

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

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

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

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

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

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

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

Settlement trades

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.

Reasons for settlement trades

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'ReasonMember
0Common trade.Clearing Member
4Balancing Derivatives Contracts entered into with the Non-defaulting Clearing Member without submitting orders.Non-defaulting Clearing Member
6Closing Derivatives Contracts entered into under the cross-default procedure.Defaulting Clearing Member
7Closing Derivatives Contracts entered into upon non-fulfillment of the Margin Call.Defaulting Clearing Member
8Closing Derivatives Contracts entered into in into upon non-fulfillment of the Delivery Obligation on the deliverable Derivatives Contracts for precious metals.Defaulting Clearing Member
100OtherDefaulting 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.

Fines and fees

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.

Equity Options

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:

Changes in the calculation of free cash for equity options

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.

New indicator - amount of the premium payable/receivable at the nearest clearing session

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.

Change of the schedule of clearing sessions

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.

Exercise of equity options

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.

Margining of equity options

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.

Prohibitions on equity options

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).

Trading gate description

PLAZA II gateway. Components, installation and setup.

Components and architecture

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.

Figure 7. Gateway architecture

Gateway architecture

Hardware and software requirements

Hardware requirements

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.

Software requirements

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

Installation for Windows

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:

Figure 8. Installation start

Installation start

Click the 'Далее' button to continue with installation:

Figure 9. Destination folder

Destination folder

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).

Figure 10. Select components to install

Select components to install

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

Click the 'Далее' button to continue with installation:

Figure 11. Custom install

Custom install

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

Click the 'Далее' button to continue with installation:

Figure 12. Select an address to connect

Select an address to connect

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 optionConfiguration fileDetails
Выделенный каналlinks_public.prod.iniConnect to Spectra - production system
Резервный каналlinks_public.rezerv.iniConnect to Spectra - reserve system
Тестовая система для разработчиков T0links_public.t0.iniConnect to Spectra - public testing system - current version
Тестовая система для разработчиков T1links_public.t1.iniConnect to Spectra - public testing system - future version
Игровая системаlinks_public.game.iniConnect to Spectra - gaming system
Свои параметры соединенияlinks_public.custom.iniUser 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.

Figure 13. User connection settings section

User connection settings section

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:

Figure 14. Enter username and password

Enter username and password

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:

Figure 15. Registering router as OS service

Registering router as OS service

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.

Figure 16. Starting installation

Starting installation

Click 'Установить' to begin installation.

Figure 17. Finishing installation

Finishing installation

Click 'Готово' to finish the installation.

Installation for Linux

Installation from zip archive

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:

  1. Execute the command:

    chmod 755 ./install.sh
  2. 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!

  3. When you receive 'Please, enter cgate install path', specify the full path to the folder to decompress the cgate software.

  4. When you receive 'Please, enter P2 login', specify the user's login.

  5. When you receive 'Please, enter P2 password', specify the user's password.

  6. 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 from a deb package or rpm package

Installation steps:

  1. 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 locationDescription
    /opt/moex/cgateBinaries, schematics, gateway documentation
    /etc/opt/moex/cgateConfiguration files, auth.ini - files
    /var/opt/moex/cgateLogging directory, trace files
    /usr/share/docCopyright, installation documentation
  2. 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!

  3. 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!

Developer guidelines

Usage of test examples

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:

  1. 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).

  2. 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.

  3. 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.

  4. Example 'send'

    'send' is used to add order into the SPECTRA and write incoming replies into the trading system log. No input parameters required.

  5. 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).

  6. 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.

  7. 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!

Distributed configurations

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.

Recommendations for third-party companies on including the Moscow Exchange runtimes into user application when distributing the user software

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.

Market data structure

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

Reference information

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' table of the 'FORTS_MISCINFO_REPL' stream.

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

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.

Recovery information

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.

Funds and limits information

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

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

Indices and rates information

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.

Auxiliary information streams

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.

Gateway usage specifics

Service replication fields

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.

Commands

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.

FieldTypeDescription
codei4Return code
messagec255Message body

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

Flood control

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:

FieldTypeDescription
queue_sizei4Number of messages for a single user
penalty_remaini4Time in milliseconds after which the next message from this user will be successfully received.
messagec128Error text message

Please pay attention to the two details:

  1. 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.

  2. A reject message with 99 type can be sent in a reply to any user's message.

Cancel On Disconnect

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:

FieldTypeDetails
seq_numberi4Heartbeat-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'.

Replication stream sets for different login subtypes

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:

Additional replication streams received (market data source: aggregated orderbook):

Additional replication streams received (market data source: full orderbook):

Replication streams set for viewing login subtype:

Additional replication streams received (market data source: aggregated orderbook):

Additional replication streams received (market data source: full orderbook):

Replication streams set for the transactional login subtype:

Changing user password for the Trading System

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:

--app_name

Application name. Optional setting;

--local_pass

Password for the local connection to the router. Optional setting;

--host

Router IP address. Optional setting, the default value is 127.0.0.1

--port

Router port. Optional setting, the default value is 4001

--ini

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.

Partitioning of the matching

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.

Stream types

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 nameDescriptionType
FORTS_TRADE_REPLUser's orders and tradesR
FORTS_ORDLOG_REPLAnonymous ordersR
FORTS_DEALS_REPLAnonymous tradesR
FORTS_USERORDERBOOK_REPLUser orders: order-book snapshotR
FORTS_ORDBOOK_REPLDepersonalized order-book snapshotR
FORTS_PROHIBITION_REPLProhibitionsR
FORTS_REFDATA_REPLReference and session informationR
RTS_INDEX_REPLOnline indicesR
FORTS_INFO_REPLReference informationR
FORTS_USER_REPLUsersR
FORTS_REJECTEDORDERS_REPLRegister of orders rejected during the clearingR
FORTS_FEE_REPLExchange fees and penaltiesAR
FORTS_FEERATE_REPLPrecise Exchange fee ratesAR
FORTS_CLR_REPLClearing informationAR
FORTS_COMMON_REPLMarket fundamentalsI
FORTS_AGGR##_REPLAggregated order-bookI
FORTS_POS_REPLInformation on positionsI
FORTS_PART_REPLInformation about funds and limitsI
FORTS_MISCINFO_REPLMiscellaneous informationI
FORTS_MM_REPLInformation on MM's obligationsI
FORTS_VM_REPLVariation margin and premiumI
FORTS_VOLAT_REPLOnline volatility informationI
FORTS_TNPENALTY_REPLInformation about transaction feesI
MOEX_RATES_REPLOnline currency ratesI
FORTS_FORECASTIM_REPLRisk forecast after limits extensionI
FORTS_RISKINFOBLACK_REPLRisk parameters for the Black-Scholes modelI
FORTS_RISKINFOBACH_REPLRisk parameters for the Bachelier modelI

Limiting the number of simultaneously open replication streams from one PLAZA II connection

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.

Handling abnormal situations

Recovery on loss of connection with Exchange servers

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)

Figure 18. Connection scheme

Connection scheme

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

Connection loss detection

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.

Recovery algorithm

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) nameInformation typeRecovery method
FORTS_TRADE_REPL
  • orders_log

Own orders activity log (futures and options)List of active orders:
  • use stream 'FORTS_USERORDERBOOK_REPL' to receive snapshot, then open stream 'FORTS_TRADE_REPL' using the revision number specified in snapshot

Orders activity log:

  • open 'FORTS_TRADE_REPL' starting from the last received revision number

FORTS_TRADE_REPL
  • multileg_orders_log

Own orders activity log (multileg orders)Orders activity log:
  • open 'FORTS_TRADE_REPL' starting from the last received revision number

FORTS_ORDLOG_REPL
  • orders_log

Complete anonymous orders activity log (futures and options)List of active orders:
  • use stream 'FORTS_ORDRBOOK_REPL' to receive snapshot, then open stream 'FORTS_ORDLOG_REPL' using the revision number specified in the snapshot

Orders activity log:

  • open 'FORTS_ORDLOG_REPL' starting from the last received revision number

FORTS_ORDLOG_REPL
  • multileg_orders_log

Complete anonymous orders activity log (multileg orders)Orders activity log:
  • open 'FORTS_ORDLOG_REPL' starting from the last received revision number

FORTS_DEALS_REPL
  • deal

  • multileg_deal

FORTS_TRADE_REPL

  • user_deal

  • multileg_deal

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_REPLGeneral market information (futures and options)Reopen the stream anew
FORTS_AGGR##_REPLOrder books for futures and options. (### - depth of order book)Reopen the appropriate stream anew
FORTS_REFDATA_REPLReference and session informationQuick method:
  • Reopen the stream using the last received revision number or 'repl state' value received on closing the stream.

Allowable method:

  • Reopen the stream anew

FORTS_PART_REPLInformation on limitsReopen the stream anew
FORTS_POS_REPLInformation on positionsReopen the stream anew
FORTS_VM_REPLInformation on variation margin and premiumReopen the stream anew
FORTS_VOLAT_REPLInformation on volatility and theoretical prices on optionsReopen the stream anew
RTS_INDEX_REPLExchange indices valuesReopen the stream anew

Upon recovery, it is very important to receive the lists of the client's current orders:

  1. List of orders which are active during the recovery procedure period

  2. 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.

General recommendations

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

  • establish alternative connections

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

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

Figure 19. Channel duplication scheme

Channel duplication scheme

Recovery in case of the Exchange infrastructure 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.

Data cleanup by streams

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.

Possible data change in case of abnormal work of publishing services

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.

Replication scheme FORTS_PUBLIC

Stream FORTS_TRADE_REPL - User's orders and trades (Type=R)

Data scheme

Tables:

Table orders_log: Log of operations with orders

Table 2. Fields of table orders_log

FieldTypeDescription
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.
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:

    1

    Buy

    2

    Sell

  • Field public_action can take the following values

    0

    Order cancelled

    1

    Order added

    2

    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:

    0

    Order cancelled

    1

    Order added

    2

    Order is exercised in the trade

    3

    The order was added by appearance of a new visible part of the iceberg

  • Field 'reason' can take the following values:

    0

    Regular order

    4

    Balancing Derivatives contracts entered into with the Non-defaulting Clearing Member without submitting orders

    6

    Closing Derivatives сontracts entered into under the cross-default procedure

    7

    Closing Derivatives Contracts entered into upon non-fulfillment of the Margin Call

    8

    Closing Derivatives сontracts entered into in into upon non-fulfillment of the Delivery Obligation on the deliverable Derivatives contracts for precious metals.

    100

    Other

  • Field 'compliance_id' can take the following values:

    " " (space or empty string)

    Not filled in/Not specified

    M

    Manual input

    S

    As a result of the conditional request (stop-loss order)

    R

    As a result of the robot algorithm work

    A

    As a result of the auto-following algorithm

    D

    Covering a position as a result of an unexecuted Margin Call

Table multileg_orders_log: Log of operations with multileg orders

Table 3. Fields of table multileg_orders_log

FieldTypeDescription
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.
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:

    1

    Buy

    2

    Sell

  • Field public_action can take the following values

    0

    Order cancelled

    1

    Order added

    2

    Order exercised in a trade

  • Field 'private_action' ('action') can take the following values:

    0

    Order cancelled

    1

    Order added

    2

    Order is exercised in the trade

    3

    The order was added by appearance of a new visible part of the iceberg

  • Field 'reason' can take the following values:

    0

    Regular order

    4

    Balancing Derivatives contracts entered into with the Non-defaulting Clearing Member without submitting orders

    6

    Closing Derivatives сontracts entered into under the cross-default procedure

    7

    Closing Derivatives Contracts entered into upon non-fulfillment of the Margin Call

    8

    Closing Derivatives сontracts entered into in into upon non-fulfillment of the Delivery Obligation on the deliverable Derivatives contracts for precious metals.

    100

    Other

  • Field 'compliance_id' can take the following values:

    " " (space or empty string)

    Not filled in/Not specified

    M

    Manual input

    S

    As a result of the conditional request (stop-loss order)

    R

    As a result of the robot algorithm work

    A

    As a result of the auto-following algorithm

    D

    Covering a position as a result of an unexecuted Margin Call

Table user_deal: User trades

Table 4. Fields of table user_deal

FieldTypeDescription
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:

    0

    Regular trade

    4

    Balancing Derivatives contracts entered into with the Non-defaulting Clearing Member without submitting orders

    6

    Closing Derivatives сontracts entered into under the cross-default procedure

    7

    Closing Derivatives Contracts entered into upon non-fulfillment of the Margin Call

    8

    Closing Derivatives сontracts entered into in into upon non-fulfillment of the Delivery Obligation on the deliverable Derivatives contracts for precious metals.

    100

    Other

Table user_multileg_deal: User’s multileg orders trades

Table 5. Fields of table user_multileg_deal

FieldTypeDescription
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:

    0

    Regular trade

    4

    Balancing Derivatives contracts entered into with the Non-defaulting Clearing Member without submitting orders

    6

    Closing Derivatives сontracts entered into under the cross-default procedure

    7

    Closing Derivatives Contracts entered into upon non-fulfillment of the Margin Call

    8

    Closing Derivatives сontracts entered into in into upon non-fulfillment of the Delivery Obligation on the deliverable Derivatives contracts for precious metals.

    100

    Other

Table heartbeat: Server times table

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 6. Fields of table heartbeat

FieldTypeDescription
replID i8 Service field of the replication subsystem
replRev i8 Service field of the replication subsystem
replAct i8 Service field of the replication subsystem
server_time t Server date and time


Table sys_events: table of events

Table 7. Fields of table sys_events

FieldTypeDescription
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

Stream FORTS_ORDLOG_REPL – anonymous orders (Type=R)

Data scheme

Tables:

Table orders_log: Log of operations with orders

Table 8. Fields of table orders_log

FieldTypeDescription
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:

    1

    Buy

    2

    Sell

  • Field public_action can take the following values

    0

    Order cancelled

    1

    Order added

    2

    Order is exercised in the trade

Table multileg_orders_log: Log of operations with multileg orders

Table 9. Fields of table multileg_orders_log

FieldTypeDescription
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:

    1

    Buy

    2

    Sell

  • Field public_action can take the following values

    0

    Order cancelled

    1

    Order added

    2

    Order exercised in a trade

Table heartbeat: Server times table

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 10. Fields of table heartbeat

FieldTypeDescription
replID i8 Service field of the replication subsystem
replRev i8 Service field of the replication subsystem
replAct i8 Service field of the replication subsystem
server_time t Server date and time


Table sys_events: table of events

Table 11. Fields of table sys_events

FieldTypeDescription
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

Stream FORTS_DEALS_REPL – anonymous trades (Type=R)

Data scheme

Tables:

Table deal: Trades

Table 12. Fields of table deal

FieldTypeDescription
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 multileg_deal: Multileg trades

Table 13. Fields of table multileg_deal

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
sess_idi4Trading session ID
isin_idi4Multileg instrument ID
id_deali8Deal ID number
public_order_id_buyi8The buyer's order ID (for iceberg order – ID of its visible part)
public_order_id_selli8The seller's order ID (for iceberg order – ID of its visible part)
xamounti8Volume, number of units of the instrument
priced16.5Price of the first part of multileg trade
rate_priced16.5Rate price
swap_priced16.5Swap price
momenttTime when the deal was made
moment_nsu8Time when the deal was made, nanoseconds since Unix epoch, UTC
nosystemi1Sign of non-system deal
xstatus_buyi8Status of the trade from the buyer's side
xstatus_selli8Status of the trade from the seller's side
xstatus2_buyi8Extension for trades statuses (in addition to the ‘xstatus_buy’ field)
xstatus2_selli8Extension for trades statuses (in addition to the ‘xstatus_sell’ field)


Notes:

Table heartbeat: Server times table

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 14. Fields of table heartbeat

FieldTypeDescription
replID i8 Service field of the replication subsystem
replRev i8 Service field of the replication subsystem
replAct i8 Service field of the replication subsystem
server_time t Server date and time


Table sys_events: table of events

Table 15. Fields of table sys_events

FieldTypeDescription
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

Stream FORTS_FEE_REPL - exchange fees and penalties (Type=AR)

Data scheme

Tables:

Table adjusted_fee: exchange fees

Table 16. Fields of table adjusted_fee

FieldTypeDescription
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 penalty: penalties

Table 17. Fields of table penalty

FieldTypeDescription
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 sys_events: table of events

Table 18. Fields of table sys_events

FieldTypeDescription
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

Stream FORTS_FEERATE_REPL - Precise Exchange fee rates (Type=AR)

Data scheme

Tables:

Table futures_rate: fee rates on futures and multi-leg instruments

Table 19. Fields of table futures_rate

FieldTypeDescription
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 option_rate: fee rates on option contracts

Table 20. Fields of table option_rate

FieldTypeDescription
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 sys_events: table of events

Table 21. Fields of table sys_events

FieldTypeDescription
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

Stream FORTS_BROKER_FEE_REPL - Brokerage fees (Type=I)

Data scheme

Tables:

Table broker_fee: brokerage fee

Table 22. Fields of table broker_fee

FieldTypeDescription
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 sys_events: table of events

Table 23. Fields of table sys_events

FieldTypeDescription
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

Stream FORTS_BROKER_FEE_PARAMS_REPL - Parameters for calculating the brokerage fee (Type=I)

Data scheme

Tables:

Table broker_fee_params: Parameters for calculating the brokerage fee

Table 24. Fields of table 'broker_fee_params'

FieldTypeDescription
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:

    sess_id

    Current calculation parameters.

    -1

    Adding new calculation parameters. Parameters will be applied in the next trading session.

    -2

    Deletion of current calculation parameters. Parameters will be deleted in the next trading session.

Table sys_events: table of events

Table 25. Fields of table sys_events

FieldTypeDescription
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

Stream FORTS_USERORDERBOOK_REPL - User orders: order-book snapshot (Type=R)

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.

Data scheme

Tables:

  • orders - Current futures and options order-book
  • info - Order-book snapshots information
Table orders: Current futures and options order-book

Table 26. Fields of table orders

FieldTypeDescription
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:

    1

    Buy

    2

    Sell

  • Field public_action can take the following values:

    0

    Order cancelled

    1

    Order added

    2

    Order is exercised in the trade

  • Field 'private_action' ('action') can take the following values:

    0

    Order cancelled

    1

    Order added

    2

    Order is exercised in the trade

    3

    The order was added by appearance of a new visible part of the iceberg

  • Field 'reason' can take the following values:

    0

    Regular order

    4

    Balancing Derivatives contracts entered into with the Non-defaulting Clearing Member without submitting orders

    6

    Closing Derivatives сontracts entered into under the cross-default procedure

    7

    Closing Derivatives Contracts entered into upon non-fulfillment of the Margin Call

    8

    Closing Derivatives сontracts entered into in into upon non-fulfillment of the Delivery Obligation on the deliverable Derivatives contracts for precious metals.

    100

    Other

  • Field 'compliance_id' can take the following values:

    " " (space or empty string)

    Not filled in/Not specified

    M

    Manual input

    S

    As a result of the conditional request (stop-loss order)

    R

    As a result of the robot algorithm work

    A

    As a result of the auto-following algorithm

    D

    Covering a position as a result of an unexecuted Margin Call

Table info: Order-book snapshots information

Table 27. Fields of table info

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
infoIDi8Unique key
logRevi8Last processed revision at the time of snapshot creation
lifeNumi4Stream life number
momenttSnapshot time
publication_statei1State of the snapshot publication


Notes:

  • Field publication_state can take the following values:

    0

    in progress

    1

    done

Stream FORTS_ORDBOOK_REPL - Depersonalized order-book snapshot (Type=R)

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.

Data scheme

Tables:

  • orders - Current order-book
  • info - Order-book snapshots information
Table orders: Current order-book

Table 28. Fields of table orders

FieldTypeDescription
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:

    1

    Buy

    2

    Sell

  • Field public_action can take the following values

    1

    Order added

    2

    Order is exercised in the trade

Table info: Order-book snapshots information

Table 29. Fields of table info

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
infoIDi8Unique key
logRevi8Last processed revision at the time of snapshot creation
lifeNumi4Stream life number
momenttSnapshot time
publication_statei1State of the snapshot publication


Notes:

  • Field publication_state can take the following values:

    0

    in progress

    1

    done

Stream FORTS_COMMON_REPL - Market fundamentals (Type=I)

Data scheme

Tables:

Table common: Market fundamentals

The table contains market fundamentals data (best buy/sell orders, opening/closing price values, etc).

Table 30. Fields of table common

FieldTypeDescription
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:

    1

    The value of the current market price in the 'market_price' field is set by the Trading Administrator.

    0

    The value of the current market price in the 'market_price' field is calculated by the system.

Table sys_events: table of events

Table 31. Fields of table sys_events

FieldTypeDescription
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

Aggregated order-book streams (Type=I)

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.

Data scheme

Tables:

Table orders_aggr: Aggregated order-books

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

FieldTypeDescription
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.

  1. 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:

  2. 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:

  3. 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:

  4. 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:

  5. 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:

  6. 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:

  7. 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:

  8. 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:

  9. 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:

Stream FORTS_POS_REPL - information on positions (Type=I)

Data scheme

Tables:

Table position: Client positions

The table contains information on clients and BF positions.

Table 33. Fields of table position

FieldTypeDescription
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
  • 1 - BF's account

  • 2 - client's account


Table position_sa: Settlement Account positions

The table contains information on Settlement Account positions.

Table 34. Fields of table position_sa

FieldTypeDescription
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 sys_events: table of events

Table 35. Fields of table sys_events

FieldTypeDescription
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

Stream FORTS_PART_REPL - information about funds and limits (Type=I)

Data scheme

Tables:

  • part - Funds and limits of clients and brokerage firms
  • part_sa - Funds and limits for Settlement Account
  • sys_events - table of events
Table part: Funds and limits of clients and brokerage firms

The table contains information about funds, limits, and settings for automatic limit changes for clients and brokerage firms.

Table 36. Fields of table part

FieldTypeDescription
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 part_sa: Funds and limits for Settlement Account

Table 37. Fields of table part_sa

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
settlement_accountc12Settlement Account
money_oldd26.2Total amount of rubles and pledges discounted to rubles at the end of the previous session
money_amountd26.2Total amount of rubles and pledges discounted to rubles
money_freed26.2Amount 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_blockedd26.2Assets pledged as initial margin.
money_pledge_amountd26.2Total amount of pledges, discounted to rubles
vm_reserved26.2Variation margin on closed positions, and FX risk.
vm_intercld26.2Variation margin withdrawn or deposited during the intraday clearing session
feed26.2Debited fee
blocked_taxd26.2Assets blocked for tax payments.
premium_intercld26.2Premium received/withdrawn at intraday clearing.
net_option_valued26.2Total estimated value of premium options in the portfolio.


Table sys_events: table of events

Table 38. Fields of table sys_events

FieldTypeDescription
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

Stream FORTS_PROHIBITION_REPL - Prohibitions (Type=R)

Data scheme

Tables:

Table prohibition: Prohibitions

Table 39. Fields of table prohibition

FieldTypeDescription
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:

    1

    CF Chief trader;

    2

    CC Administrator;

    3

    TS Administrator.

  • Field 'type' - Prohibition type

    0

    No prohibitions. Used for pinpoint permission in case of a broader prohibition;

    1

    Prohibited to open positions;

    2

    Prohibited to add any orders;

    3

    Prohibited to open sell positions;

    0x08

    BF prohibition to add requests for exercising;

    0x10

    Chief Trader prohibition to add requests for exercising; but to himself - it is possible;

    0x20

    Prohibition of requests without auto-confirmation (RFS);

    0x40

    Prohibition to request liquidity stream (RFS);

    0x80

    Prohibition to perform trades with insufficient number of quotes (RFS);

    0x100

    Prohibition to request liquidity stream with limited lifetime of quotes (RFS).

  • Field 'group_mask' - Instrument type bitmask:

    0x40000000

    Futures.

    0x80000000

    Options.

  • Field 'priority' - From high to low

    High custom priority

    12

    Medium custom priority

    11

    Low custom priority

    10

    Client code, instrument

    9

    Client code, UA

    8

    Client code, all UAs

    7

    BF code, instrument

    6

    BF code, UA

    5

    BF code, all UAs

    4

    CF code, instrument

    3

    CF code, UA

    2

    CF code, all UAs

    1

  • Field 'section' - Section name:

    1

    Securities

    2

    Commodities

    3

    Money

    4

    Mosenergo exchange, MOSENEX

    8

    Exchange of St. Petersburg, SPBEX

    9

    SPBEX_OAO

    10

    NAMEX

  • Field 'is_legacy' - Prohibition originator type:

    0

    indicates the prohibition set by the Trading Administrator/Clearing Administrator; these prohibitions cannot be changed by traders.

    1

    indicates the prohibition set by a trader; these prohibitions can be changed by traders.

Table sys_events: table of events

Table 40. Fields of table sys_events

FieldTypeDescription
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

Stream FORTS_REFDATA_REPL - Reference and session information (Type=R)

Data scheme

Tables:

Table rates: Currency rates dictionary

Table 41. Fields of table rates

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
rate_idi4Payment currency identifier
curr_basec15Base currency code
curr_coupledc15Linked currency code
radiusd16.5Price indicator change radius (in percent)


Table fut_sess_contents: Traded instruments directory (futures)

The table contains dictionary of instruments which are traded in specified trading session.

Table 42. Fields of table fut_sess_contents

FieldTypeDescription
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.


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:

    0

    Session for this instrument is scheduled. One can cancel orders for this instrument

    1

    Session for this instrument is running. One can both add and cancel orders for this instrument

    2

    Trading in all instruments has been suspended. One can cancel orders for each instrument.

    3

    Session for this instrument has been closed compulsorily. Orders can be neither added nor cancelled

    4

    Session for this instrument has been completed because the time is up. Orders can be neither added nor cancelled

    5

    Trading in this instrument has been suspended. One can cancel orders for this instrument

    6

    The opening auction for this instrument started. You can put and delete orders for this instrument.

    7

    The opening auction for this instrument is completed

  • Field signs is a bit mask and defines the following values:

    0x1

    The instrument is traded in the additional trading session (evening/morning)

    0x10

    Sign of anonymous trading

    0x20

    Sign of non-anonymous trading

    0x40

    Sign of trading in the main session

    0x100

    Sign of multileg-instrument

    0x4000

    Daily futures contract with automatic prolongation (CFD - Contract for difference)

    0x10000

    Calendar Spread

    0x40000

    Collateral

    0x80000

    Exercise in evening or intraday clearing session:

    • 0 - evening clearing session

    • 1 - intraday clearing session

    0x100000

    TAS futures

  • Field multileg_type can take the following values:

    0

    Ordinary instrument, not the multileg one

    3

    The instrument is calendar futures spread

  • Field is_trade_evening is bit mask:

    0

    Instrument is not traded

    1

    Instrument is traded in the evening trading session

    2

    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.

Table fut_vcb: Traded assets directory (futures)

The table contains directory of base contracts for instruments.

Table 43. Fields of table fut_vcb

FieldTypeDescription
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:

    I

    Cash-settled

    T

    Delivery via ASTS

    D

    Delivery by other way (not used)

  • Field trade_scheme can take the following values:

    F

    With 100% collateral

    G

    With pledge

  • Field signs is a bit mask and defines the following values:

    0x1

    Exercise in evening or intraday clearing session: 0 - evening clearing session; 1 - intraday clearing session

    0x2

    Foreign instrument: 0 - not foreign; 1 - foreign

    0x4

    TAS futures: 0 - not TAS futures; 1 - TAS futures

  • Field negative_prices can take the following values:

    0

    Futures prices, price limits and options strikes are limited to be positive only.

    1

    Futures prices and options strikes are not limited.

  • Field option_model can take the following values:

    0

    Black-Scholes model.

    1

    Bachelier model.

  • Field 'asset_class' may contain the following values:

    1

    Share

    2

    Currency

    3

    Bond

    4

    Index

    5

    Commodity

    6

    Interest rate

Table fut_instruments: Instruments dictionary

Table 44. Fields of table fut_instruments

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
isin_idi4Instrument unique ID
short_isinc25Short symbol code of the instrument for information systems
isinc25Symbol code of the instrument
namec75Instrument name
inst_termi4Shift from RTS standard instruments
base_contract_codec25Underlying asset code.
settlement_price_opend16.5Settlement price at the start of the session.
roundtoi4Number of decimal places after the decimal point for the price
min_stepd16.5Minimum price increment
lot_volumei4Lot, i.e. number of units of the underlying asset in the instrument
step_priced16.5Value of the minimum price increment
last_trade_datetExpiration date.
is_spreadi1Flag of the futures contract’s being part of an intermonth spread '1' – spread; '0' – no spread.
d_exp_starttStart date of instrument exercise.
percent_rated6.2Variation margin rate for interest rate futures
settlement_priced16.5Settlement price after the last clearing session.
signsi4Flags field
multileg_typei4Type of multileg instrument
legs_qtyi4Number of instruments for multileg instrument
step_price_clrd16.5Value of the minumum increment for the clearing session
step_price_interclrd16.5Value of the minumum increment for the intraday clearing session
step_price_currd16.5Value 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_coeffd16.5Coef. for yield calculation on percent rates futures
pctyield_totald16.5Sum of rates for yield calculation on percent rates futures
series_typec1Futures maturity type. 'M' - monthly; 'Q' - quarterly.
enforce_ims_half_nettingi1Flag - consider the risks of intermonth spread according to the "half-netto" rule: '1' - yes; '0' - no.


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 fut_bond_registry: Spot asset parameters directory

Table 45. Fields of table fut_bond_registry

FieldTypeDescription
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:

    0x1

    Share

    0x2

    Bond

    0x4

    Amortized bond

    0x800000

    Currency

Table dealer: Companies directory

Table 46. Fields of table dealer

FieldTypeDescription
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:
  • 3 - half nett

  • 4 - nett

calendar_spread_margin_type i1 Margin type for calendar spreads, for BF portfolio, applied during the evening clearing session:
  • 3 - half nett

  • 4 - nett

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:
  • 1 - Verify

  • 0 - Do not verify

limit_tied_money i1 BF trading limit accordance with the BF's total funds amount (all sections):
  • 1 - maintain accordance

  • 0 - virtual (independent) limit. The value may change according to the profit/loss values only, resulting from the evening clearing session. Applied during the evening clearing session.

limits_set i1 Verify collateral sufficiency, for BF, upon adding orders:
  • 1 - Verify

  • 0 - Do not verify

no_fut_discount i1 Discount on futures for BF portfolio, applied during the evening clearing session:
  • 1 - Discount prohibited

  • 0 - Discount allowed

no_fut_discount_client_default i1 Discount on futures for BF's clients, default value:
  • 1 - DIscount prohibited

  • 0 - DIscount allowed

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:
  • 3 - half nett

  • 4 - nett

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:

    0

    Access to trading during the morning trading session is limited. Trading operations are prohibited, except for orders cancellation operations.

    1

    Access to trading during the morning trading session is allowed.

Table sys_messages: Trading system messages

Table 47. Fields of table sys_messages

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
msg_idi4Unique message ID
lang_codec8Message language
type_idi4Message type
momenttMessage date and time
textc255Short text
urgencyi1Urgency
statusi1Message status
message_bodyc4000Full text


Message types:

type_idMessage template text
4Dear 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 #РИСКОВ#.
5Trading in #БФ# futures has been halted for the #НомерРасширения# expansion of #ГРАНИЦА# bound of the price band and #РИСКОВ#.
6Trading in #БФ# futures has been resumed. New #ГРАНИЦА# bounds of the price band: #UpCotir/DownCotir#, new #NEWRATE#.
7Initial margin are #AmountGO# #valuta#, change to the previous day #DiffAmountGO# #valuta#.
8Trading in #БФ# futures has been halted.
9Trading in #БФ# futures has been resumed.
11Contacts for liquidity providers and block trade enabling Brokers - https://www.moex.com/s3005
12Please, pay attention that today is the last trading day of #ТЕКУЩМЕСЯЦ# #НЕДЕЛЬНЫЕ?weekly##АМЕРИКАНСКИХ/ЕВРОПЕЙСКИХ# #МАРЖИРУЕМЫХ/ПРЕМИАЛЬНЫХ# #РАСЧЕТНЫХ/ПОСТАВОЧНЫХ# equity options (#БФ#).
13Orders can be cancelled now.
14Technical break begins at 14:00.
15Trading will resume at 14:05. Orders can be cancelled now.
17Currency 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.
18Currency 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.
19Exercise price calculated…
20Attention! To be exercised during the today's intraday clearing session…
500Free form text field for standard messages
501Free form text field for non-standard messages
Table opt_sess_contents: Traded instruments directory (options)

The table contains dictionary of instruments which are traded in specified trading session.

Table 48. Fields of table opt_sess_contents

FieldTypeDescription
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:

    0x1

    The instrument is traded in the additional trading session (evening/morning)

    0x10

    Sign of anonymous trading

    0x20

    Sign of non-anonymous trading

    0x40

    Sign of trading in the main session

  • Field state can take the following values:

    0

    Session for this instrument is scheduled. One can cancel orders for this instrument

    1

    Session for this instrument is running. One can both add and cancel orders for this instrument

    2

    Trading in all instruments has been suspended. One can cancel orders for each instrument.

    3

    Session for this instrument has been closed compulsorily. Orders can be neither added nor cancelled

    4

    Session for this instrument has been completed because the time is up. Orders can be neither added nor cancelled

    5

    Trading in this instrument has been suspended. One can cancel orders for this instrument

Table opt_vcb: Traded assets directory (options)

The table contains dictionary of underlying contracts for instruments.

Table 49. Fields of table opt_vcb

FieldTypeDescription
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:

    0

    Futures prices, price limits and options strikes are limited to be positive only.

    1

    Futures prices and options strikes are not limited.

  • Field option_model can take the following values:

    0

    Black-Scholes model.

    1

    Bachelier model.

Table multileg_dict: Multileg instruments dictionary

Table 50. Fields of table multileg_dict

FieldTypeDescription
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 fut_intercl_info: Information on the variation margin on futures, calculated based on the results of intraday clearing

Table 51. Fields of table fut_intercl_info

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
isin_idi4Instrument unique ID
client_codec7Client code
vm_intercld16.2Variation margin debited or credited during the intraday clearing


Table opt_intercl_info: Information on variation margin and premium on options calculated based on the results of intraday clearing

Table 52. Fields of table opt_intercl_info

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
isin_idi4Instrument unique ID
client_codec7Client code
vm_intercld16.2Variation margin debited or credited during the intraday clearing
premiumd16.5Ruble premium under the option received/withdrawn at intraday clearing. Include the financial result of exercising the position.
premium_in_settl_currencyd16.5Currency premium under the option received/withdrawn at intraday clearing. Include the financial result of exercising the position.


Table opt_exp_orders: Register of requests for exercise of option

Table 53. Fields of table opt_exp_orders

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
exporder_idi8ID of the request to exercise the options
client_codec7Client code
isin_idi4Instrument unique ID
xamounti8Number of expiring positions
sess_idi4Trading session ID
datetDate and time
xamount_applyi8Number of positions detailed in requests as of intraday clearing


Table fut_bond_nkd: Accrued interest as of the bond futures contract expiration date

Table 54. Fields of table fut_bond_nkd

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
bond_idi4ID of the bond
datetCoupon payment date
nkdd16.7Accrued interest as of the coupon payment date
is_cuponi1Flags: 0 - accrued interest as of the bond futures contract settlement date, 2 - accrued interest as of the bond settlement date


Table fut_bond_nominal: Payment of bonds’ face value

Table 55. Fields of table fut_bond_nominal

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
bond_idi4ID of the bond
datetCoupon payment date
nominald16.5payment of bonds’ face value
face_valued16.5Payment of bonds’ rest face value
coupon_nominald8.5Coupon value in % of face value
is_nominali1Type 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 fut_bond_isin: Guide on bond instruments

Table 56. Fields of table fut_bond_isin

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
isin_idi4Instrument unique ID
bond_idi4ID of the bond
coeff_conversiond5.4Conversion ratio


Table user: System users

Table 57. Fields of table user

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
loginc20Trading participant's login
start_datetLogin start time
end_datetLogin end time
client_codec77-symbol client code
operation_maski4Bitmask:
  • 2 - Limit open positions for BF

  • 8 - Limit BF on funds transfer. The setting is available to Clearing Firm operator or Trading Administrator only.

  • 16 - Money back.

  • 32 - Limit client positions.

  • 128 - Client restrictions.

  • 1024 - Orders-related restrictions for SMA logins.

langi2Message language code
sma_flagsi4Bitmask (see Notes below):
  • 1st bit - Cancel on Disconnect

  • 2nd bit - Cancel on DropCopy Disconnect

  • 3rd bit - SMA login.

sma_statusi4Bitmask (see Notes below):
  • 1st bit - enable/disable trading transactions for the login.

  • 2nd bit - cancel/do not cancel orders when trading transactions are disabled for the login.

asprefi4Client ID. For orders added by SMA login - MASTER login ID.
user_leveli1User login level:
  • 1 - CF

  • 2 - BF

  • 3 - Client

password_expiration_datetPassword 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 sess_option_series: Option series by session

Table 58. Fields of table sess_option_series

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
series_idi4Series of Options ID
underlying_idi4Futures ID
base_contract_idi4Underlying contract ID
expiration_datetExpiration period closing date
expiration_anchor_datetAnchor date (expiration date of series of Options)
days_to_expirationi4Number of business days (local calendar) before expiration date
years_to_expirationfTime before Option expiration date in fractions of year (calendar days before exercise date/number of days in year)
series_typec1Option maturity type . W-weekly; M-monthly; Q-quarterly.
small_namec25Symbol code
strike_stepd16.5Strike step
use_null_volati11 - Zero volatility calculation mode is on, 0 - Off
sub_riski11 - Risk accounting by risk sub-points mode is on, 0 - Off
volat_mind20.15Minimum volatility limit
volat_maxd20.15Maximum volatility limit
volatility_riskfCurrent volatility risk rate, in fractions
volatility_mismatch_riskfCurrent volatility mismatch risk rate, in fractions
signsi4Flags field
a_blackfVolatility curve calculation parameter for Black-Scholes model.
b_blackfVolatility curve calculation parameter for Black-Scholes model.
c_blackfVolatility curve calculation parameter for Black-Scholes model.
d_blackfVolatility curve calculation parameter for Black-Scholes model.
e_blackfVolatility curve calculation parameter for Black-Scholes model.
s_blackfVolatility curve calculation parameter for Black-Scholes model.
a_bachfVolatility curve calculation parameter for Bachelier model.
b_bachfVolatility curve calculation parameter for Bachelier model.
c_bachfVolatility curve calculation parameter for Bachelier model.
d_bachfVolatility curve calculation parameter for Bachelier model.
e_bachfVolatility curve calculation parameter for Bachelier model.
s_bachfVolatility curve calculation parameter for Bachelier model.
m_bachfVolatility curve calculation parameter for Bachelier model.
rfRisk-free interest rate.
fixed_spot_discountfSum of discounted values of declared cash flows.
projected_spot_discountfSum of discounted values of forecasted cash flows.
margin_stylei4Option margin method. 0 - Futures-style option; 1 - Equity-style option.
settlement_typei4Option type. 0 - Сash-settled; 1 - Deliverable.
exercise_stylei4Exercise style of option. 0 - American; 1 - European.
min_stepd16.5The minimum price movement.
step_priced16.5Price step cost.
lot_coefficienti4Coefficient indicating the volume of the underlying asset in the contract quote and strikes of option series.
interest_rate_risk_upfInterest rate mismatch rate in the scenario of rate movement ‘r’ upward.
interest_rate_risk_downfInterest rate mismatch rate in the downward rate movement scenario ‘r’.
step_price_currd16.5Price step cost in currency. Used for contracts with settlements in foreign currency, for ruble contracts the value is the same as 'step_price'.
underlying_priced16.5The 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_volumei4Lot, i.e. number of units of the underlying asset in the instrument.
sess_idi4Trading session ID
step_price_clrd16.5The cost of the evening clearing price step.
step_price_interclrd16.5The cost of the intraday clearing price step.
r2fRisk-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_upfInterest rate mismatch rate in the scenario of rate movement ‘r2’ upward.
interest_rate2_risk_downfInterest rate mismatch rate in the downward rate movement scenario ‘r2’.


Notes:

  • Field signs is a bit mask and defines the following values:

    0x1

    Exercise in evening or intraday clearing session: 0 - evening clearing session; 1 - intraday clearing session

Table investor: Clients directory

Table 59. Fields of table investor

FieldTypeDescription
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:
  • 3 - half nett

  • 4 - nett

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 Margin type for cross-contract spreads:
  • 3 - half nett

  • 4 - nett

coeff_im d16.5 Total collateral ratio value.
no_fut_discount i1 Discount on futures:
  • 1 - Discount prohibited

  • 0 - Discount allowed

num_clr_2delivery i4 Number of clearing sessions before expiration to start expiration scenarios calculation.
exp_weight d3.2 Expiration scenario weight, in total collateral.
xstatus i8 Client's flags, extended.


Notes:

  • Xstatus field is a bit mask:

    • 0x1 - Trust Management

    • 0x2 - Separated

    • 0x4 - Brokerage Firm (Trust Management type)

    • 0x80 - Private entity

    • 0x100 - Legal entity

    • 0x200 - Non-resident

    • 0x2000 - Individual investment account

    • 0x4000 - Flag for allowing cross-trades for negotiated orders. 1 - cross-trades allowed; 0 - cross-trades prohibited

    • 0x8000 - Stateless person

    • 0x20000 - Own

    • 0x40000 - Client

    • 0x80000 - Special BF

    • 0x10000000 - Additional own account

    • 0x10000000000 - Qualified investor

    • 0x40000000000 - Cancel a passive order in a cross-trade

Table fut_margin_type: Type of margining

Table 60. Fields of table fut_margin_type

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem
codec12Settlement Account or Brokerage Firm Code
typei1Type of Code. Settlement Account - 0, Brokerage Firm - 1.
margin_typei1Type of margining. 2 - Gross, 3 - Half nett, 4 - Nett.
UCP_typei1UCP-related Settlement Account.
prohibit_coeffd16.2Debt coefficient value for Settlement Account/Brokerage Firm/section. The value defines the maximum correlation between negative free limit volume and trading limit volume. As the value exceeded, the system prohibits operations. The prohibition mode is specified by field 'prohibit_type'.
prohibit_typei4Type of automatic prohibition for Settlement Account:
  • 1 - prohibited to open positions

  • 2 - prohibited to add orders.

settlement_account_typei1Settlement Account Type. 0 - own SA, 1 - client SA, 2 - SA (Trust Management type).
operator_inputi1

Settlement account blocking set by the TS Administrator:

  • 0 - blocking off

  • 1 - blocking on.


Notes:

  • Possible 'operator_input' field values: 0 - blocking off, 1 - blocking on. When the blocking mode is turned on, orders placed from all BF clearing accounts linked to the blocked SA are automatically cancelled. The cancelled orders in the 'xstatus' field are marked with a special sign - 'OperatorInputSA' (0x1000000000000). In the blocking mode, any trading commands with the indication of BF clearing accounts linked to this SA are prohibited, and the positions transfer between BFs is also prohibited. Orders and trades formed for SA by the Trading Administrator in blocking mode, have a special sign in the 'xstatus' field (in orders) and 'xstatus_sell' or 'xstatus_buy' fields (in trades) - 'OperatorInputSA' (0x1000000000000).

Table fut_settlement_account: Settlement Account

Table 61. Fields of table fut_settlement_account

FieldTypeDescription
replIDi8Service field of the replication subsystem
replRevi8Service field of the replication subsystem
replActi8Service field of the replication subsystem