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
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
I. INTRODUCTION ........................................................................6II. TECHNICAL OVERVIEW. ............................................................8III. DATA FLOW. .........................................................................15IV. TEST SCRIPTS AND CERTIFICATION PROCEDURE...............20 APPENDIX A……………...………………………………………24
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.
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.
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.
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
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
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.
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:
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
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.
- 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.
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.).
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.
CA (CA_IN) CAP (PACIN) -
0080 - Command to entera request for quote.
CA (CA_IN) CAP (PACIN) -
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
• 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:
• 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.
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 .
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