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 Date Description of the change Author/Comments
Number
1 2 3 4
WSE Project Team / Official version
2.0 December 2005 -
M.Smetek / based on WARSET spec.
2.01 14.02.06 - Added errors description: Appendix A

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
__________________________________________________________________________________________

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

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

Page 12/25
Warsaw Stock Exchange Schedule 2
__________________________________________________________________________________________

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

Page 13/25
Warsaw Stock Exchange Schedule 2
__________________________________________________________________________________________

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.

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 WSE responsibility / operation

API Client MMTP CAP server WARSET

Application Protocol
Orders MMTP/Data&Tech
Layer
PACIN
Warsaw
CA_IN Stock
Order Entry MMTP/ Tech Exchange
Application Trading
Replies MMTP/Data&Tech System
PACOUT
CA_OUT

MMTP/Tech

API Client
Application

RDF
Market
Market Data Data MMTP/Data&Tech
PACRDFMMTP
Application CA_OUT
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.

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:

Message (Function Send by Send to Result of

code for the Private
Data)
0001 & 0002 - Order CA (CA_IN) CAP (PACIN) -
Entry / Order modification.
0003 - Order cancellation. CA (CA_IN) CAP (PACIN) -
0065 - Command to CA (CA_IN) CAP (PACIN) -
cancel all orders from a
subscriber by the
subscriber.
0080 - Command to enter CA (CA_IN) CAP (PACIN) -
a request for quote.
0100 - Trade cancellation
CAP CA (CA_OUT) Surveillance command to
notice. (PAC_OUT) cancel a trade
0101 - Group state CAP CA (CA_OUT) stock group state change or
change notice. (PAC_OUT) a system interruption
0102 - Group state CAP CA (CA_OUT) system interruption
change notice. (PAC_OUT)
0103 - Trade creation CAP CA (CA_OUT) Surveillance command to
notice. (PAC_OUT) create a trade
0104 – MRN and morning CAP CA (CA_OUT) beginning and end of the
messages transmission (PAC_OUT) transmission – send by
notice-begin and end.
system
0105 – Execution notice: CAP CA (CA_OUT) order matching leading to
order matched. (PAC_OUT) trade creation
0106 - Stock state change CAP CA (CA_OUT) stock changing state
notice. (PAC_OUT) outside of its group's
normal behavior
0138 - Order elimination. CAP CA (CA_OUT) order elimination "by the
(PAC_OUT) system," as opposed to
order elimination as a result

Page 17/25
Warsaw Stock Exchange Schedule 2
__________________________________________________________________________________________

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 CAP CA (CA_OUT) Surveillance request to
orders. (PAC_OUT) retransmit a subscriber's
order book
0144 - Error message. CAP CA (CA_OUT) any invalid incoming
(PAC_OUT) message
0172 - Confirmation of the CAP CA (CA_OUT) valid order entry, order
order creation, modification (PAC_OUT) modification, or order
or cancellation
cancellation
0175 - Confirm global CAP CA (CA_OUT) - Surveillance command to
cancellation of all orders (PAC_OUT) cancel all orders in the
from a subscriber.
book from a subscriber

- Subscriber command to
cancel all orders in the
book from the subscriber
0191 - Confirmation of CAP CA (CA_OUT) request for quote
command to enter a (PAC_OUT)
request for quote.
0230 -Trade declaration CA (CA_IN) CAP (PACIN) -
entry
0231 - Trade cancellation CA (CA_IN) CAP (PACIN) -
0234 - TCS Want to match CAP CA (CA_OUT) TCS trade entry
trade (PAC_OUT)
0430 – Notice of TCS CAP CA (CA_OUT) TCS trade entry
trade entry (PAC_OUT)
0431 - Notice of TCS CAP CA (CA_OUT) TCS trade entry
trade entry to the other (PAC_OUT)
subscriber.
0432 - Notice of TCS CAP CA (CA_OUT) TCS trade cancellation by
trade cancellation by (PAC_OUT) subscriber
subscriber
0433 - Notice of TCS CAP CA (CA_OUT) TCS trade cancellation by
trade cancellation to the (PAC_OUT) subscriber
other subscriber.
0434 – TCS Trade CAP CA (CA_OUT) TCS trade entry
execution notice (PAC_OUT)
0435 - Notice of TCS CAP CA (CA_OUT) -
declaration cancellation by (PAC_OUT)
the system
0436 - Notice of TCS CAP CA (CA_OUT) -
trade cancellation by the (PAC_OUT)
system to the other
subscriber.
0437 - TCS group stat CAP CA (CA_OUT) TCS stock group state

Page 18/25
Warsaw Stock Exchange Schedule 2
__________________________________________________________________________________________

change notice (PAC_OUT) change

0438 - TCS stock state CAP CA (CA_OUT) TCS stock group state
change notice (PAC_OUT) change
0451 - TCS trade creation CAP CA (CA_OUT) Surveillance command to
notification. (PAC_OUT) create a TCS trade
0452 - TCS trade CAP CA (CA_OUT) Surveillance command to
cancellation notification. (PAC_OUT) cancel a TCS trade
0456 – Trade Already CAP CA (CA_OUT) TCS Want to match trade
matched (PAC_OUT)
0457 – Notice of TCS CAP CA (CA_OUT) TCS trade entry with
trade entry to all (PAC_OUT) counterpart blank
subscribers
All the public market data 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 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

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