Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

WARsaw Stock Exchange Trading System
___________________________________________________________________

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 Schedule 2 __________________________________________________________________________________________

Contents

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

Page 3/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

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.

Page 4/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

DOCUMENT HISTORY
Version Number 1 2.0 2.01 Date 2 December 2005 14.02.06 - Added errors description: Appendix A Description of the change 3 Author/Comments 4 WSE Project Team / Official version M.Smetek / based on WARSET spec.

Page 5/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

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.

Page 6/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

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.

Page 7/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

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

Page 8/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

4. 5.

6. 7. 8.

specific, detailed elements of Customer router configuration, associated with ensuring appropriate security level. Upon completing the preparations and passing positive connection tests, Customer will make his decision on using the connection. It is Customer responsibility to administer its own router, to ensure protection of Customer router, network and/or other resources against the unauthorized access. Customer is responsible for the maintenance and condition of ISDN link on his side. Connection can be established between Customer’s Applications (Customer site) and WSE CAP server (Certified Access Point – WSE backup site). 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-todate 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

Page 9/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

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.

Page 10/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

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”

Page 11/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

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,

MMTP Client

ACCESS POINT
MMTP OUT MMTP IN

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 feed from the MMTP server to the MMTP client. application message

Page 12/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

-

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

application

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”

Page 13/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

II.3. Installation, Precautions.

Administration,

Limitations

and

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.

Page 14/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

III. Data Flow.
III.1. Overview of CAP architecture.
The following diagrams illustrate the CAP basic architecture:

Customer responsibility / operation
API Client Application MMTP Protocol Layer CA_IN Order Entry Application
MMTP/ Tech MMTP/Data&Tech

WSE responsibility / operation
CAP server WARSET

Orders

MMTP/Data&Tech

PACIN

Replies
CA_OUT

PACOUT

Warsaw Stock Exchange Trading System

MMTP/Tech

API Client Application RDF Market Market Data Data Application
MMTP/Data&Tech

CA_OUT
M MMTP/ Tech

PACRDFMMTP

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.
Page 15/25

-

-

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

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”

Page 16/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

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:

Entry / Order modification. 0003 - Order cancellation. 0065 - Command to cancel all orders from a subscriber by the subscriber. 0080 - Command to enter a request for quote. 0100 - Trade cancellation notice.

Message (Function Send by code for the Private Data) 0001 & 0002 - Order CA (CA_IN) CA (CA_IN) CA (CA_IN)

Send to

Result of

CAP (PACIN) CAP (PACIN) CAP (PACIN)

-

CA (CA_IN)

CAP (PACIN)

-

CAP (PAC_OUT) 0101 - Group state CAP change notice. (PAC_OUT) 0102 - Group state CAP change notice. (PAC_OUT) 0103 - Trade creation CAP notice. (PAC_OUT) 0104 – MRN and morning CAP messages transmission (PAC_OUT)
notice-begin and end. 0105 – Execution notice: order matched.

CA (CA_OUT) Surveillance command to cancel a trade CA (CA_OUT) stock group state change or a system interruption CA (CA_OUT) system interruption CA (CA_OUT) Surveillance command to create a trade CA (CA_OUT) beginning and end of the transmission – send by system CA (CA_OUT) order matching leading to trade creation CA (CA_OUT) stock changing state outside of its group's normal behavior CA (CA_OUT) order elimination "by the system," as opposed to order elimination as a result

CAP (PAC_OUT) 0106 - Stock state change CAP notice. (PAC_OUT)
0138 - Order elimination.

CAP (PAC_OUT)

Page 17/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

0143 - Retransmitted orders. 0144 - Error message.

CAP (PAC_OUT)

CA (CA_OUT)

CAP (PAC_OUT) 0172 - Confirmation of the CAP order creation, modification (PAC_OUT)
or cancellation 0175 - Confirm global cancellation of all orders from a subscriber.

CA (CA_OUT) CA (CA_OUT)

CAP (PAC_OUT)

CA (CA_OUT)

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 Surveillance request to retransmit a subscriber's order book any invalid incoming message valid order entry, order modification, or order cancellation - Surveillance command to cancel all orders in the book from a subscriber

0191 - Confirmation of command to enter a request for quote. 0230 -Trade declaration entry 0231 - Trade cancellation 0234 - TCS Want to match trade 0430 – Notice of TCS trade entry 0431 - Notice of TCS trade entry to the other subscriber. 0432 - Notice of TCS trade cancellation by subscriber 0433 - Notice of TCS trade cancellation to the other subscriber. 0434 – TCS Trade execution notice 0435 - Notice of TCS declaration cancellation by the system 0436 - Notice of TCS trade cancellation by the system to the other subscriber. 0437 - TCS group stat

CAP (PAC_OUT) CA (CA_IN) CA (CA_IN) CAP (PAC_OUT) CAP (PAC_OUT) CAP (PAC_OUT) CAP (PAC_OUT) CAP (PAC_OUT) CAP (PAC_OUT) CAP (PAC_OUT) CAP (PAC_OUT) CAP

- Subscriber command to cancel all orders in the book from the subscriber CA (CA_OUT) request for quote CAP (PACIN) -

CAP (PACIN) CA (CA_OUT) TCS trade entry CA (CA_OUT) TCS trade entry CA (CA_OUT) TCS trade entry CA (CA_OUT) TCS trade cancellation by subscriber CA (CA_OUT) TCS trade cancellation by subscriber CA (CA_OUT) TCS trade entry CA (CA_OUT) CA (CA_OUT) -

CA (CA_OUT) TCS stock group state

Page 18/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________ change notice 0438 - TCS stock state change notice

(PAC_OUT) CAP (PAC_OUT) 0451 - TCS trade creation CAP notification. (PAC_OUT) 0452 - TCS trade CAP cancellation notification. (PAC_OUT) 0456 – Trade Already CAP matched (PAC_OUT) 0457 – Notice of TCS CAP trade entry to all (PAC_OUT)
subscribers All the public market data

CA (CA_OUT) CA (CA_OUT) CA (CA_OUT) CA (CA_OUT)

change TCS stock group state change Surveillance command to create a TCS trade Surveillance command to cancel a TCS trade TCS Want to match trade

CA (CA_OUT) TCS trade entry with counterpart blank

CAP CA (CA_OUT) orders, trades, (PACRDFMMTP 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”

Page 19/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

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,

Page 20/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

• • •

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.

Page 21/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

• •

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

Page 22/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

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.

Page 23/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________

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

Page 24/25

Warsaw Stock Exchange Schedule 2 __________________________________________________________________________________________ 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

Page 25/25