WARset Access to Developers

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

___________________________________________________________________

ACCESS FOR DEVELOPERS ___________________________________________________________________

Access to Warsaw Stock

Exchange Trading System –

DEVELOPMENT Environment

___________________________________________________________________

For agreements with access limited to Dev.

Environment only

Version 2.01– February 2006

prepared by WSE IT Department

WARsaw Stock Exchange Trading System


/25

Contents I. INTRODUCTION ........................................................................6 II. TECHNICAL OVERVIEW. ............................................................8 III. DATA FLOW. .........................................................................15 IV. TEST SCRIPTS AND CERTIFICATION PROCEDURE...............20 APPENDIX A……………...………………………………………24


/25

Warsaw Stock Exchange Disclaimer

Whilst reasonable care has been taken to ensure the details contained here are accurate and not misleading at the time of preparation, WSE is not responsible for any errors or omissions contained in this document. WSE reserves the right to treat specifications contained in this document as the subject to the later change.

This document contains information confidential and proprietary to Warsaw Stock Exchange, and may not be reproduced, disclosed or used in whole or part, in any manner, without the express prior written consent of WSE.


/25

DOCUMENT HISTORY

Version Number

Date Description of the change Author/Comments

1 2 3 4

2.0 December 2005 - WSE Project Team / Official version

2.01 14.02.06 - Added errors description: Appendix A M.Smetek / based on WARSET spec.


/25

I. Introduction I.1. Purpose.

The purpose of this document is to describe some of the basic usage questions concerning the Warsaw Stock Exchange Trading System – Dev. Environment and development of own applications.

I.2. Document scope.

This document is designed to provide an initial description of technical access to WARSET. Topics covered include:

- The main characteristics of the technical architecture.

- Detailed description of the data flow.

- Test & Certification Procedure.

I.3. Related Documentation This document can be used in conjunction with:

- “MMTP Technical Specification”, - “Market Information Stream” – description of the public market data messages, - “SLE Messages” – description of the order entry/reply messages, - “Detailed Exchange Trading Rules”.

The rules of trading at the Warsaw Stock Exchange are determined in: Rules and Regulations of the Stock Exchange, Detailed Rules of Trading as well as resolutions of the Surveillance and Management Board of the Stock Exchange.


/25

DEFINITIONS: WARSET – Warsaw Stock Exchange Trading system, CAP – access server that compresses, encrypts and stores data passing between the Customer and WSE Trading System. The server being the connecting unit to the WARSET system, CA – Customer application, the term used alternately with the SLE, CA_IN - CA communication process responsible for transmitting Customer Outgoing Data to Trading System, CA_OUT - CA communication process responsible for receiving Incoming Trading Data, the term used alternately with the SLC - public market data application HUB – The component of WARSET, providing message handling and routing functions. DIFF – A module responsible for distribution of stock exchange messages HUB subscriber – Logical access to a CAP - member profile. The orders flow is routed to and from the trading engines via a central point, called the HUB. DIFF subscriber – Logical access to a CAP – market data profile. The market flow is received from the trading engines via DIFF module.


/25

II. TECHNICAL OVERVIEW. II.1. ARCHITECTURE DESCRIPTION.

Note: WSE reserves that this Chapter contains only the basic information

regarding the technical conditions of the connection for DEV Environment. The detailed information and technical specifications can be a subject of separate instructions issued by WSE to the Customer. The technical parameters specific to individual installations or connections shall be defined prior to the installation according to the arrangements made between the IT Department of WSE and the Customer. The parameters specific to individual installations or connections shall be defined prior to the installation under the working procedure between the IT Department of WSE and Customer.

TECHNICAL CONDITIONS FOR ACCESS TO WSE DEVELOPMENT ENVIRONMENT ISDN connection. NOTE: Special arrangements would need to be made if any other connections are to be used. Please contact WSE for further details. A. Basic rules.

The following rules of using Test Environment connection apply: 1. Customer incurs the costs of the subscription fee (on his side) and installation

(on his side) of the ISDN connection to WSE. ISDN connection will be activated by Customer’s router.

2. The connections to the Test Environment are made to the back-up computer center of WSE located in PKiN, at Pl. Defilad 1 Street, in Warsaw. This connection is made by the appropriately configured CISCO router and one digital ISDN channel (B) 64 Kb.

3. The configuration or reconfiguration of the Customer access router will have to be made in coordination and consultation with WSE IT Department, which will present recommended Cisco router configuration as the model, example part of the Customer router configuration. WSE reserves the right to require


/25

specific, detailed elements of Customer router configuration, associated with ensuring appropriate security level.

4. Upon completing the preparations and passing positive connection tests, Customer will make his decision on using the connection.

5. It is Customer responsibility to administer its own router, to ensure protection of Customer router, network and/or other resources against the unauthorized access.

6. Customer is responsible for the maintenance and condition of ISDN link on his side.

7. Connection can be established between Customer’s Applications (Customer site) and WSE CAP server (Certified Access Point – WSE backup site).

8. WSE reserves the right to refuse the connection or disconnect Customer’s Applications from WSE CAP server in case of any threat to the WSE WARSET System.

B.Technical description

1. General security terms and conditions On its part WSE applies the communication safeguards aimed at ensuring its own security and preventing the unauthorized access to the data. In order to reduce Customer’s risk of losing the data, unauthorized access to the data, interfering into the transmitted data and other unauthorized access, Customer is obliged to ensure the filtering, separation and ensuring the maximum security of the transmission on its side.

2. Hardware configuration terms and conditions.

Hardware configuration recommended by WSE is Cisco up-to-date router with up-to-date IOS operating system as well. If Customer has a different equipment, its possible use should be the subject of separate technical arrangements with the IT Department of WSE. WSE relies on Cisco to supply suitable combinations of up-to-date router hardware with IOS operation system versions. • Customer’s router used to connect to WSE must support NAT (Network Address

Translation), • Customer’s router must support CHAP protocol, which will be used for

authentication purposes. Passwords for CHAP authentication will be provided by WSE,

• Customer must dedicate one ISDN channel (ISDN logical interface) for exclusive communication with WSE Test Environment. This channel (ISDN logical interface) must not be used by any other device, application or data stream. Also, this dedicated ISDN logical interface on a Customer’s router has to be configured as calling interface exclusively. Incoming ISDN connection attempts should be rejected by logical ISDN interface mentioned.

• ISDN CLIP service ( Calling Line Identity Presentation) must be set to ON. Dedicated, constant ISDN number of Customer presented to WSE router should be transmitted by Customer’s ISDN telephone exchange as open and officially


/25

notified to the IT Department of WSE. It will be the part of the connection verification procedure. The ISDN number will be automatically verified during an attempt to make the connection and any expected change in that number must be formally agreed with the IT Department of WSE in advance.

3. Periodical test of the connection

In order to prevent problems with functioning of the ISDN connection after longer periods of link idle time, Customer is obliged to test (at least once a week) the connection – simple test should concern sending (by PING utility) about 50 packets 100 bytes long, from Customer’s application server to CAP server on WSE site, which should activate the ISDN link for duration time defined in the configuration.

4. IP addresses The IP addresses used for ISDN connections will be defined by WSE during detailed technical arrangements between Customer and the IT Department of WSE. The Customer’s Applications server address will be accessed by WSE through NAT configured on the Customer’s router. The actual address of Customer’s Applications server in the internal network of Customer does not have to be known to WSE. C. Acceptance procedure. The acceptance procedure concerns the evaluation of the technical means and measures and their compliance with the WSE requirements. The basis to determine the compliance of the technical means provided by Customer with the WSE IT system concerns: • performing the installation tests, • failure-free and collision-free operation of the technical means provided by

Customer with the WSE IT system. This principle applies especially to determining the practical incompliance due to: • different interpretation of the standards used by the manufacturers of technical

means, • not meeting the standards by the technical means of Customer • unclear interpretation of the specification of technical requirements of WSE.

II.2. ACCESS POINT.

The Client application connects to the WARSET via CAP - Certified Access Point server, which uses the MMTP protocol. The CAP provides a member firm with a single access point to the WARSET architecture and the Warsaw central trading services.


/25

The CAP provides secure communications to the WARSET via a wide area network. The CAP also performs compression, encryption, authentication, and session management functions for transmitting messages between the order message/market data applications and the WARSET. The CAP is specially adapted for the connection of client order entry and market data applications to the WARSET. However the CAP encryption method is limited to 40 bits DES and in the event of using any lines not fully controlled by WSE itself or its direct telecommunication contractor VPN technology has to increase the CAP encryption and authentication facilities.

The main functions of the CAP server are:

- Sending, receiving and caching messages. CAP communications agents (also known as access points) send, receive, and cache routable messages. The CAP receives order entries from a member’s order entry application and sends them to the WARSET, and the CAP receives order replies from the central exchange and forwards them to the appropriate member’s order entry application. The CAP also receives market data from the central exchange and forwards it to member’s market data applications. The CAP uses session management functions to send and receive these messages. The Cap’s access points are PACIN and PACOUT, used for ordering entry/reply messages between member and WSE Central Trading Engine, and RDF for broadcasting messages (market data ) coming from DIFF (Data Distribution System – part of central services of WARSET).

- Providing a security demarcation point between client applications and the central system. When the CAP receives order entry messages from a member, the CAP compresses and encrypts them with a proprietary security key, and sends them to the WARSET. In the opposite direction, when the CAP receives order reply messages and market data messages from the central system, the CAP decrypts them and forwards them to the appropriate client application.

II.2.1. Public data.

Public data (market data) messages are sent using a point-to-point connection via CAP (using MMTP protocol over TCP/IP via “out path” - PACRDFMMTP) to the member’s CAP and then to the member's market data application.

Client application should process messages that are described in the related

document. ► For detailed documentation on the public data, refer to:

“ Market Information Stream”


/25

II.2.2. Private data.

Private data (order entry/reply messages) are sent using a point-to-point connection via CAP (on the “in path” via PACIN and “out path” via PACOUT) to the member’s trading application.

Client application should process messages that are described in the related document. ► For detailed documentation on the private data, refer to:

“ SLE messages”

II.2.3. Main characteristics of the MMTP protocol.

The Client application always initiates the connection. In MMTP protocol terms, the subscriber is the MMTP client. The following terms will be used in this document:

- MMTP client for the HUB subscriber or DIFF subscriber,

- MMTP server for the access point,

Figure 3: MMTP Client

To optimize performance, two separate paths are used for data exchange:

- MMTP client to HUB (via PAC_IN): MMTP IN application message feed transmitted by the MMTP client to the MMTP server.

- HUB (via PAC_OUT) to MMTP client: MMTP OUT application message feed from the MMTP server to the MMTP client.

ACCESS POINT

MMTP Client

MMTP OUT MMTP IN


/25

- DIFF (via PACRDFMMTP) to MMTP client: MMTP OUT application message feed from the MMTP server to the MMTP client.

Furthermore, both the MMTP IN and MMTP OUT paths are bi-directional. For example, the MMTP server can reply to a message from the MMTP client on the MMTP IN path. ► For detailed documentation on the MMTP protocol, refer to:

„MMTP TECHNICAL SPECIFICATIONS”


/25

II.3. Installation, Administration, Limitations and

Precautions. The Customer is fully responsible for the preparation of their facilities, design, equipment purchase, initial configuration in close co-operation with WSE, designating own qualified personnel. The Customer will be contacted by WSE Systems technicians in order to co-ordinate and schedule the following steps:

- Distribution of initial contacts, e-mail addresses, IP addresses passwords, initial configurations and installations,

- Installation of telecommunications lines, if appropriate. The person in charge must be on site.

- Line test, fail-over tests (if appropriate). All hardware must be on site and configured.

- Installation of the software (if appropriate). The Customer will schedule the following steps:

- Network preparation Customer site. - Preparation Access Point devices. - Implementation of trading and/or data feed client application servers with

access to WSE. The WSE will perform the following functions:

- Network preparation, - Management, maintenance and monitoring CAP servers at WSE Access

Point in WSE site, - Management, maintenance and monitoring of network connections.

Depending on the Customer organisation, WSE Helpdesk Office will provide service support for clients.


/25

III. Data Flow. III.1. Overview of CAP architecture. The following diagrams illustrate the CAP basic architecture: Customer responsibility / operation WSE responsibility / operation Orders MMTP/Data&Tech MMTP/ Tech Replies MMTP/Data&Tech

MMTP/Tech

Market Data MMTP/Data&Tech M MMTP/ Tech The CAP uses the following components:

- PACIN is a CAP process that receives, in MMTP/WARSET massage format, order entry messages from a Customer Application, compresses and encrypts them and sends them to WARSET,

- PACOUT is a CAP process that receives, in MMTP/WARSET message format, order reply messages from WARSET, decrypts and decompresses them, and sends them to appropriate order entry Customer Application,

- RDF is the CAP process that receives Market Data messages coming from WARSET,

- PACRDFMMTP is a thread of the RDF process that transmits, in MMTP/WARSET message format, messages decrypted and stored by RDF to the Customer’s Market Data Application.

API Client Application Order Entry Application

MMTP Protocol Layer

CAP server

API Client Application Market Data Application

WARSET Warsaw Stock Exchange Trading System

PACIN

PACOUT

PACRDFMMTP

RDF

CA_IN

CA_OUT

CA_OUT


/25

III.2. Description of Client’s Communication with CAP.

- A dialogue between the Customer Application (CA) and CAP components is accomplished by means of the TCP/IP communication protocol,

- Available ports for communication with PACIN, PACOUT, PACRDFMMTP

should be defined by WSE and will make available to Customer during the access preparation phase,

- Communication between the CA and CAP is based on the Client – server

architecture, where the Client is the Customer’s application, and the servers are the PACIN, PACOUT and PACRDFMMTP,

- As it is shown in the drawing, there may be either outgoing as well as

incoming messages from and to the CAP components: • Customer Outgoing Data: messages containing the orders data and

technical message (acknowledgement of the request, synchronization messages, etc.),

• Customer Incoming Data: messages containing the stock exchange data and information or technical messages (acknowledgement of the request, synchronization messages, etc.).

► For more details, refer to:

„MMTP TECHNICAL SPECIFICATIONS”


/25

III.3. Data messages exchanged between Customer

Application and WARSET.

Private data (order entry/reply messages) are sent using a point-to-point connection via CAP (on the “in path” via PACIN and “out path” via PACOUT) to the Customer’s trading application (CA).

Public data (market data) messages are sent using a point-to-point connection via CAP (on the “out path” via PACRDFMMTP) to the Customer's market data application (CA). Customer Application (CA) should process messages that are described in the related document.

The data messages exchanged between CA and WARSET are the following: Message (Function code for the Private Data)

Send by Send to Result of

0001 & 0002 - Order Entry / Order modification.

CA (CA_IN) CAP (PACIN) -

0003 - Order cancellation. CA (CA_IN) CAP (PACIN) - 0065 - Command to cancel all orders from a subscriber by the subscriber.


0080 - Command to enter a request for quote.


0100 - Trade cancellation notice.

CAP (PAC_OUT)

CA (CA_OUT) Surveillance command to cancel a trade

0101 - Group state change notice.

CAP (PAC_OUT)

CA (CA_OUT) stock group state change or a system interruption

0102 - Group state change notice.

CAP (PAC_OUT)

CA (CA_OUT) system interruption

0103 - Trade creation notice.

CAP (PAC_OUT)

CA (CA_OUT) Surveillance command to create a trade

0104 – MRN and morning messages transmission notice-begin and end.

CAP (PAC_OUT)

CA (CA_OUT) beginning and end of the transmission – send by system

0105 – Execution notice: order matched.

CAP (PAC_OUT)

CA (CA_OUT) order matching leading to trade creation

0106 - Stock state change notice.

CAP (PAC_OUT)

CA (CA_OUT) stock changing state outside of its group's normal behavior

0138 - Order elimination. CAP (PAC_OUT)

CA (CA_OUT) order elimination "by the system," as opposed to order elimination as a result


/25

of an "Annulation order" message from a subscriber The system can eliminate orders for a variety of reasons: the orders have reached their validity date, Surveillance has requested all orders on a particular stock be deleted, etc

0143 - Retransmitted orders.

CAP (PAC_OUT)

CA (CA_OUT) Surveillance request to retransmit a subscriber's order book

0144 - Error message. CAP (PAC_OUT)

CA (CA_OUT) any invalid incoming message

0172 - Confirmation of the order creation, modification or cancellation

CAP (PAC_OUT)

CA (CA_OUT) valid order entry, order modification, or order cancellation

0175 - Confirm global cancellation of all orders from a subscriber.

CAP (PAC_OUT)

CA (CA_OUT) - Surveillance command to cancel all orders in the book from a subscriber - Subscriber command to cancel all orders in the book from the subscriber

0191 - Confirmation of command to enter a request for quote.

CAP (PAC_OUT)

CA (CA_OUT) request for quote

0230 -Trade declaration entry


0231 - Trade cancellation CA (CA_IN) CAP (PACIN) - 0234 - TCS Want to match trade

CAP (PAC_OUT)

CA (CA_OUT) TCS trade entry

0430 – Notice of TCS trade entry

CAP (PAC_OUT)


0431 - Notice of TCS trade entry to the other subscriber.

CAP (PAC_OUT)


0432 - Notice of TCS trade cancellation by subscriber

CAP (PAC_OUT)

CA (CA_OUT) TCS trade cancellation by subscriber

0433 - Notice of TCS trade cancellation to the other subscriber.

CAP (PAC_OUT)

CA (CA_OUT) TCS trade cancellation by subscriber

0434 – TCS Trade execution notice

CAP (PAC_OUT)


0435 - Notice of TCS declaration cancellation by the system

CAP (PAC_OUT)

CA (CA_OUT) -

0436 - Notice of TCS trade cancellation by the system to the other subscriber.

CAP (PAC_OUT)

CA (CA_OUT) -

0437 - TCS group stat CAP CA (CA_OUT) TCS stock group state


/25

change notice (PAC_OUT) change 0438 - TCS stock state change notice

CAP (PAC_OUT)

CA (CA_OUT) TCS stock group state change

0451 - TCS trade creation notification.

CAP (PAC_OUT)

CA (CA_OUT) Surveillance command to create a TCS trade

0452 - TCS trade cancellation notification.

CAP (PAC_OUT)

CA (CA_OUT) Surveillance command to cancel a TCS trade

0456 – Trade Already matched

CAP (PAC_OUT)

CA (CA_OUT) TCS Want to match trade

0457 – Notice of TCS trade entry to all subscribers

CAP (PAC_OUT)

CA (CA_OUT) TCS trade entry with counterpart blank

All the public market data CAP (PACRDFMMTP)

CA (CA_OUT) orders, trades, modifications, stock group state change, ...etc,

► For detailed documentation on the private data, refer to:

“ SLE messages”

► For detailed documentation on the public data, refer to:

“ Market Information Stream”


/25

IV. Test Scripts and Certification Procedure. In details proposed conditions are as hereunder:

• Test and certification phase will be done within the WSE Development Environment.

• WSE will participate during this phase. A dedicated person from Help Desk Section will monitor the WSE Development Environment system for the duration of the test and certification phase and will be responsible for executing any “WSE initiated” activity.

• WSE will ensure environment for Test Scripts purpose at Member’s request. • Test Scripts will be executed in the WARSET Dummy Market available in the

WSE Test Environment – meaning that WSE selects securities (for “Continuous trading (quotations)” – i.e. Shares of WIG20 index, MidWIG shares, other shares, Bonds, etc.; for “Single price quotations with two fixings” for “Packet transactions”, etc) and convenes with Member to use them during this phase.

• Certification Procedure takes place in the WSE Test Environment and Member will be authorized to have an access to all of the WSE Test Markets.

• WSE reserves the right to abandon the Certification Procedure in case of occurrence of any errors, which cause any irregularities.

• The occurrence of any errors will cause to start certification phase from the beginning.

• WSE reserves the right to disconnect Member’s Application from WARSET and abandon any authorization in case of the threat to the stock market system.

• Test scripts will be provided at least 2 weeks before commencement date.

IV.1. Technical recommendations for Customer Application (CA).

→ Trader Authentication (Logon)

The Trader Station authentication should be the following at least:

• session between Trader Station and CA should be authenticated at the logon, via use of a userID and password,

• The userID can coincide with the Workstation OS account ID,

• The password should NOT be the Windows password, but a specific Trader Station application-related password (however the Trader may choose the same, it’s his responsibility). The password should be encrypted during transmission.

The following minimal rules should be applicable to the trader authentication:

• At least 5 characters,


/25

• It should differ from the 3 previously used passwords,

• It must be changed periodically,

• 3 sequentially sent wrong passwords will reject all the other attempts of connection.

→ Operation, security and backup/recovery solutions

Trader Station level: • In case of a failure of the Workstation, the trader should go to another available

Workstation.

• All data should be anyway kept on the CA server,

CA server level:

• The Customer should have its own CA backup server on an other server box.

• The Customer should be able to restore a reliable operating environment following a system failure.

• The Customer should be able to trace the messages back at each of the following stages:

- transmission of messages to WARSET, - reception of messages from WARSET.

• The archiving procedures should include timestamps all events to be precisely dated. The timestamp should be accurate to within 1/100 of second,

• It is strictly recommended to have data backup procedures and standby plan.

IV.2. Functional recommendations for Customer Application (CA).

→ CA should be able to perform the following functions: • Secured routing of orders and trade executions routing, including main message

communication control and restart,

• Processing, with selected recycling, according to market conditions (e.g. closed market, suspended stock, etc.)

• Filtering of trade executions to selected users,

• To accept the orders from the Trader Station and guarantee the delivery of trade executions, unless it detects an incompatible market format. If so, the user (Trader Station) should immediately receive a reject message.

• Receiving public data flow from WARSET.


/25

• Providing information flows in real time to Trader Station.

• Managing historical data for WARSET.

→ MMTP protocol implementation: The following is the list of the operations that the CA should process:

• Establishing connection.

• Sending orders (or command like cancellation).

• Receiving real time messages.

• Sending, receiving and processing other technical messages.

• Recognizing lack of connection.

• Correct restart and resynchronization management

• Closing session.

They respectively refer to the messages described in the “MMTP technical specifications”.


/25

IV.3. Test scripts. Test scripts will be provided on demand, before final certification. Test scripts will be shared in two phases:

• CA connectivity – Technical Units,

• Trading functions – Functional Units,

IV.4. Certification Procedure. The certification procedure concerns the evaluation of the Customer’s means and their technical and functional compliance with the WSE requirements. The basis to determine the compliance of the Customer’s Application with the WARSET system concerns: • performing the installation tests and the “Test scripts” • failure-free and collision-free co-operation with the WARSET system during the

two weeks at least. This principle applies especially to determining the practical incompliance due to unclear interpretation of the specification of technical and functional requirements of WSE as they are expressed in this document. WSE shall assess the WSE Member’s MMTP connectivity and technical means of Member only to the following extent:

- meeting the general conditions regarding the technical equipment of the Member as indicated under the respective rules concerning the access to WARSET system,

- “Test scripts” - tests performed in relation to connecting the Member Application to WARSET system, compliance of the equipment with the requirements set by WSE under other documents.

NOTE:

Please note that a Customer is responsible to perform any self-assessment to guaranty software capabilities to ensure integrity, stability and performance of the market service.


/25

Appendix A System rejection reasons: 1000 This instrument doesn't exist 1001 Unknown function 1002 Forbidden function for subscriber type 1003 Group state doesn't allow this function 1004 Instrument state doesn't allow this function 1005 Quantities must be numeric 1006 Price format is not valid 1007 A mandatory area is not or bad filled 1008 Invalid Hour area format 1009 Group not authorized for this subscriber 1010 Mandatory field $$ is not filled 1011 Field $$ is bad filled 1012 Unknown group of instrument 1013 Tick expression format is invalid 1014 This instrument doesn't allow this function 2003 Order price must be filled for limited orders 2004 Order price must not be filled for 'O', 'M' & 'X' orders 2005 Quantities must be multiple of traded lot 2006 Type of price invalid or not authorized according to stock or GR state 2013 Market price orders not supported by opposite limit 2014 Price must be valid against tick table 2016 FAK orders forbidden for at best, all or none and Stop-loss orders 2018 Invalid Date format 2019 Validity date less current 2020 Validity date must be lower than default date 2021 Order account type code must be C, N, A or V 2023 Buy-Out Orders must have limit price and multiply quantity 2025 validity date of FOK, Day or dflt order must not be filled 2028 Disclosed or minimum quantity greater than total quantity 2030 Minimum quantity forbidden in pre-open except for All or none orders 2031 Disclosed quantity too small 2032 Disclosed quantity forbidden for FAK, MOO, cross, Best and Stop orders 2033 This Subscriber doen't exist 2034 Order cannot be captured for CC 2035 Only CC can capture an order for another subscriber 2036 Order type must be 'A' 'I' 'P' or 'G' 2037 Order sequential number must be numeric 2040 Minimum quantity cannot be modified 2042 No modification for the order 2045 This order is not in the book 2046 Disclosed quantity cannot be greater than total or remaining qty 2047 Quantity must be less than 100.000.000 2053 Disclosed qty & Min Qty > 0, forbidden for FAK order 2055 Trigger price format is invalid 2056 invalid Tick table for trigger price 2057 Trigger price invalid for order type 2058 Stop price maxi-mini must be >= trigger price ; 2059 Stop price maxi-mini must be <= trigger price ; 2060 Trigger price must be < last price or last day price 2061 Trigger price must be > last price or last day price 2064 This Trader does not belong to this Member 2066 Origin date greater than current


/25

2069 Last underlying instr. price is out of limits 2070 STOP orders not authorized for SPREADS 2071 Price must be > 0 2072 Foreign firm subscriber must be different from original subscriber 2073 Order's type not accepted with allocation 2115 Total quantity must be inside the limits 2129 Minimum quantity forbidden for STOP orders 2130 Minimum quantity forbidden in pre-opening stage 2137 Order price is outside the limits ; 2500 Confirmation mandatory for this order 2501 Order handled in PreOpening - rejected in Continuous Trading 2600 The Member is NOT Market-Maker for this Instrument 2601 Buy price must be less or equal to sell price 2602 Invalid price publicity type 2901 The side of the block must be buy or sell 2903 This function is forbidden for the current TCS stock group state 2904 This function is forbidden for the current TCS stock state 2908 Timer is outside allowed limits 2910 The indicator trade must be 1 for a block 2911 The block amount is less than the minimum amount for the TCS group 2917 Validity type of block must be day 2921 The block account type must be C or N 2933 This counterpart subscriber does not exist 2934 An block cannot be entered with a counterpart equal to Surveillance 2937 The clearer does not exist 2940 The link trader-clearer does not exist 2941 The price of the block is outside allowed limits 2942 The price of the block must be the market price 2943 The block amount is higher than maximum block amount allowed 3008 No order to delete in the book 3042 HOST ORDER NUMBER cannot be null 3043 ORDER DIRECTION INDICATOR must be 'A' or 'V' 3901 Unknown order in book 3907 Displayed quantity is not multiple from trade unit 3908 New and Old quantity are equal 3909 New Displayed qty greater than disclosed quantity 3910 New Displayed quantitye greater than left quantity 3922 Order MUST have a hidden Qty in order to change its displayed Qty

WARset Access to Developers

Documents

Transcript of WARset Access to Developers