WO2018229795A1

WO2018229795A1 - Method and system for processing trading information for multiple applications

Info

Publication number: WO2018229795A1
Application number: PCT/IN2018/050386
Authority: WO
Inventors: Krishnamurthy RAVISHANKAR; Krishnamurthi ARAVINTHAN; Jothimani PREMKUMAR; Belgudri RITESH
Original assignee: Axlware Technologies Private Ltd
Current assignee: Axlware Technologies Private Ltd
Priority date: 2017-06-15
Filing date: 2018-06-12
Publication date: 2018-12-20
Anticipated expiration: 2019-12-15
Also published as: EP3639152A4; EP3639152A1

Abstract

Embodiments of the present disclosure relates to a method and a system for processing trade information for multiple applications. More particularly, the disclosure relates to supporting multiple trading applications orders through single session to the exchange server by implementing both market data and own order interfaces at the same reconfigurable device, thus reducing the resources without compromising the latency. Shared memory and buffers are used to provide normalized market data and own order updates in the same memory location accessible by multiple trading applications without any locking restrictions. Thus, improving the latency in accessing the normalized data, and memory location and cache performance at multiple trading applications without compromising the latency.

Description

Title: METHOD AND SYSTEM FOR PROCESSING TRADING INFORMATION

FOR MULTIPLE APPLICATIONS FIELD OF THE DISCLOSURE

The present subject matter is related, in general to data processing, and more particularly, but not exclusively to a method and system for processing trading information for multiple applications.

BACKGROUND

Speed of information delivery is a valuable dimension to the financial instrument trading and brokerage industry. The ability of a trader to obtain pricing information on financial instruments such as stocks, bonds and improvements in information delivery delay on the order of fractions of a second can provide important value to traders. Conventional systems provide real-time delivery of such pricing information to traders, however, massive computations are required to support such a data processing trading platform due to which latency or delay are introduced because of the processing overhead involved.

Further, conventional trading platform exchanges financial instrument data through kernel which adds additional latency and causes jitters in latency due to interruptions in the kernel. Furthermore, the trading applications will need to receive and process all financial instrument data received from the exchange which may be interested or non- interested. Also, to support different message protocol or format used by different exchange servers, the trading applications need to normalize the data to their internal format thereby involving more latency. In addition, the trading application need to maintain their own session with the exchange server used and also need to maintain separate infrastructure for financial instrument data thereby, leading to increase in resources and hence the latency involved in managing complications arising in the operation of the resources. Therefore, there is a need for a method and a system that processes trading information for multiple applications, optimizing the latency thereby improving the performance of the trading platforms. SUMMARY

One or more shortcomings of the prior art are overcome and additional advantages are provided through the present disclosure. Additional features and advantages are realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure.

Accordingly, the present disclosure relates to a method of processing data associated with multiple user applications. The method includes receiving a plurality of market data messages and own order messages from an external network. The method further comprises determining an application identity (application_id) for each of the own order messages and generating an internal representation of the received plurality of market data messages and own order messages including the application_id. The method also comprises transmitting the internal representation of the plurality of market data messages and own order messages to a plurality of applications.

Further, the present disclosure relates to a system for processing data associated with multiple applications. The system includes at least a reconfigurable logic device comprising at least a processor, a memory, a marketdata interface and a ownorder interface coupled with the processor. The system further comprises a plurality of applications coupled with the processor. The system furthermore comprises a shared memory and a shared memory interface coupled with the shared memory configured to interact with the processor and the plurality of applications. The memory stores processor-executable instructions, which, on execution, cause the processor to receive a plurality of market data messages and own order messages from an external network. Further the processor is configured to determine an application identity (application_id) for each of the plurality of own order messages and generate an internal representation of the received plurality of market data messages and own order messages including the application_id. Furthermore, the processor is configured to transmit the internal representation of the plurality of market data messages and own order messages to the plurality of user applications. The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed embodiments. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figures to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and with reference to the accompanying figures, in which:

Figure 1 illustrates an architecture diagram of an exemplary system for processing trading information for multiple applications in accordance with some embodiments of the present disclosure;

Figure 2 illustrates an exemplary block diagram of a data processing system of Figure 1 in accordance with some embodiments of the present disclosure;

Figures 3a and 3b respectively illustrates a block diagram of market data interface and own order interface of Figure 1 in accordance with some embodiments of the present disclosure;

Figure 3c illustrates a block diagram of shared memory of Figure 1 in accordance with some embodiments of the present disclosure;

Figure 3d illustrates a block diagram illustrating the updates in the buffers of the shared memory 108 of Figure 3c; Figure 4a illustrates a flowchart of an exemplary method of processing trading information received from the exchange network supporting multiple applications in accordance with some embodiments of the present disclosure; and Figure 4b illustrates a flowchart of an exemplary method of processing trading information transmitted to the exchange network supporting multiple applications in accordance with some embodiments of the present disclosure.

It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown.

DETAILED DESCRIPTION

In the present document, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the spirit and the scope of the disclosure.

The terms "comprises", "comprising", "include(s)", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by "comprises... a" does not, without more constraints, preclude the existence of other elements or additional elements in the system or apparatus.

Embodiments of the present disclosure relates to a method and system for processing trading information for multiple applications. Trading platforms are configured to carry out data processing operations based on financial data received from external sources such as exchange server for example, NYSE, NASDAQ etc. over private data communication lines. The financial data comprises a series of messages that individually represent a new offer to buy or sell a financial instrument, notifications of corrections to previously-reported sales of a financial instrument, and administrative messages related to such transactions and the like. The present disclosure relates to method and system for processing such messages using reconfigurable devices to parse and process the messages to reduce latency and transmit only filtered data interested to trading applications.

In one embodiment, the present disclosure supports multiple trading applications orders through single session to the exchange server by implementing both market data and own order interfaces at the same reconfigurable device, thus reducing the resources without compromising the latency. Shared memory and buffers are used to provide normalized market data and own order updates in the same memory location accessible by multiple trading applications without any locking restrictions. Thus, improving the latency in accessing the normalized data, and memory location and cache performance at multiple trading applications without compromising the latency.

In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense. Figure 1 illustrates an architecture diagram of an exemplary system for processing trading information for multiple applications in accordance with some embodiments of the present disclosure.

As shown in Figure 1, the exemplary system 100 comprises one or more components configured for processing trading information for multiple applications. The system 100 may be implemented using a single computer or a network of computers including cloud- based computer implementations. In one embodiment, the exemplary system 100 comprises a data processing system (hereinafter referred to as DPS) 102, co-located with an exchange network 103 comprising one or more exchange servers 104-1, 104-2, ... 104-N (collectively referred to as exchange server 104) and one or more user or client applications 105-1..N (collectively referred to as applications 105).

The Exchange server 104 may be server grade machines capable of interfacing directly with the trading servers in the same co-location network or with trading server outside the exchange co-location network over the Internet or other network connection. The Exchange server 104 typically includes one or more user interface devices, such as a keyboard, a mouse, touch screen, pen or the like, for interacting with the GUI provided on a display. The Exchange server 104 transmits or receives to/from trading information supporting multiple applications 105. In one embodiment, the Exchange server 104 disseminates market information such as new buy or sell offers, publish new or amend or cancel information on the orders, trade transactions and related information.

The applications 105 may be client applications capable of receiving trading information such as market data messages and own order update messages from the exchange server 104. Based on the received trading information, the applications 105 enable submission of orders to buy or sell a particular quantity of a listed financial instrument with particular conditions such as a maximum or minimum price to the Exchange server 104.

The DPS 102 may be a trading system or high frequency (HFT) trading platform capable of processing trading information for multiple applications. In one embodiment, the DPS 102 comprises at least a processor 106 and shared memory 108 coupled with the processor 106. The DPS 102 further comprises a reconfigurable logic device 110 coupled with the processor 106. The reconfigurable logic device (hereinafter referred to as RLD) 110 may be a co-processor or Field Programmable Gate Arrays (FPGAs) which may be reconfigured to implement a wide variety of fixed or programmable computational engines. In one embodiment, the RLD 110 comprises a market data interface 112 and an own order interface 114. The DPS 102 further comprises a User Datagram Protocol (UDP) processing engine 116 and a Transmission Control Protocol (TCP) processing engine 118 coupled with the processor 106.

In one embodiment, the DPS 102 may be deployed as a network interface card in a typical trading system. The DPS 102 abstracts one or more different exchange protocols for market data and order entry and provides a generic user space Application Programming Interface (API) to the applications 105 to access market data messages and send orders messages at a deterministic latency. As illustrated in Figure 2, the DPS 102 comprises the processor 106, the shared memory 108, and a memory 203.

The DPS 102 further includes data 204 that may be stored within the memory 203. In one example, the data 204 may include market data messages 208, own order messages 210, application_ID 212, order_ID 214, order request messages 216 other data 218. In one embodiment, the data 204 may be stored in the memory 203 in the form of various data structures. Additionally, the aforementioned data can be organized using data models, such as relational or hierarchical data models. The other data 218 may be also referred to as reference repository for storing recommended implementation approaches as reference data. The other data 218 may also store internal representation of market data messages and own order messages, risk score, predetermined risk control information, instrument_id, trade_id, generated by the DPS 102 for processing the trading information.

The RLD 110 may include, for example, the market data interface 112, the own order interface 114, an application message handler 220, a Direct Memory Access (DMA) engine 222, a configuration manager 224 and an alerts manager 226. The RLD 110 may also comprise other modules 224 to perform various miscellaneous functionalities of the DPS 102. The market data interface 112 processes the market data messages 208 received from the exchange server 104 and builds common internal representation of the market data book in the shared memory 108. The market data interface 112 also processes instrument and product status messages and passes the current trading status for each instrument such as Halted, Traded, Auction, and so on to the applications 105. The market data interface 112 receives the market data messages 208 including the market data updates from the exchange server 104, which is usually through UDP multicast protocol via the UDP processing engine 116. The market data messages 208 comprising the market data updates are processed by market data interface 112, which builds the market data book from the updates, and pass the market data book, trade and order updates to the applications 105 via a shared memory interface. An exemplary block diagram of the market data interface 112 is illustrated in Figure 3a.

In one embodiment, the market data interface 112 comprises a connection handler 302, line sequencer 304, message parser 306, snapshot manager 308, and book builder 310. The connection handler 302 manages connection of the DPS 102 to the exchange server 104. The trading information from the exchanges is usually published on dual multicast lines A and B, as the communication protocol followed is UDP. Both the lines A and B publish same duplicate packets of the trading information (or market data packets or market data messages) with a same sequence number. The market data messages 208, may be for example, market data book update messages, market data trade update messages, and market data order update messages. The connection handler 302 enables the DPS 102 to subscribe to either of the lines or subscribe to both the lines and ignore the duplicate packets.

Due to the nature of the UDP protocol, the market data messages or packets 208 transmitted from exchange server 104 over multicast can be received out of order, or with some duplicate packets or intermediate packets missing. The line sequencer module 304 detects the duplicate packets, out of order packets, packets gaps based on the packets sequence number, and feeds the packets to the message parser module 306 in sequence. In one embodiment, the line sequencer module 304 is configured to select the UDP packet from the lines whichever comes first if both the multicast lines are joined, and detect the duplicate packet based on the sequence number and ignore it. If a packet is lost in both the multicast lines, sequence number gap alert is raised via the Alert manager 226.

The message parser 306 parses the exchange specific market data messages and feed into Book builder component 310. In one embodiment, the exchange market data protocol can be Order based book messages like AddOrder, ModifyOrder, CancelOrder, OrderExecution, etc. In another embodiment, the exchange market data protocol can be Level based book messages like AddLevel, ModifyLevel, DeleteLevel. In yet another embodiment, the exchange market data protocol can be Index based book messages. The message parser component 306 is implemented based on configuration of the exchange server 104 according to the exchange market data specification.

The book builder 310 is configured to build and maintain the market data book in a common internal representation, so that exchange specific market data protocol is abstracted from the host applications 105. The internal book representation comprises a list of price levels on both bid and ask sides. Each price level contains price, qty, number of orders available at that price level. Further, the internal book representation comprises security status like trading, halted, etc., of the instrument. The book builder 310 is further configured to build and maintain the market trade information (if any) in a common internal representation as Price, Qty, TradeSide. Further, the book builder 310 is configured to build and maintain the order information of each individual order available in the market data, so that the book builder 310 can apply the market data messages 208 correctly to the orders, send the top N levels of the market data book, trade information (if any in the current updates), and order information of orders affected in the current updates to the share memory 108 in the through the DMA Engine 222 and PCIe interface (not shown). Furthermore, the book builder 310 is configured to instruct the application message handler 220 that a new market data book update has been passed to the user shared memory interface, with the indexes of the last market data book, market trade, and market order entries.

The exchange server 104 also provide a mechanism to retrieve the snapshot of the entire book. If the line sequencer component detects a sequence number gap which is bigger than a pre-configured limit or the gapped packet is not retrieved in both the duplicate multicast lines, then the DPS 102 instructs the snapshot manager 308 to retrieve the entire book from the exchange server 104. On receiving the snapshot request, the snapshot manager 308 clears the order book, handles the snapshot messages from the exchange server 104, joins the snapshot multicast channels and rebuild the entire book based on the snapshot messages from the exchange server 104.

The own order interface 114 provides connectivity with the exchange server 104 to send order request messages 216 as requested by the applications 105. Order request messages 216 include such as for example, NewOrder, ModifyOrder, CancelOrder, and related order request messages. The own order interface 114 also processes the order response messages received from the exchange server 104 which is usually through TCP protocol via the TCP processing engine 118. For example, the order response messages include at least 'NewOrderResponse', 'ModifyOrderResponse', 'CancelOrderResponse', 'OrderExecutionReport' and so on. Based on processing of the order response messages, the own order interface 114 constructs own order book stored in the shared memory 108.

The own order interface 114 can be used by multiple applications 105, and maintains single connection to the exchange server 104 irrespective of the number of applications 105. The own order interface 114 maintains the own order book individually for each application 105 to represent the orders generated by each application 105. The own order interface 114 is then configured to maintain the status of each order in the own order book along with the status information and passes this order status to the application. For example, the status information may be one of PendingNew, New, PendingReplace, Replaced, PendingCancel, Cancelled, PartiallyExecuted, Executed, and so on. The own order book updates are processed by the own order interface 114, which builds the Own order book from the updates, and pass it to the host applications 105 via the shared memory interface.

The own order interface 114 receives the order request messages 216 from the applications 105 in an internal order request format, constructs the order request messages 216 according to the exchange specific protocol and sends it to the exchange server 104 in a sequenced manner. An exemplary block diagram of the own order interface 114 is illustrated in Figure 3b. In one embodiment, the own order interface 114 comprises a message parser 312, an own order book builder 304, a send orders interface 316, a message builder 318, risk control module 320 and a connection handler component 322. The connection handler 322 maintains the TCP connection to the exchange network 103. The connection handler 322 maintains exchange network's primary and secondary exchange server connection details. In one embodiment, the connection handler 322 connects to the primary exchange server and on determination of failure of the primary exchange server, the connection handler 322 tries to connect with the secondary exchange server. The connection handler 322 also generates alerts and transmits to the control application on detection of disconnection from the exchange network 103.

The message parser 312 parses the own order update messages received from the exchange server 104 in exchange specific format, and feed them to own order book builder 304 in a common internal representation. Own order update messages include for example, AddOrder, ModifyOrder, CancelOrder, OrderExecuted and so on. The message parser component 312 is implemented based on exchange orders entry system specification.

The send orders interface 316 is the entry point into the own orders interface 114 for the order request messages passed from the applications 105 via the platform driver (not shown). Example of the order request messages include NewOrder, ModifyOrder, and CancelOrder. On receiving the order request messages from the applications 105, the send orders interface 316 validates the order request messages against pre-configured basic risk controls like max order size, max order notional, etc. In one embodiment, if the risk checks are satisfied, the send orders interface 316 adds the order request messages to an internal queue to feed into the message builder 318. In another embodiment, if the risk checks are not satisfied, the send orders interface 316 returns a rejected error back to the respective client application 105, via the platform driver.

The message builder component 318 receives the order requests in a common internal representation from the send orders interface 316 queue, and converts the order messages in exchange specific format. The message builder component 318 implementations vary from exchange to exchange, and is implemented according to the exchange orders entry system specification.

The own order book builder 304 receives the new order or order updates from send orders interface 316, receives the order updates from message parser 312, and creates and maintains the own order book with aggregated view of own orders in the market in an internal representation. In one example, the internal representation of the own order book comprises a list of price levels on both bid and ask sides, each price level contains price, qty available at that price level. Further, the internal representation also comprises the security status like trading, halted, etc., of the instrument. The own order book builder 304 build and maintain the own trade information (if any) in a common internal representation as Price, Qty, TradeSide. Also, the own order book builder 304 builds and maintains the order information of each individual own order in the market, so that the own order book builder 304 can apply the own order messages 210 correctly to the orders. Own order messages, for example may be own order book update messages, own order trade update messages, and own order update messages. Further, the own order book builder 304 sends the own orders book, trade information (if any in the current updates), and order information of orders affected in the current updates to the shared memory 108 in the user space through the DMA Engine 222 and the PCIe interface. Furthermore, the own order book builder 304 instructs the application message handler 220 that a new own order book update has been passed to the user shared memory interface, with the indexes of the last own order book, own trade, and own order entries.

The application message handler 220 is configured to trigger the applications 105 to consume the new market data or own order book, trade, order information from the user shared memory interface, based on configured triggering mechanism. For example, the triggering mechanism may be one or more of triggering rules such as for example, trigger the application after every update from market data or own order interface, trigger the application only after update from market data and own order interface. Based on the triggering mechanism, the application message handler 220 adds entries to the shared memory interface to indicate the current latest view which can be a combination of for example, market data book view after the current event, market data trades received in the current event, market data order updates received in the current event, own order book view after the current event, own order trades received in the current event and own order updates received in the current event.

The DPS 102 further comprises a control process (not shown) that initializes DPS 102 with configurations (like risk control configurations) and everyday reference data (like UDP multicast addresses/ports, TCP IP addresses/ports, interested products/instruments) read from user configuration files. The control process also provides an interface to dump alerts/statistics passed from trading platform to User GUI or files. Furthermore, the control process provides an interface to pass dynamic configuration updates (like risk control configurations) to shared memory interface. The shared memory interface is the interface between the RLD 110 and the applications 105 for receiving trading information such as market data messages 208, own order messages 210 and so on. The trading information thus passed is stored in the shared memory that comprises different circular buffers. The platform driver acts as an interface between the DPS API layer and RLD 110 for sending orders. The platform driver also sends the order request messages 216 directly to the RLD 110. The platform driver also acts as an interface between the control process and RLD 110 for implementing the functionality of the control process.

Figure 3c illustrates a block diagram of the shared memory 108 of the DPS 102 and Figure 3d illustrates a block diagram illustrating the buffers used for various updates in the shared memory 108. In one embodiment, the shared memory 108 comprises one or more buffers coupled with the applications 105. Each of the one or more buffers in the shared memory 108 is identified by at least one or more of unique instrument_id, and application_id 212. The instrument_id may be a unique identification of the financial instrument maintained by the exchange network 103. Application_id 212 is a unique identification to each application 105 assigned by the RLD 110 when the applications are initialized and registered with the RLD 110.

In one embodiment, the shared memory 108 comprises a marketdatabook buffer 332, a marketdatatrade buffer 334, a marketdataorderupdates buffer 336, an ownorderbook buffer 338, an ownordertrade buffer 340, an ownorderupdates buffer 342 and a masterupdate buffer 344. The DPS 102 is configured to update one or more of marketdatabook buffer 332, marketdatatrade buffer 334, marketdataorderupdates buffer 336, corresponding to the instrument_id to reflect the marketdatabook, marketdatatrade and marketdataorderupdates. The DPS 102 is also configured to update one or more of ownorderdatabook buffer 338, ownordertrade buffer 340, and ownorderupdates buffers 342 in the shared memory corresponding to the instrument_id and the application_id 212 to reflect the ownorderbook, ownordertrade, and ownorderupdates view in response to transmitting the plurality of order request messages to the external network. The marketdatabook buffer 332, identified by the instrument_id, includes one or more entries or records. Each entry in the marketdatabook buffer 332 corresponds to view of a market data book information of predetermined number of ordered market data for a given instrument. The marketdatabook buffer 332 is updated in response to receiving and processing the market data update message. The marketdatatrade buffer 334, identified by the instrument_id, includes one or more entries, each entry being identified by a trade_id and corresponds to view of market data trade information. The marketdatatrade buffer 334 is updated in response to receiving and processing the market trade update message. The marketdataorderupdates buffer 336, identified by the instrument_id, includes one or more entries. Each entry is identified by an order id and corresponds to view of a market data order information. The marketdataorderupdates buffer 336 is updated in response to receiving and processing the market data order update message.

The ownorderdatabook buffer 338, identified by the instrument_id and the application_id 212, includes one or more entries or records. Each entry corresponds to view of an own order book information for application 105 corresponding to the application_id 212. The ownorderdatabook buffer 338 is updated in response to receiving and processing the own order book data update message. The ownorderdatabook buffer 338 is also updated in response to sending the order request messages 216. The ownordertrade buffer 340, identified by the instrument_id and application_id 212, includes one or more entries, each entry, identified by the trade_id. Each entry in the ownordertrade buffer 340 corresponds to view of an own order trade information for application 105 corresponding to the application_id 212 that is updated in response to receiving and processing the own order trade update message.

The ownorderupdates buffer 342 identified by the instrument_id and application_id 212, includes one or more entries, each entry, identified by the order_id 214, corresponds to view of an own order information for application 105 corresponding to the application_id 212. The ownorderupdates buffer 342 is updated in response to receiving the own order update message and in response to sending the order request messages 216.

The DPS 102 further updates the masterupdates buffer 344 comprising at least instrument id corresponding to one or more instruments, index of latest entries in one or more of marketdatabook buffer 332, marketdatatrades buffer 334, marketdataorderupdates buffer 336, ownorderbook buffer 338, ownordertrade buffer 340 and ownorderupdates buffer 342, and flag symbols to indicate the type of updates in the current entry. The DPS 102 further updates a global masterupdatesbuffer index 346 (as shown in Figure 3d) to indicate the last update made by the processor 106. Each application 105 updates a masterupdatesbuffer index 348-1, 348-2, ... 348-N (collectively referred to as masterupdatesbuffer index 348) corresponding to each application 105 to indicate the last update read by the applications 105 in response to any update to the masterupdates buffer 344.

Further, each application 105 compares the respective masterupdatesbuffer index 348 against the global masterupdates buffer index 346 to identify the new updates, and accesses all the updates in the masterupdates buffer 344 between own masterupdatesbuffer_index 348 and global masterupdatesbuffer index 346. The applications 105 further determines the instrument_id from corresponding entry in the materupdates buffer 346 and accesses the one or more of marketdatabook buffer 332, marketdatatrade buffer 334, marketdataorderupdates buffer 336, corresponding to the instrument_id. In another embodiment, the applications 105 determines the instrument_id and application_id from corresponding entry in the materupdates buffer 346, and determines whether the application_id matches the corresponding application_id 212. Based on the matching, the applications 105 determines that there are new own order updates and accesses the one or more of ownorderdatabook buffer 338, ownordertrade buffer 340, and ownorderupdates buffers 342 corresponding to the instrument_id and application_id 212. As mentioned above, in both embodiment, the applications 105 use the latest masterupdatesbuffer index 348 to access the latest entry in the one or more buffers.

In operation, the processor 106 receives a plurality of market data messages 208 and own order messages 210 from an external network such as exchange server 104. In one embodiment, the market data interface 112 receives the plurality of market data messages or packets 208 from the exchange server 104 via the UDP processing engine 116. The connection handler 302 manages connection of the DPS 102 to the exchange server 104. The line sequencer module 304 detects the duplicate packets, out of order packets, packets gaps based on the packets sequence number, and feeds the packets to the message parser module 306 in sequence. If a packet is lost in both the multicast lines, sequence number gap alert is raised via the Alert manager 226. The message parser 306 parses the exchange specific market data messages and feed into book builder 310. The book builder 310 is configured to build and maintain the market data book in a common internal representation, so that exchange specific market data protocol is abstracted from the host applications 105. The book builder 310 is configured to build and maintain the order information of each individual order available in the market data, so that the book builder 310 can apply the market data messages 208 correctly to the orders. Further, the book builder 310 is configured to instruct the application message handler 220 that a new market data book update has been passed to the user shared memory interface, with the indexes of the last market data book, market trade, and market order entries.

The exchange server 104 also provide a mechanism to retrieve the snapshot of the entire book. If the line sequencer 304 detects a sequence number gap which is bigger than a pre- configured limit or the gapped packet is not retrieved in both the duplicate multicast lines, then the DPS 102 instructs the snapshot manager 308 to retrieve the entire book from the exchange server 104. On receiving the snapshot request, the snapshot manager 308 clears the order book, joins the snapshot multicast channels, handles the snapshot messages from the exchange server 104, and rebuild the entire book based on the snapshot messages from the exchange server 104.

The own order interface 114 receives the plurality of own order messages 210 from the exchange server 104 via the TCP processing engine 118. The message parser 312 parses the own order messages 210 such as own order update messages received from the exchange server 104 in exchange specific format, and feed them to own order book builder 304 in a common internal representation, so that exchange specific own order interface protocol is abstracted from the host applications. The own order book builder 304 builds and maintains the order information of each individual own order in the market, so that the own order book builder 304 can apply the own order messages 210 correctly to the orders. Further, the own order book builder 304 sends the own orders book, trade information (if any in the current updates), and order information of orders affected in the current updates to the user space shared memory 108 through the DMA Engine 222 and the PCIe interface. Furthermore, the own order book builder 304 instructs the application message handler 220 that a new own order book update has been passed to the user shared memory interface, with the indexes of the last own order book, own trade, and own order entries.

The processor 106 determines an application identity (application_id) 212 for each of the plurality of own order messages 210 and generates an internal representation of the received plurality of market data messages 208 and own order messages 210 including the application_id 212. Upon generation of the internal representation, the processor 106 transmits the internal representation of the plurality of market data messages 208 and own order messages 210 to the plurality of user applications 105. Based on the processing of the internal representation of the plurality of market data messages 208 and the plurality of own order messages 210, the applications 105 generate a plurality of order request messages 216 in the internal representation format.

The send orders interface 316 is the entry point into the own orders interface 114 for the order request messages 216 passed from the applications 105 via the platform driver. On receiving the order request messages 216 from the applications 105, the platform driver assigns the plurality of order request messages 216 received into one or more slots of a queue maintained by the send orders interface 316. Each slot of the queue corresponds to the application_id 212 associated with the plurality of user applications 105. The send orders interface 316 continuously polls the one or more slots in a predetermined manner for example, in a round-robin fashion to determine if there is any order request message in one or more slots. Upon determination of order request message in one or more slots, the send orders interface 316 validates the order request messages 216 against pre- configured basic risk controls. In one embodiment, if the risk checks are satisfied, the send orders interface 316 adds the order request messages 216 to an internal queue to feed into the message builder 318. In another embodiment, if the risk checks are not satisfied, the send orders interface 316 returns a rejected error back to the respective client application 105, via the platform driver and generates an alert that an order request failed to pass through the risk validation process.

The message builder component 318 receives the order request messages 216 in a common internal representation from the send orders interface 316 queue, and converts the order request messages in exchange specific format. The own order book builder 304 receives the new order or order updates from send orders interface 316, receives the order updates from message parser 312, and creates and maintains the own order book with aggregated view of own orders in the market in an internal representation. The application message handler 220 is configured to trigger the applications 105 to consume the new market data or own order book, trade, order information from the user shared memory interface, based on configured triggering mechanism. Based on the triggering mechanism, the application message handler 220 adds entries to the shared memory interface to indicate the current latest view. The DPS 102 also provides multiple filtering mechanisms at different levels of trading information. For example, the filtering mechanisms include such as instrument level filtering, market data filtering and message level filtering. The DPS 102 provides the instrument level filtering by filtering the market data based on instruments for which the user applications 105 have registered or interested. In another embodiment, the DPS 102 provides the market data filtering by filtering the market data and exposing only the top price levels to the application, and the number of price levels exposed is configurable. In yet another embodiment, the DPS 102 provides the message level filtering by filtering and parsing the messages that are essential for building market data and own order books and trade information. Thus, the system 100 processes the market data and own order data at the RLD using different filtering mechanisms configurable by the users, providing the normalized, filtered data which are interested to the applications. This improves the latency in accessing the normalized data, and memory locality and caching performance at trading applications. It also allows different applications to receive the same market data, but receives only own order updates without compromising the latency.

Figure 4a illustrates a flowchart of an exemplary method of processing trade information received from the exchange network supporting multiple applications in accordance with some embodiments of the present disclosure.

As illustrated in Figure 4a, the method 400 comprises one or more blocks implemented by the processor 106 for processing trading information received from the exchange network 103. The method 400 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform particular functions or implement particular abstract data types.

The order in which the method 400 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 400. Additionally, individual blocks may be deleted from the method 400 without departing from the scope of the subject matter described herein. Furthermore, the method 400 can be implemented in any suitable hardware, software implemented by a processor, firmware, or combination thereof.

At block 402, market data message and own order messages are received. In one embodiment, the processor 106 receives a plurality of market data messages 208 and own order messages 210 from an external network such as exchange server 104. In one embodiment, the market data interface 112 receives the plurality of market data messages 208 from the exchange server 104 via the UDP processing engine 116. The connection handler 302 manages connection of the DPS 102 to the exchange server 104. The line sequencer module 304 detects the duplicate packets, out of order packets, packets gaps based on the packets sequence number, and feeds the packets to the message parser module 306 in sequence. If a packet is lost in both the multicast lines, sequence number gap alert is raised via the Alert manager 226. The own order interface 114 receives the plurality of own order messages 210 from the exchange server 104 via the TCP processing engine 118. At block 404, internal representation of the received messages is generated. In one embodiment, the message parser 306 parses the exchange specific market data messages and feed into book builder 310. The book builder 310 is configured to build and maintain the market data book in a common internal representation, so that exchange specific market data protocol is abstracted from the host applications 105. The book builder 310 is configured to build and maintain the order information of each individual order available in the market data, so that the book builder 310 can apply the market data messages 208 correctly to the orders. Further, the book builder 310 is configured to instruct the application message handler 220 that a new market data book update has been passed to the user shared memory interface, with the indexes of the last market data book, market trade, and market order entries.

The exchange server 104 also provide a mechanism to retrieve the snapshot of the entire book. If the line sequencer 304 detects a sequence number gap which is bigger than a pre- configured limit or the gapped packet is not retrieved in both the duplicate multicast lines, then the DPS 102 instructs the snapshot manager 308 to retrieve the entire book from the exchange server 104. On receiving the snapshot request, the snapshot manager 308 clears the order book, handles the snapshot messages from the exchange server 104, joins the snapshot multicast channels and rebuild the entire book based on the snapshot messages from the exchange server 104. The message parser 312 parses the own order messages such as own order update messages received from the exchange server 104 in exchange specific format, and feed them to own order book builder 304 in a common internal representation, so that exchange specific own order interface protocol is abstracted from the host applications. The own order book builder 304 builds and maintains the order information of each individual own order in the market, so that the own order book builder 304 can apply the own order messages 210 correctly to the orders. Further, the own order book builder 304 sends the own orders book, trade information (if any in the current updates), and order information of orders affected in the current updates to the user space shared memory 108 through the DMA Engine 222 and the PCIe interface. Furthermore, the own order book builder 304 instructs the application message handler 220 that a new own order book update has been passed to the user shared memory interface, with the indexes of the last own order book, own trade, and own order entries.

At block 406, internal representations are transmitted to user applications. In one embodiment, the processor 106 determines an application identity (application_id) 212 for each of the plurality of own order messages 210 and generates an internal representation of the received plurality of market data messages 208 and own order messages 210 including the application_id 212. Upon generation of the internal representation, the processor 106 transmits the internal representation of the plurality of market data messages 208 and the plurality of own order messages 210 to the plurality of user applications 105. Figure 4b illustrates a flowchart of an exemplary method of processing trade information transmitted to the exchange network supporting multiple applications in accordance with some embodiments of the present disclosure.

As illustrated in Figure 4b, the method 410 comprises one or more blocks implemented by the processor 106 for processing trading information transmitted to the exchange network 103. The method 410 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform particular functions or implement particular abstract data types. The order in which the method 410 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 410. Additionally, individual blocks may be deleted from the method 410 without departing from the scope of the subject matter described herein. Furthermore, the method 410 can be implemented in any suitable hardware, software implemented by a processor, firmware, or combination thereof.

At block 412, order request messages are created in internal representation. In one embodiment, the applications 105 generate a plurality of order request messages 216 in the internal representation format in response to the market data updates and own order updates. The order request messages 216 are passed via the platform driver and added to the slot corresponding to the application_id 212.

At block 414, order request messages are assigned to slot corresponding to the application. In one embodiment, the send orders interface 316 receives the order request messages 216 from the applications 105 and assigns the plurality of order request messages 216 into one or more slots of a queue maintained by the send orders interface 316. Each slot of the queue corresponds to the application_id 212 associated with the plurality of user applications 105. The send orders interface 316 continuously polls the one or more slots in a predetermined manner for example, in a round-robin fashion to determine if there is any order request message in one or more slots. Upon determination of order request message 216 in one or more slots, the send orders interface 316 validates the order request messages 216 against pre-configured basic risk controls. In one embodiment, if the risk checks are satisfied, the send orders interface 316 adds the order request messages 216 to an internal queue to feed into the message builder 318. In another embodiment, if the risk checks are not satisfied, the send orders interface 316 returns a rejected error back to the respective client application 105, via the platform driver and generates an alert that an order request failed to pass through the risk validation process. The send orders interface 316 passes the order information such as a new order or as update on the existing order (in case of modify or cancel requests), and pass it to the own order book builder 304to construct the ownorder book and order information. At block 416, external representation of order request message is generated. In one embodiment, the message builder component 318 receives the order request messages 216 in a common internal representation from the send orders interface 316 queue, and converts the order request messages 216 in exchange specific format. The own order book builder 304 receives the new order or order updates from send orders interface 316, receives the order updates from message parser 312, and creates and maintains the own order book with aggregated view of own orders in the market in an internal representation.

The application message handler 220 is configured to trigger the applications 105 to consume the new market data or own order book, trade, order information from the user shared memory interface, based on configured triggering mechanism. Based on the triggering mechanism, the application message handler 220 adds entries to the shared memory interface to indicate the current latest view.

The DPS 102 is configured to update one or more of ownorderdatabook buffer, ownordertrade buffer, ownorderupdates buffers in the shared memory corresponding to the instrument_id and the application_id 212 to reflect the ownorderbook, ownordertrade, and ownorderupdates view in response to transmitting the plurality of order request messages to the external network.

The marketdatabook buffer 332 is updated in response to receiving and processing the market data update message. The marketdatatrade buffer 334 is updated in response to receiving and processing the market trade update message. The marketdataorderupdates buffer 336 is updated in response to receiving and processing the market data order update message. The ownorderdatabook buffer 338 is updated in response to receiving and processing the own order book data update message. The ownordertrade buffer 340 is updated in response to receiving and processing the own order trade update message. The ownorderupdates buffer 342 identified by the instrument_id and application_id, includes one or more entries, each entry, identified by the order_id 214, corresponds to view of an own order information. The ownorderupdates buffer 342 is updated in response to receiving the own order update message. The DPS 102 further updates the masterupdates buffer 344 comprising at least instrument id corresponding to one or more instruments, index of latest entries in one or more of marketdatabook buffer 332, marketdatatrades buffer 334, marketdataorderupdates buffer 336, ownorderbook buffer 338, ownordertrade buffer 340 and ownorderupdates buffer 342, and flag symbols to indicate the type of updates in the current entry. The DPS 102 further updates a global masterupdatesbuffer index 346 to indicate the last update made by the processor 106.Each application 105 updates a masterupdatesbuffer index 348 corresponding to each application 105 to indicate the last update read by the applications 105 in response to any update to the masterupdates buffer 344. Thus, the system 100 processes the market data and own order data at the RLD using different filtering mechanisms configurable by the users, providing the normalized, filtered data which are interested to the applications. This improves the latency in accessing the normalized data, and memory locality and caching performance at trading applications. It also allows different applications to receive the same market data, but updates only own order updates without compromising the latency.

The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. Also, the words "comprising," "having," "containing," and "including," and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise.

Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term "computer-readable medium" should be understood to include tangible items and exclude carrier waves and transient signals, i.e., are non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.

Advantages of the embodiment of the present disclosure are illustrated herein

In an embodiment, the present disclosure allows different applications to receive and maintain the same market data view, but receive and maintain individual ownorders view, reducing the resources and without compromising the latency

In an embodiment, the present disclosure improves the latency in accessing the normalized data, and memory locality and caching performance at trading applications. By using a shared memory, both market data and own order updates are accessed faster as they are stored in same place.

It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims.

Claims

The Claims:

1. A method for processing data associated with multiple applications, said method comprising:

receiving, by a processor (106) of a reconfigurable logic device (110), a plurality of market data messages (208) and own order messages (210) from an external network (103);

determining, by the processor (106), an application identity (application_id) (212) for each of the plurality of own order messages (210);

generating, by the processor (106), an internal representation of the received plurality of market data messages (208) and own order messages (210) including the application_id (212); and

transmitting, by the processor (106), the internal representation of the plurality of market data messages (208) and own order messages (210) to a plurality of user applications (105).

2. The method as claimed in claim 1, further comprising:

receiving, from each user application (105), a plurality of order request messages (216) in the internal representation format, in response to processing of the plurality of market data messages (208);

assigning, the application_id (212) of the corresponding user application in each order request message (216) created by the user application (105);

generating a corresponding plurality of order request messages (216) in the external representation; and

transmitting the plurality of order request messages (216) to the external network (103).

3. The method as claimed in claim 1, wherein the plurality of market data messages (208) comprises market data book update messages, market data trade update messages, and market data order update messages.

4. The method as claimed in claim 1, wherein the plurality of own order messages

(210) comprises own order book update messages, own order trade update messages, and own order update messages. The method as claimed in claim 2, wherein generating a corresponding plurality of order request messages (216) comprising one or more steps of:

receiving the plurality of order request messages (216) in the internal representation from the plurality of user applications (105);

assigning the plurality of order request messages (216) received into one or more slots, each slot corresponding to the application_id (212) associated with the plurality of user applications (105);

polling the one or more slots in a predetermined manner;

determining risk score based on comparison of order information in the plurality of order request messages (216) with predetermined risk control information, in response to polling; and

converting the plurality of order request messages (216) into a corresponding plurality of order request messages in the external representation based on the determination.

The method as claimed in claim 1 , further comprising updating one or more buffers of a shared memory (108) identified by at least one or more of unique instrument_id, and the application_id (212), coupled with the plurality of user applications, with the plurality of market data messages (208) and own order messages (210) in the internal representation thus generated.

The method as claimed in claim 6, wherein updating the one or more buffers comprise updating a marketdatabook buffer (332), identified by the instrument_id, that includes one or more entries, each entry corresponds to view of a market data book information of predetermined number of ordered market data for a given instrument, in response to receiving the market data update message.

The method as claimed in claim 6, wherein updating the one or more buffers comprise updating a marketdatatrade buffer (334), identified by the instrument_id, that includes one or more entries, wherein each entry, identified by a trade_id, corresponds to view of market data trade information, in response to receiving the market trade update message.

9. The method as claimed in claim 6, wherein updating the one or more buffers comprise updating a marketdataorderupdates buffer (336), identified by the instrument_id, that includes one or more entries, wherein each entry, identified by an order id, corresponds to view of a market data order information, in response to receiving the market data order update message.

10. The method as claimed in claim 6, wherein updating the one or more buffers comprise updating a ownorderdatabook buffer (338), identified by the instrument_id and the application_id (212), that includes one or more entries, each entry corresponds to view of an own order book information, in response to receiving the own order book data update message.

11. The method as claimed in claim 6, wherein updating the one or more buffers comprise updating a ownordertrade buffer (340), identified by the instrument_id and application_id (212), that includes one or more entries, each entry, identified by the trade_id, corresponds to view of an own order trade information, in response to receiving the own order trade update message.

12. The method as claimed in claim 6, wherein updating the one or more buffers comprise updating a ownorderupdates buffer (342), identified by the instrument_id and application_id (212), that includes one or more entries, each entry, identified by the order_id (214), corresponds to view of an own order information, in response to receiving the own order update message.

13. The method as claimed in claim 5, further comprising updating one or more of ownorderdatabook buffer (338), ownordertrade buffer (340), ownorderupdates buffers (342) in the shared memory (108) corresponding to the instrument_id and the application_id (212) to reflect the ownorderbook, ownordertrade, and ownorderupdates view in response to transmitting the plurality of order request messages (216) to the external network (103).

14. The method as claimed in claim any of 6 or 13, further comprising updating a masterupdates buffer (344) comprising at least instrument_id corresponding to one or more instruments, index of latest entries in one or more of marketdatabook buffer (332), marketdatatrade buffer (334), marketdataorderupdates buffer (336), ownorderbook buffer (338), ownordertrade buffer (340) and ownorderupdates buffer (342), and flag symbols to indicate the type of updates in the current entry.

15. The method as claimed in claim 14, further comprising updating a global masterupdatesbuffer index (346) to indicate the last update made by the processor (106) and updating a masterupdatesbuffer index (348) corresponding to each user application (105) to indicate the last update read by the plurality of user applications (105) in response to any update to the masterupdates buffer (344).

16. A system (102) for processing data associated with multiple applications, device comprising:

a reconfigurable logic device (110) comprising at least a processor (106), a memory, a marketdata interface (112) and a ownorder interface (114) coupled with the processor (106);

a plurality of user applications (105) coupled with the processor (106); and a shared memory (108) and a shared memory interface coupled with the shared memory (108) configured to interact with the processor (106) and the plurality of applications (105);

wherein the memory stores processor-executable instructions, which, on execution, cause the processor (106) to:

receive a plurality of market data messages (208) and own order messages (210) from an external network (103);

determine an application identity (application_id) (212) for each of the plurality of own order messages (210);

generate an internal representation of the received plurality of market data messages (208) and own order messages (210) including the application_id (212); and

transmit the internal representation of the plurality of market data messages (208) and own order messages (210) to the plurality of user applications (105).

17. The system as claimed in claim 16, wherein the processor is further configured to: receive a plurality of order request messages (216) created by the plurality of user applications (105) in the internal representation format;

assign the application_id (212) of the corresponding user application (105) in each order request message (216) created by the user application (105);

generate a corresponding plurality of order request messages (216) in the external representation; and

transmit the plurality of order request messages (216) to the external network (103).

18. The system as claimed in claim 16, wherein the plurality of market data messages (208) comprises market data book update messages, market data trade update messages, and market data order update messages.

19. The system as claimed in claim 16, wherein the plurality of own order messages (210) comprises own order book update messages, own order trade update messages, and own order update messages.

20. The system as claimed in claim 17, wherein the processor (106) is configured to generate a corresponding plurality of order request messages (216) by performing one or more steps of:

polling the one or more slots in a predetermined manner;

determining risk score based on comparison of order information in the plurality of order request messages (216) with predetermined risk control information, in response to polling; and converting the plurality of order request messages (216) into a corresponding plurality of order request messages in the external representation based on the determination. 21. The system as claimed in claim 16, wherein the shared memory (108) comprises one or more buffers identified by at least one or more of unique instrument_id and the application_id (212), coupled with the plurality of user applications (105), updated with the plurality of market data messages (208) and own order messages (210) in the internal representation upon generation.

22. The system as claimed in claim 21, wherein the one or more buffers comprise a marketdatabook buffer (332), identified by the instrument_id, that includes one or more entries, each entry corresponds to view of a market data book information of predetermined number of ordered market data for a given instrument, updated by the processor (106) in response to receiving the market data update message.

23. The system as claimed in claim 21, wherein the one or more buffers comprise a marketdatatrade buffer (334), identified by the instrument_id, that includes one or more entries, wherein each entry, identified by a trade_id, corresponds to view of market data trade information updated by the processor (106) in response to receiving the market trade update message.

24. The system as claimed in claim 21, wherein the one or more buffers comprise a marketdataorderupdates buffer (336), identified by the instrument_id, that includes one or more entries, wherein each entry, identified by an order_id (214), corresponds to view of a market data order information updated by the processor (106) in response to receiving the market data order update message.

25. The system as claimed in claim 21, wherein the one or more buffers comprise a ownorderbook buffer (338), identified by the instrument_id and the application_id

(212), that includes one or more entries, each entry corresponds to view of an own order book information updated by the processor (106) in response to receiving the own order book data update message. The system as claimed in claim 21, wherein the one or more buffers comprise a ownordertrade buffer (340), identified by the instrument_id and the application_id (212), that includes one or more entries, each entry, identified by the trade_id, corresponds to view of an own order trade information updated by the processor in response to receiving the own order trade update message.

The system as claimed in claim 21, wherein the one or more buffers comprise a ownorderupdates buffer (342), identified by the instrument_id and the application_id (212), that includes one or more entries, each entry, identified by the order_id (214), corresponds to view of an own order information updated by the processor (106) in response to receiving the own order update message.

The system as claimed in claim 16, wherein the processor (106) is further configured to update one or more of ownorderbook buffer (338), ownordertrade buffer (340), ownorderupdates buffers (342) in the shared memory (108) corresponding to the instrument_id and the application_id (212) to reflect the ownorderbook, ownordertrade, and ownorderupdates view in response to transmitting the plurality of order request messages (216) to the external network (103).

The system as claimed in claim 20 or 28, further comprising a masterupdates buffer (344) comprising at least instrument id corresponding to one or more instruments, index of latest entries in one or more of marketdatabook buffer (332), marketdatatrade buffer (334), marketdataorderupdates buffer (336), ownorderbook buffer (338), ownordertrade buffer (340) and ownorderupdates buffer (342), and flag symbols to indicate the type of updates in the current entry.

The system as claimed in claim 29, wherein the processor is further configured to update a global masterupdatesbuffer index (348) to indicate the last update made by the processor and update a masterupdatesbuffer index (346) corresponding to each user application to indicate the last update read by the plurality of user applications (105) in response to any update to the masterupdates buffer (344).