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

Clearing firms are authorized to:

Clearing firms are obliged to:

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

Brokerage firms are authorized to:

Brokerage firms are obliged to:

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

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

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

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

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

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

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

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

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

An underlying asset IS IN NO WAY A TRADING INSTRUMENT!

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

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

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

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 tenge for a contract is calculated as following:

, where:

Two more fields are required to fill when it comes about future contracts quoted in foreign currency:

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

The SPECTRA system has four fields to identify each instrument:

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

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

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

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

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

Orders can be subdivided into three types: quoted, offsetting, and fill-or-kill orders. A quoted order remains in queue after it has been fully or partly exercised. An offsetting orders have to be removed from the system after auction ended, no matter whether it has been exercised fully or partly. At last, the fill-or-kill orders — the offsetting orders which can only be exercised fully.

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

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

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

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

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

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

Users can do the following:

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

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

Data on own trades are stored in table 'user_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 table '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 table 'user_deal' of stream 'FORTS_TRADE_REPL', or by the flag nosystem in table 'deal' of stream 'FORTS_DEALS_REPL' (for details see Trade types, created upon exercising and expiration of futures and options).

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

The iceberg orders main features:

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

Flags applied to orders and trades:

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

Trades are shown as following:

Trading in the SPECTRA system is carried out within a trading session. 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 and many others.

The clearing session is taking place in the end of the trading session. The following operations are performed:

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

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

The table is added into the following replication streams:

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

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

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, commission fees, etc.). Also, the system calculates collateral sufficiency to meet initial margin requirements.

Settlement accounts are subdivided into three sections:

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

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

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

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.

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.

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. The Kazakh tenge is used as collateral.

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.

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

The trading limit for a Brokerage Firm does not depend on the size of the collateral and is set using the ChangeBFLimit command. Also, the trading limit of the Brokerage Firm is changed to the amount of profit or loss determined during the evening clearing session (variation margin and fees).

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

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

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

The SPECTRA system allows to set up the additional limits on client trading operations, i.e. prohibitions, when it is possible to prohibit opening positions and placing orders for a certain client (or for all clients), a certain instrument (or for all instruments) or a certain underlying asset (or for all underlying assets). To perform such actions, the gateway provides the FutChangeClientProhibit method.

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:

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

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, despite the availability of trading system.

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

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

To transfer a position from one clearing register to another, a clearing participant should add a transaction TransferClientPosition 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 UIN (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 instruments).

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

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

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

This will be done in the following steps:

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

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

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

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

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

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

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

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

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

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

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

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

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

The codes with strike "-10":

The codes with strike "0":

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

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

Futures trades reports 'f04', 'f04cl':

Options trades reports 'o04', 'o04cl':

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

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

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

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

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

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

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

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

Figure 1. Gateway architecture

Download the latest gateway software version from. The installation file's name is 'setup_SpectraCGate_x64_vx.x.x.x .exe', where x.x.x.x is the software version number, for example 6.6.0.186

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

Figure 2. Installation start

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

Figure 3. Destination folder

The default destination folder is C:\KASE\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 4. Select components to install

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

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

Figure 5. Custom install

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

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

Figure 6. Select an address to connect

Select the trading system to which you want to connect (production, test, 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.

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:

Figure 7. 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 8. Enter username and password

Enter username and password for the connection selected in the previous step.

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 9. 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 10. Starting installation

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

Figure 11. Finishing installation

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

The distribution kit for Linux OS consists of installation script ('install.sh') and archive file 'tar.gz' (for example, 'cgate-1.3.9.8.x86_64.tar.gz'); the archive file contains loadable modules 'cgate' and 'cgate_java', files 'include', documentation files and test examples.

Installation order:

The reference information includes the following data:

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

Trade information includes:

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

Snapshots of active orders are sent with 2 minute interval in 'FORTS_USERORDERBOOK_REPL' stream.

Includes the following:

Position information

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

That group includes the streams providing the following additional functions:

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

To send a command, you should create a publisher with parameters 'NAME = FORTS_SRV', '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.

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

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

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

Please pay attention to the two details:

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

LocalTimeField=<field
  name>

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

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

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

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

The connection activity monitoring algorithm is as following:

The order cancellation conditions are as following:

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

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

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

The command is not included into transaction fee.

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

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:

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:

Binding of instruments to matchings may change when trading session changes.

New algorithm for receiving trade data

There is only one orders matching module In the TS SPECTRA version 6.3,and old replication streams (without partitioning by matchings) are left for backward compatibility. But old streams will be deleted in future versions of the system, So, we recommend that users rebuild their systems to work with new data streams. Also two new commands 'MoveOrder' (msgid=438) and 'DelOrder' (msgid=436) was added to TS version 6.3. These commands should be used to move and delete orders for futures and options in the trading system with several matchings.

Types of data streams:

The table below shows the gradation of streams by type:

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

Figure 12. Connection scheme

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

General recommendations

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

• establish alternative connections

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

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

Figure 13. Channel duplication scheme

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

Tables:

Tables:

Tables:

Tables:

Tables:

Tables:

Tables: