TP Fo Trimmed NNF Protocol 9.29
TP Fo Trimmed NNF Protocol 9.29
NSE Confidential
Futures and Options Trading System - Protocol for Non-Neat Front End
Notice
© Copyright National Stock Exchange of India Ltd (NSEIL). All rights reserved. Unpublished rights
reserved under applicable copyright and trades secret laws.
The contents, ideas and concepts presented herein are proprietary and confidential. Duplication
and disclosure to others in whole, or in part is prohibited
2
Futures and Options Trading System - Protocol for Non-Neat Front End
Revision History
Version Pages Changed Description
3
Futures and Options Trading System - Protocol for Non-Neat Front End
Preface
Purpose
This document describes the protocol to be used for Non-NEAT Front end (NNF) to communicate
with the Futures and Options Trading System (FOTS). Thus, it serves as a guide to the NNF
programmers, for developing software that can communicate with FOTS.
Target Audience
This document is written for system designers and programmers of user organisations and third
party software developers, who are responsible for the development of software that interacts
with FOTS.
Organisation of this Document
This document is organised as follows:
Chapters Description
4
Futures and Options Trading System - Protocol for Non-Neat Front End
Chapters Description
Chapter 5 Details the order types, rules and structure of Spread order entry
and the structures of the system responses. It also covers the order
modification, trade modification and cancellation structures for
Spread orders.
Chapter 6 Describes rules and structure of 2L and 3L order entry and the
structures of the system responses. It also covers the trade
modification and cancellation structures for 2L and 3L orders.
Chapter 8 Discusses the end of the trading day activities. It details the
messages, structures and reports related to transmission of header,
data and trailer of Bhavcopy.
Chapter 10 Describes how member systems can directly connect to NSE for
trading, while using existing formats of business messages from NNF
API documents.
5
Futures and Options Trading System - Protocol for Non-Neat Front End
CLI Client
CM Corporate Manager
DL Dealer
DQ Disclosed Quantity
OI Open Interest
OL Odd Lot
OSL Open Strata Link
6
Futures and Options Trading System - Protocol for Non-Neat Front End
PRO Proprietary
RL Regular Lot
SL Stop Loss
ST Special Terms
TM Trading Member
TP Trigger Price
TWS Trader Workstation
VCID Virtual Circuit ID
VSAT Very Small Aperture Terminal
7
Futures and Options Trading System - Protocol for Non-Neat Front End
CONTENTS
CHAPTER 1 INTRODUCTION ...................................................................................................... 14
CHAPTER 2 GENERAL GUIDELINES .......................................................................................... 15
GUIDELINES FOR DESIGNERS ............................................................................................................... 15
GUIDELINES FOR PROGRAMMERS ........................................................................................................ 16
MESSAGE STRUCTURE DETAILS .......................................................................................................... 17
DATA TYPES USED IN MESSAGE STRUCTURE ....................................................................................... 17
MESSAGE HEADER ............................................................................................................................. 18
INNER MESSAGE HEADER ................................................................................................................... 20
BROADCAST PROCESS HEADER ........................................................................................................... 20
ERROR MESSAGE ................................................................................................................................ 21
INVALID MESSAGE LENGTH RESPONSE TRANSCODE ............................................................................ 22
COMMUNICATION NETWORK CONNECTIONS FOR NNF USERS .............................................................. 22
MEMBER GUIDE TO THE GATEWAY ROUTER FUNCTIONALITY .............................................................. 23
CHAPTER 3 LOGON AND DOWNLOAD ..................................................................................... 25
ORDER OF TRANSACTION CODE E XCHANGES DURING LOGON AND LOGOFF .......................................... 25
LOGON REQUEST ................................................................................................................................ 27
LOGON RESPONSE .............................................................................................................................. 30
Logon Confirmation Response ....................................................................................................... 30
Logon Error .................................................................................................................................. 32
SYSTEM INFORMATION DOWNLOAD .................................................................................................... 33
System Information Request ........................................................................................................... 33
System Information Response ........................................................................................................ 34
UPDATE LOCAL DATABASE DOWNLOAD ............................................................................................. 38
Update Local Database Request .................................................................................................... 38
Update Local Database Response .................................................................................................. 40
Partial System Information Response ............................................................................................. 40
Update Local Database Download ................................................................................................ 41
Getting Exchange-defined Portfolio ............................................................................................... 45
Portfolio Request........................................................................................................................... 45
Portfolio Response ........................................................................................................................ 46
MESSAGE DOWNLOAD ........................................................................................................................ 47
Message Download Request .......................................................................................................... 48
Message Download Response ........................................................................................................ 48
LOGOFF REQUEST ............................................................................................................................... 50
LOGOFF CONFIRMATION RESPONSE ..................................................................................................... 51
CHAPTER 4 ORDER AND TRADE MANAGEMENT ................................................................... 52
ORDER ENTRY .................................................................................................................................... 52
Order Types .................................................................................................................................. 52
Order Terms.................................................................................................................................. 53
Rules of Order Entry ..................................................................................................................... 54
Order Entry Request ...................................................................................................................... 55
Order Terms Attributes.................................................................................................................. 64
Rules of Order Entry (when broker is in Closeout Status) ............................................................... 65
Order Entry Response ................................................................................................................... 65
ORDER MODIFICATION ....................................................................................................................... 69
Rules of Order Modification .......................................................................................................... 69
Order Modification Request........................................................................................................... 69
8
Futures and Options Trading System - Protocol for Non-Neat Front End
9
Futures and Options Trading System - Protocol for Non-Neat Front End
10
Futures and Options Trading System - Protocol for Non-Neat Front End
11
Futures and Options Trading System - Protocol for Non-Neat Front End
12
Futures and Options Trading System - Protocol for Non-Neat Front End
13
Futures and Options Trading System - Protocol for Non-Neat Front End
Chapter 1 Introduction
The National Stock Exchange of India Ltd (NSEIL) provides a fully automated screen based
trading system. This enables trading members spread across the length and breadth of India to
trade directly from their offices through an extensive telecommunication network. The system
e principles
of an order driven market, based on price-time priority. For trading the trading members can use
NEAT Front end or Non-NEAT Front end (NNF) to establish a network connection with the
Futures and Options host system of National Stock Exchange (NSE). NNF is a front end, which is
developed and maintained by vendors other than NSE. NSE provides the NNF users with the
design documents of the front end. However, their respective vendors support them and NSE is
not responsible for the performance of NNF.
14
Futures and Options Trading System - Protocol for Non-Neat Front End
15
Futures and Options Trading System - Protocol for Non-Neat Front End
position comes to the first position; the byte in (n-1) position comes to the second
position and so on.
For example, if the value to be sent is 1A2B (hexadecimal), reverse the bytes to 2B1A.
The same applies while receiving messages. So if the value received is 02BC, the actual
value is BC02. Hence, you need to twiddle such data types before sending and after
receiving to ensure that correct data is sent and received.
Note:
Twiddling is required because endian order can be of two different types big and little.
A big-endian representation has a multibyte integer written with its most significant byte
on the left. A little-endian representation, on the other hand, places the most significant
byte on the right. Intel's 80x86 processors and their clones are little endian. Sun's
SPARC, Motorola's 68K, and the PowerPC families are all big endian.
All of the protocol layers in the TCP/IP suite are defined to be big endian. The trading
system uses big-endian order. Hence, if your system uses little-endian order twiddle the
numeric value before sending and after receiving over a TCP/IP connection.
2. All alphabetical data must be converted to upper case before sending to the host. No
NULL terminated strings should be sent to the host end. Instead, terminate strings with
blanks before sending. The strings received from the host end are padded with blanks
and are not NULL terminated.
3. All the structures should be defined in the following manner:
16
Futures and Options Trading System - Protocol for Non-Neat Front End
Field of type CHAR or Unsigned CHAR, or CHAR Arrays should be byte aligned.
Structures of odd size should be padded to an even number of bytes.
All other types of structure members should be word aligned.
4. All numeric data must be set to zero (0) before sending to the host, unless a value is
assigned to it.
5. Whenever the field name is mentioned as Reserved for example: Reserved field in
Broadcast Process Header, it should be mapped to CHAR buffer and initialized to NULL.
Note:
The values of all the constants and transaction codes given in the document are listed in
the Appendix.
The suffix IN in the transaction codes implies that the request is sent from the NNF /
NEAT application to the trading system whereas the suffix OUT implies that the message
is sent from the trading system to NNF / NEAT application.
17
Futures and Options Trading System - Protocol for Non-Neat Front End
Message Header
Each structure is prefaced with a MESSAGE_HEADER. The structure of the MESSAGE_HEADER
is as follows:
The following table provides the brief description of the various fields present in the
MESSAGE_HEADER structure.
18
Futures and Options Trading System - Protocol for Non-Neat Front End
19
Futures and Options Trading System - Protocol for Non-Neat Front End
20
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the BCAST_HEADER
structure.
Note
The machine number is stored in 0th position.
MessageLength This field is set to the length of the entire message, including the
length of the message header.
Error Message
When the Error Code in the MESSAGE_HEADER is not zero, the structure sent is ERROR
RESPONSE. The Error Message will describe the error received. The structure is as follows:
21
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
MS_ERROR_RESPONSE structure.
22
Futures and Options Trading System - Protocol for Non-Neat Front End
Interactive VCID follows a bidirectional path between the NNF and NEAT to host end. All the
interactive / request messages and its respective response follow through this channel. Even the
unsolicited message such as trade message flows from exchange (host end) to the trader
terminal through this channel.
of which default features like IP fragmentation, no QoS etc. continue to be enabled and available
for use by members. Default IP fragmentation a valid feature in the TCP/IP protocol works at
message level and usage of same by one member connection will not block or impact the
messages of other member connections.
BCID follows a unidirectional path which is from the host end to the NNF / NEAT. All the
broadcast data are transmitted through this broadcast circuit from the host end for all the
traders. Since this is a one way connection, the data flow is always from the exchange (host end)
to the trader terminal.
However the members have represented that they are required to try to login on multiple
gateway server sequentially before they are able to successfully login on the Exchange for
trading activity. Thus valuable time is lost by the member for trying to access the Exchange. The
same is more severe during re-login / disconnections faced by the members.
In order to address these queries the Gateway Router Functionality has been proposed to be
implemented.
1. It is now proposed that members will first connect to a gateway router server in the
respective segment details of which will be published by the Exchange.
2. The gateway router server will decide which gateway server is available for the member
and will accordingly provide the details of the allocated gateway server to the member
through the response message.
3. After getting the response message the member will need to connect to the allocated
gateway server.
23
Futures and Options Trading System - Protocol for Non-Neat Front End
Thus, the process of allocating gateway servers becomes Exchange determined and highly
simplified for the member.
The gateway router will decide the gateway server for the member for each trading day in the
following manner:
1. The gateway router will maintain the used capacity of each gateway server. The gateway
router will allocate least used gateway server (according to capacity). The capacity is
based on the no. of messages allotted for each Box Id.
2. If all gateway servers have similar used capacity then a gateway server will be randomly
allocated by the gateway router server.
3. Once a member has been provided session key with gateway server details by gateway
router server, the member is expected to connect and login to the allocated gateway
server at any time during rest of the trading day.
4. If the member gets logged off from the allocated gateway server, then the member has
to request the gateway router server for getting new session key and gateway server
details.
5. A member will be directed to the same gateway server by the gateway router server, once
it has been allocated for the trading day.
6. Though the user will get directed to the same gateway, the user must ask the gateway
router for getting the gateway details and session key as the old session key will be
unique for that particular session and is cleaned up from the gateway once the user gets
logged off.
7. Also, if the gateway has a failure during the day, the user will be allocated a new gateway
server. This will be done transparently for the user by the gateway router server.
At the end of each trading day the gateway router server will clean up the used capacity, and will
have the same capacity (full capacity) available for all gateway servers for the next day.
24
Futures and Options Trading System - Protocol for Non-Neat Front End
25
Futures and Options Trading System - Protocol for Non-Neat Front End
The following sequence explains the order in which the transcodes are sent and received during
log-off process.
Sequence Transaction Code Sent By Received By
No
1 SIGN_OFF_REQUEST_IN NNF Host End
2 SIGN_OFF_REQUEST_OUT Host End NNF
The structure given below is part of Logon request and response structure. It specifies the
markets that are allowed for the trading member to place an order. Note to NNF Developer: Use
any one of following two structures:
Table 5 ST_BROKER_ELIGIBILITY_PER_MKT
Structure Name ST_BROKER_ELIGIBILITY_PER_MKT
Packet Length 2 bytes
Field Name Data Type Size Offset
For Small Endian Machines
Reserved BIT 4 0
26
Futures and Options Trading System - Protocol for Non-Neat Front End
Logon Request
The process by which a trader logs on to the trading system is called Logon Process. User needs
to send the request as per the structure given below for establishing an interactive circuit with
the host end:
Table 6 MS_SIGNON
Structure Name MS_SIGNON
Packet Length 278 bytes
Transaction Code SIGN_ON_REQUEST_IN (2300)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to Message STRUCT 40 0
Header in Chapter 2)
UserID LONG 4 40
Reserved CHAR 8 44
Password CHAR 8 52
Reserved CHAR 8 60
NewPassword CHAR 8 68
TraderName CHAR 26 76
LastPasswordChangeDate LONG 4 102
BrokerID CHAR 5 106
Reserved CHAR 1 111
BranchID SHORT 2 112
VersionNumber LONG 4 114
27
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the MS_SIGNON
structure.
28
Futures and Options Trading System - Protocol for Non-Neat Front End
Note
Branch ID can be of 3 digits.
VersionNumber This field should contain the version number of the trading
system. The format is VERSION.RELEASE.SUB_RELEASE. (For
example, 7.02.00)
Batch2StartTime This field should be set to numerical zero.
HostSwitchContext This field should be set to blank.
Colour This field should be set to blank.
UserType This field can take one of the following values.
This field should be set to zero while sending to the host.
SequenceNumber This field should be set to numerical zero while sending the
request to host.
WorkstationNumber This field should contain the network ID of the workstation. This
is a seven digit number. The first five digits are fixed by the
Exchange and represent the various port / switch locations. The
29
Futures and Options Trading System - Protocol for Non-Neat Front End
Logon Response
The trader, after issuing a sign-on request, waits for the system response. The response will
either be Confirmation or Logon Error.
A successful logon results in the Logon Confirmation Response, for which the following structure
is sent back:
Table 7 MS_SIGNON
Structure Name MS_SIGNON
Packet Length 278 bytes
Transaction Code SIGN_ON_REQUEST_OUT (2301)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER (Refer to STRUCT 40 0
Message_Header in Chapter 2)
UserID LONG 4 40
Reserved CHAR 8 44
Password CHAR 8 52
Reserved CHAR 8 60
NewPassword CHAR 8 68
TraderName CHAR 26 76
LastPasswordChangeDate LONG 4 102
BrokerID CHAR 5 106
Reserved CHAR 1 111
BranchID SHORT 2 112
VersionNumber LONG 4 114
EndTime LONG 4 118
30
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the MS_SIGNON
structure.
Field Name Brief Description
TransactionCode This field is part of Message Header structure. The value should be
SIGN_ON_REQUEST_OUT (2301).
LogTime The current time at the trading system is sent back as number of
seconds since midnight of January 1, 1980. The time at the NNF
workstation must be synchronised with this time.
UserId This field contains the ID of the user or broker.
TraderName This field contains the user name.
LastPassword This field contains the last date and time when the password was
ChangeDateTime changed.
BrokerId This field should contain the trading member ID.
BranchId This field should contain the Branch ID to which the broker belongs.
Note
Branch ID can be of 3 digits.
EndTime This field contains the time when the markets last closed and it is
sent as the number of seconds since midnight of January 1, 1980.
Note: If this time is different from the time sent in an earlier logon,
all orders, trades and messages for this trader must be deleted from
the Local Database.
31
Futures and Options Trading System - Protocol for Non-Neat Front End
Logon Error
In case the logon is unsuccessful an error response is generated, for which the structure
returned is:
ERROR RESPONSE (Refer to Error Message in Chapter 2)
32
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the ERROR_RESPONSE
structure.
This request can be sent only if the trader has logged on successfully. The format of the request
is as follows:
Table 8 MS_SYSTEM_INFO_REQ
Structure Name MS_SYSTEM_INFO_REQ
Packet Length 44 bytes
Transaction Code SYSTEM_INFORMATION_IN (1600)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER (Refer to STRUCT 40 0
Message Header in Chapter 2)
LastUpdatePortfolioTIme LONG 4 40
33
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
MS_SYSTEM_INFO_REQ structure.
Note:
Last Update Portfolio Time is the last updated time of the
Exchange defined Portfolios in the LDB portfolio file.
Note: TWS User has to set time_stamp2 field present in the tws message header to zero in
SYSTEM_INFORMATION_IN message.
Table 9 MS_SYSTEM_INFO_DATA
Structure Name MS_SYSTEM_INFO_DATA
Packet Length 106 bytes
Transaction Code SYSTEM_INFORMATION_OUT(1601)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER (Refer to STRUCT 40 0
Message Header in Chapter 2)
ST_MARKET_STATUS STRUCT 8 40
ST_EX_MARKET_STATUS STRUCT 8 48
ST_PL_MARKET_STATUS STRUCT 8 56
UpdatePortfolio CHAR 1 64
MarketIndex LONG 4 65
DefaultSettlementPeriod (Normal) SHORT 2 69
DefaultSettlementPeriod (Spot) SHORT 2 71
DefaultSettlementPeriod (Auction) SHORT 2 73
CompetitorPeriod SHORT 2 75
SolicitorPeriod SHORT 2 77
WarningPercent SHORT 2 79
VolumeFreezePercent SHORT 2 81
SnapQuoteTime SHORT 2 83
34
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 10 ST_MARKET_STATUS
Structure Name ST_MARKET_STATUS
Packet Length 8 bytes
Field Name Data Type Size in Byte Offset
Normal SHORT 2 0
Oddlot SHORT 2 2
Spot SHORT 2 4
Auction SHORT 2 6
Table 11 ST_EX_MARKET_STATUS
Structure Name ST_EX_MARKET_STATUS
Packet Length 8bytes
Field Name Data Type Size in Byte Offset
Normal SHORT 2 0
Oddlot SHORT 2 2
Spot SHORT 2 4
Auction SHORT 2 6
Table 12 ST_PL_MARKET_STATUS
Structure Name ST_PL_MARKET_STATUS
Packet Length 8 bytes
Field Name Data Type Size in Byte Offset
Normal SHORT 2 0
Oddlot SHORT 2 2
35
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 13 ST_STOCK_ELIGIBLE_INDICATORS
Structure Name ST_STOCK_ELIGIBLE_INDICATORS
Packet Length 2 bytes
Field Name Data Type Size Offset
For Small Endian Machines
Reserved BIT 5 0
BooksMerged BIT 1 0
MinimumFill BIT 1 0
AON BIT 1 0
Reserved Byte 1 1
For Big Endian Machines
AON BIT 1 0
MinimumFill BIT 1 0
BooksMerged BIT 1 0
Reserved BIT 5 0
Reserved Byte 1 1
The following table provides the details of the various fields present in the
MS_SYSTEM_INFO_DATA structure.
36
Futures and Options Trading System - Protocol for Non-Neat Front End
37
Futures and Options Trading System - Protocol for Non-Neat Front End
This message is sent to request the host end to update the local database at the front end. The
structure is as follows:
Table 14 MS_UPDATE_LOCAL_DATABASE
Structure Name MS_UPDATE_LOCAL_DATABASE
Packet Length 82 bytes
Transaction Code UPDATE_LOCALDB_IN(7300)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
Message Header in Chapter 2)
LastUpdateSecurityTime LONG 4 40
LastUpdateParticipantTime LONG 4 44
LastUpdateInstrumentTime LONG 4 48
LastUpdateIndexTime LONG 4 52
RequestForOpenOrders CHAR 1 56
Reserved CHAR 1 57
ST_MARKET_STATUS (Refer to STRUCT 8 58
System Information Response in
Chapter 3)
38
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
MS_UPDATE_LOCAL_DATABASE structure.
39
Futures and Options Trading System - Protocol for Non-Neat Front End
The response will be either the database download, or a partial system information download.
The latter will occur if the trader does not have the latest market status.
This is returned if the market status sent in the System Information Response (Refer System
Information Response Chapter 3) is not the same at the host end or the markets are opening. In
th
structure is returned:
The following table provides the details of the various fields present in the SYSTEM
INFORMATION DATA structure.
40
Futures and Options Trading System - Protocol for Non-Neat Front End
The download comprises of a header, data and the trailer. Each updated security status,
participant (if selected) and GTC/GTD order will be sent as a separate message.
Table 15 UPDATE_LDB_HEADER
Structure Name UPDATE_LDB_HEADER
Packet Length 42 bytes
Transaction Code UPDATE_LOCALDB_HEADER(7307)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
Message Header in Chapter 2)
Reserved CHAR 2 40
The following table provides the details of the various fields present in the
UPDATE_LDB_HEADER structure.
The following table provides the details of the various fields present in the MESSAGE_HEADER
structure.
41
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 16 MS_DOWNLOAD_INDEX
42
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 17 INDEX_DETAILS
Structure Name INDEX_DETAILS
Packet Length 24 bytes
Field Name Data Type Size in Byte Offset
IndexName CHAR 15 0
Token Long 4 15
LastUpdateDateTime LONG 4 19
The following table provides the details of the various fields present in the
MS_DOWNLOAD_INDEX structure.
Table 18 MS_DOWNLOAD_INDEX_MAP
43
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 19 BCAST_INDEX_MAP_DETAILS
Structure Name BCAST_INDEX_MAP_DETAILS
Packet Length 41 bytes
Field Name Data Type Size in Byte Offset
BcastName CHAR 26 0
ChangedName CHAR 10 26
DeleteFlag CHAR 1 36
LastUpdateDateTime LONG 4 37
The following table provides the details of the various fields present in the
MS_DOWNLOAD_INDEX_MAP structure.
44
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 20 UPDATE_LOCAL_DB_TRAILER
Structure Name UPDATE_LOCALDB_TRAILER
Packet Length 42 bytes
Transaction Code UPDATE_LOCALDB_TRAILER (7308)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
Reserved CHAR 2 40
The following table provides the details of the various fields present in the
UPDATE_LDB_HEADER structure.
The user can download the exchange-defined portfolio by sending the portfolio request
structure.
Portfolio Request
Table 21 EXCH_PORTFOLIO_REQ
45
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
EXCH_PORFOLIO_REQ structure.
Field Name Brief Description
TransactionCode This field is the part of Message Header (Refer to
MESSAGE_HEADER structure chapter 2).The transaction
code is EXCH_PORTF_IN (1775).
LastUpdateDtTime This field should contain the time when the portfolio
information was last updated for all portfolio information
that is downloaded. Further download requests can use the
latest time to get updated information on the portfolio.
Setting this time to zero results in complete download.
Portfolio Response
This structure is sent in response to the portfolio request. The structure is as follows:
Table 22 EXCH_PORTFOLIO_RESP
Structure Name EXCH_PORTFOLIO_RESP
Packet Length 329 bytes
Transaction Code EXCH_PORTF_OUT (1776)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
NoOf Records SHORT 2 40
MoreRecords CHAR 1 42
Filler CHAR 1 43
PORTFOLIO_DATA [15] STRUCT 19 44
ARRAY
Table 23 PORTFOLIO_DATA
46
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
EXCH_PORFOLIO_RESP structure.
Field Name Brief Description
TransactionCode This field is the part of Message Header (Refer to
MESSAGE_HEADER structure chapter 2).The transaction
code is EXCH_PORTF_OUT (1776).
Portfolio This field contains the name of the portfolio.
Token This field contains the token number of the security in the
portfolio.
NoOfRecords This field contains the number of records. Depending upon
this number of records will be filled up in subsequent
PORTFOLIO_DATA structure.
MoreRecords
DeleteFlag
is deleted or not, where:
Message Download
This request is used to download the messages intended for the trader, from the trading system.
When the trader makes a request for message download, all the transactions of the trader and
other important broadcasts are downloaded. The response consists of Header and Trailer to
indicate the beginning and end of download and is similar to Update Local Database Download.
Message downloads will be served through each individual stream. Hence, message download
request needs to be sent individually for a stream by the user.
47
Futures and Options Trading System - Protocol for Non-Neat Front End
This message is sent for requesting message download. The structure sent to the trading system
is as follows:
Table 24 MS_MESSAGE_DOWNLOAD
Structure Name MS_MESSAGE_DOWNLOAD
Packet Length 48 bytes
Transaction Code DOWNLOAD_REQUEST (7000)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
SequenceNumber Double 8 40
The following table provides the details of the various fields present in the
MS_MESSAGE_DOWNLOAD structure.
The download response comprises of a header, data and a trailer. Each trader specific broadcast
message will be sent separately.
48
Futures and Options Trading System - Protocol for Non-Neat Front End
49
Futures and Options Trading System - Protocol for Non-Neat Front End
Broadcast Messages
Market Open, Market Close, Market Pre-Open ended,
Preopen Shutdown Message, Broadcast Message String,
Turnover exceeded, Broker Reactivated, Broadcast message
sent from NSE-Control. Refer to Broadcast Messages in
Chapter 9.
Contingency broadcast message. Refer to Exception
Handling in Chapter 11.
Logoff Request
The process by which a trader quits or signs off from the trading system is called Logoff Process.
It is a request to break the virtual circuit between the trading system host and the front end.
The following table provides the details of the various fields present in the MS_SIGNOFF
structure.
50
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 25 SIGNOFF_OUT
Structure Name SIGNOFF_OUT
Packet Length 40 bytes
Transaction Code SIGN_OFF_REQUEST_OUT (2321)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
UserId LONG 4 40
Reserved CHAR 145 44
The following table provides the details of the various fields present in the SIGNOFF_OUT
structure.
51
Futures and Options Trading System - Protocol for Non-Neat Front End
Order Entry
Order Modification
Order Cancellation
Trade Modification
Trade Cancellation
Order Entry
Order entry allows the trader to place orders in the market. The system accepts the orders from
the users and matches the orders with the orders in the order books maintained at HOST END to
order matching. If the order does not match, the order is placed in the appropriate book with the
price and time stamp.
Order Types
Regular Lot: Regular Lot Orders are orders in the normal market that have none of the
following terms attached: All or None (AON), Minimum Fill (MF) and Trigger Price.
Special Terms: Special Terms Orders are orders in the normal market which have
special attributes attached to it. They must have MF or AON.
Negotiated Trade Orders: Negotiated Trade Orders are regular lot orders with the
Counter Party ID.
52
Futures and Options Trading System - Protocol for Non-Neat Front End
Stop Loss Orders: Stop Loss Orders are orders in normal market with Trigger Price
specified. They may have the Minimum Fill or AON attribute specified.
Market If Touched: Market If Touched Orders are orders in normal market with Trigger
Price specified. They may have the Minimum Fill or the AON attribute specified. Market
if touched orders are almost identical to stop orders, except that they are used when
the market is currently trading on the opposite side of the order price.
Order Terms
The following terms and conditions are used during order entry and modification:
Disclosed Quantity (DQ): This term allows the dealer to disclose only a portion of the
order quantity to the market. After the initial disclosed quantity is matched, subsequent
disclosed quantity is shown to the market. All the disclosures will be shown to the
market with the same order number.
Trigger Price (TP): The Stop Loss book type allows the broker to release an order into
the system after the market price crosses a threshold price referred to as the trigger
price. This facility is available for orders in normal market only. For a stop loss buy
order, the trigger price should not be greater than the limit price. For a stop loss sell
order, the trigger price should not be less than the limit price. All the stop loss orders
will be kept in a separate book till they are triggered. The price is to be multiplied by
100.
Immediate or Cancel (IOC): This term forces the order to match immediately, else be
cancelled. If the order trades partially, the remaining part is cancelled.
Day: This is the default term for an order. At the end of the trading day, all outstanding
Day orders are cancelled by the system.
Good till Date (GTD): This term allows the dealer to keep an order in the system for a
certain number of days. The number of days must be greater than 1 and less than or
equal to the maximum number of days allowed for GTC orders. Each day is a calendar
day.
Good till Cancelled (GTC): This term allows the broker to keep an order in the system
until it is canceled. However, the order is canceled by the system automatically if it
remains outstanding for more than the maximum number of days allowed for GTC
orders.
Minimum Fill (MF): This term allows the broker to ensure that the quantity traded is at
least the Minimum Fill amount specified. The minimum fill must be in multiples of the
market lot and less than the order quantity. MF quantity must be less than or equal to
Disclosed Quantity when the order has both MF and Disclosed Quantity attributes.
53
Futures and Options Trading System - Protocol for Non-Neat Front End
All or None (AON): This term allows the broker to ensure that the entire order is traded
and if not, nothing is traded at all. This can result in multiple trades or a single trade.
54
Futures and Options Trading System - Protocol for Non-Neat Front End
55
Futures and Options Trading System - Protocol for Non-Neat Front End
56
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 27 CONTRACT_DESC
Structure Name CONTRACT_DESC
Packet Length 28 bytes
Field Name Data Type Size in Byte Offset
InstrumentName CHAR 6 0
Symbol CHAR 10 6
ExpiryDate LONG 4 16
StrikePrice LONG 4 20
OptionType CHAR 2 24
CALevel SHORT 2 26
57
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 28 ST_ORDER_FLAGS
Structure Name ST_ORDER_FLAGS
Packet Length 2 bytes
Field Name Data Type Size Offset
For Small Endian Machines
AON BIT 1 0
IOC BIT 1 0
GTC BIT 1 0
Day BIT 1 0
MIT BIT 1 0
SL BIT 1 0
Market BIT 1 0
ATO BIT 1 0
Reserved BIT 3 1
Frozen BIT 1 1
Modified BIT 1 1
Traded BIT 1 1
MatchedInd BIT 1 1
MF BIT 1 1
For Big Endian Machines
ATO BIT 1 0
Market BIT 1 0
SL BIT 1 0
MIT BIT 1 0
Day BIT 1 0
GTC BIT 1 0
IOC BIT 1 0
AON BIT 1 0
MF BIT 1 1
MatchedInd BIT 1 1
Traded BIT 1 1
Modified BIT 1 1
Frozen BIT 1 1
Reserved BIT 3 1
58
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 29 ADDITIONAL_ORDER_FLAGS
Structure Name ADDITIONAL_ORDER_FLAGS
Packet Length 1 bytes
Field Name Data Type Size Offset
For Small Endian Machines
BOC BIT 1 0
COL BIT 1 0
Reserved BIT 1 0
Reserved BIT 1 0
STPC BIT 1 0
Reserved BIT 3 0
For Big Endian Machines
Reserved BIT 3 0
STPC BIT 1 0
Reserved BIT 1 0
Reserved BIT 1 0
COL BIT 1 0
BOC BIT 1 0
The following table provides the details of the various fields present in the MS_OE_REQUEST
structure.
Field Name Brief Description
TransactionCode This field is the part of Message Header (Refer to
MESSAGE_HEADER structure chapter 2).The transaction
code is BOARD_LOT_IN (2000).
ParticipantType Since only exchange can initiate the auction, this field
This fiel
for solicitor order.
CompetitorPeriod This field should be set to zero.
SolicitorPeriod This field should be set to zero.
Modified / CancelledBy This field should denote who has modified or cancelled a
particular order. It should take one of the following
values:
59
Futures and Options Trading System - Protocol for Non-Neat Front End
60
Futures and Options Trading System - Protocol for Non-Neat Front End
61
Futures and Options Trading System - Protocol for Non-Neat Front End
62
Futures and Options Trading System - Protocol for Non-Neat Front End
Settlor This field should specify the ID of the participants who are
responsible for settling the trades through the custodians.
63
Futures and Options Trading System - Protocol for Non-Neat Front End
64
Futures and Options Trading System - Protocol for Non-Neat Front End
Note: - STPC bit can be set for RL, 2L, 3L, Spread, SL transcodes. STPC bit in the modification
transcodes should be same as set in the original order else the modification request will be
rejected. In case of triggered stop loss order, bit selected during order entry will be considered.
Only the following orders will be considered valid when a broker is in Closeout status:
1. Orders with the following:
Market Type :- NORMAL,
Book Type :- REGULAR (RL),
Order Type : IMMEDIATE or CANCEL
2. Participant order entry will not be allowed if the broker is in Closeout status.
3. Value of CloseoutFlag in MS_OE_REQUEST for different transaction codes will be as
follows:
BOARD_LOT_IN (2000): The value of the CloseoutFlag must be sent blank
ORDER_CONFIRMATION(2073) and ORDER_CANCEL_CONFIRMATION(2075):
The
order if the broker is in close out state
entered order is close order if the broker is in close out state.
For all other transcodes using the MS_OE_REQUEST structure CloseoutFlag will
be ignored
The primary response is the Order Requested message which is stopped currently. The
secondary response can be Order Confirmation, Order Freeze, Order Error or one of the general
error responses. Order freeze response is generated when the order placed by the trader has
resulted in freeze and is waiting for the approval of the exchange. The order error response is
65
Futures and Options Trading System - Protocol for Non-Neat Front End
given when the entered order is rejected by the trading system. The reason for the rejection is
given in the Error Code.
Note: Order Requested Message (2001) is stopped to reduce the packet sent from the host
end.
The following table provides the details of the various fields present in the
MS_OE_REQUEST structure.
This response does not imply that the order is confirmed, and is followed by the Order
Confirmation response.
66
Futures and Options Trading System - Protocol for Non-Neat Front End
transaction code is sent. This can be an unsolicited message as well. The message sent is as
follows:
The following table provides the details of the various fields present in the MS_OE_REQUEST
structure.
Note
The reason code in the structure can be used to differentiate orders that got freeze approval
from orders that got normal confirmation.
67
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the MS_OE_REQUEST
structure.
Note:
The reason code in the structure can be used to differentiate price freeze and quantity freeze.
.
68
Futures and Options Trading System - Protocol for Non-Neat Front End
Order Modification
Order Modification enables the trader to modify unmatched orders.
The trader can modify the quantity, price and attributes of an order by specifying the order
number of the order to be modified.
MS_OE_REQUEST (Refer to Order Entry Request in Chapter 4)
The following table provides the details of the various fields present in the MS_OE_REQUEST
structure.
69
Futures and Options Trading System - Protocol for Non-Neat Front End
Note: Order Modification Response (2041) is stopped to reduce the packet sent from the host
end.
To modify Price of an existing regular book order (Book Type 1), following optimized structure
can be used. This request is in addition to existing Modification transcode mentioned in the
document. Volume will not be modified through this transcode. To modify any other properties
of the order, please refer to regular Order Modification Section in Futures and Options NNF
protocol.
70
Futures and Options Trading System - Protocol for Non-Neat Front End
Price New price that will overwrite the current Limit price. If it is
sent as 0 (zero) then order will be modified as Market
Priced Order.
Volume Latest image of volume should be populated in this field.
LastModified Value of the Last modified time stamp as received on last
transaction response.
71
Futures and Options Trading System - Protocol for Non-Neat Front End
Note: - STPC (Refer to Order Terms Attributes in Chapter 4) bit set at order entry shall be
considered in case of incoming 2013 transcode.
Order Modification Confirmation Response
Successful modification of the order results in Order Modification Confirmation. When the order
modification is confirmed, the modified order time is filled and sent back. On modification, the
order can result in a freeze. If the freeze is approved then order modification will be received as
72
Futures and Options Trading System - Protocol for Non-Neat Front End
This is sent when order modification request is rejected. The reason for rejection will be given
by the Error Code in the header. The message sent is as follows:
73
Futures and Options Trading System - Protocol for Non-Neat Front End
Order Cancellation
The trader can cancel any unmatched/partially matched order by specifying the Order number.
74
Futures and Options Trading System - Protocol for Non-Neat Front End
LastModifiedTime This should contain time of last activity done on that order.
Last activity could be order entry, order modification or last
trade time of that order. It is in number of seconds from
midnight of January 1, 1980.
LastActivityReference In Order Cancellation request, this field should contain
LastActivityReference value received in response of the
last activity done on that order. Last activity could be order
entry, order modification or last trade of that order. Currently
the same shall be in nanoseconds. Changes if any shall be
notified.
Note: Order Cancellation Response (2071) is stopped to reduce the packet sent from the host
end.
Successful cancellation of order results in Order Cancellation Confirmation Response. This will
-Control cancels the order. The same transcode will also be
sent in response if normal IOC order results in partial cancellation or 2L/3L Order results in
partial cancellation. The message sent is as follows:
The following table provides the details of the various fields present in the MS_OE_REQUEST
structure, for batch order cancellation.
75
Futures and Options Trading System - Protocol for Non-Neat Front End
The order cancellation error is sent when the cancellation request is rejected by the trading
system. The reason for rejection will be given by the Error Code in the header. The message sent
is as follows:
The following table provides the details of the various fields present in the MS_OE_REQUEST
structure.
Kill Switch
This functionality provides a facility to traders to cancel all of their orders at the same time.
Also, user can cancel all outstanding orders on particular contract by specifying contract
information in request packet.
Kill Switch Request
76
Futures and Options Trading System - Protocol for Non-Neat Front End
The kill switch error is sent when the request is rejected by the trading system. The reason for
rejection will be given by the Error Code in the header. The message sent is as follows:
Trade Modification
Trade Modification is a facility provided by NSE to allow users to change client account number
of executed trades.
Table 31 MS_TRADE_INQ_DATA
77
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
MS_TRADE_INQ_DATA structure.
78
Futures and Options Trading System - Protocol for Non-Neat Front End
FillPrice This field should contain the price at which the trade took
place. This is to be multiplied by 100 before sending to the
trading system host.
MarketType This field should contain the value to denote the type of
market Normal or Odd Lot or Spot or Auction.
Normal Market.
BuyOpenClose This field should be set to Open or Close for
Buy trade.
Buy / SellBrokerId This field should contain the trading member ID of the
broker who placed the order for the trade or the one who is
responsible for the settlement.
TraderId This field should contain the ID of the user on whose behalf
request is to be made.
RequestedBy This field indicates which side (Buy/Sell) of the trade is to
be modified/cancelled. This should contain one of the
following values
modified/cancelled.
SellOpenClose This field should contain the Open / Close indicator for the
Sell trade.
BuyAccount Number This field should contain the Account Number of the trade
on Buy side.
SellAccount Number This field should contain the Account Number of the trade
on Sell side.
ReservedFiller This filed is reserved for future use and any value in this
field will be ignored.
BuyPAN This field shall contain the PAN (Permanent Account
Number/PAN_EXEMPT). This field shall be mandatory for
all orders (client/participant/PRO orders).
79
Futures and Options Trading System - Protocol for Non-Neat Front End
If trade modification request is rejected due to erroneous data then the structure sent is:
The following table provides the details of the various fields present in the
MS_TRADE_INQ_DATA structure.
Trade Cancellation
To cancel a trade, both parties of the trade must request for trade cancellation. The process is
as follows:
1.
2. If any error was encountered in the entered data then Trade Error message is sent.
Otherwise it goes as an alert to the NSE control.
3. The counter party to the trade is notified of the trade cancellation request (Refer to
Unsolicited Messages, Chapter 7).
4. When both the parties of the trade have asked for trade cancellation, it may be approved
or rejected by the Exchange (Refer to Unsolicited Messages, Chapter 7).
80
Futures and Options Trading System - Protocol for Non-Neat Front End
This is an acknowledgement signifying that the request has reached the trading system. The
field details of the structure are as follows:
After the requested response if any error is detected in the data, the following structure is sent:
81
Futures and Options Trading System - Protocol for Non-Neat Front End
Note:
IOC
Special Terms: In this case, only orders with all or None (AON) attribute are
allowed. Normal Day orders and IOC orders are also allowed. AON allows the
82
Futures and Options Trading System - Protocol for Non-Neat Front End
broker to ensure that the entire order is traded or none at all. This might result in
multiple trades or single trade.
The following terms and conditions cannot be used during spread ST order entry:
Trigger Price (TP)
Spread day orders will be allowed only on future contracts. Valid spread combinations will be
pre-defined in the Spread Combination Contract file.
Spread day orders on eligible spread combinations with price difference within the operating
range, will be allowed.
Since day orders are allowed, following functionalities will be applicable for spread day orders:
Spread order modification
o Change in price difference and quantity will be allowed.
o Modification of spread day order to IOC will not be allowed.
o All other rules for normal order modification remain same for spread order
modifications.
Spread order cancellation
Broker suspension When a broker is suspended then all the outstanding spread orders of the
firm will also be cancelled by the system. Respective users will get spread order cancellation
message.
Batch Order Cancellation - At the end of the day, all the outstanding spread day orders will be
cancelled by the system. Respective users will get spread order cancellation message.
83
Futures and Options Trading System - Protocol for Non-Neat Front End
The order cancellation due to broker suspension or batch order cancellation will be sent with
new transcode BATCH_SPREAD_CXL_OUT (9004). For this transcode existing structure
MS_SPD_OE_REQUEST will be used.
A new master file is introduced to maintain the valid spread combinations. The spread
combination consists of two contracts. The combination will be updated on daily basis. The file
will be made available every day for uploading in the front end. Structure of this file is provided
in subsequent section (Refer to Spread Combination File in Chapter 5).
Broadcast for Spread Combination Master Update
Any intraday change in the spread combination master will be available as broadcast. A new
structure BCAST_SPD_MSTR_CHG with transcode 7309 is defined. Structure of the new
transcode 7309 is given in subsequent section (Refer to MS_SPD_UPDATE_INFO in Chapter 5).
Spread MBP (market by price) will be reflecting spread activities. These packets will be
compressed. The existing Spread MBP (MS_SPD_MKT_INFO) structure will be changed to send
broadcast for spread MBP, for price difference statistics. The changes in the structure are
mentioned in MS_SPD_MKT_INFO Chapter 9.
84
Futures and Options Trading System - Protocol for Non-Neat Front End
85
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 32 MS_SPD_OE_REQUEST
Structure Name MS_SPD_OE_REQUEST
Packet Length 480 bytes
Transaction Code SP_BOARD_LOT_IN (2100)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
ParticipantType1 CHAR 1 40
Filler1 CHAR 1 41
CompetitorPeriod1 SHORT 2 42
SolicitorPeriod1 SHORT 2 44
ModCxlBy1 CHAR 1 46
Filler9 CHAR 1 47
ReasonCode1 SHORT 2 48
StartAlpha1 CHAR 2 50
EndAlpha1 CHAR 2 52
Token1 LONG 4 54
CONTRACT_DESC (Refer to Order STRUCT 28 58
Entry Request in Chapter 4)
OpBrokerId1 CHAR 5 86
Fillerx1 CHAR 1 91
FillerOptions1 CHAR 3 92
Fillery1 CHAR 1 95
OrderType1 SHORT 2 96
OrderNumber1 DOUBLE 8 98
AccountNumber1 CHAR 10 106
BookType1 SHORT 2 116
BuySell1 SHORT 2 118
DisclosedVol1 LONG 4 120
DisclosedVolRemaining1 LONG 4 124
TotalVolRemaining1 LONG 4 128
Volume1 LONG 4 132
VolumeFilledToday1 LONG 4 136
Price1 LONG 4 140
TriggerPrice1 LONG 4 144
GoodTillDate1 LONG 4 148
EntryDateTime1 LONG 4 152
MinFillAon1 LONG 4 156
86
Futures and Options Trading System - Protocol for Non-Neat Front End
87
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 33 MS_SPD_LEG_INFO
88
Futures and Options Trading System - Protocol for Non-Neat Front End
FillerY CHAR 1 79
Note: For spread order entry leg3 is not filled.
The following table provides the details of the various fields present in the Order Entry Request
structure.
89
Futures and Options Trading System - Protocol for Non-Neat Front End
90
Futures and Options Trading System - Protocol for Non-Neat Front End
91
Futures and Options Trading System - Protocol for Non-Neat Front End
92
Futures and Options Trading System - Protocol for Non-Neat Front End
day orders.
All other flags must be sent as zero for the order
entry request.
nts All or None
attribute.
or
Cancel attribute.
Open / Close2 Open / Close order indicator. This field should
contain one of the following values:
ADDITIONAL_ORDER_FLAGS Refer to Additional_Order_Flags and Order Terms
Attributes tables in Chapter 4 for the relevant
description.
For reserved bit kindly set the values with 0
PAN This field shall contain the PAN (Permanent Account
Number/PAN_EXEMPT). This field shall be
mandatory for all orders (client/participant/PRO
orders).
Algo ID For Algo order this field shall contain the Algo ID
issued by the exchange. For Non-Algo order, this
field shall be Zero(0)
Reserved This field is reserved for future use. This should be
populated as 0 for the message to be accepted by
exchange host.
LastActivityReference In case of order entry response, this field will contain
a unique value. Currently the same shall be in
nanoseconds. Changes if any shall be notified.
93
Futures and Options Trading System - Protocol for Non-Neat Front End
Note: - For 2L/3L/Spread orders, STPC bit from additional order flag of the first leg will be
referred.
The primary response of order entry is the Order Requested Message. The secondary response
includes Market Order response, Order Confirmation response, Order Freeze response, and
Order Error response. Market order response is provided when the entered order is market order.
Each successful order entry results in order confirmation. The order error response is provided
when the entered order is rejected by the trading system. The reason for the rejection is provided
by the error code.
Note: Order Requested message is stopped to reduce the packet sent from the host end.
Note: Order Request Response (2101) is stopped to reduce the packet sent from the host end.
Successful order entry results in Order Confirmation response when the order confirmed is
returned. When the entered order goes for a freeze and that freeze is approved, a similar
transaction code is sent. This can be an unsolicited message as well. The message sent is as
follows:
MS_SPD_OE_REQUEST (Refer to Order Entry Request of Spread Order in Chapter 5)
The following table provides the details of the various fields present in the Order Confirmation
Response structure.
94
Futures and Options Trading System - Protocol for Non-Neat Front End
OrderTerms The flags are set as discussed in Order Entry Request in Chapter
4.
The order error response is sent when the entered order is rejected by the trading system. The
reason for the rejection is provided by reason code and the reason string. The message sent is:
MS_SPD_OE_REQUEST (Refer to Order Entry Request of Spread Order in Chapter 5)
ErrorCode This field contains the error number. Refer to the List of Error
Codes in Appendix.
In the case of Immediate or Cancel (IOC) order, the system accepts the orders from the users
and tries to immediately match the orders with the orders in the books. If the order does not
match, the order is cancelled by the system. Then the order cancel confirmation response is
return back. The message sent is as follows:
95
Futures and Options Trading System - Protocol for Non-Neat Front End
According to the rules of Order Modification, the following modifications are not allowed:
The trader can modify the quantity, price and attributes of an order by specifying the order
number of the order to be modified.
MS_SPD_OE_REQUEST (Refer to Order Entry Request of Spread Order in Chapter 5)
The following table provides the details of the various fields present in the Order Modification
Request structure.
Field Name Brief Description
TransactionCode The transaction code is:
For Order Modification: SP_ORDER_MOD_IN (2118).
For Order Cancellation: SP_ORDER_CANCEL_IN (2106).
96
Futures and Options Trading System - Protocol for Non-Neat Front End
Modified / CancelledBy This field should denote who has modified or cancelled a
particular order. It should contain one of the following
values:
OrderNumber This field should contain the Order Number of the order to
be modified.
TraderId1 This field should contain the ID of the user on whose behalf
order is to be modified/cancelled.
EntryDateTime This field, while coming from the host, contains the date
and time when the order entered the trading system. This
field should be set to zero while sending to the host.
LastModified1 In the case of order entry, this field will be same as Entry
Date Time. After the order is modified, it contains the time
when the Order was last modified. It is the time in seconds
from midnight of January 1, 1980.
In case of Order Modification Request, this field should
contain the time when the Order was last modified.
LastActivityReference In Order modification request, this field should contain
LastActivityReference value received in response of the last
activity done on that order. Last activity could be order
entry, order modification or last trade of that order.
Currently the same shall be in nanoseconds. Changes if any
shall be notified.
Note: Order Modification/Cancellation Response (2119/2107) message is stopped to reduce
the packet from the host end.
Successful modification of the order results in Order Modification Confirmation. When the order
modification is confirmed, the modified order time is filled and sent back. On modification the
order can result in a freeze. If the freeze is approved, then order modification will be received as
97
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the Order Modification
Confirmation Response structure.
Field Name Brief Description
TransactionCode The transaction code is SP_ORDER_MOD_CON_OUT (2136).
SP_ORDER_CXL_CONFIRMATION (2130).
LastModifiedTime This field contains the time when the order was last modified
(in seconds from midnight of January 1, 1980.)
LastActivityReference This field will contain a unique value for current activity.
Currently the same shall be in nanoseconds. Changes if any
shall be notified.
The reason for rejection will be given by the Error Code in the header. The message sent is as
follows:
98
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 34 MS_SPD_UPDATE_INFO
Table 35 SEC_INFO
99
Futures and Options Trading System - Protocol for Non-Neat Front End
OptionType CHAR 2 26
CALevel SHORT 2 28
Table 36 ST_SPD_ELIGIBILITY
The following table provides the details of the various fields present in the Spread Combination
Master Update Broadcast structure.
100
Futures and Options Trading System - Protocol for Non-Neat Front End
CONTROL RECORD
DETAIL RECORD
1 Token1 NUMBER 6
2 Token2 NUMBER 6
3 InstrumentName1 CHAR 6
4 Symbol1 CHAR 10
101
Futures and Options Trading System - Protocol for Non-Neat Front End
5 Series1 CHAR 2
6 ExpiryDate1 NUMBER 10
7 StrikePrice1 NUMBER 10
8 OptionType1 CHAR 2
9 CALevel1 NUMBER 7
10 InstrumentName2 CHAR 6
11 Symbol2 CHAR 10
12 Series2 CHAR 2
13 ExpiryDate2 NUMBER 10
14 StrikePrice2 NUMBER 10
15 OptionType2 CHAR 2
16 CALevel2 NUMBER 7
17 ReferencePrice NUMBER 10
18 DayLowPriceDiffRange NUMBER 10
19 DayHighPriceDiffRange NUMBER 10
20 OpLowPriceDiffRange NUMBER 10
21 OpHighPriceDiffRange NUMBER 10
22 BoardLotQuantity1 NUMBER 9
23 MinimumLotQuantity1 NUMBER 9
24 TickSize1 NUMBER 9
25 BoardLotQuantity2 NUMBER 9
26 MinimumLotQuantity2 NUMBER 9
27 TickSize2 NUMBER 9
28 Eligibility CHAR 1
29 DeleteFlag CHAR 1
The following table provides the details of the various fields present in the Spread Combination
File structure.
Field Name Brief Description
102
Futures and Options Trading System - Protocol for Non-Neat Front End
DayLowPriceDiffRange Day low price difference range for the combination. It may
be changed intraday.
Note: The value can be a positive number/ negative
number or zero.
DayHighPriceDiffRange Day high price difference range for the combination. It may
be changed intraday.
Note: The value can be a positive number or zero.
103
Futures and Options Trading System - Protocol for Non-Neat Front End
104
Futures and Options Trading System - Protocol for Non-Neat Front End
Note: By default, all 2L and 3L orders are Immediate or Cancel (IOC) orders.
Security is suspended
Security is expelled
Broker is suspended
Broker does not exist in the trading system
Broker is deactivated
User is disabled
Participant is suspended
ge
105
Futures and Options Trading System - Protocol for Non-Neat Front End
Order attributes are not entered properly for various book types
For Multi-leg orders i.e. 2L/3L orders all tokens in the respective legs should be from the
same stream.
Note:
following table:
determined by NSE-Control.
Note: For spread order, this is not used. This must be sent as
zero for spread order entry request.
Price2 This field should contain the price at which the order is placed.
To enter a Market order, the price should be zero. The price
must be a multiple of the Tick Size. This is to be multiplied by
100 before sending to the trading system. The order will be
106
Futures and Options Trading System - Protocol for Non-Neat Front End
determined by NSE-Control.
Note: The value can be a positive number or zero. For spread
order, this is not used. This must be sent as zero for spread
order entry request.
Note: Descriptions of other fields are same as given in Spread Order Entry Request in
Chapter 4. The fields and their description given below are applicable for 3L orders
only.
ParticipantType3 This is not used.
CompetitorPeriod3 This is not used.
SolicitorPeriod3 This is not used.
Modified / This is not used.
CancelledBy3
ReasonCode3 This is not used.
TokenNumber3 This is the Token Number of the contract on which order is to
-
-
done only on contract descriptor.
If the valid token number is sent, validation will be done on
token number as well as on the contract descriptor.
SecurityInformation3 This structure contains following fields.
(contract descriptor Instrument Name, Symbol, Expiry Date, Strike Price, Option
3) Type and CA Level of the contract.
This is mandatory and should be filled while sending the order
entry request.
CA Level should be set to zero.
CounterPartyBroker This is not used.
Id3
OrderType3 This is not used.
Buy / SellIndicator3 This field should contain one of the following values:
DisclosedVolume3 This is not used. This must be sent as zero for the order entry
request.
DisclosedVolume This is not used. This must be sent as zero for the order entry
Remaining3 request.
107
Futures and Options Trading System - Protocol for Non-Neat Front End
by NSE-Control.
VolumeAvailable This is not used. This must be sent as zero for the order entry
request.
MinimumFill This is not used. This must be sent as zero for the order entry
Volume3 request.
Open / Close3 Open / Close order indicator. This field should contain one of
the following values:
Cover / Uncover3 This field should contain one of the following values:
nts Uncovered
108
Futures and Options Trading System - Protocol for Non-Neat Front End
Note: Order requested response (2103/2105) message is stopped to reduce the packet sent
from the host end.
No transaction code for price confirmation will be sent for 2L/3L orders.
Successful order entry results in Order Confirmation Response. The order confirmed is returned.
When the entered order goes for a freeze and that freeze is approved, this same transaction code
The order error response is sent when the entered order is rejected by the trading system. The
reason for the rejection is given by reason code and the reason string. The message sent is:
MS_SPD_OE_REQUEST (Refer to Spread Order Entry Request in Chapter 5)
109
Futures and Options Trading System - Protocol for Non-Neat Front End
The system accepts the orders from the users and tries to match the orders immediately with
the orders in the books. If the order does not match, the order is cancelled by the system. Then
the order cancel confirmation response is sent back. The message sent is as follows:
MS_SPD_OE_REQUEST (Refer to Spread Order Entry Request in Chapter 5)
LastModifiedTime This will be the current cancellation time. (It will be same as
LogTime)
Partial cancellation of order results in Order Cancellation Confirmation Response. This transcode
will be sent in response if 2L/3L Order results in partial cancellation. The message sent is as
follows:
110
Futures and Options Trading System - Protocol for Non-Neat Front End
Trade Modification
Refer to Trade Modification in Chapter 4.
Trade Cancellation
Refer to Trade Cancellation in Chapter 4.
111
Futures and Options Trading System - Protocol for Non-Neat Front End
112
Futures and Options Trading System - Protocol for Non-Neat Front End
113
Futures and Options Trading System - Protocol for Non-Neat Front End
Trade Confirmation
Trade confirmation is an unsolicited message which is generated when any order of the trader is
traded. The order may trade completely or partially. The following structure is sent:
Table 37 MS_TRADE_CONFIRM
114
Futures and Options Trading System - Protocol for Non-Neat Front End
115
Futures and Options Trading System - Protocol for Non-Neat Front End
116
Futures and Options Trading System - Protocol for Non-Neat Front End
117
Futures and Options Trading System - Protocol for Non-Neat Front End
Trade Modification
Trade Modification is a facility provided by NSE to allow users to change client account number
of executed trades.
The trade modification is confirmed and the new trade data is sent.
118
Futures and Options Trading System - Protocol for Non-Neat Front End
Trade Cancellation
Trade Cancellation Requested Notification
This message is sent when the counter party of the trade requests for a trade cancellation. The
structure sent is:
When NSE-Control approves the trade cancellation request, the structure sent is:
When NSE-Control rejects the trade cancellation alert, the structure sent is:
Limits Updations
A message is sent to the respective dealers for Updations of user order value limit and branch
order value limit by the Corporate Manager.
Table 38 MS_ORDER_VAL_LIMIT_DATA
Structure Name MS_ORDER_VAL_LIMIT_DATA
Packet Length 206 bytes
119
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 39 INSTRUMENT_USER
Structure Name INSTRUMENT_USER
Packet Length 64 bytes
Field Name Data Type Size in Byte Offset
BranchBuyValueLimit DOUBLE 8 0
BranchSellValueLimit DOUBLE 8 8
BranchUsedBuyValueLimit DOUBLE 8 16
BranchUsedSellValueLimit DOUBLE 8 24
UserOrderBuyValueLimit DOUBLE 8 32
UserOrderSellValueLimit DOUBLE 8 40
UserOrderUsedBuyValueLimit DOUBLE 8 48
UserOrderUsedSellValueLimit DOUBLE 8 56
The following table provides the details of the various fields present in the Limits Updation
structure.
120
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 40 DEALER_ORD_LMT
Structure Name DEALER_ORD_LMT
Packet Length 66 bytes
Transaction Code DEALER_LIMIT_UPDATE_OUT (5733)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
BrokerId CHAR 5 40
UserId LONG 4 45
OrdQtyBuff DOUBLE 8 49
OrdValBuff DOUBLE 8 57
The following table provides the details of the various fields present in the Order limit Update
structure:
121
Futures and Options Trading System - Protocol for Non-Neat Front End
This happens when the Corporate Manager updates the spread order limit for any user.
SPD_ORD_LIMIT_UPDATE_OUT transcode is being sent to all the individual users.
Table 41 SPD_ORD_LMT
Structure Name SPD_ORD_LMT
Packet Length 66 bytes
Transaction Code SPD_ORD_LIMIT_UPDATE_OUT (5772)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
BrokerId CHAR 5 40
UserId LONG 4 45
SpdOrdQtyBuff DOUBLE 8 49
SpdOrdValBuff DOUBLE 8 57
The following table provides the details of the various fields present in the Spread Order Limit
Update structure.
Field Name Brief Description
TransactionCode The transaction code is:
USER_ORDER_LIMIT_UPDATE_OUT (5731).
BrokerId This field contains the Trading Member ID of the broker.
UserId This field should contain the user ID of the user/broker.
SpdOrdQtyBuff This field contains the maximum Order quantity which user can
enter while spread order entry.
SpdOrdValBuff This field contains the maximum order value which user can
enter while spread order entry.
122
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 42 MS_TRADER_INT_MSG
123
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in Message in Trading
Structure.
To identify the Market wide OI Limit broadcast messages, a new action code is defined with value
Table 43 MS_BCAST_MESSAGE
Structure Name MS_BCAST_MESSAGE
Packet Length 320 bytes
Transaction Code BCAST_JRNL_VCT_MSG (6501).
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
BranchNumber SHORT 2 40
BrokerNumber CHAR 5 42
ActionCode CHAR 3 47
ST_BCAST_DESTINATION STRUCT 2 50
Reserved CHAR 26 52
BroadcastMessageLength SHORT 2 78
BroadcastMessage CHAR 239 80
Table 44 ST_BCAST_DESTINATION
124
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the General Broadcast
Message structure.
Field Name Brief Description
TransactionCode The transaction code is:
BCAST_JRNL_VCT_MSG (6501).
BranchNumber
BrokerNumber This field contains the Trading Member ID of the broker.
ActionCode This field contains the action code which indicates the action
taken.
Note: For example,
- system
- Listing
Market Wide OI Limit Message
Broadcast This field specifies the destination of the message, that is,
Destination Trader Workstation or Control Workstation.
Broadcast This field contains the length of the broadcast message.
MessageLength
BroadcastMessage This field contains the broadcast message.
125
Futures and Options Trading System - Protocol for Non-Neat Front End
To identify the
Table 45 CTRL_MSG_TO_TRADER
Structure Name CTRL_MSG_TO_TRADER
Packet Length 290 bytes
Transaction Code For interactive messages
CTRL_MSG_TO_TRADER (5295).
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
TraderId LONG 4 40
ActionCode CHAR 3 44
Reserved CHAR 1 47
BroadCastMessageLength SHORT 2 48
BroadCastMessage CHAR 239 50
The following table provides the details of the various fields present in the Trader Specific
Message structure.
126
Futures and Options Trading System - Protocol for Non-Neat Front End
Other Messages
BroadCastMessage Message Length
Length
BroadCastMessage Message
127
Futures and Options Trading System - Protocol for Non-Neat Front End
Chapter 8 Bhavcopy
The bhavcopy is broadcasted at the end of the day. Firstly, a message is sent that the broadcast
of the bhavcopy will start now. Next the header is sent indicating that actual data will follow this
packet. Then the data for non-depository is sent. On completion of the data of the depository
securities, a packet follows stating that the bhavcopy for the depository securities will be
broadcasted after this packet. Thereafter, the data for the depository securities is broadcasted.
This follows the trailer record, marking the end of bhavcopy.
Bhavcopy Broadcast
Bhavcopy is sent after closing of trading hours. However, Futures and Options trading system
will have the capability to have different trading sessions for various underlying assets. As such,
separate bhavcopy will be generated for each trading session.
system will be capable of having different trading sessions, this document is restricted to
describe changes with respect to one such trading session. This trading session is referred as
There are no changes in the structure of the bhavcopy broadcast, the values in Message Type
field available in the current structure will be used to identify the trading session for which the
bhavcopy is being broadcasted. The changes in the Message Type field value for various
bhavcopy structures are presented as follows:
This is the first message broadcasted that the bhavcopy will be started now. The structure sent
is:
128
Futures and Options Trading System - Protocol for Non-Neat Front End
The header for the bhavcopy is sent before actual data packet. The message structure sent is
MS_RP_HDR. To identify the type of bhavcopy broadcast, the Message type field will be used.
The value for Regular Trading Session bhavcopy, Additional Trading Session bhavcopy and final
REPORT HEADER
Table 46 MS_RP_HDR
Structure Name MS_RP_HDR
Packet Length 108 bytes
Transaction Code RPRT_MARKET_STATS_OUT_RPT
(1833)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
MessageType CHAR 1 40
ReportDate LONG 4 41
UserType SHORT 2 45
BrokerId CHAR 5 47
FirmName CHAR 25 52
TraderNumber LONG 4 77
TraderName CHAR 26 81
The following table provides the details of the various fields present in the Report Header
structure.
129
Futures and Options Trading System - Protocol for Non-Neat Front End
The actual data packet is sent after the report header. The message structure sent is
MS_RP_MARKET_STATS. To identify the type of bhavcopy broadcast, the Message type
field will be used. The value for Regular Trading Session bhavcopy, Additional Trading
REPORT
MARKET STATISTICS
Table 47 MS_RP_MARKET_STATS
Structure Name MS_RP_MARKET_STATS
Packet Length 488 bytes
Transaction Code RPRT_MARKET_STATS_OUT_RPT (1833).
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
MessageType CHAR 1 40
Reserved CHAR 1 41
NumberOfRecords SHORT 2 42
MKT_STATS_DATA[6] STRUCT 74 44
Table 48 MKT_STATS_DATA
Structure Name MKT_STATS_DATA
Packet Length 74 bytes
Field Name Data Type Size in Byte Offset
CONTRACT_DESC (Refer to Order STRUCT 28 0
Entry Request in Chapter 4)
130
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the Report on market
Statistics structure.
This field is
NumberOfRecords This field contains the number of markets for which Market
Statistics is being sent. In a packet, maximum 6 records can
be packed.
Symbol This field contains the Symbol of the security.
Series This field contains the series of a security.
MarketType This field contains one of the following values.
OpenPrice This field contains the open price of a security.
HighPrice This field the highest trade price.
LowPrice This field contains the lowest trade price.
131
Futures and Options Trading System - Protocol for Non-Neat Front End
PreviousClosePrice
Table 49 MKT_IDX_RPT_DATA
Structure Name MKT_IDX_RPT_DATA
Packet Length 66 bytes
Transaction Code MKT_IDX_RPT_DATA (1836).
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
MessageType CHAR 1 40
IndexName CHAR 15 41
MKT_INDEX STRUCT 10 56
Table 50 MKT_INDEX
Structure Name MKT_INDEX
Packet Length 10 bytes
Field Name Data Type Size in Byte Offset
Opening SHORT 2 0
High SHORT 2 2
Low SHORT 2 4
Closing SHORT 2 6
Start SHORT 2 8
The following table provides the details of the various fields present in the Market Index Report
structure.
132
Futures and Options Trading System - Protocol for Non-Neat Front End
INDUSTRY_INDEX_REPORT
Table 51 IND_IDX_RPT_DATA
Structure Name IND_IDX_RPT_DATA
Packet Length 394 bytes
Transaction Code IND_IDX_RPT_DATA (1837).
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
MessageType CHAR 1 40
Reserved CHAR 1 41
NumberOf IndustryRecords SHORT 2 42
INDUSTRY_INDEX[10] STRUCT 35 44
Table 52 INDUSTRY_INDEX
Structure Name INDUSTRY_INDEX
Packet Length 35 bytes
Field Name Data Type Size in Byte Offset
IndustryName CHAR 15 0
Opening LONG 4 15
High LONG 4 19
Low LONG 4 23
Closing LONG 4 27
Start LONG 4 31
133
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the Industry Index
Report structure.
SECTOR_INDEX_REPORT
Table 53 SECT_IDX_RPT_DATA
Structure Name SECT_IDX_RPT_DATA
Packet Length 248 bytes
Transaction Code SECT_IDX_RPT_DATA (1838).
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
MessageType CHAR 1 40
IndustryName CHAR 15 41
NumberOf Industry Records SHORT 2 56
INDEX_DATA[10] STRUCT 19 58
Table 54 INDEX_DATA
Structure Name INDEX_DATA
Packet Length 19 bytes
Field Name Data Type Size in Byte Offset
SectorName CHAR 15 0
IndexValue LONG 4 15
134
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the Sector Index Report
structure.
Trailer Record
After all the data packets are sent, trailer record is sent to indicate the end of Bhavcopy
transmission. The message structure sent is MS_RP_TRAILER. To identify the type of
bhavcopy, broadcast the Message type field will be used. The value for Regular Trading
Session, Additional Trading Session and final bhavcopy w
.The structure is:
REPORT TRAILER
Table 55 MS_RP_TRAILER
Structure Name MS_RP_TRAILER
Packet Length 46 bytes
Transaction Code RPRT_MARKET_STATS_OUT_RPT (1833).
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
MessageType CHAR 1 40
NumberOfPackets LONG 4 41
Reserved CHAR 1 45
The following table provides the details of the various fields present in the Report Trailer
structure.
135
Futures and Options Trading System - Protocol for Non-Neat Front End
r final bhavcopy
NumberOfRecords This contains the number of data packets sent in the
bhavcopy.
Spread Bhavcopy
After completion of early bhavcopy broadcast, spread bhavcopy will be broadcasted. Initially a
message will be sent in the broadcast message transcode BCAST_JRNL_VCT_MSG for the start
of the spread bhavcopy. After the message, the header will be sent to indicate the start of spread
bhavcopy broadcast, which will be followed by actual data packets. After the data packets the
trailer record, marking the end of bhavcopy will be sent. Finally on completion of download, a
The header for the spread bhavcopy is sent before actual data packet. The message structure
sent is MS_RP_HDR. To identify the type of spread bhavcopy, broadcast the Message type field
136
Futures and Options Trading System - Protocol for Non-Neat Front End
will be used. The value for Regular Trading Session, Additional Trading Session and final
REPORT HEADER
Table 56 MS_RP_HDR
Structure Name RP_HDR
Packet Length 108 bytes
Transaction Code SPD_BC_JRNL_VCT_MSG(1862)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
MessageType CHAR 1 40
org_scope CHAR 1 41
report_date LONG 4 42
user_type SHORT 2 46
broker_number CHAR 5 48
broker_name CHAR 25 53
trader_number LONG 4 78
trader_name CHAR 26 82
The following table provides the details of the various fields present in the Report Header
structure.
137
Futures and Options Trading System - Protocol for Non-Neat Front End
The actual data packet is sent after the report header. The message structure sent is
RP_SPD_MKT_STATS. To identify the type of spread bhavcopy broadcast, the Message type
field will be used. The value for Regular Trading Session, Additional Trading Session and final
MARKET STATISTICS
Table 57 RP_SPD_MKT_STATS
Structure Name RP_SPD_MKT_STATS
Packet Length 278 bytes
Transaction Code SPD_BC_JRNL_VCT_MSG (1862).
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
MessageType CHAR 1 40
Reserved CHAR 1 41
NoOfRecords SHORT 2 42
SPD_STATS_DATA[3] STRUCT 78 44
Table 58 SPD_STATS_DATA
Structure Name SPD_STATS_DATA
Packet Length 78 bytes
Field Name Data Type Size in Byte Offset
MARKETTYPE SHORT 2 0
INSTRUMENTNAME1 CHAR 6 2
SYMBOL1 CHAR 10 8
EXPIRYDATE1 LONG 4 18
STRIKEPRICE1 LONG 4 22
OPTIONTYPE1 CHAR 2 26
CALEVEL1 SHORT 2 28
INSTRUMENTNAME2 CHAR 6 30
SYMBOL2 CHAR 10 36
EXPIRYDATE2 LONG 4 46
STRIKEPRICE2 LONG 4 50
OPTIONTYPE2 CHAR 2 54
CALEVEL2 SHORT 2 56
OPENPD LONG 4 58
138
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the Spread Market
Statistics Report structure.
NumberOfRecords This field contains the number of markets for which Market
Statistics is being sent. In a packet maximum 3 records can be
packed.
MarketType This field contains one of the following values.
Symbol1/Symbol2 This field contains the Symbol of the security of leg1 and leg2.
Instrument1/Instrum This field contains the instrument type of leg1 contract and leg
ent2 2 contract.
Expirydate1/ExpiryD This field contains the Expiry date of leg 1 and leg2 contract
ate2 respectively.
StrikePrice1/StrikePr This field the strike price1 and strike price 2 of leg1 and leg2
ice2 of spread contract
Note: Will not be used as spread for options are not allowed.
OptionType1/Option This field contains the Option type of leg1 and leg2 of spread
Type2 contract
Note: Will not be used as spread for options are not allowed.
CALevel1/CAlevel2 This field contains the CAlevel value of leg1 and leg2 of spread
contract.
139
Futures and Options Trading System - Protocol for Non-Neat Front End
LowPD This field contains the Low price difference traded for spread
contract
LastTradedPD This field contains the value of last traded price difference of
spread contract.
NoOfContractsTrade This field contains number of contracts traded.
d
Trailer Record
After all the data packets are sent, trailer record is sent to indicate the end of Spread Bhavcopy
transmission. The message structure sent is MS_RP_TRAILER. To identify the type of spread
bhavcopy broadcast, the Message type field will be used. The value for Regular Trading
REPORT TRAILER
Table 59 MS_RP_TRAILER
Structure Name MS_RP_TRAILER
Packet Length 46 bytes
Transaction Code SPD_BC_JRNL_VCT_MSG(1862)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
MessageType CHAR 1 40
NumberOfPackets LONG 4 41
Reserved CHAR 1 45
The following table provides the details of the various fields present in the Trailer Record
structure.
140
Futures and Options Trading System - Protocol for Non-Neat Front End
NumberOfPackets This contains the number of data packets sent in the spread
bhavcopy.
Note: This is sent as 0 from host
141
Futures and Options Trading System - Protocol for Non-Neat Front End
Chapter 9 Broadcast
This section describes the Compression and Decompression algorithm of Broadcast data and
the various Broadcast messages with their structures.
LZO compression algorithm is used to compress the above specified broadcast transaction
codes. The details of the LZO compression algorithm are described later.
The LZO stands for Lempel Ziv Oberhaumer. This algorithm is freely available on the internet
(URL: http://www.oberhumer.com/opensource/lzo). It is made available by free software
foundation. The algorithm is tested on various operating systems like UNIX and red hat Linux.
Sequential Packing
To improve the effective data transfer, the idea of sequential packing along with the LZO
compression algorithm has been incorporated. At the host end, sequential packing algorithm
packs the incoming data packets, which is then transmitted over the network. The data packets
are packed in FIFO order.
142
Futures and Options Trading System - Protocol for Non-Neat Front End
For example,
arranged in the following order:
1st packet will be stored at the first place in the buffer, 2 nd packet will be stored at the second
place, and so on.
At the front end while unpacking the buffer, the packets are to be segregated in the same order,
that is, isolate each packet and process each packet as per the sequence viz- first packet first
and last packet at the end. The packets within a buffer may be an admixture of compressed and
uncompressed data packets.
Host End Sends Front End Receives Front end Unpacking
Process
packets
1
2
1
1
2
2
3
Add
3
3
Up -
-
-
-
-
-
N
n
Structure
n
Incoming packet at the front end can be interpreted by mapping onto the following structure.
Struct {
CHAR cNetId [2]
SHORT iNoPackets
CHAR cPackData [512]
} BcastPackData
where,
143
Futures and Options Trading System - Protocol for Non-Neat Front End
Equity:- 4
Equity Derivative:- 2
Currency Derivative:- 6
iNoPackets The number of packets that are sequentially packed
cPackData Buffer containing all the packets.
The buffer when mapped to, by the above structure, the number of packets in the buffer can be
known. The next task is to segregate the packets and process the individual packets.
Pseudocode
struct {
SHORT iCompLen
CHAR cCompData [MAX_MESSAGE_SIZE]
}BcastCmpPacket
Note: The above structure is currently used to interpret the incoming packets.
The iCompLen intimates us whether the packet is compressed or uncompressed. For the
compressed packets (iCompLen > 0) pass the buffer to the decompression routine, else follow
the uncompressed packet routing.
The packets received through the broadcast traffic have to be interpreted as follows
COMPRESSION_BROADCAST_DATA
{
SHORT CompressionLen
CHAR BroadcastData [ ]
}
The first two bytes of the broadcast packet indicate the length of the data after
compression.
If the compression length is zero, the data received is not compressed.
If the length is non-zero, the data following the length should be decompressed
by using the decompression routine.
Inside the broadcast data, the first 8 bytes before the message header/ broadcast
header should be
ignored. The message header/ broadcast header starts from the 9th byte.
144
Futures and Options Trading System - Protocol for Non-Neat Front End
The LZO directory (lzo1.07) contains all the LZO source, header and library files. These files are
to be included while building an application.
Sample Implementation using MS-Visual Studio VC++ 6.0:
Put lzo 1.07 folder in C drive
Go to Microsoft Visual C++
Go to Tools -> Options -> Directories [ALT T O]
Set the fo
A Include files C:\lzo1.07
B Library files C:\lzo1.07
C Source files C:\lzo1.07
145
Futures and Options Trading System - Protocol for Non-Neat Front End
Note:
Inside the broadcast data, the first byte indicates the market type. Ignore the rest of the 7 bytes
before message header/ broadcast header
Options market.
The message header/ broadcast header starts from 9th byte. The remaining portion of the buffer
has to be mapped as usual from the message header/ broadcast header to the following
structures as specified from Chapter 4 to Chapter 10.
The following table provides the details of the various fields present in the General Message
Broadcast structure.
146
Futures and Options Trading System - Protocol for Non-Neat Front End
147
Futures and Options Trading System - Protocol for Non-Neat Front End
148
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 61 ST_SEC_ELIGIBILITY_PER_MARKET
Structure Name ST_SEC_ELIGIBILITY_PER_MKT
Packet Length 3 bytes
Field Name Data Type Size Offset
For Small Endian Machines
Reserved BIT 7 0
Eligibility BIT 1 0
Status SHORT 2 1
For Big Endian Machines
Eligibility BIT 1 0
Reserved BIT 7 0
Status SHORT 2 1
Table 62 ST_ELIGIBILITY_INDICATORS
Structure Name ST_ELIGIBILITY_INDICATORS
Packet Length 2 bytes
Field Name Data Type Size Offset
For Small Endian Machines
Reserved BIT 5 0
MinimumFill BIT 1 0
AON BIT 1 0
ParticipateInMarketIndex BIT 1 0
Reserved CHAR 1 1
For Big Endian Machines
ParticipateInMarketIndex BIT 1 0
AON BIT 1 0
MinimumFill BIT 1 0
149
Futures and Options Trading System - Protocol for Non-Neat Front End
Reserved BIT 5 0
Reserved CHAR 1 1
Table 63 ST_PURPOSE
Structure Name ST_PURPOSE
Packet Length 2 bytes
Field Name Data Type Size Offset
For Small Endian Machines
Exercise Style BIT 1 0
Reserved BIT 1 0
EGM BIT 1 0
AGM BIT 1 0
Interest BIT 1 0
Bonus BIT 1 0
Rights BIT 1 0
Dividend BIT 1 0
Reserved BIT 3 1
Is Corporate Adjusted BIT 1 1
Is This Asset BIT 1 1
Pl Allowed BIT 1 1
Ex Rejection Allowed BIT 1 1
Ex Allowed BIT 1 1
For Big Endian Machines
Dividend BIT 1 0
Rights BIT 1 0
Bonus BIT 1 0
Interest BIT 1 0
AGM BIT 1 0
EGM BIT 1 0
Reserved BIT 1 0
Exercise Style BIT 1 0
Ex Allowed BIT 1 1
Ex Rejection Allowed BIT 1 1
Pl Allowed BIT 1 1
Is This Asset BIT 1 1
Is Corporate Adjusted BIT 1 1
Reserved BIT 3 1
150
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the Security Master
structure.
Field Name Brief Description
TransactionCode The transaction code is BCAST_SECURITY_MSTR_CHG
(7305).
Token This field contains the token number of the security being
updated. This is unique for a particular symbol-series
combination.
SecurityInformation This contains the Symbol and Series (EQ / IL / TT) of the
security.
PermittedToTrade This field contains one of the following values.
- Listed but not permitted to trade.
- Permitted to trade.
IssuedCapital This field contains the issue size of the security.
WarningQuantity This field contains the warning quantity.
FreezeQuantity This field contains the freeze quantity.
CreditRating This field contains the credit rating of the security.
Eligibility
particular market.
Status This field contains one of the following values.
- Open
- Suspended
- Pre-open extended
151
Futures and Options Trading System - Protocol for Non-Neat Front End
152
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 64 MS_INSTRUMENT_UPDATE_INFO
Structure Name MS_INSTRUMENT_UPDATE_INFO
Packet Length 80 bytes
Transaction Code BCAST_INST_MSTR_CHG (7324)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
InstrumentId SHORT 2 40
153
Futures and Options Trading System - Protocol for Non-Neat Front End
InstrumentName CHAR 6 42
InstrumentDescription CHAR 25 48
InstrumentUpdateTime LONG 4 73
DeleteFlag CHAR 1 77
The following table provides the details of the various fields present in the Instrument Master
structure.
InstrumentUpdateTime This field contains the time when this record has
been modified.
DeleteFlag This field contains one of the following values to
denote whether the instrument is deleted or not.
Table 65 PARTICIPANT_UPDATE_INFO
Structure Name PARTICIPANT_UPDATE_INFO
Packet Length 84 bytes
Transaction Code BCAST_PART_MSTR_CHG (7306)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
ParticipantId CHAR 12 40
154
Futures and Options Trading System - Protocol for Non-Neat Front End
ParticipantName CHAR 25 52
ParticipantStatus CHAR 1 77
ParticipantUpdateDateTime LONG 4 78
DeleteFlag CHAR 1 82
The following table provides the details of the various fields present in the Participant Status
structure.
155
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 67 TOKEN_AND_ELIGIBILITY
Structure Name TOKEN_AND_ELIGIBILITY
Packet Length 12 bytes
Field Name Data Type Size in Byte Offset
Token LONG 4 0
ST_SEC_STATUS_PER_MARKET[4] STRUCT 8 4
Table 68 ST_SEC_STATUS_PER_MARKET
Structure Name ST_SEC_STATUS_PER_MARKET
Packet Length 2 bytes
Field Name Data Type Size in Byte Offset
Status SHORT 2 0
The following table provides the details of the various fields present in the Security Status
structure.
156
Futures and Options Trading System - Protocol for Non-Neat Front End
- Pre-open extended
to all workstations. The same structure is also sent when any broker is reactivated. The structure
is as follows:
Table 69 MS_BROADCAST_LIMIT_EXCEEDED
Structure Name MS_BROADCAST_LIMIT_EXCEEDED
Packet Length 98 bytes
Transaction Code BCAST_TURNOVER_EXCEEDED (9010) and
BROADCAST_BROKER_REACTIVATED (9011)
Field Name Data Type Size in Byte Offset
BCAST_HEADER(Refer to STRUCT 40 0
BCAST_HEADER in Chapter 2)
BrokerCode CHAR 5 40
CounterBrokerCode CHAR 5 45
WarningType SHORT 2 50
Token LONG 4 52
InstrumentName CHAR 6 56
Symbol CHAR 10 62
ExpiryDate LONG 4 72
StrikePrice LONG 4 76
OptionType CHAR 2 80
CA Level SHORT 2 82
TradeNumber LONG 4 84
TradePrice LONG 4 88
TradeVolume LONG 4 92
Final CHAR 1 96
Filler CHAR 1 97
The following table provides the details of the various fields present in the <XYZ> structure.
157
Futures and Options Trading System - Protocol for Non-Neat Front End
158
Futures and Options Trading System - Protocol for Non-Neat Front End
Following message codes will still be sent, in case of Market opening for the second time during
the day e.g. during sun outage, circuit hit
BC_PRE_OR_POST_DAY_MSG (6531). This is sent when the market is preopened.
BC_PRE_OPEN_ENDED (6571). This is sent when the pre-open period ends.
BC_OPEN_MSG (6511). This is sent when the market is opened.
Whenever the status of the market changes, the following structure is sent:
BCAST_VCT_MESSAGES
Table 70 MS_BCAST_VCT_MSGS
Structure Name MS_BCAST_VCT_MSGS
Packet Length 320 bytes
Transaction Code BCAST_TURNOVER_EXCEEDED (9010) and
BROADCAST_BROKER_REACTIVATED (9011)
Field Name Data Type Size in Byte Offset
BCAST_HEADER(Refer to STRUCT 40 0
BCAST_HEADER in Chapter 2)
Token LONG 4 40
SEC_INFO (Refer to SEC_INFO in STRUCT 30 44
Chapter 5)
MarketType SHORT 2 74
ST_BCAST_DESTINATION STRUCT 2 76
BroadcastMessageLength SHORT 2 78
BroadcastMessage CHAR 239 80
The following table provides the details of the various fields present in the Market Status
structure.
159
Futures and Options Trading System - Protocol for Non-Neat Front End
In addition : To identify the category of the market in the message, the existing field
broadcast message header (BCAST_HEADER) of the message structure
MS_BCAST_VCT_MSG, will contain values as indicated below
160
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 71 MS_TICKER_TRADE_DATA
Structure Name MS_TICKER_TRADE_DATA
Packet Length 484 bytes
Transaction Code BCAST_TICKER_AND_MKT_INDEX (7202)
Field Name Data Type Size in Byte Offset
BCAST_HEADER(Refer to STRUCT 40 0
BCAST_HEADER in Chapter 2)
Number of Records SHORT 2 40
ST_TICKER_INDEX_INFO[17] STRUCT 26 42
Table 72 ST_TICKER_INDEX_INFO
Structure Name ST_TICKET_INDEX_INFO
Packet Length 26 bytes
Field Name Data Type Size in Byte Offset
Token LONG 4 0
MarketType SHORT 2 4
FillPrice LONG 4 6
FillVolume LONG 4 10
OpenInterest LONG 4 14
DayHiOI LONG 4 18
DayLoOI LONG 4 22
The following table provides the details of the various fields present in the Ticker and Market
Index structure.
Field Name Brief Description
TransactionCode The transaction code sent is
BCAST_TICKER_AND_MKT_INDEX (7202).
NumberOfRecords This field contains the number of times (maximum 17) the
structure TICKER INDEX INFORMATION is repeated.
Token This field contains the token number, which is a unique
number given to a particular symbol-series combination.
161
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 73 MS_BCAST_MBO_MBP
Structure Name MS_BCAST_MBO_MBP
Packet Length 410 bytes
Transaction Code BCAST_MBO_MBP_UPDATE (7200)
Field Name Data Type Size in Byte Offset
BCAST_HEADER(Refer to STRUCT 40 0
BCAST_HEADER in Chapter 2)
ST_INTERACTIVE_MBO_DATA STRUCT 235 40
Record Buffer CHAR Sizeof(ST_M 275
BP_INFO)*1
0
Total Buy Quantity DOUBLE 8 375
Total Sell Quantity DOUBLE 8 383
ST_INDICATOR STRUCT 2 391
ClosingPrice LONG 4 393
OpenPrice LONG 4 397
HighPrice LONG 4 401
LowPrice LONG 4 405
162
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 74 ST_INTERACTIVE_MBO_DATA
Structure Name ST_INERACTIVE_MBO_DATA
Packet Length 235 bytes
Field Name Data Type Size in Byte Offset
Token LONG 4 0
BookType SHORT 2 4
TradingStatus SHORT 2 6
VolumeTradedToday LONG 4 8
LastTradedPrice LONG 4 12
NetChangeIndicator CHAR 1 16
NetPriceChangeFromClosingPrice LONG 4 17
LastTradeQuantity LONG 4 21
LastTradeTime LONG 4 25
AverageTradePrice LONG 4 29
AuctionNumber SHORT 2 33
AuctionStatus SHORT 2 35
InitiatorType SHORT 2 37
InitiatorPrice LONG 4 39
InitiatorQuantity LONG 4 43
AuctionPrice LONG 4 47
AuctionQuantity LONG 4 51
RecordBuffer CHAR Sizeof(ST_M 55
BO_INFO)*1
0
Table 75 ST_MBO_INFO
Structure Name ST_MBO_INFO
Packet Length 18 bytes
Field Name Data Type Size in Byte Offset
TraderId LONG 4 0
Qty LONG 4 4
Price LONG 4 8
ST_MBO_MBP_TERMS STRUCT 2 12
Min Fill Qty LONG 4 14
163
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 76 ST_MBP_INFO
Structure Name ST_MBP_INFO
Packet Length 10 bytes
Field Name Data Type Size in Byte Offset
Qty LONG 4 0
Price LONG 4 4
NoOfOrders SHORT 2 8
Table 77 ST_INDICATOR
Structure Name ST_INDICATOR
Packet Length 2 bytes
Field Name Data Type Size Offset
For Small Endian Machines
Reserved BIT 4 0
Sell BIT 1 0
Buy BIT 1 0
Last Trade Less BIT 1 0
Last Trade More BIT 1 0
Reserved CHAR 1 1
For Big Endian Machines
Last Trade More BIT 1 0
Last Trade Less BIT 1 0
Buy BIT 1 0
Sell BIT 1 0
Reserved BIT 4 0
Reserved CHAR 1 1
Table 78 ST_MBO_MBP_TERMS
Structure Name ST_MBO_MBP_TERMS
Packet Length 2 bytes
Field Name Data Type Size Offset
For Small Endian Machines
Reserved BIT 6 0
AON BIT 1 0
MF BIT 1 0
Reserved CHAR 1 1
For Big Endian Machines
164
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
MS_BCAST_MBO_MBP structure.
LastTradedPrice This field contains the price at which the latest trade in a
security has taken place.
165
Futures and Options Trading System - Protocol for Non-Neat Front End
LastTradeQuantity This field contains the quantity at which the last trade
took place in a security.
LastTradeTime This field contains the time when the last trade took
place in a security.
AverageTradePrice This field contains the average price of all the trades in a
security.
AuctionNumber This field contains the auction number. The maximum
value this field can take is 9999. It is set to zero other
than auction.
166
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 80 INTERACTIVE_ONLY_MBP_DATA
Structure Name INTERACTIVE_ONLY_MBP_DATA
Packet Length 213 bytes
Field Name Data Type Size in Byte Offset
Token LONG 4 0
BookType SHORT 2 4
167
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 81 MBP_INFORMATION
Structure Name MBP_INFORMATION
Packet Length 12 bytes
Field Name Data Type Size in Byte Offset
Quantity LONG 4 0
Price LONG 4 4
168
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
MS_BCAST_ONLY_MBP structure.
169
Futures and Options Trading System - Protocol for Non-Neat Front End
170
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 82 MS_BCAST_INQ_RESP_2
Structure Name MS_BCAST_INQ_RESP_2
Packet Length 472 bytes
Transaction Code BCAST_MW_ROUND_ROBIN (7201)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
NoOfRecords SHORT 2 40
ST_MARKET_WATCH_BCAST[5] STRUCT 86 42
Table 83 ST_MARKET_WATCH_BCAST
Structure Name ST_MARKET_WATCH_BCAST
Packet Length 86 bytes
Field Name Data Type Size in Byte Offset
Token LONG 4 0
ST_MKT_WISE_INFO [3] STRUCT 26 4
OpenInterest LONG 4 82
Table 84 ST_MKT_WISE_INFO
Structure Name ST_MKT_WISE_INFO
Packet Length 26 bytes
Field Name Data Type Size in Byte Offset
ST_INDICATOR (Refer to STRUCT 2 0
ST_INDICATOR structure in Chapter
9)
BuyVolume LONG 4 2
BuyPrice LONG 4 6
SellVolume LONG 4 10
SellPrice LONG 4 14
171
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
MS_BCAST_INQ_RESP_2 structure.
Table 85 MS_SEC_OPEN_MSGS
Structure Name MS_SEC_OPEN_MSGS
Packet Length 62 bytes
Transaction Code SECURITY_OPEN_PRICE (6013)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
Symbol CHAR 10 40
172
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
MS_SEC_OPEN_MSGS structure.
Token This field contains the token number which is a unique number given
to a particular symbol-series combination.
OpeningPrice This field contains the open price of the security.
173
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 86 MS_BCAST_INDICES
Structure Name MS_BCAST_INDICES
Packet Length 468 bytes
Transaction Code BCAST_INDICES (7207)
Field Name Data Type Size in Byte Offset
BCAST_HEADER (Refer to Broadcast STRUCT 40 0
Process Header in Chapter 2)
NumberOfRecords SHORT 2 40
MS_INDICES [6] STRUCT 71 42
Table 87 MS_INDICES
Structure Name MS_INDICES
Packet Length 71 bytes
Field Name Data Type Size in Byte Offset
IndexName CHAR 21 0
IndexValue LONG 4 21
HighIndexValue LONG 4 25
LowIndexValue LONG 4 29
OpeningIndex LONG 4 33
ClosingIndex LONG 4 37
PercentChange LONG 4 41
YearlyHigh LONG 4 45
YearlyLow LONG 4 49
NoOfUpmoves LONG 4 53
NoOfDownmoves LONG 4 57
Market Capitalisation DOUBLE 8 61
NetChangeIndicator CHAR 1 69
Reserved CHAR 1 70
The following table provides the details of the various fields present in the
MS_BCAST_INDICES structure.
174
Futures and Options Trading System - Protocol for Non-Neat Front End
175
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 89 INDUSTRY_INDICES
Structure Name INDUSTRY_INDICES
Packet Length 20 bytes
Field Name Data Type Size in Byte Offset
IndustryName CHAR 15 0
IndexValue LONG 4 15
The following table provides the details of the various fields present in the
MS_BCAST_INDUSTRY_INDICES structure.
176
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 90 MS_GLOBAL_INDICES
Structure Name MS_GLOBAL_INDICES
Packet Length 138 bytes
Transaction Code GI_INDICES_ASSETS (7732)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
INDEX_DETAILS STRUCT 98 40
Table 91 INDEX_DETAILS
Structure Name INDEX_DETAILS
Packet Length 98 bytes
Field Name Data Type Size in Byte Offset
Token LONG 4 0
Name CHAR 50 4
Open LONG 4 54
High LONG 4 58
Low LONG 4 62
Last LONG 4 66
Close LONG 4 70
PrevClose LONG 4 74
LifeHigh LONG 4 78
LifeLow LONG 4 82
filler1 LONG 4 86
filler2 LONG 4 90
filler3 LONG 4 94
The following table provides the details of the various fields present in the
MS_GLOBAL_INDICES structure.
177
Futures and Options Trading System - Protocol for Non-Neat Front End
The new transcode MS_GLOBAL_CONTRACTS will be sent for the broadcast of Global Indices
contracts. The Structure for same is given as follows:
Table 92 MS_GLOBAL_CONTRACTS
Structure Name MS_GLOBAL_CONTRACTS
Packet Length 162 bytes
Transaction Code GI_CONTRACT_ASSETS (7733)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer to STRUCT 40 0
MESSAGE_HEADER in Chapter 2)
CONTRACT_DETAILS STRUCT 122 40
Table 93 CONTRACTS_DETAILS
Structure Name CONTRACTS_DETAILS
Packet Length 122 bytes
Field Name Data Type Size in Byte Offset
Token LONG 4 0
NseSymbol CHAR 16 4
InstrumentName CHAR 6 20
ExpDay SHORT 2 26
ExpMonth SHORT 2 28
ExpYear SHORT 2 30
OptionType CHAR 2 32
StrikePrice LONG 4 34
BidPrice LONG 4 38
178
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
MS_GLOBAL_CONTRACTS structure.
179
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 94 MS_SPD_MKT_INFO
Structure Name MS_SPD_MKT_INFO
Packet Length 204 bytes
Transaction Code BCAST_SPD_MBP_DELTA (7211)
Field Name Data Type Size in Byte Offset
BCAST_HEADER(Refer to STRUCT 40 0
BCAST_HEADER in Chapter 2)
Token1 LONG 4 40
Token2 LONG 4 44
MbpBuy SHORT 2 48
180
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 95 MbpBuys
Structure Name MbpBuys
Packet Length 10 bytes
Field Name Data Type Size in Byte Offset
NoOrders SHORT 2 0
Volume LONG 4 2
Price LONG 4 6
Table 96 MbpSells
Structure Name MbpSells
Packet Length 10 bytes
Field Name Data Type Size in Byte Offset
NoOrders SHORT 2 0
Volume LONG 4 2
Price LONG 4 6
Table 97 TotalOrderVolume
Structure Name TotalOrderVolume
Packet Length 16bytes
Field Name Data Type Size in Byte Offset
Buy DOUBLE 8 0
Sell DOUBLE 8 8
181
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
MS_SPD_MKT_INFO structure.
182
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 98 CM_ASSSET_OI
Structure Name CM_ASSET_OI
Packet Length 504 bytes
Transaction Code MKT_MVMT_CM_OI_IN (7130)
Field Name Data Type Size in Byte Offset
Reserved CHAR 2 0
Reserved CHAR 2 2
LogTime LONG 4 4
MarketType CHAR 2 8
TransactionCode SHORT 2 10
NoOfRecords SHORT 2 12
Reserved CHAR 8 14
TimeStamp LONG LONG 8 22
Reserved CHAR 8 30
MessageLength SHORT 2 38
OPEN_INTEREST [58] STRUCT 8 40
183
Futures and Options Trading System - Protocol for Non-Neat Front End
Table 99 OPEN_INTEREST
Structure Name OPEN_INTEREST
Packet Length 8 bytes
Field Name Data Type Size in Byte Offset
TokenNo LONG 4 0
CurrentOI LONG 4 4
184
Futures and Options Trading System - Protocol for Non-Neat Front End
185
Futures and Options Trading System - Protocol for Non-Neat Front End
Message Formats
Change to packet format
186
Futures and Options Trading System - Protocol for Non-Neat Front End
Note: Member systems must populate relevant User ID field in the header.
187
Futures and Options Trading System - Protocol for Non-Neat Front End
GR_REQUEST
Structure Name MS_GR_REQUEST
Packet Length 48 bytes
Transaction Code GR_REQUEST (2400)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER STRUCT 40 0
Box ID SHORT 2 40
BrokerID CHAR 5 42
Filler CHAR 1 47
GR_RESPONSE
Structure Name MS_GR_RESPONSE
Packet Length 76 bytes
Transaction Code GR_RESPONSE(2401)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER STRUCT 40 0
Box ID SHORT 2 40
BrokerID CHAR 5 42
Filler CHAR 1 47
IP Address CHAR 16 48
Port LONG 4 64
Session Key CHAR 8 68
188
Futures and Options Trading System - Protocol for Non-Neat Front End
BOX_SIGN_ON_REQUEST_IN
Structure Name MS_BOX_SIGN_ON_REQUEST_IN
Packet Length 60 bytes
Transaction Code BOX_SIGN_ON_REQUEST_IN(23000)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER STRUCT 40 0
BoxId SHORT 2 40
BrokerId CHAR 5 42
Reserved CHAR 5 47
SessionKey CHAR 8 52
BOX_SIGN_ON_REQUEST_OUT
Structure Name MS_BOX_SIGN_ON_REQUEST_OUT
Packet Length 52 bytes
Transaction Code BOX_SIGN_ON_REQUEST_OUT(23001)
Field Name Data Type Size in Byte Offset
189
Futures and Options Trading System - Protocol for Non-Neat Front End
MESSAGE_HEADER STRUCT 40 0
BoxId SHORT 2 40
Reserved CHAR 10 42
A few fields in the Logon message (transaction code 2300) have to be populated differently for
direct connection:
How to Logoff?
To logoff from the exchange trading system, there is no change and use the existing protocol
defined in Chapter 3 of protocol document.
190
Futures and Options Trading System - Protocol for Non-Neat Front End
Heartbeat exchange
Member systems must exchange heartbeat signals with exchange trading system during periods
of inactivity. Trading Host will consider the member system as inactive after missing two
heartbeats in succession, and disconnect the socket connection. Heartbeats will carry following
data in MessageData segment of the message. Heartbeat is to be sent only if there is inactivity
for 30 seconds. The format is MESSAGE_HEADER with following detail.
Connection Termination
When the connection is terminated by exchange, exchnage will send Sign off packet (transaction
code: 20322) with appropriate error code (Refer to List of Error Codes in Appendix).
191
Futures and Options Trading System - Protocol for Non-Neat Front End
MS_BOX_SIGN_OFF
Structure Name MS_BOX_SIGN_OFF
Packet Length 42 bytes
Transction code BOX_SIGN_OFF (20322)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER STRUCT 40 0
BoxId SHORT 2 40
192
Futures and Options Trading System - Protocol for Non-Neat Front End
Message structure
Message structure is as follows:
MS_BCAST_CONT_MESSAGE
Structure Name MS_BCAST_CONT_MESSAGE
Packet Length 244 bytes
Transaction Code BCAST_CONT_MSG (5294).
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER STRUCT 40 0
StreamNumber SHORT 2 40
Status SHORT 2 42
Reserved CHAR 200 44
193
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides details of the various fields present in above Message structure.
194
Futures and Options Trading System - Protocol for Non-Neat Front End
Branch order value limit will be applicable to users available in the branch.
Branch Order Value Limit Update Request
The following table provides the details of the various fields present in the
BRANCH_ORD_VAL_LIMIT_UPDATE_REQ structure.
195
Futures and Options Trading System - Protocol for Non-Neat Front End
On successful branch limit updates, exchange will send Branch Order Limit Update Response to
- Corporate manager
- Branch manager(of branch id mentioned in request)
The following table provides the details of the various fields present in the
BRANCH_ORD_VAL_LIMIT_UPDATE_REQ structure.
196
Futures and Options Trading System - Protocol for Non-Neat Front End
If branch order value limit update request is rejected by trading system then Error response
packet will be sent to user who has sent limit update request. Reason for rejection will be given
by ErrorCode in the header and ErrorMessage in the packet.
The following table provides the details of the various fields present in the
MS_ERROR_RESPONSE structure.
197
Futures and Options Trading System - Protocol for Non-Neat Front End
USER_LIMITS[2] STRUCT 64 80
The following table provides the details of the various fields present in the
USER_ORD_VAL_LIMIT_UPDATE_REQ structure.
On successful user limit updates, exchange will send User Order Limit Update Response to
- user who has sent limit update request
198
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
USER_ORD_VAL_LIMIT_UPDATE_REQ structure.
If user order value limit update request is rejected by trading system then error response
packet will be sent to user who has sent limit update request. Reason for rejection will be given
by Errorcode in the header ErrorMessage in the packet.
The following table provides the details of the various fields present in the
MS_ERROR_RESPONSE structure.
Order Limit
This functionality provides facility to specify maximum quantity per order and maximum value
per order that user can enter in order entry/ modification request.
199
Futures and Options Trading System - Protocol for Non-Neat Front End
Corporate manager can set limit on order quantity and order value of an order, entered by user
Similarly Branch manager can set limit on order quantity and
order value of an order entered by user within the branch.
The following table provides the details of the various fields present in the
NORMAL_ORD_LIMIT_UPDATE_REQ structure.
200
Futures and Options Trading System - Protocol for Non-Neat Front End
On successful normal order limit updates, exchange will send Normal Order Limit Update
Response to
- user who has sent limit update request
- user for which limit has been set
- Corporate manager (if branch manager tries to update limit for user within branch).
If normal order limit update request is rejected by trading system then Normal Order Limit
Update Response packet will be sent to user who has sent limit update request. Reason for
rejection will be given by ErrorCode in the header.
The following table provides the details of the various fields present in the
NORMAL_ORD_LIMIT_UPDATE_REQ structure.
Similar to Normal order limit update, spread order limits can also be updated with below
mentioned request.
NORMAL_ORD_LIMIT_UPDATE_REQ (Refer to Normal Order Limit Update Request in Chapter
12)
The following table provides the details of the various fields present in the
NORMAL_ORD_LIMIT_UPDATE_REQ structure.
201
Futures and Options Trading System - Protocol for Non-Neat Front End
On successful spread order limit updates, exchange will send Spread Order Limit Update
Response to
- user who has sent limit update request
- user for which limit has been set
- Corporate manager (if branch manager tries to update limit for user within branch).
If spread order limit update request is rejected by trading system then Spread Order Limit
Update Response packet will be sent to user who has sent limit update request. Reason for
rejection will be given by ErrorCode in the header.
The following table provides the details of the various fields present in the
NORMAL_ORD_LIMIT_UPDATE_REQ structure.
202
Futures and Options Trading System - Protocol for Non-Neat Front End
Reset UserId
This functionality enables the Corporate Manager to terminate the active session for users
e active session for
users within the branch.
The following table provides the details of the various fields present in the MS_SIGNON
structure.
In below mentioned scenarios, exchange trading system will send User Reset Response to
user who has sent user reset request,
- On Successful user session reset
The following table provides the details of the various fields present in the MS_SIGNON
structure.
If User Reset request is rejected by trading system then Error Response packet will be sent
to user who has sent user reset request. Reason for rejection will be given by ErrorCode in the
header and ErrorMessage in the packet.
203
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
MS_ERROR_RESPONSE structure.
Reset Password
User whose p
On resetting the password of disabled user, status of the user will be changed to
inactive.
The Corporate Manager will not be allowed to reset password for other corporate
manager.
204
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
RESET_USER_PASSWORD_IN_FO structure.
In below mentioned scenarios, exchange trading system will send User password reset
response to user who has sent user password reset request
- On Successful user password reset
- If user password reset request is rejected by exchange trading system
(Reason for rejection will be given by ErrorCode in the header.)
The following table provides the details of the various fields present in the
RESET_USER_PASSWORD_IN_FO structure.
205
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
COL_USER_STATUS_CHANGE_IN structure.
In below mentioned scenarios, exchange trading system will send User COL Status Update
response to user who has sent status update request
- On Successful COL status updates
- If User COL status update request is rejected by exchange trading system
(Reason for rejection will be given by ErrorCode in the header.)
206
Futures and Options Trading System - Protocol for Non-Neat Front End
Reserved CHAR 1 45
The following table provides the details of the various fields present in the
COL_USER_STATUS_CHANGE_OUT structure.
Also, in case of successful COL status update, trading system will send interactive
message to
- user who has sent status update request
- user for which status has been updated
- Branch manager (if the status update is done for the dealer under his branch).
- Other Branch managers of same branch (if status update is done for Branch manager).
The following table provides the details of the various fields present in the
MS_TRADER_INT_MSG Structure.
207
Futures and Options Trading System - Protocol for Non-Neat Front End
If Trade Modification status for user is enabled then user will be allowed to send Trade
modification request to exchange trading system.
The following table provides the details of the various fields present in the
USER_TRD_MOD/CXL_STATUS_CHG_REQ structure.
208
Futures and Options Trading System - Protocol for Non-Neat Front End
On successful Trade Mod status update, trading system will send User TRD-MOD Status
Update Response to the user who has sent status update request as well as to the user for
which TRD-MOD status has been set.
If User TRD-MOD status update request is rejected by trading system, then status update
response packet will be sent to user who has sent status update request.
Reason for rejection will be given by ErrorCode in the header.
The following table provides the details of the various fields present in the
USER_TRD_MOD/CXL_STATUS_CHG_RESP structure.
209
Futures and Options Trading System - Protocol for Non-Neat Front End
Also, in case of successful Trade Mod status update, trading system will send interactive
message to
- user who has sent status update request
- user for which status has been updated
- Branch manager (if the status update is done for the dealer under his branch).
- Other Branch managers of same branch (if status update is done for Branch manager).
The following table provides the details of the various fields present in the
MS_TRADER_INT_MSG Structure.
If Trade Cancellation status for user is enabled then user will be allowed to send Trade
cancellation request to exchange trading system.
210
Futures and Options Trading System - Protocol for Non-Neat Front End
UserId This field should contain user id for which trade cxl status to be
set.
TrdModCxlBit
set. It should contain one of following values,
On successful Trade Cxl status update, trading system will send User TRD-CXL Status Update
Response to the user who has sent status update request as well as to the user for which TRD-
CXL status has been set.
If User TRD-CXL status update request is rejected by trading system, then status update
response packet will be sent to user who has sent status update request.
Reason for rejection will be given by ErrorCode in the header.
211
Futures and Options Trading System - Protocol for Non-Neat Front End
Also, in case of successful Trade Cxl status update, trading system will send interactive
message to
- user who has sent status update request
- user for which status has been updated
- Branch manager (if the status update is done for the dealer under his branch).
- Other Branch managers of same branch (if status update is done for Branch manager).
The following table provides the details of the various fields present in the
MS_TRADER_INT_MSG Structure.
Field Name Brief Description
TransactionCode The transaction code is: CTRL_MSG_TO_TRADER (5295).
BroadCastMessage This field contains Message Length
Length
BroadCastMessage This field contains actual Message
Unlock User
firm.
As soon as User Unlock request reaches trading system, User Unlock Requested Response
message is sent to user who has sent Unlock User Request. This in turn generates alert to NSE-
Control user. This alert may be approved or rejected by exchange.
212
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the
USER_ADDR_UNLOCK_REQ_FO structure.
This is an acknowledgement signifying that the User Unlock Request has reached the trading
system. If any error is encountered in the User Unlock Request data then appropriate error
code will be set.
The following table provides the details of the various fields present in the
USER_ADDR_UNLOCK_CONFIRM_FO structure.
213
Futures and Options Trading System - Protocol for Non-Neat Front End
If error code field value is zero (0) then unlock request for user
is made to exchange successfully.
If error code field value is non-zero then unlock request for user
is not initiated. Refer to List of Error Codes in Appendix.
The following table provides the details of the various fields present in the
USER_ID_UNLOCK_APPROVE_FO structure.
On Rejecting the User unlock alert, trading system will send User Unlock Reject Response to
user who has sent User Unlock Request.
The message sent will be of the following format:
USER_ADDR_UNLOCK_APPROVE_FO (refer to User Unlock Approve Response chapter 12)
The following table provides the details of the various fields present in the
USER_ADDR_UNLOCK_APPROVE_FO structure.
Field Name Brief Description
TransactionCode The transaction code is USER_ADDR_UNLOCK_REJECT_OUT
(5484)
214
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the MS_OE_REQUEST
structure.
Field Name Brief Description
TransactionCode The transaction code is KILL_SWITCH_IN (2062).
TraderId This field should contain 0 for Trading Member level kill
switch request.
TokenNumber For cancellation of all orders, token number should be set to
-
For cancellation of orders on particular contract, valid token
number of the contract is to be sent.
SecurityInformation For cancellation of orders on particular contract, this field is
(CONTRACT mandatory.
DESCRIPTOR) This structure contains the following fields:
Instrument Name, Symbol, Expiry Date, Strike Price, Option
Type and CA Level of the contract.
CA Level should be set to zero.
The Member level kill switch error is sent when the request is rejected by the trading system.
The reason for rejection will be given by the Error Code in the header. The message sent is as
follows:
MS_OE_REQUEST (Refer to Order Entry Request in Chapter 4)
The following table provides the details of the various fields present in the MS_OE_REQUEST
structure.
215
Futures and Options Trading System - Protocol for Non-Neat Front End
The kill switch error is sent when the request is rejected by the trading system. The reason for
rejection will be given by the Error Code in the header. The message sent is as follows:
216
Futures and Options Trading System - Protocol for Non-Neat Front End
This functionality enables Corporate Manager and Branch Manager to place orders in the market.
For Order Entry request, please refer Trimmed Order Entry Request Structure from Trimmed
Structures section.
For Order Entry response, please refer Trimmed Order Entry/Mod/Cxl Response Structure from
Trimmed Structures section.
Order Modification
This functionality enables the Corporate Manager and Branch Manager to modify their
unmatched orders by specifying the order number of the order to be modified. Corporate
Manager can modify his own order and also for his Branch Manager and Dealers/Traders. Branch
Manager can modify his own order and also for his Dealers/Traders.
For Order Modification request, please refer Trimmed Order Mod/Cxl Request Structure from
Trimmed Structures section.
For Order Modification response, please refer Trimmed Order Entry/Mod/Cxl Response
Structure from Trimmed Structures section.
Order Cancellation
The functionality enables the Corporate Manager and Branch Manager to cancel their
unmatched/partially matched orders by specifying the order number. Corporate Manager can
cancel his own order and also for his Branch Managers and Dealers/Traders. Branch Manager
can cancel his own order and also for his Dealers/Traders.
For Order Cancellation request, please refer Trimmed Order Mod/Cxl Request Structure from
Trimmed Structures section.
217
Futures and Options Trading System - Protocol for Non-Neat Front End
For Order Cancellation response, please refer Trimmed Order Entry/Mod/Cxl Response
Structure from Trimmed Structures section.
Trade Modification
This functionality enables Corporate Manager and Branch Manager to modify their trades. Only
account number modification is allowed. Corporate Manager can modify his own trade and also
for his Branch Managers and Dealers/Traders. Branch Manager can modify his own trade and
also for his Dealers/Traders.
Please refer Trade Modification section (in Chapter 4) for further details.
Trade Cancellation
This functionality enables Corporate Manager and Branch Manager to cancel their trades. But to
cancel a trade, both the parties of the trade must request for trade cancellation. Corporate
Manager can cancel his own trade and also for his Branch Managers and Dealers/Traders. Branch
Manager can cancel his own trade and also for his Dealers/Traders.
Please refer Trade Cancellation section (in Chapter 4) for further details.
This facility is provided to trading members in closeout mode to place an opposite order with
intent to reduce the open positions. Close out orders entered shall be Regular Lot (RL) and
Immediate or Cancel (IOC) orders.
Clearing members can place order entry on behalf of the linked trading members. A close out
order entry can be placed by Corporate Manager of member type PCM (Professional clearing
member) or PCM+TM (Professional clearing member which is also a Trading member).
218
Futures and Options Trading System - Protocol for Non-Neat Front End
If the order is rejected by the close out system, the rejection message shall be sent only to the
clearing member. If the order is matched, the trade confirmation shall be sent to the clearing
member and the trading member on whose behalf order was placed.
For the format for closeout order entry please refer Trimmed Order Entry Request Structure from
Trimmed Structures section for further details.
The UserId and BrokerId field has to be the one given below in case of close out order entry.
For Closeout order entry response, please refer Trimmed Order Entry/Mod/Cxl Response
Structure from Trimmed Structures section.
This functionality enables Corporate Manager and Branch Manager to place spread orders in the
market.
Please refer Spread Order Entry section (in Chapter 5) for further details.
This functionality enables the Corporate Manager and Branch Manager to modify their
unmatched spread orders by specifying the order number of the order to be modified. Corporate
Manager can modify his own spread order and also for his Branch Manager and Dealers/Traders.
Branch Manager can modify his own spread order and also for his Dealers/Traders.
Please refer Spread Order Modification section (in Chapter 5) for further details.
219
Futures and Options Trading System - Protocol for Non-Neat Front End
The functionality enables the Corporate Manager and Branch Manager to cancel their
unmatched/partially matched spread orders by specifying the order number. Corporate Manager
can cancel his own spread order and also for this Branch Managers and Dealers/Traders. Branch
Manager can cancel his own spread order and also for his Dealers/Traders.
Please refer Spread Order Cancellation section (in Chapter 5) for further details.
This functionality enables Corporate Manager and Branch Manager to place 2L and 3L orders in
the market.
For Order entry request, please refer Order Entry Request section (in Chapter 6).
For Order entry response, please refer Order Entry Response section (in Chapter 6).
220
Futures and Options Trading System - Protocol for Non-Neat Front End
221
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the GIVEUP_RESPONSE
structure.
222
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the details of the various fields present in the GIVEUP_RESPONSE
structure.
223
Futures and Options Trading System - Protocol for Non-Neat Front End
224
Futures and Options Trading System - Protocol for Non-Neat Front End
Appendix
List of Error Codes
The error codes along with their corresponding value and description are listed in the following
table.
225
Futures and Options Trading System - Protocol for Non-Neat Front End
226
Futures and Options Trading System - Protocol for Non-Neat Front End
227
Futures and Options Trading System - Protocol for Non-Neat Front End
228
Futures and Options Trading System - Protocol for Non-Neat Front End
229
Futures and Options Trading System - Protocol for Non-Neat Front End
230
Futures and Options Trading System - Protocol for Non-Neat Front End
231
Futures and Options Trading System - Protocol for Non-Neat Front End
232
Futures and Options Trading System - Protocol for Non-Neat Front End
233
Futures and Options Trading System - Protocol for Non-Neat Front End
234
Futures and Options Trading System - Protocol for Non-Neat Front End
235
Futures and Options Trading System - Protocol for Non-Neat Front End
236
Futures and Options Trading System - Protocol for Non-Neat Front End
Reason Codes
The reason codes and the corresponding values are listed in the following table.
237
Futures and Options Trading System - Protocol for Non-Neat Front End
REPORT_TRAILER 48
REPORT_HEADER 108
SPD_MKT_STATS_RPT_DATA 1862 RP_SPD_MKT_STATS 104 B
BOARD_LOT_IN 2000 MS_OE_REQUEST 316 I
NEG_ORDER_TO_BL 2008 MS_OE_REQUEST 316 I
NEG_ORDER_BY_CPID 2009 MS_OE_REQUEST 316 B
ORDER_MOD_IN 2040 MS_OE_REQUEST 316 I
ORDER_MOD_REJECT 2042 MS_OE_REQUEST 316 I
ORDER_CANCEL_IN 2070 MS_OE_REQUEST 316 I
ORDER_CANCEL_REJECT 2072 MS_OE_REQUEST 316 I
ORDER_CONFIRMATION 2073 MS_OE_REQUEST 316 I
ORDER_MOD_CONFIRMATION 2074 MS_OE_REQUEST 316 I
ORDER_CANCEL_CONFIRMATION 2075 MS_OE_REQUEST 316 I
PRICE_MOD_IN 2013 PRICE_MOD 106 I
CANCEL_NEG_ORDER 2076 MS_OE_REQUEST 316 I
SP_BOARD_LOT_IN 2100 MS_SPD_OE_REQUEST 480 I
TWOL_BOARD_LOT_IN 2102 MS_SPD_OE_REQUEST 480 I
THRL_BOARD_LOT_IN 2104 MS_SPD_OE_REQUEST 480 I
SP_ORDER_CANCEL_IN 2106 MS_SPD_OE_REQUEST 480 I
SP_ORDER_MOD_IN 2118 MS_SPD_OE_REQUEST 480 I
SP_ORDER_CONFIRMATION 2124 MS_SPD_OE_REQUEST 480 I
TWOL_ORDER_CONFIRMATION 2125 MS_SPD_OE_REQUEST 480 I
THRL_ORDER_CONFIRMATION 2126 MS_SPD_OE_REQUEST 480 I
SP_ORDER_CXL_REJ_OUT 2127 MS_SPD_OE_REQUEST 480 I
SP_ORDER_CXL_CONFIRMATION 2130 MS_SPD_OE_REQUEST 480 I
TWOL_ORDER_CXL_CONFIRMATI 2131 MS_SPD_OE_REQUEST 480 I
ON
238
Futures and Options Trading System - Protocol for Non-Neat Front End
239
Futures and Options Trading System - Protocol for Non-Neat Front End
240
Futures and Options Trading System - Protocol for Non-Neat Front End
241
Futures and Options Trading System - Protocol for Non-Neat Front End
242
Futures and Options Trading System - Protocol for Non-Neat Front End
* I/B - Interactive/Broadcast
The trascation codes that will contain timestamp in nanoseconds from 01-Jan-1980 00:00:00
are listed in following table:
PRICE_CONFIRMATION 2012
ORDER_MOD_REJECT 2042
ORDER_CANCEL_REJECT 2072
ORDER_CONFIRMATION 2073
243
Futures and Options Trading System - Protocol for Non-Neat Front End
ORDER_MOD_CONFIRMATION 2074
ORDER_CANCEL_CONFIRMATION 2075
SP_ORDER_CONFIRMATION 2124
TWOL_ORDER_CONFIRMATION 2125
THRL_ORDER_CONFIRMATION 2126
SP_ORDER_CXL_REJ_OUT 2127
SP_ORDER_CXL_CONFIRMATION 2130
TWOL_ORDER_CXL_CONFIRMATION 2131
THRL_ORDER_CXL_CONFIRMATION 2132
SP_ORDER_MOD_REJ_OUT 2133
SP_ORDER_MOD_CON_OUT 2136
SP_ORDER_ERROR 2154
TWOL_ORDER_ERROR 2155
THRL_ORDER_ERROR 2156
FREEZE_TO_CONTROL 2170
ON_STOP_NOTIFICATION 2212
TRADE_CONFIRMATION 2222
ORDER_ERROR 2231
BATCH_ORDER_CANCEL 9002
BATCH_SPREAD_CXL_OUT 9004
ORDER_CONFIRMATION_TR 20073
ORDER_MOD_CONFIRMATION_TR 20074
ORDER_CXL_CONFIRMATION_TR 20075
TRADE_CONFIRMATION_TR 20222
Order Terms:
244
Futures and Options Trading System - Protocol for Non-Neat Front End
IOC Input
GTC Input
Day Input
MIT Input
SL Input
Market Output
ATO Output
Frozen Output
Modified Output
Traded Output
MatchedInd Output
245
Futures and Options Trading System - Protocol for Non-Neat Front End
** Other input flags in the order terms are not allowed, hence should not be set.
Note: Order requested message is stopped for the following transcodes (Both interactive and
journal download).
BOARD_LOT_OUT
SPOT_OUT
NEGOTIATED_OUT
STO_OUT
ODD_LOT_OUT
ON_STOP_OUT
SP_BOARD_LOT_OUT
TWOL_BOARD_LOT_OUT
THRL_BOARD_LOT_OUT
ORDER_MOD_OUT
ORDER_CANCEL_OUT
SP_ORDER_CANCEL_OUT
SP_ORDER_MOD_OUT
TWOL_ORDER_CANCEL_OUT
TWOL_ORDER_MOD_OUT
THRL_ORDER_CANCEL_OUT
THRL_ORDER_MOD_OUT
Market Types
The market types are listed in the following table.
246
Futures and Options Trading System - Protocol for Non-Neat Front End
Market Status
The market can be one of the statuses listed in the following table.
Book Types
There are seven books listed in the following table and these books fall under any one of the
four market types.
Security Status
The security status is listed in the following table.
Status ID Status
1 Preopen
2 Open
3 Suspended
4 Preopen Extended
247
Futures and Options Trading System - Protocol for Non-Neat Front End
Activity Types
The activity types that are sent in the reports along with their description and code are listed in
the following table.
248
Futures and Options Trading System - Protocol for Non-Neat Front End
The upload files have a header record at the beginning of the file followed by the detail records.
HEADER
Table 126 CONTRACT_FILE_HEADER
Structure Name CONTRACT_FILE_HEADER
Packet Length 13 bytes
Field Name Data Type Size in Byte Offset
NEATFO CHAR 6 0
Reserved CHAR 1 6
VersionNumber CHAR 5 7
Reserved CHAR 1 12
STOCK STRUCTURE
Table 127 STOCK_STRUCTURE
249
Futures and Options Trading System - Protocol for Non-Neat Front End
250
Futures and Options Trading System - Protocol for Non-Neat Front End
251
Futures and Options Trading System - Protocol for Non-Neat Front End
252
Futures and Options Trading System - Protocol for Non-Neat Front End
PermittedToTrade This field can have any one of the following value:
- Listed but not permitted to trade
- Permitted to trade
Reserved Identifier This field can have any one of the following value:
Unreserved Contract
Reserved Contract
253
Futures and Options Trading System - Protocol for Non-Neat Front End
254
Futures and Options Trading System - Protocol for Non-Neat Front End
255
Futures and Options Trading System - Protocol for Non-Neat Front End
The following table provides the description of the newly added field.
Participant Structure
Header
Table 129 PARTICIPANT_FILE_HEADER
Structure Name PARTICIPANT_FILE_HEADER
256
Futures and Options Trading System - Protocol for Non-Neat Front End
Structure
257
Futures and Options Trading System - Protocol for Non-Neat Front End
Header
Table 131 SECURITY_FILE_HEADER
Structure Name SECURITY_FILE_HEADER
Packet Length 19 bytes
Field Name Data Type Size in Byte Offset
NEATCM CHAR 6 0
Reserved CHAR 1 6
VersionNumber CHAR 7 7
Reserved CHAR 1 14
CreationTime LONG 4 15
Security Structure
Table 132 SECURITY_STRUCTURE
Structure Name SECURITY_STRUCTURE
Packet Length 230 bytes
Field Name Data Type Size in Byte Offset
Token LONG 4 0
Reserved CHAR 1 4
Symbol CHAR 10 5
Reserved CHAR 1 15
Series CHAR 2 16
Reserved CHAR 1 18
InstrumentType SHORT 2 19
Reserved CHAR 1 21
IssuedCapital DOUBLE 8 22
Reserved CHAR 1 30
PermittedToTrade SHORT 2 31
Reserved CHAR 1 33
CreditRating CHAR 17 34
Reserved CHAR 1 51
ST_SEC_ELIGIBILITY_ PER_ STRUCT 5 52
MARKET [6] (Refer )
BoardLotQty LONG 4 57
Reserved CHAR 1 61
TickSize LONG 4 62
Reserved CHAR 1 66
258
Futures and Options Trading System - Protocol for Non-Neat Front End
259
Futures and Options Trading System - Protocol for Non-Neat Front End
260
Futures and Options Trading System - Protocol for Non-Neat Front End
261
Futures and Options Trading System - Protocol for Non-Neat Front End
262
Futures and Options Trading System - Protocol for Non-Neat Front End
Trimmed Structures
Trimmed Order Entry Request Structure
263
Futures and Options Trading System - Protocol for Non-Neat Front End
BranchId SHORT 2 70
TraderId LONG 4 72
BrokerId CHAR 5 76
Open/Close CHAR 1 81
Settlor CHAR 12 82
Pro / ClientIndicator SHORT 2 94
ADDITIONAL_ORDER_FLAGS STRUCT 1 96
Filler LONG 4 98
NnfField DOUBLE 8 102
PAN CHAR 10 110
Algo ID LONG 4 120
Reserved SHORT 2 124
Reserved CHAR 32 126
264
Futures and Options Trading System - Protocol for Non-Neat Front End
265
Futures and Options Trading System - Protocol for Non-Neat Front End
266
Futures and Options Trading System - Protocol for Non-Neat Front End
267
Futures and Options Trading System - Protocol for Non-Neat Front End
268
Futures and Options Trading System - Protocol for Non-Neat Front End
269
Futures and Options Trading System - Protocol for Non-Neat Front End
270
Futures and Options Trading System - Protocol for Non-Neat Front End
271
Futures and Options Trading System - Protocol for Non-Neat Front End
272
Futures and Options Trading System - Protocol for Non-Neat Front End
273
Futures and Options Trading System - Protocol for Non-Neat Front End
274
Futures and Options Trading System - Protocol for Non-Neat Front End
275