isv zal nr 2 do nr 3 MMTP

8/14/2019 isv zal nr 2 do nr 3 MMTP

http://slidepdf.com/reader/full/isv-zal-nr-2-do-nr-3-mmtp 1/25

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

WAR saw S tock E xchange T rading System




__________________________________________________________________________________________

/25

Contents

I. INTRODUCTION ........................................................................6II. TECHNICAL OVERVIEW. ............................................................8III. DATA FLOW. .........................................................................15IV. 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

VersionNumber

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 AM.Smetek / based on WARSET spec.




__________________________________________________________________________________________

/25

I. Introduction

I.1. Purpose.

The purpose of this document is to describe some of the basic usage questionsconcerning the Warsaw Stock Exchange Trading System – Dev. Environmentand development of own applications.

I.2. Document scope.

This document is designed to provide an initial description of technical access toWARSET. 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 andRegulations of the Stock Exchange, Detailed Rules of Trading as well as resolutionsof 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 theWARSET system,

CA – Customer application, the term used alternately with the SLE,

CA_IN - CA communication process responsible for transmitting Customer OutgoingData to Trading System,

CA_OUT - CA communication process responsible for receiving Incoming TradingData, the term used alternately with the SLC - public market data application

HUB – The component of WARSET, providing message handling and routingfunctions.

DIFF – A module responsible for distribution of stock exchange messages

HUB subscriber – Logical access to a CAP - member profile. The orders flow isrouted 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 flowis 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 beactivated by Customer’s router.

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

3. The configuration or reconfiguration of the Customer access router will have tobe made in coordination and consultation with WSE IT Department, which will

present recommended Cisco router configuration as the model, example partof the Customer router configuration. WSE reserves the right to require




__________________________________________________________________________________________

/25

specific, detailed elements of Customer router configuration, associated withensuring 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 unauthorizedaccess.

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

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

8. WSE reserves the right to refuse the connection or disconnect Customer’sApplications from WSE CAP server in case of any threat to the WSE WARSETSystem.

B.Technical description

1. General security terms and conditions

On its part WSE applies the communication safeguards aimed at ensuring its ownsecurity and preventing the unauthorized access to the data.

In order to reduce Customer’s risk of losing the data, unauthorized access to thedata, interfering into the transmitted data and other unauthorized access, Customeris obliged to ensure the filtering, separation and ensuring the maximum security ofthe 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, itspossible use should be the subject of separate technical arrangements with the ITDepartment of WSE.WSE relies on Cisco to supply suitable combinations of up-to-date router hardwarewith 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 byWSE,

• Customer must dedicate one ISDN channel (ISDN logical interface) for exclusivecommunication with WSE Test Environment. This channel (ISDN logical interface)must not be used by any other device, application or data stream. Also, thisdedicated ISDN logical interface on a Customer’s router has to be configured ascalling interface exclusively. Incoming ISDN connection attempts should berejected 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 shouldbe 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 connectionverification procedure. The ISDN number will be automatically verified during anattempt to make the connection and any expected change in that number must beformally 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 longerperiods of link idle time, Customer is obliged to test (at least once a week) theconnection – simple test should concern sending (by PING utility) about 50 packets100 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. TheCustomer’s Applications server address will be accessed by WSE through NATconfigured on the Customer’s router. The actual address of Customer’s Applicationsserver 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 andmeasures and their compliance with the WSE requirements.The basis to determine the compliance of the technical means provided by Customerwith the WSE IT system concerns:

• performing the installation tests,

• failure-free and collision-free operation of the technical means provided byCustomer 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 technicalmeans,

• 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 AccessPoint server, which uses the MMTP protocol. The CAP provides a member firmwith a single access point to the WARSET architecture and the Warsaw centraltrading services.




__________________________________________________________________________________________

/25

The CAP provides secure communications to the WARSET via a widearea network. The CAP also performs compression, encryption, authentication,and session management functions for transmitting messages between theorder message/market data applications and the WARSET. The CAP isspecially adapted for the connection of client order entry and market data

applications to the WARSET. However the CAP encryption method is limited to40 bits DES and in the event of using any lines not fully controlled by WSE itselfor its direct telecommunication contractor VPN technology has to increase theCAP 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 theCAP receives order replies from the central exchange and forwards themto the appropriate member’s order entry application. The CAP alsoreceives market data from the central exchange and forwards it tomember’s market data applications. The CAP uses session managementfunctions to send and receive these messages. The Cap’s access pointsare PACIN and PACOUT, used for ordering entry/reply messages betweenmember and WSE Central Trading Engine, and RDF for broadcastingmessages (market data ) coming from DIFF (Data Distribution System – part of central services of WARSET).

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

II.2.1. Public data.

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

Client application should process messages that are described in the relateddocument.

► 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-pointconnection 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 relateddocument.

► 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, thesubscriber 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 feedtransmitted 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 applicationmessage feed from the MMTP server to the MMTP client.

Furthermore, both the MMTP IN and MMTP OUT paths are bi-directional. Forexample, 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 andPrecautions.

The Customer is fully responsible for the preparation of their facilities, design,equipment purchase, initial configuration in close co-operation with WSE, designatingown qualified personnel.The Customer will be contacted by WSE Systems technicians in order to co-ordinateand 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 incharge 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 servicesupport 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 massageformat, order entry messages from a Customer Application, compressesand encrypts them and sends them to WARSET,

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

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

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

API ClientApplication

Order EntryApplication

MMTPProtocolLayer

CAP server

API Client

Application

MarketDataApplication

WARSET

WarsawStock ExchangeTradingSystem

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, PACRDFMMTPshould be defined by WSE and will make available to Customer during theaccess preparation phase,

- Communication between the CA and CAP is based on the Client – serverarchitecture, where the Client is the Customer’s application, and theservers 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 exchangedata and information or technical messages (acknowledgement ofthe request, synchronization messages, etc.).

► For more details, refer to:

„MMTP TECHNICAL SPECIFICATIONS”




__________________________________________________________________________________________

/25

III.3. Data messages exchanged between CustomerApplication and WARSET.

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

Public data (market data) messages are sent using a point-to-point connectionvia CAP (on the “out path” via PACRDFMMTP) to the Customer's market dataapplication (CA).

Customer Application (CA) should process messages that are described in therelated document.

The data messages exchanged between CA and WARSET are the following:

Message (Functioncode for the PrivateData)

Send by Send to Result of

0001 & 0002 - OrderEntry / Order modification.

CA (CA_IN) CAP (PACIN) -

0003 - Order cancellation. CA (CA_IN) CAP (PACIN) -0065 - Command to

cancel all orders from asubscriber by thesubscriber.


0080 - Command to entera request for quote.


0100 - Trade cancellationnotice.

CAP(PAC_OUT)

CA (CA_OUT) Surveillance command tocancel a trade

0101 - Group statechange notice.

CAP(PAC_OUT)

CA (CA_OUT) stock group state change ora system interruption

0102 - Group statechange notice.

CAP(PAC_OUT)

CA (CA_OUT) system interruption

0103 - Trade creation

notice.

CAP

(PAC_OUT)

CA (CA_OUT) Surveillance command to

create a trade0104 – MRN and morning

messages transmissionnotice-begin and end.

CAP(PAC_OUT)

CA (CA_OUT) beginning and end of thetransmission – send bysystem

0105 – Execution notice:order matched.

CAP(PAC_OUT)

CA (CA_OUT) order matching leading totrade creation

0106 - Stock state changenotice.

CAP(PAC_OUT)

CA (CA_OUT) stock changing stateoutside of its group'snormal behavior

0138 - Order elimination. CAP

(PAC_OUT)

CA (CA_OUT) order elimination "by the

system," as opposed toorder elimination as a result




__________________________________________________________________________________________

/25

of an "Annulation order"message from a subscriberThe system can eliminateorders for a variety ofreasons: the orders have

reached their validity date,Surveillance has requestedall orders on a particularstock be deleted, etc

0143 - Retransmittedorders.

CAP(PAC_OUT)

CA (CA_OUT) Surveillance request toretransmit a subscriber'sorder book

0144 - Error message. CAP(PAC_OUT)

CA (CA_OUT) any invalid incomingmessage

0172 - Confirmation of theorder creation, modification

or cancellation

CAP(PAC_OUT)

CA (CA_OUT) valid order entry, ordermodification, or order

cancellation0175 - Confirm global

cancellation of all ordersfrom a subscriber.

CAP(PAC_OUT)

CA (CA_OUT) - Surveillance command tocancel all orders in thebook from a subscriber

- Subscriber command tocancel all orders in thebook from the subscriber

0191 - Confirmation ofcommand to enter arequest for quote.

CAP(PAC_OUT)

CA (CA_OUT) request for quote

0230 -Trade declarationentry


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

tradeCAP(PAC_OUT)

CA (CA_OUT) TCS trade entry

0430 – Notice of TCStrade entry

CAP(PAC_OUT)


0431 - Notice of TCStrade entry to the othersubscriber.

CAP(PAC_OUT)


0432 - Notice of TCStrade cancellation bysubscriber

CAP

(PAC_OUT)

CA (CA_OUT) TCS trade cancellation by

subscriber0433 - Notice of TCS

trade cancellation to theother subscriber.

CAP(PAC_OUT)

CA (CA_OUT) TCS trade cancellation bysubscriber

0434 – TCS Tradeexecution notice

CAP(PAC_OUT)


0435 - Notice of TCSdeclaration cancellation bythe system

CAP(PAC_OUT)

CA (CA_OUT) -

0436 - Notice of TCStrade cancellation by thesystem 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) change0438 - TCS stock state

change noticeCAP(PAC_OUT)

CA (CA_OUT) TCS stock group statechange

0451 - TCS trade creationnotification.

CAP(PAC_OUT)

CA (CA_OUT) Surveillance command tocreate a TCS trade

0452 - TCS tradecancellation notification.

CAP(PAC_OUT)

CA (CA_OUT) Surveillance command tocancel a TCS trade

0456 – Trade Alreadymatched

CAP(PAC_OUT)

CA (CA_OUT) TCS Want to match trade

0457 – Notice of TCStrade entry to allsubscribers

CAP(PAC_OUT)

CA (CA_OUT) TCS trade entry withcounterpart blank

All the public market data CAP(PACRDFMMTP)

CA (CA_OUT) orders, trades,modifications, stock groupstate 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 DevelopmentEnvironment.

• WSE will participate during this phase. A dedicated person from Help DeskSection will monitor the WSE Development Environment system for theduration of the test and certification phase and will be responsible forexecuting 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 theWSE 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 duringthis phase.

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

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

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

• WSE reserves the right to disconnect Member’s Application from WARSETand abandon any authorization in case of the threat to the stock marketsystem.

• 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 TraderStation 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 ofconnection.

→ Operation, security and backup/recovery solutions

Trader Station level:

• In case of a failure of the Workstation, the trader should go to another availableWorkstation.

• 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 environmentfollowing a system failure.

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

- transmission of messages to WARSET,

- reception of messages from WARSET.

• The archiving procedures should include timestamps all events to be preciselydated. 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 CustomerApplication (CA).

→ CA should be able to perform the following functions:

• Secured routing of orders and trade executions routing, including main messagecommunication control and restart,

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

• Filtering of trade executions to selected users,

• To accept the orders from the Trader Station and guarantee the delivery of tradeexecutions, 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 technicalspecifications”.




__________________________________________________________________________________________

/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 andtheir technical and functional compliance with the WSE requirements.The basis to determine the compliance of the Customer’s Application with theWARSET 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 tounclear interpretation of the specification of technical and functional requirements ofWSE as they are expressed in this document.

WSE shall assess the WSE Member’s MMTP connectivity and technical means ofMember only to the following extent:

- meeting the general conditions regarding the technical equipment of theMember as indicated under the respective rules concerning the access toWARSET system,

- “Test scripts” - tests performed in relation to connecting the MemberApplication to WARSET system, compliance of the equipment with therequirements 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 exist1001 Unknown function1002 Forbidden function for subscriber type1003 Group state doesn't allow this function1004 Instrument state doesn't allow this function1005 Quantities must be numeric1006 Price format is not valid1007 A mandatory area is not or bad filled1008 Invalid Hour area format1009 Group not authorized for this subscriber1010 Mandatory field $$ is not filled1011 Field $$ is bad filled

1012 Unknown group of instrument1013 Tick expression format is invalid1014 This instrument doesn't allow this function2003 Order price must be filled for limited orders2004 Order price must not be filled for 'O', 'M' & 'X' orders2005 Quantities must be multiple of traded lot2006 Type of price invalid or not authorized according to stock or GR state

2013 Market price orders not supported by opposite limit2014 Price must be valid against tick table2016 FAK orders forbidden for at best, all or none and Stop-loss orders2018 Invalid Date format2019 Validity date less current

2020 Validity date must be lower than default date2021 Order account type code must be C, N, A or V2023 Buy-Out Orders must have limit price and multiply quantity2025 validity date of FOK, Day or dflt order must not be filled2028 Disclosed or minimum quantity greater than total quantity2030 Minimum quantity forbidden in pre-open except for All or none orders2031 Disclosed quantity too small2032 Disclosed quantity forbidden for FAK, MOO, cross, Best and Stop orders2033 This Subscriber doen't exist2034 Order cannot be captured for CC2035 Only CC can capture an order for another subscriber2036 Order type must be 'A' 'I' 'P' or 'G'2037 Order sequential number must be numeric

2040 Minimum quantity cannot be modified2042 No modification for the order2045 This order is not in the book 2046 Disclosed quantity cannot be greater than total or remaining qty2047 Quantity must be less than 100.000.0002053 Disclosed qty & Min Qty > 0, forbidden for FAK order2055 Trigger price format is invalid2056 invalid Tick table for trigger price2057 Trigger price invalid for order type2058 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 price2061 Trigger price must be > last price or last day price

2064 This Trader does not belong to this Member2066 Origin date greater than current




__________________________________________________________________________________________

2069 Last underlying instr. price is out of limits2070 STOP orders not authorized for SPREADS2071 Price must be > 02072 Foreign firm subscriber must be different from original subscriber2073 Order's type not accepted with allocation2115 Total quantity must be inside the limits

2129 Minimum quantity forbidden for STOP orders2130 Minimum quantity forbidden in pre-opening stage2137 Order price is outside the limits ;2500 Confirmation mandatory for this order2501 Order handled in PreOpening - rejected in Continuous Trading2600 The Member is NOT Market-Maker for this Instrument2601 Buy price must be less or equal to sell price2602 Invalid price publicity type2901 The side of the block must be buy or sell2903 This function is forbidden for the current TCS stock group state2904 This function is forbidden for the current TCS stock state2908 Timer is outside allowed limits2910 The indicator trade must be 1 for a block

2911 The block amount is less than the minimum amount for the TCS group2917 Validity type of block must be day2921 The block account type must be C or N2933 This counterpart subscriber does not exist2934 An block cannot be entered with a counterpart equal to Surveillance2937 The clearer does not exist2940 The link trader-clearer does not exist2941 The price of the block is outside allowed limits2942 The price of the block must be the market price2943 The block amount is higher than maximum block amount allowed3008 No order to delete in the book 3042 HOST ORDER NUMBER cannot be null3043 ORDER DIRECTION INDICATOR must be 'A' or 'V'

3901 Unknown order in book 3907 Displayed quantity is not multiple from trade unit3908 New and Old quantity are equal3909 New Displayed qty greater than disclosed quantity3910 New Displayed quantitye greater than left quantity3922 Order MUST have a hidden Qty in order to change its displayed Qty

isv zal nr 2 do nr 3 MMTP

Documents

Transcript of isv zal nr 2 do nr 3 MMTP