Proto SLBM NNF Protocol 2.0
Proto SLBM NNF Protocol 2.0
Version 2.0
March 2020
1
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Notice
2
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Change History:
Version 2.0
March 2020
Pages Description
Changed
17 Updates done in Communication Network Connections for NNF Users
3
Version 2.0
NSEIL - SLBM 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 Securities Lending and Borrowing Market Trading System and
thus serves as a development guide for the NNF users.
Target Audience
This document is written for system designers and programmers of user organizations
and third party software developers who are responsible for the development of software
to interact with NSE’s SLBM Trading System.
Chapters Description
4
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
5
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
TP Trigger Price
TWS Trader Workstation
VCID Virtual Circuit ID
VSAT Very Small Aperture Terminal
VV.RR.SS Version. Release. Sub-release
WHS Warehouse
6
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
CONTENTS
7
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
8
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
9
Version 2.0
NSEIL - SLBM 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, enabling trading members spread across the length and breadth
of India to trade directly from their offices through an extensive telecommunication
network. The system is known as ‘National Exchange for Automated Trading’ (NEAT)
system. It adopts the principles of an order driven market, based on price-time priority.
The trading members can use NEAT Front end or Non-NEAT Front end (NNF) to
establish a network connection with the host system of National Stock Exchange (NSE)
for trading. NNF is a front end which is developed and maintained by vendors other than
NSE. NSE provides the NNF users with the general guideline document of the front end
whereas they are supported by their respective vendors and NSE is not responsible for
the performance of the NNF.
Communication Network
Connectivity to the Exchange is through WAN protocol on TCP/IP. There are two types
of connectivity;
Interactive connectivity – On TCP/IP for user specific messages to and from the
Exchange.Trading Front can connect to the exchange through a middleware application
called Trading Access Point (TAP), The TAP protocol is defined in the annexure below.
Market data – The market data is sent as broadcast based on UDP connection
Broadcast circuit ID (BCID) follows a unidirectional path which is from the host end to the
TWS. 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
10
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Introduction
This chapter provides general guidelines for the designers and programmers who
develop NNF. It also provides information on data types and their size which can help in
understanding various structures.
The message structure consists of two parts namely message header and message
data. The message header consists of the fields of the header which is prefaced with all
the structures.
The message data consists of the actual data that is sent across to the host or received
from the host.
1. The order of the log-on messages should strictly be maintained as given in the
following section (Chapter 3) of the document. Otherwise, the user cannot log on
to the trading system.
2. All time fields are number of seconds from midnight January 1 1980.
4. All price fields must be multiplied by 100 before sending to the host end and
divided by 100 while receiving from the host end as the host system processes
prices in paise.
11
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
1. If your system uses little-endian order, the data types such as UINT, SHORT,
LONG and DOUBLE contained in a packet, which occupy more than one byte
should be twiddled (byte reversed). Twiddling involves reversing a given number
of bytes such that the byte in ‘n’ 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. So twiddle such data types before sending and after receiving to ensure
that correct data is sent and received.
Note:
Twiddling is required because of the variety in endian order—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. The trading system host end uses big-endian order.
5. All reserved fields mentioned, should be mapped to CHAR buffer and initialized
to NULL.
12
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Note:
The values of all the constants and transaction codes given in the document are
listed in Appendix.
The suffix IN in the transaction codes implies that the request is sent from the
TWS to the host end whereas OUT implies that the message is sent from the
host end to TWS
Message Header
13
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
14
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
The broadcast messages like market open, market close, market in pre-open are
prefaced with BCAST_HEADER. Some fields in the header are fixed. The remaining
fields are variable and set differently for each transaction code. The structure of the
BCAST_HEADER is as follows:
Table 2 BROADCAST_HEADER
ErrorCode This field contains the error number which describes the
type of error.
Refer to List of Error Codes in Appendix.
15
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
SEC_INFO
Structure Name SEC_INFO
Packet Length 12 bytes
Field Name Data Type Size in Byte Offset
Symbol CHAR 10 0
Series CHAR 2 10
Error Message
When the Error Code in the Message Header is not zero, ERROR RESPONSE is sent.
The Error Message will describe the error received. The structure is as follows:
Table 3 ERROR_RESPONSE
Structure Name ERROR RESPONSE
Packet Length 180 bytes
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER STRUCT 40 0
(Refer Table1 )
SEC_INFO (Refer STRUCT 12 40
sec_info)
Error Message CHAR 128 52
16
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
There are two types of virtual circuit connections used to communicate with the
host end. One is the Interactive Virtual Circuit ID (VCID) and the other is the
Broadcast Circuit ID (BCID).
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.
17
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
The National Stock Exchange of India has enhanced SLBM Trading System by changing
existing 2-tier system to 3-tier system with introduction of a middle-ware between Front-
End and Host End. The introduced middle-ware is named as TAP - Trading Access
Point and all the interactive message communication between front-end and host-end
will be through this TAP. The protocol and message flow required to be implemented for
communication through TAP is explained in detail in following sections.
Diagrammatic representation:
TCP/IP TCP/ IP
NNF Front TAP SLBMTS
End (IP based) HostEnd
TCP/IP communication protocol shall be used between NNF and TAP as well as
between TAP and host end as per the Network setup.
Guidelines for TCP/IP connectivity (Windows based) between NNF and TAP are as
follows
18
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
5. Revc () function will be called to receive data packets from TAP Box.
6. Send () function will be called to send data packets to TAP Box.
7. Pragma pack (2) to be used for all structures flowing between Front-
End and TAP Box.
8. It is recommended to disable Nagle's algorithm.
For non Windows based systems, use equivalent parameters in the above steps.
Steps:
1. After TCP socket is created, NNF application has to set SO_KEEPALIVE option
of the socket at SOL_SOCKET level.
2. Also, following Keep-alive parameters should be set in the Operating System on
which NNF is installed
a. Keep Alive Time : 20 seconds
b. Number of Keep Alive Retries: 5
c. Keep Alive Interval : 2 seconds
This structure is applicable to all messages that flow between NNF and Host through
TAP box.
Packet Format
19
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Packet Validation
Validation will be done for all requests flowing between TAP and Front-End.
Validation will be done through the combination of Checksum, Sequence Number and
length field.
Before sending the request to TAP box, Front-End will have to generate a sequence
number and checksum value. All the requests being sent from Front-End will be sent in
the format described above.
If validation of sequence number, checksum value & length will fail at TAP Box end, TAP
Box will disconnect the socket connection.
On receiving the response from TAP, NNF software is expected to validate sequence
number, checksum value & length field.
Sequence number must be in sequential order. For any fresh connection the number
should start from 1. On reaching the maximum limit of the data type of the sequence
number, the numbers should be reset to 1. Checksum field and the checksum
recalculated on the data field must match. Length field must be less than or equal to
1024.
If any one of these validations fails, the Front-End needs to drop the connection and
reestablish a fresh connection.
20
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Packet flow between TAP Box and Front-End will be controlled using Flow Control
Mechanism.TAP will send an 'Invitation Packet' to Front-End on establishing a fresh
connection.
Number of requests specified in Invitation Packet will be the maximum limit for requests
which will be allowed to be sent to TAP from Front-End.
After the front-end has utilized the invitation count fully, the TAP will send the next
invitation packet. Only on receiving the next invitation, the front-end is expected to send
subsequent requests.
Note:
In the invitation packet, the following fields are to be used
21
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
In case of any exception while processing the ‘invitation packet’ the connection should
be dropped. A new connection needs to be established by the front end with the TAP.
The above given considerations are applicable only for following transaction codes:
1. BOARD_LOT_IN (2000)
2. ORDER_CANCEL_IN (2070)
3. ORDER_MOD_IN (2040)
22
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Introduction
This section describes how a trader logs on to the trading system. It covers the log-on
request and the system responses. This section also describes the download of the
updated information on the securities, participants and the status of the markets. It
covers the structures and field descriptions of System Information Download, Local
Database Download and Message Download.
The process by which a trader logs on to the trading system is called Logon Process.
The trader, after issuing a sign-on request, waits for the system response. The response
could be a successful logon or an error message.
The following sequence explains the order in which transaction codes are sent and
received during log-on process.
Sequence Transaction Code Sent By Received By
No
1 SIGN_ON_REQUEST_IN (2300) TWS Host End
23
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
The following sequence explains the order in which the transaction codes are sent and
received during log-off process.
Sequence Transaction Code Sent By Received By
No
1 SIGN_OFF_REQUEST_IN (2320) TWS Host End
2 SIGN_OFF_REQUEST_OUT (2321) Host End TWS
Logon Request
When the user wants to establish an interactive circuit with the host, he sends this
request. The structure for this request is as follows:
Table 5 SIGNON_IN
Structure Name SIGNON IN
Packet Length 212 bytes
Transaction Code SIGN_ON_REQUEST_IN (2300)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER(Refer STRUCT 40 0
Table 1)
UserId LONG 4 40
Password CHAR 8 44
NewPassword CHAR 8 52
TraderName CHAR 26 60
LastPasswordChangeDateTime LONG 4 86
BrokerId CHAR 5 90
Reserved CHAR 1 95
BranchId SHORT 2 96
VersionNumber LONG 4 98
Reserved CHAR 56 102
UserType SHORT 2 158
SequenceNumber DOUBLE 8 160
WorkstationNumber CHAR 14 168
BrokerStatus CHAR 1 182
ShowIndex CHAR 1 183
BrokerEligibilityPerMarket STRUCT 2 184
(Refer Table 5.1(pg no. 25) for
Small Endian machines and
Table 5.2(pg no. 25) for Big
Endian machines)
BrokerName CHAR 26 186
24
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
25
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
LastPassword This field should be set to numerical zero while log on.
ChangeDateTime
UserType This field indicates the type of user. It can take one of the
following values when it is sent from the host:
‘0’ denotes Dealer
‘4’ denotes Corporate Manager
‘5’ denotes Branch Manager
This field should be set to ‘0’ while sending to the host.
SequenceNumber This field should be set to numerical zero while sending
the request to host.
26
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Logon Response
A successful logon results in the Logon Confirmation Response. The following structure
is sent back:
27
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
28
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Logon Error
29
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
The current status of the markets and the values of global variables are downloaded to
the trader in response to system information request.
Table 7 SYSTEM_INFO_REQ
Structure Name SYSTEM_INFO_REQ
Packet Length 40 bytes
Transaction Code SYSTEM_INFORMATION_IN (1600)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER STRUCT 40 0
(Refer Table 1)
Table 8 SYSTEM_INFORMATION_DATA
Structure Name SYSTEM_INFORMATION_DATA
Packet Length 90 bytes
Transaction Code SYSTEM_INFORMATION_OUT (1601)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER (Refer STRUCT 40 0
30
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
31
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
32
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
MaximumGTCDays This field contains the maximum GTC days, that is, the
maximum number of days after which a Good Till
Canceled order will be canceled.
SecurityEligibilityIndicator If the Minimum Fill flag is set, then orders will have the
Minimum Fill attribute set. If the All Or None (AON) flag is
set, then orders will have the AON attribute set.
DisclosedQuantity This field contains the disclosed quantity allowed
PercentAllowed percentage. The disclosed quantity, if set, will not be
greater than this percent of the total quantity.
The list of updated securities and participants is downloaded in response to update local
database request. Any carried over GTC or GTD orders are also downloaded with this
request.
Table 9 UPDATE_LOCALDB_IN
Structure Name UPDATE_LOCALDB_IN
Packet Length 58 bytes
Transaction Code UPDATE_LOCALDB_IN (7300)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER (Refer STRUCT 40 0
Table 1)
LastUpdateSecurityTime LONG 4 40
LastUpdateParticipantTime LONG 4 44
RequestForOpenOrders CHAR 1 48
Reserved CHAR 1 49
NormalMarketStatus SHORT 2 50
33
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
34
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
sent back in the MARKET STATUS as ‘wait till markets are open’. The following
structure is returned:
Table 10 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 STRUCT 40 0
(Refer Table 1)
Reserved CHAR 2 40
35
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Table 12 UPDATE_LDB_HEADER
Structure Name UPDATE_LDB_HEADER
Packet Length 42 bytes
Transaction Code UPDATE_LOCALDB_TRAILER. (7308)
Field Name Data Type Size in Byte Offset
MESSAGE_HEADER STRUCT 40 0
(Refer Table 1)
Reserved CHAR 2 40
36
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
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.
Alpha_Char (Header) This contains the stream number of the host to which it
has to send the DOWNLOAD_REQUEST.
SequenceNumber This contains the time last message was received by the
workstation. This can be obtained from the Time Stamp1
of the MESSAGE_HEADER. To retrieve the messages
from the beginning of the trading day, this field should be
set to ‘0’ or the Sequence Number received in the logon
response message.
37
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
38
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Chapter 6.
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, Chapter 8
Logoff Request
The process by which a trader quits or signs off from the trading system is called Logoff
Process.
39
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
When the user logs on again, the user receives a packet giving the details of when
he/she logged off. The structure sent is:
Note: MS_SIGNOFF message is sent in the Message Header itself. The length of the
packet is 40 bytes.
40
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
This section describes about entering new orders, modifying existing orders, and
canceling outstanding orders. The trader can begin entering the orders once he has
logged on to the trading system and the market is in open state. Please note that for
SLBM Buy indicates Borrow and Sell indicates Lend.
Order Entry
Order entry allows the trader to place orders in the market. The system accepts the
orders from the users and tries to match the orders with the orders in the books
immediately. If the order does not match, the order is placed in the appropriate book with
the price and time stamp.
The trader can also place recall and repay orders. The recall and repay orders will be
validated by the OVS system and if the order is valid, the order will get confirmed. This
order gets traded in the system like a normal order.
The system also allows the trader to enter the trades negotiated outside. Both the
parties involved in the trade have to enter the trade as negotiated trade entries.
Negotiated trade will only be allowed for Regular Lot orders. The negotiated trade orders
can only be “Day” orders.
Order Types
Regular Lot
Regular Lot Orders are orders in the normal market that have none of the following
terms attached: All Or None, Minimum Fill and Trigger Price.
Special Terms
Special Terms Orders are orders in the normal market which have special attribute
attached to it. They must have Minimum Fill (MF) or All Or None (AON).However
Special Term orders are not allowed in SLBM.
41
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Recall orders are regular lot buy orders. Repay orders are regular lot sell orders.
Spot Orders
Spot Orders are orders in spot market where the settlement period is different from the
normal market and is fixed by the exchange. However, spot orders are not allowed in
SLBM.
Auction Orders
Auction Orders are simple day orders and can only have the ‘Day’ term set to 1. Auction
orders are not allowed in SLBM.
Order Terms
Following terms and conditions can be used during order entry and order modification.
42
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
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.
Hence the Good till date field will be used for the purpose of reverse leg settlement date
of every order related transaction viz, order entry, order modification, order
cancellation.The order placed by the trader, should contain the reverse leg settlement
date of that corresponding contract in this GTD field. And the same will be validated in
the HE correspondingly.
43
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
44
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
45
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
46
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
ParticipantType Since only exchange can initiate the auction, this field
should not be set to ‘I’ for initiator.
This should be set to ‘C’ for competitor order and ‘S’
for solicitor order.
47
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
48
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
49
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
50
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
51
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
OrderNumber This field contains the order number assigned to the order.
The first two digits will contain the stream number (This will be
different from the stream number for Journal Download
Request-Response). The next fourteen digits will contain
fourteen digit sequence number.
Price This field contains the price of the order. If a Market order was
entered when market was in Open state, the ‘Market’ flag in
Order Terms is set and is priced at the prevailing price at the
trading system. If the market order is entered when the market
was in preopen, the trading system sets the ‘ATO’ bit in Order
Terms and prices at ‘-1’. If it was a priced order the order gets
confirmed at that price.
52
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Price This field contains the price of the order. . If a Market order
was entered when market was in Open state, the ‘Market’ flag
in Order Terms is set and price is set at the prevailing price at
the trading system. If the market order is entered when the
market was in preopen, this transcode is not received.
Order_Flags (Refer to Order Entry Request in Chapter 5)
53
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Order Modification
Order Modification enables the trader to modify unmatched orders. All order types
except Auction can be modified.
54
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
OrderNumber This should contain order number which is the identity of the
order to be modified.
Last ModifiedTime 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,
Note: The other fields of order modification request are same as the fields of order entry
request.
Order Modification Response
This response is sent back when an order modification is requested. This does not imply
that the order modification is confirmed. The response can be Order Modification
Confirmation, Order Freeze, Order Modification Error or one of the general error
responses. The order modification error response is given when the modified order is
rejected by the trading system. The reason for the rejection is given by the reason code
and the reason string. The message sent is of the following format:
55
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Last ModifiedTime This field contains the time when the order was last
modified. It is in number of seconds from midnight of
January 1, 1980,
EntryDateTime This field contains the time at which last modified by user.
It is in number of seconds from midnight of January 1,
1980,
Price Yes Changing the order price will always result in the
order losing its time priority.
Quantity Yes The quantity of an order can be reduced any
number of times without the order losing its time
priority. However, increasing the quantity of an
order will always result in the order losing its time
priority.
PRO/CLI No
Account No. No
Day Yes Changing to or from a Day order retains time
priority
GTC Yes Changing to or from a GTC order retains time
priority
56
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Order Cancellation
The trader can cancel any unmatched/partially matched order by specifying the order
number.
57
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
OrderNumber This field should contain the order number which is the
identity of the order to be cancelled.
Last ModifiedTime 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,
58
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Trade Modification
Trade Cancellation
To cancel a trade, both the parties of the trade must request for trade cancellation. As
soon as the request reaches the trading system, a requested message is sent. If any
error is encountered in the entered data, Trade Error message is sent. Otherwise it goes
to the NSE-Control as an alert. The counter party to the trade is notified of the trade
cancellation request (Refer to Unsolicited Messages in Chapter 6). When both the
parties of the trade ask for trade cancellation, it may be approved or rejected by the
Exchange (Refer to Unsolicited Messages in Chapter 6).
FillNumber This field should contain the trade number of the trade to be
cancelled.
59
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Table 16 TRADE_INQUIRY_DATA
FillNumber This field should contain the trade number of the trade to be
cancelled.
60
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
61
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
This section details the unsolicited messages that are received on the interactive
connection. These messages are not received by the users in response to any request.
The Day orders which are not traded are deleted in the batch at the end of the day.
GTC\GTD orders which are valid till date, if not traded, are also removed from the book.
A response for the same is sent to the user. The structure sent is:
When any stop loss order entered is triggered, the user who entered the order is sent
the following message:
This message is sent when a previous order, which resulted in freeze, is approved by
the Exchange. The format of the message is as follows:
62
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
This message is sent when a previous order, which resulted in freeze, is rejected by the
Exchange. The format of the message is as follows:
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 17 MS_TRADE_CONFIRM
63
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
64
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Order type This field contains the order type of the order
under trade. Will be blank for normal and ‘RC’
and ‘RP’ for repay orders.
65
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
This message is sent when the counter party of the trade requests a trade cancellation.
The structure sent is:
When NSE-Control approves the trade cancellation request the structure sent is:
66
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
When NSE-Control rejects the trade cancellation alert the structure sent is:
Whenever a negotiated order is entered and the counter party ID is same as the user’s
broker ID then all the users under this broker are notified. The structure is:
After the alert is generated for a negotiated trade, the NSE-Control can reject the trade,
send both the orders to the regular lot book or send one to the regular lot and cancel the
other. The structure sent is:
67
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
A message can be sent to the trader(s) from the NSE-Control Work Station. If it is sent
to all the traders, it comes as a broadcast in the structure BROADCAST_MESSAGE.
(Refer to General Message Broadcast in Chapter 8)
When the message is sent to a particular user, it comes as an interactive message in the
following structure:
Table 18 MS_TRADER_INT_MSG
68
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Table 19 MS_TRADER_INT_MSG
69
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
ActionCode This field contains the action code to indicate the action
taken.
For example,
‘SYS’ - System
‘AUI’ - Auction Initiation
‘AUC’ - Auction Complete
‘LIS’ – Listing
70
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
This section describes the end of the trading day activities. It covers the transmission
of Security Bhav Copy. This takes place after the markets close for the day.
Message Stating the Transmission of Security Bhav Copy Will Start Now
This is the first message which is broadcasted saying that the bhav copy will be started
now. The structure sent is:
Table 20 MS_RP_HDR
71
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
TraderName This field contains the name of the trader. This is set to
blanks.
72
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
73
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
This is same as the data packet for non-Depository securities. The structure sent is:
74
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Trailer Record
This indicates that the transmission of bhav copy ends here. The structure is:
Note: The Bhavcopy which is broadcasted from CM will be dropped and will not be
received by SLBM users in NEAT.
75
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Chapter 8 Broadcast
Introduction
The following information of Capital Market will also be broadcasted to the SLBM users
in NEAT system:
The broadcast traffic from the exchange which gives the on-line quotes to the trading
terminals has been continually increasing, especially during market open and market
close. To accommodate the increased broadcast traffic, the exchange has come up with
a compression algorithm to compress some of the specific broadcast transaction codes,
which are as follows:
Decompression Routine
NSE will provide the object file containing the decompression routine.
76
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
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.
For example,
If ‘n’ packets are packed in a buffer, they are arranged in the following order:
1st packet will be stored at the first place in the buffer, 2nd Packet will be stored at the
second place, and so on.
At the front end while de packing 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.
Calling Convention
The decompression routine is a C-callable routine with the following prototype:
77
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Parameters
Ip: it is the pointer to the input buffer.
IpL: It is the pointer to a short containing the length of input.
Op: it is the pointer of the output buffer.
OpL: It is the pointer to a short containing the length of output.
ErrorCode: it is the pointer to a short containing the error code.
Packet Format
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,
COMPRESSION_BROADCAST_DATA
{
SHORT CompressionLen
CHAR BroadcastData [ ]
}
Note:
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.
78
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
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 should be
ignored. The message header starts from the 9th byte.
The lzo directory (lzo1.07) contains all the lzo source, header and library files.
These files are to be included while building an application.
Where
out Specifies input compressed buffer
decomp_inlen Specifies the input length of the buffer ( Length of Compressed buffer )
in Specifies the out put (decompressed) buffer
decomp_outlen Specifies the output length of the decompressed buffer
79
Version 2.0
NSEIL - SLBM 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. If the first byte has the value of ‘4’, it is Capital market
and if it is ‘7’ then it is of SLBM.
Any general message is broadcasted in the following structure. The structure sent is:
Table 23 BROADCAST_MESSAGE
80
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
This message is sent when any global operating parameters are changed or status of
markets is changed. The structure of the message is:
81
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
This is sent whenever the parameter of any security is changed. The structure is given
below.
SECURITY STRUCT 12 89
ELIGIBILITY PER
MARKET [4] (refer
table 24.1 for small
endian & 24.2 for big
endian)
IssueRate SHORT 2 101
IssueStartDate LONG 4 103
InterestPaymentDate LONG 4 107
IssueMaturityDate LONG 4 111
BoardLotQuantity LONG 4 115
TickSize LONG 4 119
Name CHAR 25 123
Reserved CHAR 1 148
82
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Table 24.1 SECUIRITY ELIGIBILITY PER MARKET (For Small Endian Machines)
Structure Name SECUIRITY ELIGIBILITY PER MARKET
Packet Length 3 bytes
Field Name Data Type Size Offset
Reserved BIT 7 0
Eligibility BIT 1 0
Status SHORT 2 1
Table 24.2 SECUIRITY ELIGIBILITY PER MARKET (For Big Endian Machines)
Structure Name SECUIRITY ELIGIBILITY PER MARKET
Packet Length 3 bytes
Field Name Data Type Size in Byte Offset
Eligibility BIT 1 0
Reserved BIT 7 0
83
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
84
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
85
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
86
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
87
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
This message is sent whenever there is any participant change. The structure sent is:
This message is sent whenever the status of any security changes. The structure sent
is:
88
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
89
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
‘2’ - Open
‘3’ - Suspended
‘4’ - Preopen extended
When a broker’s turnover limit exceeds, the broker is deactivated and a message is
broadcast to all workstations. The same structure is also sent when any broker is
reactivated. The structure is:
90
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
This structure is sent whenever there is any auction related activity in CM.This includes
any change in Auction MBO. The structure is:
91
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
92
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
When the status of an auction changes in CM (from pending to active or, competitor
period or solicitor period is ended or started) a message is broadcast to all workstations
with the following structure and transaction codes:
93
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
94
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Whenever the status of the market changes, the following structure is sent:
Table 30 Change of Market Status
95
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
96
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
NumberOfRecords This field indicates the number of times (Maximum 28) the
structure TICKER INDEX INFORMATION is repeated.
97
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
The information regarding the best buy orders and the best sell orders is given in the
following format:
98
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
The information regarding the best buy orders and the best sell orders is given in the
following format:
99
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
100
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
101
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
102
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
The market watch information gives the best buy order and its quantity, best sell order
and its quantity and the last trade price. The structure sent for the purpose is:
BuyPrice LONG 4 6
SellVolume LONG 4 10
SellPrice LONG 4 14
LastTradePrice LONG 4 18
LastTradeTime LONG 4 22
103
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
BuyVolume This field contains the quantity of the best Buy order.
104
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
BuyPrice This field contains the price of the best Buy order.
SellVolume This field contains the quantity of the best Sell order.
SellPrice This field contains the price of the best Sell order.
LastTradePrice This field contains the latest trade price of a security.
LastTradeTime This field contains the latest trade time of a security.
When the market opens the open price of the security is sent in the following structure:
Token LONG 4 52
OpeningPrice LONG 4 56
If there has been no data on the broadcast circuit for a stipulated time period, then a
pulse is sent. This time is nine seconds now but it can be changed by NSE–Control. This
is only to intimate that the circuit is still there but there is no data to send. The structure
sent is:
105
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
106
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
107
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
This Packet contains the index values of Nine Indices with name. The structure is as
follows:
Table 37 BROADCAST INDUSTRY INDICES
Structure Name BROADCAST INDUSTRY INDICES
Transaction Code BCAST_IND_INDICES (7203)
Packet Length 467 Bytes
Field Name Data Type Size in Offset
Byte
BCAST_HEADER (Refer Table 2) STRUCT 40 0
NumberOfRecords SHORT 2 40
Indices[17] (Refer Table 37.1) STRUCT 425 42
108
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
This packet will contain the buy back Information which are running on that day.This will
be broadcasted for every one hour from Market open till market closes on that day.
BUYBACK is not there in SLBM system.
The structure is as follows:
Table 38 BROADCAST BUY_BACK
Structure Name BROADCAST BUY_BACK
Transaction Code BCAST_BUY_BACK (7211)
Packet Length 426 Bytes
Field Name Data Type Size in Offset
Byte
BCAST_HEADER (Refer Table 2) STRUCT 40 0
NumberOfRecords SHORT 2 40
BuyBackData [6] (Refer Table STRUCT 384 42
38.1)
109
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
110
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Appendix
List of Error Codes
111
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
112
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
113
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
114
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
115
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
116
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
117
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
118
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
119
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
The reason codes and the corresponding values are given below.
120
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Branch 7
User 8
Participant 9
Counter Party 10
Order Number 11
Auction Number 15
Price Freeze 17
Quantity Freeze 18
121
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
122
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
123
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
IOC : input
GTC : input
Day : input
SL : input
Market : output
ATO : output
Frozen : output
Modified : input
Traded : output
MatchedInd : output
124
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Market Status
Book Types
125
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Auction Status
Status ID Description
AUCTION_PENDING_APPROV 1 If the auction is initiated by the trader an alert
AL is generated at the CWS. The auction status is
in pending for approval.
AUCTION_PENDING 2 If any auction in the particular security is
already going on, the status of the auction
entered next is pending.
OPEN_COMPETITIOR_PERIO 3 When the auction gets initiated, this is the
D status.
OPEN_SOLICITOR_PERIOD 4 Auction enters solicitor period.
AUCTION_MATCHING 5 After solicitor period ends, the auction enters
matching state. The matching of auction
orders takes place.
AUCTION_FINISHED 6 Status after matching of orders is done and
auction trades are generated.
AUCTION_CXLED 7 Auction is cancelled by NSE-Control.
Security Status
Status Status ID
Preopen 1
Open 2
Suspended 3
Preopen Extended 4
Activity Types
The activity types that are sent in reports are given below.
126
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Header
Table 39 SECURITY_FILE_HEADER
Stock Structure
Table 40 STOCK_STRUCTURE
127
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
128
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
129
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
130
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
131
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
MF ‘1’- MF is allowed.
‘0’- MF is not allowed
132
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Remark Remarks
LocalLDBUpdateDateTime This is the local database update date-time.
DeleteFlag This indicates the status of the security,
whether the security is deleted or not.
‘N‘ : Active
‘Y‘ : Deleted
FaceValue This field contains face value of the security
ISIN Number This field contains the ISIN
Number of the security.
Header
Table 41 CONTRACT_FILE_HEADER
Stock Structure
Table 42 STOCK_STRUCTURE
Structure Name STOCK_STRUCTURE
Packet Length 249bytes
Field Name Data Type Size in Offset
Byte
Token LONG 4 0
Reserved CHAR 1 4
Symbol CHAR 10 5
133
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
134
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
135
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
136
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
MF ‘1’- MF is allowed.
‘0’- MF is not allowed
137
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Participant_slb Structure
Header
138
Version 2.0
NSEIL - SLBM Trading System Protocol for Non-NEAT Front End
Table 43 PARTICIPANT_FILE_HEADER
Structure
Table 44 PARTICIPANT_STRUCTURE
139
Version 2.0