Feed handling device, system and feed handling method

Abstract

This application proposes a feed handling device embodied on FPGA, comprising: multiple normalization blocks, configured to receive financial market data feed from multiple exchanges, derive packets transmitted in feed into normalized updates; a MUX Block, configured to merge the normalized updates into a single sequenced stream; an OBM block, configured to maintain a LOB for all financial instruments traded in multiple exchanges, process each order related updates to update LOB, retrieve information from LOB to populate empty fields in updates, a BBM block, configured to process each order related updates to update a level book, track top N price levels for all financial instruments traded in multiple exchanges. Wherein entries in LOB and level book don't need to be sorted in sequence, updates are pipelined from through all blocks remaining sequence as they are received. This application also proposes a feed handling system and a feed handling method.

Description

FEED HANDLING DEVICE, SYSTEM AND FEED HANDLING METHODTECHNICAL FIELD

[0001] The present application generally relates to the field of integrated circuits, and more particularly, to a feed handling device, system and a feed handling method.TERMINOLOGY

[0002] Market data: market data from an exchange refers to real-time and historical information about financial instruments traded in this exchange, such as order book data (e.g. bid price, ask price, and their sizes / quantities), trade related data (e.g. volumes / quantities, and timestamps), and reference data (e.g. symbol details, trading status, and corporate actions). Market participants, such as trading firms or individual traders, may analyze price movements, executed trades, and develop algorithmic strategies based on the market data received from the exchange.

[0003] Exchange: an exchange can be a stock exchange, a futures exchange, a commodity exchange, etc. An exchange has its own specification for format of market data. Due to mergers and acquisitions, an exchange group can own multiple exchanges. Exchanges in the same exchange group could use the same technology platform and therefore the same format specification.

[0004] Feed: market data transmitted by an exchange may be referred to a feed. In practice, an exchange may transmit multiple copies of its market data for redundancy, and each copy sent over a separate network connection. For example, each copy may be sent with UDP multicast over a separate Ethernet connection. In such case, each copy of market data sent over a separate network connection may be referred to a feed. All feeds from one exchange may differ in packetization due to the different type of network connection, such as optical fiber, wireless transmission.

[0005] Packet and raw message: within a feed, market data is encapsulated in the form of packets, for example, UDP packet if UDP multicast is applied. Payload in each packet may comprise one or more discrete raw messages, each raw message is associated with a sequence number. Each packet may comprise a field indicating sequence number of the first raw message carried in its payload, and another field indicating the amount of raw messages carried in its payload. If the latter is absent in format specification for market data, it is assumed that there is only one raw message per packet.

[0006] Channel: an exchange may classify its market data according to certain standard, e.g., market data for financial instruments of different industries. The exchange may transmit its market data of the same classification in the same channel. All the channels may share a feed in a time division multiplexing mode. Each channel is associated with a channel number, and all the packets within a channel is marked with the channel number.

[0007] Incremental updates: within market data feeds, each raw message may comprise one or more incremental updates. Each incremental updates corresponds to a record in the order book of the exchange, which may refer to a single action, such as create / add, modify, replace, delete or executed, adopted to a financial instrument traded in the exchange, or a single event occurred in the exchange, such as trade suspension, market close, etc.

[0008] Snapshot: periodic full-order book snapshots containing all active orders in the exchanges at certain time point. Each snapshot is marked with a sequence number, which indicates the sequence number of the latest raw message captured by this snapshot.BACKGROUND

[0009] Since the importance of the market data to the market participants, exchanges may distribute market data via high-speed networks, for example, using UDP multicast, to ensure minimal latency for market participants.

[0010] Market data reflects how an order is entered, modified, traded, or canceled in the market. Some exchanges include all necessary details in each incremental update, such as order ID, symbol name or symbol ID, price, quantity, old price, new price, old quantity, and new quantity for modification updates. Others, however, only provide full details when a new order is entered, assuming that market participants will track order information internal their own trading system. In such cases, subsequent updates may comprise only the order ID, requiring market participants to maintain other information.

[0011] Additionally, the uniqueness of the order ID varies across exchanges, some exchanges enforce a globally unique order ID across all symbols, while others make it unique only within a specific symbol or even a side (bid / ask) of a symbol. As a result, the different format of the market data and the various uniqueness of the order ID adopted by different exchanges often result in ambiguity when the market participants receive market data from multiple exchanges.

[0012] Therefore, to support exchanges that do not always send full order details, market participants must maintain a local order book to track all active orders in exchanges. A fundamental function of the local order book is to retrieve the old price and old quantity of an order when a subsequent incremental update arrives from market data. This allows market participants to properly interpret modifications and maintain an accurate view of the market.

[0013] Moreover, market participants may need to have a summarized representation of the order book, helping with a quickly assess liquidity at different price points, as well as  to track the best bid price and best ask price, which are critical for price discovery and execution strategies.

[0014] However, the ability and efficiency of the present systems in the market are not yet sufficient for processing large volume of market data fed to market participants in variety of formats. More particularly, neither the hardware nor the strategies of the present systems in the market are powerful and sophisticated enough to build up and maintain real-time and accurate local order book and summarized representation based on the large volume market data in different formats for price discovery and execution strategies in a consolidated hardware architecture.SUMMARY

[0015] The present application proposes a feed handling device, comprising: multiple normalization blocks, each of which comprises: a parse cell, configured to receive packets of a financial market data feed from an exchange via an network connection, slice each packet transmitted by the financial market data feed into one or more raw messages, then slice each raw message into one or more incremental updates, and slice each incremental updates into different fields; and a normalization cell, coupled to the parse cell, configured to receive sliced fields and information from the parse cell and organize the sliced fields and information into normalized updates with a normalized format; wherein when the normalization cell outputs the normalized updates, they are in the same sequence as the sequence of the incremental updates arriving at the parse cell; wherein each of the normalized updates comprise a type field; a MUX Block, coupled to all the multiple normalization blocks, configured to merge the normalized updates from the multiple normalization blocks into a single sequenced stream; an OBM block, coupled to the MUX block, configured to receive normalized updates from the MUX block, identify whether each of the normalized update is an order related update or a non-order related update by the type field, process each of the order related updates to update a LOB, retrieve information from the LOB to populate any empty fields in the order related updates, and transmit each of the normalized updates to downstream block in the same sequence as they are received; wherein, the OBM block is configured to maintain a single LOB for all financial instruments traded in the multiple exchanges or a portion thereof selected by the user, and entries in the LOB do not need to be sorted in any sequence; a BBM block, coupled to the OBM block, configured to receive normalized updates from the OBM block, process each of the order related updates to update a level book that aggregates the order related update into various price levels; track top N price levels for all the financial instruments traded in the multiple exchanges or a portion thereof selected by the user, wherein N is an integer set by the user; generate data for fill consolidation service or trade summary service as required by the user; transmit each of the normalized updates to downstream block in the same sequence as they are received, and transmit top N price levels or their changes and other data required by the user to downstream block; wherein, the BBM block is configured to maintain a single level book for all financial instruments traded in the multiple exchanges or a portion thereof selected by the user, and entries in the level book do not need to be sorted in any sequence; and an output block, coupled to the BBM block, configured to receive output from the BBM block and format the output into a format adaptive to trading server running by the user, and transmit formatted output to the trading server running by the user.

[0016] The present application further proposes a feed handling system, comprising: multiple network connectors, configured to support network connections with multiple exchanges; a feed handling device described above; a storage block, coupled to the feed handling device, configured to store an LOB maintained by the feed handling device; a connector, coupled between the feed handling device and the user’s trading server; a power block, configured to provide the power supply to the feed handling system; a clock block, configured to provide the clock signal to the feed handling system; and a BMC block, configured to handle board management functions, including controlling the power-up sequence and continuously monitoring temperatures, voltages, and other sensor data.

[0017] The present application further proposes a feed handling method performed by a feed handling device described above, comprising: receiving financial market data feeds from multiple exchanges; filtering the packets transmitted in the financial market data feeds with redundancy; parsing each packet transmitted in the feeds into one or more raw messages, then into one or more incremental updates, then into fields; organizing the fields and relevant information into normalized updates in the same sequence as the original incremental updates; merging the normalized updates corresponding to the multiple exchanges into one stream of the normalized message; maintaining a single LOB for all financial instruments traded in the multiple exchanges or a portion thereof selected by the user without sorting entries in the LOB, and pipelining the normalized updates to downstream in the same sequence as they are received; maintaining a single level book for all financial instruments traded in the multiple exchanges or a portion thereof selected by the user without sorting entries in the level book, and tracking top N price levels on each side for each financial instrument; generating necessary data for trade summary service or fill consolidation service if required by the user; and transforming format of feed handling output into that can be supported by the user’s trading server.BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Hereinafter, embodiments of the present application will be described in further detail with reference to the accompanying drawings, wherein:

[0019] Figure 1 is a block diagram illustrating a feed handling device according to an embodiment of the present application;

[0020] Figure 2 is a block diagram illustrating format of normalized updates according to an embodiment of the present application;

[0021] Figure 3 is a block diagram illustrating an order book management block in a feed handling device according to an embodiment of the present application;

[0022] Figure 4 is a block diagram illustrating format of keys generated by book updating cell according to an embodiment of the present application;

[0023] Figure 5 is a block diagram illustrating format of an entry in local order book maintained by order book management block according to an embodiment of the present application;

[0024] Figure 6 is a flow chart illustrating a working flow of order book management block maintaining local order book and remaining sequence of received normalized updates according to an embodiment of the present application;

[0025] Figure 7 is a block diagram illustrating a book building management block in a feed handling device according to an embodiment of the present application;

[0026] Figure 8 is a block diagram illustrating format of an entry of level book maintained by book building management block according to an embodiment of the present application;

[0027] Figure 9 is a block diagram illustrating exemplary tables for tracking top price levels on one side according to an embodiment of the present application;

[0028] Figure 10 is a block diagram illustrating a feed handling device according to an embodiment of the present application;

[0029] Figure 11 is a block diagram illustrating a feed handling device according to an embodiment of the present application;

[0030] Figure 12 is a block diagram illustrating a feed handling system according to an embodiment of the present application;

[0031] Figure 13 is a block diagram illustrating a feed handling device with initialization according to an embodiment of the present application;

[0032] Figure 14 is a block diagram illustrating a feed handling device with initialization according to an embodiment of the present application;

[0033] Figure 15 is a block diagram illustrating a feed handling device with initialization according to an embodiment of the present application; and

[0034] Figure 16 is a block diagram illustrating a feed handling device with initialization according to an embodiment of the present application.DESCRIPTION OF DISCLOSURE

[0035] For the purposes, technical solutions and advantages of the embodiments of the present application to become clearer, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application, and it is obvious that the described embodiments are a part of the embodiments of the present application rather than all the embodiments. Based on the embodiments in the present application, all the other embodiments obtained by a person of ordinary skill in the art without making any inventive effort fall within the scope of protection of the present application.

[0036] In modern quantitative trading, market participants rely on real-time market data feeds that provide incremental updates on trades, quotes, and order book changes directly from exchanges. Terminologies related to market data, such as exchanges, feeds, packets and raw messages, channels, incremental updates, have been explained in the above.

[0037] Figure 1 is a block diagram illustrating a feed handling device according to an embodiment of the present application. According to an embodiment of the present application, feed handling device 100 may be embodied on integrated circuits, such as Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC). According to a preferred embodiment, feed handling device 100 may be embodied in a single FPGA chip due to lower latency, better performance, and smaller dimension of feed handling device 100.

[0038] For example, The FPGA may include core programmable logic blocks (PLBs), configurable interconnect fabric, input / output blocks (IOBs / IOEs), embedded hardened resources, and additional advanced components.

[0039] In one embodiment, PLBs is the fundamental logic elements vary by vendor terminology but serve the same core purpose of implementing combinational and sequential logic, which may include look-up table (LUT) and flip-flop (FF); wherein LUT is a small SRAM-based memory array, and FF synchronizes output to a clock signal for state storage, critical for sequential logic operations.

[0040] In one embodiment, configurable interconnect fabric may enable flexible routing between all FPGA blocks, which may include routing channels, switch blocks, connection blocks and programming technology; wherein routing channels are horizontal / vertical metal tracks that transmit signals across the chip, switch blocks located at routing channel intersections allow signals to turn between directions, connection blocks link PLBs to routing channels and controlling signal input / output to logic blocks, and programming technology is SRAM-based switches (most common) using configuration bits to activate / deactivate connections.

[0041] In one embodiment, IOBs / IOEs may be used as peripheral-located blocks connecting the FPGA to external devices, supporting diverse interface standards; key features of IOBs / IOEs are programmable voltage levels (LVCMOS, LVTTL, LVDS), drive strength adjustment, and signal termination; wherein, IOBs / IOEs may comprise IO banks which are grouped IOBs / IOEs sharing power / ground rails, configurable for mixed-standard operation, and high-speed transceivers which are embedded in high-end FPGAs.

[0042] In one embodiment, embedded hardened resources are dedicated blocks integrated in modern FPGAs to boost performance and efficiency, reducing reliance on general-purpose logic, which may include block RAM (BRAM), digital signal processing (DSP) blocks and clock management tiles (CMTs); wherein, BRMA are dedicated memory blocks for efficient data storage that can be cascaded / subdivided to form RAM, ROM, FIFOs, or shift registers, with higher density than distributed register-based storage; DSP blocks are optimized for arithmetic operations (multiply-accumulate, FIR / IIR filters, FFT), high-end modes may support floating-point arithmetic alongside integer / fixed-point operations; CMTs may include phase-locked loops (PLLs) or digital clock manager (DCMs) for clock generation, frequency synthesis, phase shifting, and jitter reduction to synchronize system timing.

[0043] In one embodiment,  additional advanced components may include embedded processors, configuration logic and security blocks; wherein, embedded processors are hardened CPU cores for heterogeneous compute, merging software flexibility with hardware acceleration; configuration logic refers to SRAM-based FPGAs loading bit streams at power-up, some support partial reconfiguration for dynamic hardware updates without full chip reset; security blocks have encryption engines, secure boot, and anti-tamper features to protect configuration data and intellectual property.

[0044] Owing to the inherent characteristics and capabilities of integrated circuits such as FPGAs or ASICs, including parallel processing architecture, configurable logic resources, and high-speed data interfaces, the hardware-based feed handling device provided by the present application is capable of efficiently handling massive volumes of high-frequency financial instrument market data. Such hardware implementation enables real-time data processing and computation with significantly improved throughput and reduced latency, making the device particularly suitable for performance-critical scenarios in financial markets, such as high frequency trading (HFT).

[0045] According to an embodiment of the present application, the feed handling device 100 shown in Figure 1 can comprise a normalization block 110.

[0046] According to an embodiment of the present application, normalization block 110 shown in Figure 1 can comprise an input port, which may be coupled to a network connection from exchange A. Exchange A transmits feed A of market data through the network connection. Therefore, normalization block 110 may be configured to receive feed A of market data from exchange A via its input port.

[0047] According to an embodiment of the present application, network connection from the exchange can comprise optical connectors, such as Quad Small Form-factor Pluggable Double Density (QSFP-DD), Quad Small Form-factor Pluggable (QSFP) or Small Form-factor Pluggable (SFP), or electronic connections such as 10 GE copper connectors.

[0048] According to an embodiment of the present application, normalization block 110 can comprise a parse cell 111, coupled to input port of normalization block 110.

[0049] According to an embodiment of the present application, normalization block 110 can comprise a normalization cell 112, coupled to output port of parse cell 111.

[0050] As explained in the TERMINOLOGY, within a feed, market data is encapsulated in the form of packets. The payload in each packet may comprise one or more discrete raw messages, each raw message is associated with a sequence number. Each packet may comprise a field indicating sequence number of the first raw message carried in its payload, and another field indicating the amount of raw messages carried in its payload, the latter will be absent in case only one raw message is carried by the packet.

[0051] Meanwhile, an exchange may classify its market data into different channels according to certain standard. All the channels may share a feed in a time division multiplexing mode. Each channel is associated with a channel number, and all packets within a channel is marked with the channel number. Therefore, any packet transmitted within a feed can comprise yet another field indicating its channel number.

[0052] Furthermore, each raw message may comprise one or more incremental updates, each of which corresponds to a record in order book of the exchange. For example, an "Incremental Refresh Book" message from Chicago Mercantile Exchange (CME) may contain a group of level updates and a group of order updates.

[0053] According to an embodiment of the present application, parse cell 111 may be configured to receive packets in feed A from exchange A. Since format specification of exchange A may be preset into parse cell 111, once a packet arrives, parse cell 111 may be configured to identify boundary of raw messages in each packet, boundary of incremental updates in each raw message, and finally slice each incremental update into fields, such as symbol ID, price, quantity (Qty.), side, etc. Then parse cell 111 may be configured to mark the fields in each incremental update with information that enables normalization cell 112 to identify the first and the last fields in this update.

[0054] There are different types of incremental updates, for example, order book updates (such as new order, modification, cancellation, execution), and market status updates (such as market open / close, halts, auction imbalances). According to an embodiment of the present application, normalization cell 112 may be configured to receive the parsed fields and information from parse cell 111, and create normalized updates with an internal format based on the parsed field and information received from parse cell 111. Normalized updates created by normalization cell 112 includes two kinds as following:

[0055] 1. normalized updates derived from each incremental update based on parsed fields and information of incremental updates;

[0056] 2. synthetic updates generated based on information received from parsed cell 111 to facilitate the processing of market data.

[0057] Please be noted that normalized updates, including synthetic updates, are in the same formatting scheme which is described in detailed later on. For the sake of simplicity, whenever normalized updates are mentioned as a general concept, it should be understood that synthetic updates are included, no need to specify every time.

[0058] Figure 2 is a block diagram illustrating format of normalized updates according to an embodiment of the present application.

[0059] According to an embodiment of the present application, as shown in Figure 2, format of a normalized update can comprise a header.

[0060] According to an embodiment of the present application, header of a normalized update can comprise a type field to indicate the type of each normalized updates. In practice, different exchanges have different presentation of the type of each incremental update, e.g. National Association of Securities Dealers Automated Quotations （NASDAQ）may present the type of an incremental update indicating a new order has been added into its order book in a different way from CME. Therefore, normalization cell 112 may be further configured to unify the type field of normalized updates when deriving them from incremental updates indicating similar actions to an order, i.e. when an incremental update indicating a new order has been added into order book of exchange A arrives, no matter exchange A is NASDAQ or CME and no matter how exchange A presents the type of this update, normalization cell 112 will set a unified type field to this update, such as “Add”. Such type field doesn’t need to adopt the same presentation as exchange A. This feature is also useful when feed handling device processes financial market data feeds from multiple exchanges (which will be described in details later on) and different exchanges present the type of incremental updates indicating the same action in different ways. For example, as shown in Figure 2:

[0061] a type field of “Add” indicates normalized update 201 is derived from an incremental update represents a new order has been added or created into order book of exchange A;

[0062] a type field of “Mod (modification)” indicates normalized update 202 is derived from an incremental update represents price of an existing order in order book of exchange A has been modified but quantity remains unchanged, or both price and quantity of an existing order in order book of exchange A has been modified, or quantity of an existing order in order book of exchange A has been increased but price remains unchanged;

[0063] a type field of “Reduce” indicates normalized update 203 is derived from an incremental update represents quantity of an existing order in order book of exchange A has been reduced but price remains unchanged.

[0064] a type field of “Replace” indicates normalized update 204 is derived from an incremental update represents an existing order in order book of exchange A has been replaced by a new order;

[0065] a type field of “Delete” indicates normalized update 205 is derived from an incremental update represents an existing order has been deleted from order book of exchange A;

[0066] a type field of “Executed” indicates normalized update 206 is derived from an incremental update represents an existing order in order book of exchange A has been fully traded (quantity of the trade is equal to quantity of the existing order);

[0067] a type field of “Partial Executed” indicates normalized update 207 is derived from an incremental update represents an existing order in order book of exchange A has been partially traded (quantity of the trade is less than quantity of the existing order);

[0068] a type field of “Trade Status” indicates normalized update 208 is derived from an incremental update represents exchange A informing market participants about new status on certain classification of products traded in exchange A;

[0069] a type field of “EoP” indicates normalized update 209 representing an end of a packet transmitted in feed A by exchange A; different from exemplary normalized update 201 to normalized update 208 above, normalized update 209 with a type field of “EoP” is a synthetic update generated by normalization cell 112 based on information received from parse cell 111.

[0070] According to other embodiment of the present application, header of a normalized update can comprise other type fields either corresponding to incremental updates from the exchange or required by processing conducted by feed handing device.

[0071] According to an embodiment of the present application, header of a normalized update can comprise another field of “exchange ID” to indicate from which exchange’s incremental update this normalized update is derived from. The normalization cell 112 may be further configured to assign an exchange ID to each normalized update as an internal reference based on the exchange from which the original incremental update is received. This feature is also applicable when feed handling device processes financial market data feeds from multiple exchanges, in such case, the exchange ID assigned by normalization cell is supposed to uniquely differentiates one exchange from another within feed handling device.

[0072] According to an embodiment of the present application, header of a normalized update can comprise other two fields which are  “sequence No.” and “byte depth”; wherein “sequence No.” is obtained from information received from parse cell 111 and indicates this normalized update is derived from an incremental update belongs to a raw message with the specific “sequence No.”; and “byte depth” is generated by normalization cell 112 based on information received from parse cell 111 and indicates the position of the original incremental update among all incremental updates included in the same packet. Information in fields of “sequence No.” and “byte depth” will be pipelined to the output for the user’s trading server along with normalized updates to facilitate the user logging, debugging and evaluating latency of feed handling device accurately.

[0073] According to an embodiment of the present application, as shown in Figure 2, a format of a normalized update can comprise a body. For normalized updates having different type fields, such as normalized update 201 to normalized update 209, fields included in their respective bodies may vary from each other.

[0074] For example, for a normalized update with type field of “Add”, such as normalized update 201 shown in Figure 2, its body can comprise a field of “instrument ID”. According to an embodiment of the present application, normalization cell 112 may be configured to map field of “symbol ID” in original incremental update from exchange A into field of “instrument ID” in corresponding normalized update.

[0075] Usually, the exchange allocates a long symbol ID to each financial instrument traded in the exchange, such as a 32-bit number, a 64-bit number, or a string, since the exchange needs to identify and track big amount of financial instruments. However, market participants who use feed handling device provided by the present application (herein after referred to as “the user”) probably pay attention to comparably smaller amount of financial instruments. In order to save memory space and provide lower latency to feed handling device, normalization cell 112 is able to receive instructions from the user about which financial instruments need to be tracked, and assign a corresponding instrument ID to each financial instrument selected by the user. The instrument ID can comprise a linear index number which may be shorter than symbol ID in original incremental update.  For example, an instrument ID might be a 12-bit number if feed handling device can support the user to select up to 4,096 financial instruments. The instrument ID may cover all financial instruments traded in exchange A or a portion thereof selected by the user. This feature is also applicable when feed handling device processes financial market data feeds from multiple exchanges, in such case, instrument ID may cover all financial instruments traded in all exchanges or a portion thereof selected by the user; in addition, instrument ID may be unique across all the exchanges or instrument ID plus exchange ID may be unique across all the exchanges.

[0076] In addition, for a normalized update with type field of “Add”, such as normalized update 201 shown in Figure 2, its body can further comprise fields of “order ID”, “Qty.”, “price” and “side”, indicating normalized update 201 is derived from an incremental update represents a new order with “order ID” for buying (“side”) or selling (“side”) certain “Qty.” of an financial instrument with “instrument ID” at certain “price” has added into order book of exchange A.

[0077] For example, a normalized update with type field of “Mod”, such as normalized update 202 shown in Figure 2, its body can comprise fields of “order ID”, “Qty.”, “price” and “side”, indicating normalized update 202 is derived from an incremental update represents price of an existing order in order book of exchange A on either buy “side” or sell “side” has been modified into “price” but quantity remains unchanged, or both price and quantity of an existing order in order book of exchange A on either buy “side” or sell “side” has been modified into “price” and “Qty.”, or quantity of an existing order in order book of exchange A on either buy “side” or sell “side” has been increased to “Qty.” but price remains unchanged.

[0078] For example, for a normalized update with type field of “Reduce”, such as normalized update 203 shown in Figure 2, its body can comprise fields of “order ID”, “Qty.”, “price” and “side”, indicating normalized update 203 is derived from an incremental update represents quantity of an existing order in order book of exchange A on either buy “side” or sell “side” has decreased to “Qty.” or decreased by a “Qty.”, but price remains unchanged.

[0079] For example, for a normalized update with type field of “Replace”, such as normalized update 204 shown in Figure 2, its body can comprise fields of “old order ID”, “new order ID”, “Qty.” and “price”, indicating normalized update 204 is derived from an incremental update represents an existing order with “old order ID” in order book of exchange A has been replaced by a new order with “new order ID”, quantity and price of the existing order has also been replaced by “Qty.” and “price” of the new order.

[0080] For example, for a normalized update with type field of “Delete”, such as normalized update 205 shown in Figure 2, its body can comprise field of “order ID”, indicating normalized update 205 is derived from an incremental update represents an existing order with “order ID” has been deleted from order book of exchange A.

[0081] For example, for a normalized update with type field of “Executed”, such as normalized update 206 shown in Figure 2, its body can comprise field of “order ID”, indicating normalized update 206 is derived from an incremental update represents an existing order with “order ID” has been fully traded in exchange A.

[0082] For example, for a normalized update with type field of “Partial Executed”, such as normalized update 207 shown in Figure 2, its body can comprise fields of “order ID” and “Qty.”, indicating normalized update 207 is derived from an incremental update represents an existing order with “order ID” has been partially traded with a “Qty.” in exchange A.

[0083] For example, for a normalized update with type field of “Trade Status”, such as normalized update 208 shown in Figure 2, its body can comprise fields of “product class” and “new status”, indicating normalized update 208 is derived from an incremental update represents exchange A informing market participants about “new status” on certain classification of products (“product class”) traded in exchange A.

[0084] For example, for a normalized update with type field of “EoP”, such as normalized update 209 shown in Figure 2, its body can comprise no field, indicating that normalized update 209 corresponds to an end of a packet transmitted in feed A by exchange A.

[0085] According to an embodiment of the present application, although normalized updates with different type fields may comprise different fields in their bodies, they overlaid on the same memory space or have a same number of bits.

[0086] According to an embodiment of the present application, in case the user has selected a portion of financial instruments traded in exchange A to be tracked by feed handling device 100, normalization cell 112 may be configured to only derive the incremental updates with a symbol ID matching the financial instrument selected by the user into normalized updates and discard those incremental updates with a symbol ID without matching the user’s selection. However, some incremental updates do not have a field of symbol ID, then normalization cell 112 may be configured to derive all of them into normalized updates and transmit to the downstream block, leaving downstream block to exclude the normalized updates without matching the user’s selection.

[0087] According to an embodiment of the present application, normalization block 110 may process incremental updates from exchange A in sequence, i.e., normalized updates transmitted from normalization block 110 to downstream block will be in the same sequence as they are in the original incremental updates received from exchange A. This ensures the output of the normalization block 110 is always predictable and repeatable. This feature is applicable to all blocks in feed handling device 100 and ensures the output of feed handling device 100 is predictable and repeatable.

[0088] According to other embodiments of the present application, format of a normalized update may comprise other fields to support requirements in practice. According to an embodiment of the present application, feed handling device 100 shown in Figure 1 can comprise an order book management (OBM) block 120, coupled to normalization cell 112 in normalization block 110, may be configured to receive stream of normalized updates from normalization cell 112 and implement the following tasks.

[0089] 1. Processing each order related normalized update (such as normalized updates with type field “Add”, “Mod”, “Reduce”, “Replace”, “Delete”, “Executed” or “Partial Executed”), track corresponding entry in local order book (LOB) and update LOB based on each order related update; wherein, if order related normalized update being processed relates to multiple more than one price levels, OBM block 120 may be further configured to generate multiple synthetic updates, each of which relates to one price level respectively. Please be noted that, LOB is maintained by OBM block of feed handling device provided by the present application that is different from the order book of the exchange.

[0090] 2. In case the user has selected a portion of financial instruments traded in exchange A to be tracked by feed handling device 100, for those normalized updates without information in field of “instrument ID”, further excluding normalized updates not related to the financial instruments selected by the user based on information in LOB.

[0091] 3. Transmitting normalized updates without any empty fields in header and body directly to the downstream block in feed handling device 100.

[0092] 4. For normalized updates having empty field(s) in header or body, retrieving corresponding information from LOB, and populating the empty field(s) in the normalized updates with the retrieved information before transmitting the updates to the downstream block in feed handling device 100.

[0093] 5. Since different types of normalized updates may take different time to be processed, e.g., an order related update may take longer time to be processed than a non-order related update (such as updates with type field “Trade Status” or “EoP”), OBM block 120 may be configured to coordinate all the normalized updates, and make sure when being transmitted to the downstream block, they are in the same sequence as they are received.

[0094] According to an embodiment of the present application, OBM block 120 maintains single LOB to track all financial instruments traded in exchange A, or a portion thereof selected by the user. Entries in LOB corresponds to active orders for all financial instruments traded in exchange A, or a portion thereof selected by the user. This feature is also applicable when feed handling device processes financial market data feeds from multiple exchanges, in such case, OBM block maintains single LOB to track all financial instruments in multiple exchanges, or a portion thereof selected by the user. Entries in LOB corresponds to active orders for all financial instruments traded in multiple exchanges, or a portion thereof selected by the user.

[0095] According to different embodiments of the present application, LOB can be stored in memory space inside feed handling device 100, or in a storage block 150 outside feed handling device 100.

[0096] Figure 3 is a block diagram illustrating an OBM block according to an embodiment of the present application.

[0097] According to an embodiment of the present application, as shown in Figure 3, OBM block 120 in feed handling device 100 can comprise a classifier cell 301, coupled to normalization cell 112 in feed handling device 100, may be configured to receive stream of normalized updates from normalization cell 112. Once receiving a normalized update, classifier cell 301 may be configured to identify the type of this update based on its type field and route this update to appropriate downstream cells in OBM block 120.

[0098] According to an embodiment of the present application, as shown in Figure 3, OBM block 120 in feed handling device 100 can comprise a book updating cell 302, coupled to classifier cell 301, may be configured to receive stream of normalized updates routed by classifier cell 301.

[0099] According to an embodiment of the present application, as shown in Figure 3, OBM block 120 in feed handling device 100 can comprise a queue cell 303, coupled to classifier cell 301.

[0100] According to an embodiment of the present application, as shown in Figure 3, OBM block 120 in feed handling device 100 can comprise a joiner cell 304, coupled to both book updating cell 302 and queue cell 303.

[0101] According to an embodiment of the present application, when a normalized update from normalization cell 112 arrives, classifier cell 301 may be configured to identify the type of this update based on type field in its header. If normalized update arrives is an order related update, classifier cell 301 may be configured to route one copy of this update to book updating cell 302 and route another copy of the same update to queue cell 303. If normalized update arrives is a non-order related update, classifier cell 301 may be configured to route this update to queue cell 303.

[0102] In book updating cell 302, after an order related update being processed, action(s) corresponding to this update will be conducted to update LOB, such as adding a new entry into LOB, reducing quantity of an existing entry in LOB, or deleting an existing entry from LOB.

[0103] Not like the existing technology that setting up separate books for each financial instrument and sort entries in each book by price, OBM block 120 in feed handling device 100 maintains single LOB, which may comprise entries to track active orders for all financial instruments traded in exchange A or a portion thereof selected by the user, without sorting the entries in any sequence. This feature is also applicable when feed handling device processes financial market data feeds from multiple exchanges, in such case, OBM block maintains single LOB, which may comprise entries to track active orders for all financial instruments traded in all exchanges, or a portion thereof selected by the user, without sorting the entries in any sequence. This is a significant advantage of the present application compared with the existing technology. Less memory space is occupied and less operations are conducted due to not sorting the entries in any sequence, which means no need to shift the entries in case an existing entry is deleted or a new entry is added. This feature for sure brings lower latency, better performance, and smaller dimension to the feed handling device provided by the present application. Of course, in order to achieve this LOB, book updating cell 302 in OBM block 120 is designed to perform particular working flow as below.

[0104] According to an embodiment of the present application, LOB is stored in form of a hash table, entries in LOB dynamically share memory space in feed handling device 100 or in storage block 150 outside feed handling device 100.

[0105] According to an embodiment of the present application, when an order related update arrives, book updating cell 302 may be configured to extract some fields from this update to generate a key. Figure 4 is a block diagram illustrating format of keys generated by book updating cell according to an embodiment of the present application. For example, such as key 401 shown in Figure 4, in order to ensure each key is unique across all incoming order related updates, key 401 can comprise fields of “exchange ID”, “instrument ID”, “order ID”, and “side”.

[0106] In practice, since different exchanges have different specification for format of financial market data, some exchanges, such as Deutsche Boerse AG, always transmits incremental updates without any empty fields, the others, such as New York Stock Exchange (NYSE), only transmits an incremental update without any empty fields when a new order has been added into its order book, and when this order has been modified later on, the exchange will only transmits an incremental update with fields of “order ID” and the information being modified, leaving other fields such as “symbol ID” empty.

[0107] In the former case, when an order related update arrives, book updating cell 302 may be configured to generate a key for this update in accordance with a format such as key 401 shown in Figure 4. In the latter case, when an order related update arrives, book updating cell 302 may be configured to generate a key for this update in accordance with a format such as key 402 shown in Figure 4, setting field “instrument ID” to a default value, for example 0, even if this update is an “Add” update containing an “instrument ID” derived from a “symbol ID” in the original incremental update.

[0108] Actually, for feed handling device 100 shown in Figure 1, a key including four fields as shown in Figure 4 is more than enough to ensure the uniqueness of keys across all incoming order related updates from only one exchange. However, the present application also provides feed handling device processing financial market data feeds from multiple exchanges, format of keys as shown in Figure 4 is also able to ensure the uniqueness of keys across all incoming order related updates from multiple exchanges, therefore, no need to re-design format of keys for feed handling device supporting multiple exchanges within the scope of this application.

[0109] According to an embodiment of the present application, based on the key of the order related update arrives, book updating cell 302 may be further configured to calculate a target signature for this update by hash function adopted by hash table of LOB. Target signature indicates the target memory address in hash table of LOB that may be updated due to this update. According to an embodiment of the present application, one memory address in hash table of LOB can comprise one or more memory cells to store one or more entries respectively.

[0110] Figure 5 is a block diagram illustrating format of an entry in LOB maintained by OBM block according to an embodiment of the present application. According to an embodiment of the present application, as shown in Figure 5, entry 501 in LOB can comprise fields of “exchange ID”, “instrument ID”, “order ID”, “side”, “price” and “Qty.”.

[0111] For an order related update arrives with type field of “Add”, book updating cell 302 may be configured to transform this update into a new entry of LOB according to format shown in Figure 5 and store this entry in an empty memory cell at target memory address in hash table of LOB indicated by its target signature.

[0112] For an order related update arrives without type field of “Add” (such as “Mod”, “Reduce”, “Replace”, “Delete”, “Executed” or “Partial Executed”), book updating cell 302 may be further configured to do the following tasks.

[0113] 1. Finding the target memory address in hash table of LOB indicated by target signature of update arrives.

[0114] 2. Generating keys for one or more entries already stored in memory cells of target memory address; rules of generating keys for entries are the same as that of generating key for order related update arrives as described previously.

[0115] 3. Comparing key of the update arrives with keys of one or more entries already stored in target memory address and finding the target entry which has the same key as the update arrives.

[0116] In case feed handling device 100 only processes market data of a portion of financial instruments traded in exchange A selected by the user and no target entry has been located, it means order related update arrives is an update without a field of “instrument ID” and not related to a financial instrument selected by the user, then book updating cell 302 may be configured to drop this update arrives.

[0117] Once the target entry has been located, book updating cell 302 may be further configured to update target entry based on different type of order related update arrives as following.

[0118] For an order related update arrives with a type field of “Reduce”, according to an embodiment of the present application, book updating cell 302 may be further configured to fetch the field of “Qty.” from “Reduce” update arrives and minus its “Qty.” from field of “Qty.” in target entry; according to another embodiment of the present application, book updating cell 302 may be further configure to fetch the field of “Qty.” from “Reduce” update arrives and take place the field of “Qty.” in target entry by “Qty.” in “Reduce” update.

[0119] For an order related update arrives with a type field of “Delete”, book updating cell 302 may be further configured to delete target entry, no need to shift or rebalance any other existing entries in case a B tree or balance tree architecture is applied.

[0120] For an order related update arrived with a type field of “Executed”, book updating cell 302 may further configured to delete target entry, no need to shift or rebalance any other existing entries in case a B-tree or balance tree architecture is applied.

[0121] For an order related update arrives with a type field of “Partial Executed”, book updating cell 302 may further configured to fetch the field of “Qty.” from “Partial Executed” update arrives and minus its “Qty.” from field of “Qty.” in target entry.

[0122] For an order related update arrives with a type field of “Mod”, the procedure to update target entry is different from other type of order related updates. As described previously, an order related update with a type field of “Mod” may indicate this “Mod” update is derived from an incremental update represents: case 1 - price of an existing order in order book of exchange A on either buy “side” or sell “side” has been modified into “price” but quantity remains unchanged, or case 2 - both price and quantity of an existing order in order book of exchange A on either buy “side” or sell “side” has been modified into “price” and “Qty.”, or  case 3 - quantity of an existing order in order book of exchange A on either buy “side” or sell “side” has been increased to “Qty.” but price remains unchanged.

[0123] According to an embodiment of the present application, for case 3, book updating cell 302 may be further configured to fetch the field of “Qty.” from “Mod” update arrives and take place the field of “Qty.” in target entry by “Qty.” in “Mod” update.

[0124] According to an embodiment of the present application, for case 1 and case 2, book updating cell 302 may be further configured to generate two synthetic updates in the same formatting scheme as normalized updates. The first synthetic update may comprise a type field of “Mod Delete”, a field of “exchange ID”, a field of “Sequence No.”, and a field of “byte depth” in its header; and may comprise a field of “order ID” in its body; wherein, except for the type field, information in other fields are the same as the corresponding fields in original “Mod” update. The second synthetic update may comprise a type field of “Mod Add”, a field of “exchange ID”, a field of “Sequence No.”, and a field of “byte depth” in its header; and may comprise a field of “order ID”, a field of “Qty.”, a field of “price”, and a field of “side” in its body; wherein, except for the type field, information in other fields are the same as the corresponding fields in original “Mod” update.

[0125] Then, book updating cell 302 may be further configured to delete the target entry due to “Mod Delete” update, transform “Mod Add” update into a new entry of LOB according to format shown in Figure 5 and store this new entry in the memory cell just been vacated by deleting the target entry.

[0126] For an order related update arrives with a type field of “Replace”, the procedure to generate a key and update target entry are different from other type of order related updates. In a “Replace” update, its body can comprise a field of “old order ID” and a field of “new order ID”, therefore, for a “Replace” update arrives, book updating cell 302 may be configured to generate two keys for this update in accordance with a format shown in Figure 4. The field of “order ID” in the first key may comprise the information in the field of “old order ID” in “Replace” update, and the field of “order ID” in the second key may comprise the information in the field of “new order ID”. Based on two keys of “Replace” update arrives, book updating cell 302 may be further configured to calculate two target signatures for this update by hash function adopted by hash table of LOB. According to an embodiment of the present application, book updating cell 302 may be further configured to generate two synthetic updates in the same formatting scheme as normalized updates. The first synthetic update may comprise a type field of “Replace Delete”, a field of “exchange ID”, a field of “sequence No.”, and a field of “byte depth” in its header; and may comprise a field of “order ID” in its body; wherein, information in fields of “exchange ID”, “sequence No.”, and “byte depth” are the same as the corresponding fields in original “Replace” update, and information in field of “order ID” is the same as the field of “old order ID” in original “Replace” update. The second synthetic update may comprise a type field of “Replace Add”, a field of “exchange ID”, a field of “sequence No.”, and a field of “byte depth” in its header; and may comprise a field of “order ID”, a field of “Qty.”, and a field of “price” in its body; wherein, “exchange ID”, “sequence No.”, “byte depth”, “Qty.” and “price” are the same as the corresponding fields in original “Replace” update, and information in field of “order ID” is the same as the field of “new order ID” in original “Replace” update.

[0127] Then, book updating cell 302 may be further configured to delete the target entry located based on the first target signature (the procedure is similar to the other type of order related updates, no need to repeat here again) due to “Replace Delete” update, transform “Reduce Add” update into a new entry of LOB according to format shown in Figure 5 and store this new entry in the memory cell located based on the second target signature.

[0128] In order to resolve hash collision, according to other embodiments, book updating cell 302 may be configured to calculate multiple target signatures for each order related update arrives by multiple hash functions, which indicating multiple target memory addresses in hash table of LOB.

[0129] In addition, according to an embodiment of the present application, queue cell 303 in OBM block 120 may be configured to receive stream of normalized updates routed by classifier cell 301.

[0130] Generally, when a normalized update arrives, if the update is an order related update, classifier cell 301 may be configured to route it to book updating cell 302 to do the processing described previously; meanwhile, no matter the update arrives is an order related update or a non-order related update, classifier cell 301 may be configured to route each normalized update arrives to queue cell 303.

[0131] According to an embodiment of the present application, queue cell 303 can comprise a First in First out (FIFO). Therefore, queue cell 303 may be basically configured to pass the stream of normalized updates from classifier cell 301 to joiner cell 304 in a mode of first in and first out, which ensure normalized updates keep the same sequence when leaving queue cell 303 as coming in. Additional to such first in and first out mode, based on the type of each normalized update arrives and whether the normalized update arrives having any empty fields or not, classifier cell 301 may be further configured to control whether each normalized update need to wait certain actions taken by book updating cell 302 when it is this update’s turn to leave queue cell 303.

[0132] According to an embodiment of the present application, if a normalized update is an order related update without any empty fields, which means the original incremental update from the exchange doesn’t have any empty fields (such as an incremental update from the exchange indicating a new order has been added into its order book, or all incremental updates transmitted by Deutsche Boerse AG), queue cell 303 may be configured to send this update to joiner cell 304 when it is this update’s turn without receiving any confirmation to indicate LOB has been properly updated based on this order related update by book updating block 302. Then joiner cell 304 may be configured to follow the same sequence and send this update to downstream block in feed handling device 100.

[0133] According to another embodiment of the present application, if a normalized update is an order related update having empty field(s) (which means the original incremental update from the exchange does have one or more empty fields, e.g., when an order is deleted, NASDAQ ITCH protocol only transmits an incremental update with order ID, leaving other fields empty), as described above, it is understood that, there is another copy of this order related update also being routed to book updating cell 302 for processing to update LOB, meanwhile classifier cell 301 may be configured to add a control bit to the copy of this update being routed to queue cell 303, the copy queuing in queue cell 303 will not leave queue cell 303 when it is it’s turn but wait until the processing of the corresponding copy in book updating cell 302 is completed. On the other side, upon the processing is completed, book updating cell 302 may be configured to use order ID to retrieve the information missing in empty field(s) of this update from corresponding entry in LOB that is just updated, and the information retrieved by book updating cell 302 and the copy of this update temporarily waiting in queue cell 303 will be sent to joiner cell 304 at the same time. Finally, joiner cell 304 may be configured to populate the normalized update received from queue cell 303 by retrieved information received from book updating 302, i.e. insert the retrieved information received from book updating cell 302 into the empty field(s) in normalized update received from queue cell 303. Then joiner cell 304 may be configured to follow the same sequence and send this populated update to downstream block in feed handling device 100.

[0134] For an order related updates with a type field of “Mod” or “Replace”, instead of the original update, synthetic updates generated by book updating cell 302 for “Mod” or “Replace” update will be transmitted to joiner cell 304 and then pipelined to downstream block in feed handling device 100. This feature makes downstream block do not need to generate synthetic updates for “Mod” or “Replace” update again, and conduct the processing directly based on synthetic updates, which will simplify the processing in downstream block in feed handling device 100. In case the user insists to track all original updates from the exchange, according to different embodiments of the present application, as required by the user, the original “Mod” or “Replace” update will be transmitted to joiner cell 304 and then pipelined to downstream block in feed handling device 100 as well.

[0135] According to an embodiment of the present application, if a normalized update is a non-order related update, queue cell 303 may be configured to send this update to joiner cell 304 when it is this update’s turn. Then joiner cell 304 may be configured to follow the same sequence and send this update to downstream block in feed handling device 100.

[0136] In summary, working flow of OBM block 120 described above has many advantages compared with the existing technology, on the premise of not affecting the updating of LOB by each order related update, OBM block 120 provides a much lower latency to feed handling device 100 due to avoiding unnecessary waiting for part of normalized updates, meanwhile not disrupting the original sequence of the normalized updates when they are received from normalization cell 112, both are important to feed handling device for financial instruments market data.

[0137] Figure 6 is a flow chart illustrating the working flow of OBM block maintaining LOB and remaining sequence of received normalized update according to an embodiment of the present application. Flow chart in Figure 6 summarizes the working flow (which can be considered as a method) about how OBM block update LOB based on each order related update received from normalization cell and how OBM block remains the original sequence of normalized updates as they are received. As shown in Figure 6, the summarized working flow of OBM block may comprise the following steps.

[0138] 6000: A normalized update arrives at classifier cell in OBM block;

[0139] 6100: identifying whether this update arrives is an order related update or non-order related;

[0140] 6200: for order related update (identified by 6100), send a copy to book updating cell in OBM block;

[0141] 6300: identifying the type of this update;

[0142] 6310: for update with a type field of “Add” (identified by 6300), generate a key for the update;

[0143] 6311: calculating a target signature based on the key generated in 6310;

[0144] 6312: using target signature to locate a target memory address in hash table of LOB;

[0145] 6313: transforming this update into an entry of LOB and store it into any empty memory cell in target memory address.

[0146] 6320: For update without a type field of “Add” (identified by 6300), generate a key for the update;

[0147] 6321: calculating a target signature based on the key;

[0148] 6322: using target signature to locate a target memory address in hash table of LOB;

[0149] 6323: generating a key for each entry already stored in memory cell of target memory address;

[0150] 6324: comparing key of the update with keys of entries already stored in target memory address and find a target entry;

[0151] 6325: updating target entry by information in the update;

[0152] 6326: identifying whether this update have any empty fields;

[0153] 6327: if yes (identified by 6326), retrieving information missing in the empty fields from target entry just updated;

[0154] 6600: send (information retrieved in 6327) to joiner cell of OBM block.

[0155] 6400: For order related update (identified by 6100), send another copy to queue cell in OBM block;

[0156] 6410: identifying whether this update has any empty fields;

[0157] 6420: if yes (identified by 6410), this update has to wait in queue cell until processing of the other copy of this update has completed in book updating cell;

[0158] 6600: (upon the processing of the other copy of this update has completed in book updating cell), sending (this order related update) to joiner cell.

[0159] 6600: If no (identified by 6410), sending (this order related update) to joiner cell at its turn.

[0160] 6500:  For non-order related update (identified by 6100), sending this update to queue cell;

[0161] 6600: sending (this non-order related update) to joiner cell.

[0162] 6610: For each normalized update (received by 6600), identifying whether this update has any empty fields;

[0163] 6620: if yes (identified by 6610), populating the empty fields with retrieved information;

[0164] 6700: sending (populated update) to downstream block.

[0165] 6700: If no (identified by 6610), sending (this update without empty fields) to downstream block.

[0166] According to an embodiment of the present application, feed handling device 100 shown in Figure 1 can comprise a book building management (BBM) block 130, coupled to joiner cell 304 in OBM block 120.

[0167] According to an embodiment of the present application, feed handling device 100 shown in Figure 1 can comprise an output block 140, coupled to BBM block 130, may be configured to receive the output from BBM block 130 and transform format of the output into that can be supported by trading strategies logic on the same chip as feed handling device 100 via internal bus, or by CPU / GPU of the user’s trading server via network connector, for example a PCIe connector, Ethernet, Infiniband or proprietary network interface.

[0168] According to an embodiment of the present application, BBM block 130 may be configured to implement following tasks.

[0169] 1. Receiving stream of normalized updates or (including updates populated by OBM block 120 and synthetic updates generated by OBM block 120) from joiner cell 304 in OBM block 120, and pipeline each of them to output block 140 in the same sequence as they are received.

[0170] 2. Building up a level book that aggregates normalized updates (including updates populated by OBM block 120 and synthetic updates generated by OBM block 120) received from joiner cell 304 in OBM block 120 into various price levels, and update level book based on each of the updates.

[0171] 3. Tracking top N price level for all the financial instruments traded in exchange A or a portion thereof selected by the user, wherein N is an integer set by the user for each financial instrument.

[0172] 4. Generating data for fill consolidation in case the user select such service, or generating trade summary data in case the user select such service.

[0173] According to other embodiments, besides the task mentioned above, BBM block can be designed to implement other tasks based on the user’s requirement.

[0174] Please be noted that, since OBM block 120 has populated some of the order related updates and generated synthetic updates for some of the order related updates in the same formatting scheme as normalized updates, whenever mentioning order related updates, non-order related updates or normalized updates received from OBM block 120 and processed by BBM block 130 as a general concept in the following description, the updates populated and transmitted by OBM block 120 and synthetic updates generated and transmitted by OBM block 120 are always included thereof, which will not be specified every time for the sake of simplicity.

[0175] In addition, one of the main tasks conducted by BBM block 130 is to build up a level book that aggregates normalized updates received from OBM block 120 into various price levels, and update level book based on each of the updates. Among all type of normalized updates, some of them may cause updating to more than one price levels in level book, such as updates with a type field of “Mod” (the cases that price been changed) and “Replace”. Anyway, OBM block 120 has generated synthetic updates for these kind of updates and transmit them to BBM block 130. Therefore, BBM block 130 only need to process updates that may only cause updating to one price level in level book, for example, normalized updates with a type field of “Add”, “Reduce”, “Delete”, “Mod”(the case that price remain unchanged), “Executed” and “Partial Executed”, and synthetic updates with a type field “Mod Delete”, “Mod Add”, “Replace Delete” and “Replace Add”. This feature for sure will bring simpler processing to BBM block 130 and even lower latency to feed handling device 100.

[0176] Figure 7 is a block diagram illustrating a BBM block in a feed handling device according to an embodiment of the present application.

[0177] According to an embodiment of the present application, BBM block 130 can comprise a queue cell 701, coupled to joiner cell 304 in OBM block 120, may be configured to receive stream of normalized updates from joiner cell 304.

[0178] According to an embodiment of the present application, BBM block 130 can comprise a central processing cell 702, coupled between queue cell 701 and output block 140 in feed handling device 100, may be configured to receive stream of normalized updates from queue cell 701.

[0179] According to an embodiment of the present application, queue cell 701 can comprise a FIFO. Therefore, queue cell 701 may be basically configured to pass stream of normalized updates from joiner cell 304 to central processing cell 702 in a mode of first in and first out. Then central processing cell 702 may be configured to complete processing for each updates and transmit them to output block 140 in the same sequence as they are received from queue cell 701, wherein the processing for each updates may comprise communicating with relevant functional cells shown in Figure 7, such as level book cell 703, top levels cell 704, trade summary cell 705 or fill consolidation cell 706, which will be described in details later on.

[0180] Generally, central processing cell 702 may be configured to adopt state machine based processing. According to an embodiment of the present application, central processing cell 702 may be configured to process normalized updates one at a time, guaranteeing their original arrival sequence is preserved; wherein each state of the state machine can handle specific types of updates or partial processing steps.

[0181] According to an embodiment of the present application, as shown in Figure 7, state machine of central processing cell 702 can comprise idle state, dedicated to process non-order related updates that typically require less complex handling.

[0182] According to an embodiment of the present application, as shown in Figure 7, state machine of central processing cell 702 can comprise other states, such as state 1, state 2, … or state N), may handle order related updates that typically require more complex handling.

[0183] According to an embodiment of the present application, central processing cell 702 always reads the next normalized updates from queue cell 701, depending on its type field, the update transitions through different states to complete the processing. Because updates are de-queued and processed in sequence, the overall arrival sequence of the updates is preserved.

[0184] According to an embodiment of the present application, non-order related updates might only need to pass through idle state or idle state plus state 1, making their processing path simpler and faster. Meanwhile, order related updates might traverse multiple states, e.g., idle state to state 1 to state 2 to state N, accommodating longer or more complex processing steps. Even though some order related updates take longer to process, state machine processes them one-by-one, ensuring no updates overtakes another in the sequence.

[0185] According to an embodiment of the present application, central processing cell 702 may be further configured to build up a level book and update the level book based on each order related update.

[0186] According to an embodiment of the present application, as shown in Figure 7, BBM block 140 can comprise a level book cell 703, coupled to central processing cell 702, may be configured to store the level book maintained by BBM block 140.

[0187] According to an embodiment of the present application, level book is stored in form of a hash table. Each entry of level book represents a price level aggregated by different order related updates on the same side relevant to the same financial instrument. Each entry in level book can comprise a key-value pair. Figure 8 is a block diagram illustrating format of an entry of level book maintained by BBM block according to an embodiment of the present application.

[0188] According to an embodiment of the present application, as shown in Figure 8, format of entry 801 in level book can comprise a key, which including fields of “exchange ID”, “instrument ID”, “side” and “price”, wherein field of “side”, for example, can be a one-bit value indicating if the entry representing a price level on ask side or bid side, field of “price” represents the price level aggregated by this entry.

[0189] According to an embodiment of the present application, as shown in Figure 8, format of entry 801 in level book can comprise a value, which including fields of “Qty.” and field of “amount of orders”, wherein field of “Qty.” represents the total quantity of all active orders at the price level aggregated by this entry, field of “amount of orders” indicates how many orders have been accumulated into this price level so far.

[0190] According to an embodiment of the present application, once an order related update arrives, central processing cell 702 may be configured to extract some fields from the update arrives to generate a key for this update according to format of key in entry of level book shown in Figure 8.

[0191] According to an embodiment of the present application, based on the key of order related update arrives, central processing cell 702 may be further configured to calculate a target signature for this update by hash function adopted by hash table of level book. Target signature indicates the target memory address in hash table of level book that may be updated due to this update. According to an embodiment of the present application, one memory address in hash table of level book can comprise one or more memory cells to store one or more entries respectively.

[0192] According to an embodiment of the present application, central processing cell 702 may be further configured to locate the target memory address in hash table of level book indicated by target signature of order related update arrives. Then compare key of the update arrives with keys of one or more entries already stored in target memory address to see whether there is a target entry having the same key as the update arrives.

[0193] If no target entry is found, it means “price” on buy or sell “side” of order related update arrives is a new price level which has not been aggregated by any existing entry in level book, then central processing cell 702 may be further configured to transformed the update arrives into a new entry of level book according to format shown in Figure 8, and insert this new entry into an empty memory cell at target memory address in hash table of level book stored in level book cell 703. Similar to LOB maintained by OBM block 120, level book no need to sort its entries in any sequence. This feature is also applicable when feed handling device processes financial market data feeds from multiple exchanges, in such case, BBM block maintains a level book that aggregates normalized updates received from joiner cell in OBM block into various price levels, and update level book based on each of the updates for all financial instruments traded in all exchanges, or a portion thereof selected by the user, without sorting the entries in any sequence.

[0194] If a target entry has been found, central processing cell 702 may be further configured to update target entry based on different type of order related update arrives as following.

[0195] For an update arrives with type field of “Add”, “Mod” (the case that price remain unchanged), “Mod Add” or “Replace Add”, central processing cell 702 may be further configured to add the “Qty.” in update arrives to “Qty.” in target entry, and maintain “amount of orders” in target entry accordingly.

[0196] For an update arrives with type field of “Reduce”, “Delete”, “Mod Delete”, “Replace Delete”, “Partial Executed” or “Executed”, if “Qty.” in update arrives is less than “Qty.” in target entry, central processing cell 702 may be further configured to minus “Qty.” in update arrives from “Qty.” in target entry, and maintain “amount of orders” in target entry accordingly; if  “Qty.” in update arrives equals to “Qty.” in target entry, central processing cell 702 may be further configured to delete target entry.

[0197] In order to resolve hash collision, according to other embodiments, central processing cell 702 may be configured to calculate multiple target signatures for each update arrives by multiple hash functions, which indicating multiple target memory addresses in hash table of level book.

[0198] According to an embodiment of the present application, in level book, since order related updates received from joiner cell 304 in OBM block 120 have been aggregated to price levels, there are much less entries in level book than that in LOB, so level book maintained by BBM block 130 can be stored in memory space inside feed handling device 100, that is level book cell 703 can be set in same FPGA / ASIC as feed handling device 100. According to other embodiments of the present application, level book can also be stored in the off chip memory, such as storage block 150.

[0199] According to an embodiment of the present application, BBM block 130 may be configured to convert prices into ticks. The price of a financial instrument has a minimal price change value called tick size. Tick value is price divided by tick size. If the stock is priced at $1.97 and tick size is $0.01, its tick value is 197. If level book stores tick value in field of “price” in its entries, central processing cell 702 may be configured to convert field of “price” in order related update arrived into tick value as well.

[0200] In the present application, normalized updates can be pipelined to BBM block in the same sequence as they are received from the exchange, plus LOB in the present application is a single hash table comprising entries of all the financial instruments traded in the exchange(s) or a portion thereof selected by the user, and no need to sort the entries in any sequence. Therefore, it is possible for the present application to build up a level book separate from LOB. Similar to LOB, level book in the present application is a single hash table comprising entries of all the financial instruments traded in the exchange(s) or a portion thereof selected by the user, and no need to sort the entries in any sequence. This is another significant advantage of the present application compared with the existing technology. A separate level book facilitate tracking top price levels of the financial instruments which will be described in details later on, less memory space is occupied and less operations are conducted, which brings lower latency, better performance, and smaller dimension to the feed handling device of the present application.

[0201] According to an embodiment of the present application, BBM block 130 can comprise a top levels cell 704, coupled to central processing cell 702, may be configured to track top price levels of all financial instruments traded in exchange A or a portion thereof selected by the user.

[0202] Top price levels of financial instruments traded in exchange A or a portion thereof selected by the user is one of analysis results of feed handling device 100 concerned most by the user. To implement this task, according to an embodiment of the present application, top levels cell 704 may be configured to maintain two tables to track top price levels on each side (bid / ask), that are four tables in total, and two of the four tables for bid side and the other two for ask side. Figure 9 is a block diagram illustrating exemplary tables for tracking top price levels on one side according to an embodiment of the present application.

[0203] According to an embodiment of the present application, once feed handling device 100 is powered on, the user is able to configure an integer N and an integer M for each of all financial instrument traded in exchange A or each of a portion thereof selected by the user; wherein N represents how many price levels the user requires feed handling device 100 to track for each financial instrument, M represents the capacity of price levels the user sets for each financial instrument, and M is greater than N. According to different embodiments of the present application, the user can configure different N and different M for different financial instruments.

[0204] According to an embodiment of the present application, once M and N for all financial instruments traded in exchange A or a portion thereof selected by the user are configured, top levels cell 704 may configured to build the first table and the second table on each side, for example, Table 1 shown in Figure 9 is the first table on one side, and Table 2 shown in Figure 9 is the second table on the same side.

[0205] According to an embodiment of the present application, each entry in the first table indicates memory space allocated to each instrument in the second table. For example, as shown in Figure 9, entry 901 in Table 1 is an entry for instrument K that including field of “start address” of memory space allocated to instrument K in Table 2, field of integer “N” configured by the user for instrument K, and field of “end address” of memory space allocated to instrument K in Table 2, wherein memory address in Table 2 can comprise multiple memory cells, and amount of memory cells between “start address” and “end address” in Table 2 can accommodate price levels with amount of M (configured by the user). According to another embodiment of the present application, field of “end address” can be replaced by a field of “size of memory space” that accommodating M price levels. Meanwhile, the second table will allocate a memory space from “start address” to “end address” to accommodate M price levels of a financial instrument. For example, as show in Figure 9, the user has configured M as 12, and Table 2 allocates 3 memory addresses from “start address” to “end address” to instrument K, each memory address can comprise multiple  memory cells (e.g., four as shown in Figure 9) to store multiple price levels.

[0206] According to an embodiment of the present application, top levels cell 704 sets a valid bit (e.g., a 4-bits number) in each memory cell to indicate if this memory cell is stored with a price level or empty, e.g., 1 for the cell is stored with price level, 0 for empty.

[0207] According to an embodiment of the present application, along with the updating to level book by each order related update received from joiner cell 304 in OBM block 120, central processing cell 702 may be configured to store top M price levels on each side of each financial instrument in corresponding memory space in the second table based on address information in the first table.

[0208] Once an order related update with type field of “Add”, “Mod Add” or “Replace Add” arrives and level book has been updated accordingly, central processing cell 702 may be configured to use “instrument ID” and “side” in update arrives to find corresponding memory space in the second table on that “side”, and update top M price levels stored in corresponding memory space as following.

[0209] If “price” in update arrives is closer to market quote than price level in 1stmemory cell of corresponding memory space, central processing cell 702 may be configured to delete price level in Mthmemory cell, shift price levels in 1stto (M-1)thmemory cells into 2ndto Mthmemory cells, insert “price” in update arrives into 1stmemory cell.

[0210] If “price” in update arrives is between price levels in 1stand  Mthmemory cells, but not equal to any of them, central processing cell 702 may be configured to delete price level in Mthmemory cell, shift price levels further from market quote than “price” in update arrives in corresponding memory space one memory cell behind, insert “price” in update arrives into the memory cell just been vacated.

[0211] Once an order related update with type field of “Reduce”, “Delete”, “Mod Delete”, “Replace Delete”, “Partial Executed” or “Executed” arrives and level book has been updated accordingly, central processing cell 702 may be configured to use “instrument ID” and “side” in update arrives to find corresponding memory space in the second table on that “side”, and update top M price levels stored in corresponding memory space as following.

[0212] If update arrives has caused deleting target entry from level book and price level in target entry equals to one of top M price levels stored in corresponding memory space, central processing cell 702 may be configured to delete price level equal to price level in target entry being deleted, shift all price levels after deleted price level in corresponding memory space one memory cell ahead, read level book stored in level book cell 703 to find the new Mthprice level and insert it into Mthmemory cell.

[0213] Up to this stage, it is clearer that why the user is entitled to configure not only integer N indicating the required amount of top price levels, but also another bigger integer M indicating capacity of top price levels. The price levels stored in (N+1)thto Mthmemory cell in memory space corresponding to each financial instrument can be seen as a cache to facilitate finding the new Nthprice level when one of N price levels is deleted, price level stored in (N+1)thmemory cell is shifted one memory cell ahead to be the new Nthprice level immediately. This feature for sure provides much lower latency to feed handling device 100.

[0214] If there is no more cached price level stored in (N+1)thto Mthmemory cell, central processing cell 702 may be configured to immediately read level book to search for the new Nthprice level. In case level book uses tick value in its entry field of “price”, central processing cell 702 can linearly search the new Nthprice level in level book. For example, if the newly shifted (N-1)thprice level is tick 100, central processing cell 702 may be configured to find whether tick 101, 102, or 103 … is in any entry’s field of “price” in level book until finding a valid tick in level book.

[0215] According to an embodiment of the present application, central processing cell 702 may be configured to refill top M price levels during idle time, wherein idle time could be when central processing cell 702 finishes processing a whole packet, that is a non-order related update with type field of “EoP” being received and processed by central processing cell 702. In addition, idle time also requires no normalized update is waiting to be processed by central processing cell 702.

[0216] According to another embodiment of the present application, although top levels cell 704 can support the user to configure up to top M price levels, the user is also entitled to configure another integer T besides N and M based on trading experiences; wherein T  is an integer between N and M. When refill happen during idle time, only refill up to T price levels. The remaining empty price levels between T and M could be filled when new levels are inserted when central processing cell 702 processes “Add”, “Mod Add” or “Replace Add” updates. In this case, fewer price levels are refilled during idle time and brings more flexibility.  As shown in Figure 9, Table 2 is an example that value of N, T and M are configured as 6, 1 and 12 respectively, and 1stto (N+T)thmemory cells have their associated valid bit as 1, other empty slots would have valid bit as 0.

[0217] According to an embodiment of the present application, whenever a change in top N price levels of any financial instrument has happened, central processing cell 702 may be configured to send only the changes in top N price levels to output block 140, on the premise that not affecting pipelining normalized updates to output block 140.

[0218] According to another embodiment of the present application, top levels cell 704 may be configured to maintain the first table for both bid and ask sides, so each of all financial instruments traded on exchange A or a portion thereof selected by the user has the same memory allocation for both sides, while top levels cell 704 may be configured to maintain the separate second table for each side, that is three tables in total.

[0219] According to another embodiment of the present application, in the second table maintained by top levels cell 704 for each side, quantity and amount of orders relevant to each price level may be stored as well. In this way, level book stored in level book cell 703 doesn’t need to store entries corresponding to price levels stored in the second table maintained by top levels cell 704 for each side.

[0220] In practice, when a trade happens in an exchange, a new order regarding this trade, usually called an “aggressor”, will match partial of an existing order, one existing order or multiple existing orders in the order book of the exchange. Once such “aggressor” is executed, the existing order(s) matched are traded as well, then the exchange sends incremental update(s) to indicate which existing order(s) matched have just been traded.

[0221] Furthermore, when a large trade occurs, a large “aggressor” order may cause many existing orders in order book of the exchange to be traded. These existing orders may be at the same price level or across multiple price levels. Upon incremental updates regarding these existing orders arriving at feed handling device 100, it may take a long time to process them one-by-one. For some users, promptly knowing a large trade has occurred and understanding the overall result and influence of such large trade is important, and details of individual incremental updates may be skipped. Therefore, feed handling device 100 optionally provides a trade summary service or a fill consolidation service for all financial instruments traded in exchange A or a portion thereof selected by the user.

[0222] In practice, large trades are handled differently by different exchanges. Some exchanges, e.g., CME, send an incremental update with a type of “trade summary” to indicate that a large trade has occurred before sending one or multiple incremental updates related to that large trade; meanwhile, some other exchanges, e.g., NYSE, does not send a “trade summary” update.

[0223] Exchanges also often support “iceberg” resting orders to enable market participants to hide the true quantity they intend to trade. When an “iceberg” order is executed, the traded quantity may exceed the visible quantity at the price level.

[0224] This behavior may cause a “trade summary” update from exchanges to report a quantity that differs from the quantity reflected in the current level book maintained by BBM block.

[0225] The trade summary service and fill consolidation service provided by feed handling device of the present application are designed to address the above-mentioned scenarios, respectively.

[0226] According to an embodiment of the present application, BBM block 130 can comprise a trade summary cell 705, coupled to central processing cell 702. In case the user configures trade summary service to a certain financial instrument, e.g., instrument J, central processing cell 702 may be configured to route updates with a type field of “trade summary” (so called “trade summary update” hereinafter) related to instrument J to trade summary cell 705. A trade summary update may include information regarding a total quantity of a forecasted large trade, and a range of price levels of the orders to be traded for instrument J by the large trade. Then trade summary cell 705 may be configured to use instrument ID and price levels indicated in trade summary update to retrieve quantities and amount of orders of each price level, calculate a preliminary result based on information forecasted by this trade summary update, and send the preliminary result back to central processing cell 702 then to output block 140. After sending trade summary update, exchange A will continue to send real incremental updates for the orders traded by this  large trade, normalization block 110, OBM block 120 and central processing cell 702 in BBM block 130 will process these updates as previously described. Upon the processing is completed, for example, a non-order related update with type field of “End of Event (EoE)” arrives, trade summary cell 705 may be configured to compare the preliminary result calculated before with the actual result in level book. If the preliminary result doesn’t match the actual result,  for example, due to an “iceberg” trade, trade summary cell 705 may be configured to generate and send a synthetic update  for correcting the preliminary result to central processing cell 702 and then to output block 140. When the trade summary service is enabled, central processing cell 702 and output block 140 may be configured not to transmit individual order-related updates relevant to the large trade to the trading server of the user.

[0227] The trade summary service provided by the feed handling device of the present application not only enables the user to receive the result of the trade summary as early as possible, but also provides a mechanism to correct the forecasted trade summary result, thereby improving both the effectiveness and accuracy of the feed handling device.

[0228] Again, the ability to implement such service is attributed to the fact that all normalized updates, whether order-related updates or non-order-related updates, are pipelined through a series of blocks of the feed handling device in the same sequence as they are originally received from the exchange. In existing technologies, first, the original sequence of updates may be disrupted due to building separate books for different financial instruments; second, in order to pass a trade summary update as soon as possible, the trade summary update may be routed separately from other updates. Therefore, even if existing technologies provide a similar service, it is not possible to accurately track the orders and their aggregated price levels involved in a trade summary update, which may result in errors in calculating and verifying the result.

[0229] According to an embodiment of the present application, BBM block 130 can comprise a fill consolidation cell 706, coupled to central processing cell 702. In case the user configures fill consolidation service for a certain financial instrument, e.g., instrument H, central processing cell 702 may be configured to route order related updates with a type field “Partial Executed” or “Executed” (so called “fill update” hereinafter) for instrument H to fill consolidation cell 706.  If a next incoming fill update for instrument H satisfies the user defined condition for instrument H, e.g., with the same price level, fill consolidation cell 706 may be configured to record all fill updates that satisfying the condition until the condition is no longer satisfied by a newly incoming fill update or a “EoP” update is received. Fill consolidation cell 706 may accumulate the quantities, amount of orders and other information required by the user, and send a report about fill consolidation result to central processing cell 702 and then to output block 140.

[0230] According to different embodiments of the present application, report on fill consolidation result may include different information in accordance to the different condition and requirement defined by the user.

[0231] According to an embodiment of the present application, fill consolidation cell 706 may be configured to record fill updates on instrument H at the same price level, so the report about fill consolidation result includes all fill updates at such price level, instrument ID, price, total quantity traded by these fill updates, amount of orders traded by these fill updates.

[0232] According to another embodiment of the present application, fill consolidation cell 706 may be configured to record all fill updates across all price levels on instrument H in this large trade event, so the report on fill consolidation result includes instrument ID, total quantity traded by these fill updates, amount of orders traded by these fill updates, worst price (price furthest from market quote) traded by these fill updates.

[0233] According to yet another embodiment of the present application, report on fill consolidation result sent by fill consolidation cell 706 can include an array which lists total quantity on instrument H traded by all relevant fill updates, amount of orders traded at each price level and their prices.

[0234] According to other embodiment of the present application, the user can configure not to send individual fill updates for instrument H when fill consolidation service is enabled.

[0235] Similarly, central processing cell 702 may be configured to send output relevant to trade summary service or fill consolidation service to output block 140 on the premise that not affecting pipelining normalized updates to output block 140.

[0236] Figure 10 is a block diagram illustrating a feed handling device according to an embodiment of the present application. According to an embodiment of the present application, feed handling device 1000 may be embodied on integrated circuits, such as FPGA or ASIC. According to a preferred embodiment, feed handling device 1000 may be embodied in a single FPGA chip due to lower latency, better performance, and smaller dimension of feed handling device 1000.

[0237] According to an embodiment of the present application, different from feed handling device 100 previously described, feed handling device 1000 shown in Figure 10 can comprise an arbitration block 1060.

[0238] As explained in TERMINOLOTY, the exchange transmits multiple copies of its market data for redundancy, and each copy sent over a separate network connection. Therefore, arbitration block can comprise multiple input ports to couple to multiple network connections of the exchange for receiving multiple feeds of market data from the exchange respectively. Multiple feeds from one exchange may differ in packetization due to the different types of network connection, such as optical fiber, wireless transmission.

[0239] According to an embodiment of the present application, arbitration block 1060 shown in Figure 10 can comprise two input ports, each of them is coupled to a separate network connection from exchange B.

[0240] Exchange B transmits feed B1 and feed B2 of market data through two separate network connections. Therefore, arbitration block 1060 is configured to receive feed B1 and feed B2 of market data from exchange B via its two input ports.

[0241] According to an embodiment of the present application, the network connections from the exchange can comprise optical connectors, such as QSFP-DD, QSFP or SFP, or electronic connections such as 10 GE copper connectors.

[0242] According to an embodiment of the present application, arbitration block 1060 may be configured to receive feed B1 and feed B2 of market data from exchange B and merge redundant feeds into a single and sequenced stream for downstream processing.

[0243] According to an embodiment of the present application, arbitration block 1060 may be configured to record a sequence number that is expected to arrives with the next packet, arbitration block 1060 accomplishes the merge by comparing sequence numbers of incoming packets (e.g., UDP packets) from feed B1 and feed B2, to identify and only forward the packet who arrives earlier with a sequence number that is equal to or bigger than the expected sequence number and discard the other one. This can be seen as a lossless arbitration scenario, where feeds are assumed to have no packet losses, arbitration block simply forwards the arriving instance of each packet who arrive earlier with a sequence number that is equal to or bigger than the expected sequence number, using the destination IP, port ID, sequence number of the first raw message in the packet and amount of raw messages in the packet, to guarantee in-sequence delivery.

[0244] In cases where feed B1 and feed B2 have different packetization due to different type of network connections that adopts different communication protocols, such as feed B1 grouping raw messages [1, 2, 3] and [4] in two packets while feed B2 groups raw messages [1] and [2, 3, 4] in two packets.

[0245] In order to detect and eliminate duplicate packets in the above cases, according to an embodiment of the present application, arbitration block 1060 may be configured to forward complete packet payload (it means packets cannot be sliced), for example, the packet payload containing raw messages [1, 2, 3] from feed B1 and the packet payload containing raw messages [2, 3, 4] from feed B2, leaving raw message level duplication to the downstream block of feed handling device 1000. Or, according to another embodiment of the present application, arbitration block 1060 may be configured to use channel ID, timestamp, and byte depth to detect raw message boundaries and slice packets, remove duplicate raw messages directly during arbitration.

[0246] Arbitration block in the present application may also comprise multiple input ports (e.g., more than two) to receive multiple market data feeds transmitted by an exchange, the working principle is similar to arbitration block 1060 in feed handling device 1000, no need to repeat here again.

[0247] According to other embodiments of the present application, arbitration block 1060 may adopt other arbitration logic or strategy based on the real trading scenario.

[0248] According to an embodiment of the present application, feed handling device 1000 can comprise a normalization block 1010, coupled to arbitration block 1060.

[0249] According to an embodiment of the present application, normalization block 1010 can comprise parse cell 10101, coupled to arbitration block 1060, may be configured to receive stream of packets merged by arbitration block 1060, other working principle is similar to parse cell 111 in feed handling device 100, no need to repeat here again.

[0250] According to an embodiment of the present application, addition to the working principle similar to parse cell 111, in case packets received from arbitration block 1060 are with raw message level duplication, parse cell 10101 may be further configured to discard duplicated copy of raw messages, which means only preserve one copy among duplicated raw messages with the same sequence number.

[0251] According to an embodiment of the present application, normalization block 1010 can comprise normalization cell 10102, coupled to parse cell 10101, its working principle is similar to normalization cell 112 in feed handling device 100, no need to repeat here again.

[0252] According to an embodiment of the present application, feed handling device 1000 can comprise an OBM block 1020, coupled to normalization cell 10102, its structure and working principle are similar to OBM block 120 in feed handling device 100, no need to repeat here again. OBM block 1020 may be coupled to a storage block 1050 outside feed handling device 1000, according to different embodiments of the present application, LOB maintained by OBM block 1020 can be stored in memory space inside feed handling device 1000, or in storage block 1050.

[0253] According to an embodiment of the present application, feed handling device 1000 can comprise a BBM lock 1030, coupled to OBM block 1020, its structure and working principle are similar to BBM block 130 in feed handling device 100, no need to repeat here again.

[0254] According to an embodiment of the present application, feed handling device 1000 can comprise an output block 1040, coupled to BBM block 1030, its working principle is similar to output block 140 in feed handling device 100, no need to repeat here again.

[0255] In practice, market participants may need to receive financial market data from multiple exchanges, present application can provide a feed handling device able to process financial market data received from multiple exchanges. Figure 11 is a block diagram illustrating a feed handling device according to an embodiment of the present application. According to an embodiment of the present application, feed handling device 1100 may be embodied on integrated circuit, such as FPGA or ASIC. According to a preferred embodiment, feed handling device 1100 may be embodied in a single FPGA chip due to lower latency, better performance, and smaller dimension of feed handling device 1100.

[0256] According to an embodiment of the present application, feed handling device provided by the present application can comprise multiple arbitration blocks to receive financial market date feeds from multiple exchanges respectively. For example, as shown in Figure 11, feed handling device 1100 can comprise arbitration block 1161 and arbitration block 1162; wherein arbitration block 1161 can comprise two input ports, each of them is coupled to a separate network connection from exchange C, and arbitration block 1162 can comprise two input ports, each of them is coupled to a separate network connection from exchange D.

[0257] Exchange C transmits feed C1 and feed C2 of market data through two separate network connections. Therefore, arbitration block 1161 may be configured to receive feed C1 and feed C2 of market data from exchange C via its two input ports. Exchange D transmits feed D1 and feed D2 of market data through two separate network connections. Therefore, arbitration block 1162 may be configured to receive feed D1 and feed D2 of market data from exchange D via its two input ports.

[0258] According to an embodiment of the present application, the network connections from the exchanges can comprise optical connectors, such as QSFP-DD, QSFP or SFP, or electronic connections such as 10 GE copper connectors.

[0259] According to an embodiment of the present application, working principle of arbitration block 1161 for exchange C and arbitration block 1162 for exchange D are similar to arbitration block 1060 in feed handling device 1000, no need to repeat here again.

[0260] According to an embodiment of the present application, feed handling device provided by the present application can comprise multiple normalization blocks to process stream of packets merged by multiple arbitration blocks for multiple exchanges respectively. For example, as shown in Figure 11, feed handling device 1100 can comprise normalization block 1111 and normalization block 1112.

[0261] According to an embodiment of the present application, each of the multiple normalization blocks can comprise a parse cell coupled to arbitration block for the same exchange. For example, as shown in Figure 11, normalization block 1111 can comprise parse cell 11111, coupled to arbitration block 1161, may be configured to receive stream of packets merged by arbitration block 1161 for exchange C, and normalization block 1112 can comprise a parse cell 11121, coupled to arbitration block 1162, may be configured to receive stream of packets merged by arbitration block 1161 for exchange D. Working principle of parse cell 11111 and parse cell 11121 are similar to parse cell 10101 in feed handling device 1000, no need to repeat here again.

[0262] According to an embodiment of the present application, each of the multiple normalization blocks can comprise a normalization cell coupled to parse cell in the same normalization block. For example, as shown in Figure 11, normalization block 1111 can comprise normalization cell 11112, coupled to parse cell 11111, and normalization block 1112 can comprise normalization cell 11122, coupled to parse cell 11121. Working principle of normalization cell 11112 and normalization cell 11122 are similar to normalization cell 112 in feed handling device 100, no need to repeat here again.

[0263] According to an embodiment of the present application, feed handling device provided by the present application that supports multiple exchanges can comprise a MUX block, coupled to all multiple normalization blocks for multiple exchanges, and may be configured to merge normalized updates from different normalization blocks into a single sequenced stream. Here, when talking about normalized updates, synthetic updates generated by multiple normalization blocks for multiple exchanges, such as “EoP” updates are included thereof, which will not specify every time for the sake of simplicity. For example, different from feed handling device 100 and feed handling device 1000, feed handling device 1100 can comprise a MUX block 1170, coupled to both normalization cell 11112 for exchange C and normalization cell 11122 for exchange D, may be configured to receive normalized updates from both normalization cells and merge them into a single sequenced stream of normalized updates for downstream processing.

[0264] Normalized updates can arrive at MUX block simultaneously from different normalization cells for different exchanges. According to an embodiment of the present application, MUX block may be configured to merge normalized updates in round-robin strategy and always finish processing a packet from one normalization cell before switching to processing normalized updates from next normalization cell. For example, when MUX block 1170 is idle, if normalized updates from exchange C and exchange D arrive at the same time, MUX block 1170 may be configured to process a normalized update from exchange C, then wait and continue to process normalized update in the same packet until a normalized message with type field of “EoP” being processed, which means finishing a packet before switching. Then, MUX block 1170 may be configured to process normalized updates from exchange D even if there are more normalized updates from exchange C waiting.

[0265] According to another embodiment of the present application, MUX block may be configured to merge normalized update in round-robin strategy and switch after one update being processed. For example, when MUX block 1170 is idle, if normalized updates from exchange C and exchange D arrive at the same time, MUX block 1170 may be configured to process a normalized update from exchange C, then switch to process a normalized update from exchange D, then switch back exchange C, and so on.

[0266] When feed handling device provided by the present application processes market data feeds from multiple exchanges, such as exchanges more than two, feed handling device may comprise a MUX block that coupled to all normalization block for all exchanges, the working principle of MUX block 1170 in feed handling device 1100 is also applicable.

[0267] According to an embodiment of the present application, feed handling device 1100 can comprise an OBM block 1120, coupled to MUX block 1170, may be configured to receive and process normalized updates from MUX block 1170, its structure and working principle are similar to OBM block 120 in feed handling device 100, no need to repeat here again. When feed handling device provided by the present application processes market data feeds from multiple exchanges, such as exchanges more than two, structure and working principle of OBM block 120 in feed handling device 100 is also applicable.

[0268] According to an embodiment of the present application, feed handling device 1100 can comprise a BBM block 1130, coupled to OBM block 1120, its structure and main working principle are similar to BBM block 130 in feed handling device 100, no need to repeat here again. When feed handling device provided by the present application processes market data feeds from multiple exchanges, such as exchanges more than two, structure and working principle of BBM block 130 in feed handling device 100 is also applicable.

[0269] According to an embodiment of the present application, feed handling device 1100 can comprise an output block 1140, coupled to BBM block 1130, its working principle is similar to output block 140 in feed handling device 100, no need to repeat here again. When feed handling device provided by the present application processes market data feeds from multiple exchanges, such as exchanges more than two, working principle of output block 140 in feed handling device 100 is also applicable.

[0270] Present application can provide a feed handling method performed by feed handling device provided by the present application that embodied on integrated circuit such as FPGA or ASIC. According to an embodiment of the present application, the feed handling method can comprise the following steps.

[0271] Receiving financial market data feeds from one or more exchanges.

[0272] In case the exchange transmits its financial market data with multiple feeds for redundancy, according to an embodiment of the present application, the feed handling method may further comprise filtering the packets transmitted with redundancy.

[0273] Parsing each packet in all feeds into one or more raw messages, then into one or more incremental updates, then into fields.

[0274] Organizing parsed fields and relevant information into normalized updates in the same sequence as the original incremental updates; and generating synthetic updates such as “EoP” update to indicate the end of a packet.

[0275] In case feed handling device supports to receive financial market data feeds from multiple exchanges, according to an embodiment of the present application, feed handling method may further comprise merging normalized updates from the multiple exchanges into one stream of the normalized updates.

[0276] Maintaining a single LOB for all financial instruments traded in one or more exchanges supported by feed handling device or a portion thereof selected by the user without sorting entries in LOB, and pipelining the normalized updates to downstream in the same sequence as they are received.

[0277] Maintaining a single level book for all financial instruments traded in the one or more exchanges supported by feed handling device or a portion thereof selected by the user without sorting entries in the level book, and tracking top N price levels on each side for each of the financial instruments.

[0278] Transforming format of feed handling output into that can be supported by CPU / GPU of the user’s trading server.

[0279] Wherein “maintaining a single LOB for all financial instruments traded in one or more exchanges supported by feed handling device or a portion thereof selected by the user without sorting entries in LOB” may include processing each order related updates (including generating synthetic updates for some type thereof when necessary) to  update corresponding entries in LOB.

[0280] Wherein “pipelining the normalized updates to downstream in the same sequence as they are received” may include retrieving information from LOB and inserting into any empty field(s) of the normalized updates, making them into populated normalized updates.

[0281] Wherein “maintaining a single level book for all financial instruments traded in one or more exchanges supported by feed handling device or a portion thereof selected by the user without sorting entries in the level book” may include processing each order related updates (including synthetic updates for some types thereof) to update corresponding entries in level book.

[0282] Wherein “tracking top N price levels on each side for each of the financial instruments” may include updating top N price levels whenever the level book being updated.

[0283] According to an embodiment of the present application, the feed handling method can further comprise: generating data for trade summary service if required by the user; or generating data for fill consolidation service if required by the user.

[0284] Wherein, the feed handling output can comprise: each of normalized updates; changes to the top N price level on each side for any financial instrument; data for trade summary service or fill consolidation service if required by the user.

[0285] According to other embodiments of the present application, the feed handling output may comprise other updates, information or data as different requirements in practice.

[0286] Present application can provide a feed handling system embodied on integrated circuit that comprises any of feed handling devices described above. Figure 12 is a block diagram illustrating a feed handling system according to an embodiment of the present application.

[0287] According to an embodiment of the present application, feed handling system 1201 shown in Figure 12 may be embodied as a PCIe card form factor, which thanks to features and advantages of feed handling device described above that brings a much smaller dimension compared with the existing technology (usually a separate box) and can be easily plug into the user’s trading server.

[0288] According to an embodiment of the present application, feed handling system 1201 shown in Figure 12 can have at least one network connection. Each of the at least one network connection may be configured to receive financial market data feed from one exchange. For example, feed handling system 1201 can comprise network connection 1254 and network connection 1255 to receive financial market data feeds from two exchanges respectively.

[0289] According to an embodiment of the present application, the network connections can use either optical connectors, such as QSFP-DD, QSFP or SFP, or electronic connections such as 10 GE copper connectors.

[0290] According to an embodiment of the present application, feed handling system 1201 shown in Figure 12 can comprise a feed handling device 1200. Feed handling device 1200 could be any one of feed handling devices previously described. Feed handling device 1200 may be embodied on integrated circuit such as FPGA or ASIC. According to a preferred embodiment, feed handling device 1200 may be embodied in a single FPGA chip due to lower latency, better performance, and smaller dimension of feed handling device 1200.

[0291] According to an embodiment of the present application, feed handling system 1201 shown in Figure 12 can comprise a connector 1256, such as a PCIe connector, via which coupled to user’s trading server and forward output of feed handling device 1200 to CPU / GPU of the user’s trading server.

[0292] According to an embodiment of the present application, feed handling system 1201 shown in Figure 12 can comprise a power block 1251, may be configured to provide the power supply to feed handling system 1201.

[0293] According to an embodiment of the present application, feed handling system 1201 shown in Figure 12 can comprise a clock block 1252, may be configured to provide the clock signal to feed handling system 1201.

[0294] According to an embodiment of the present application, feed handling system 1201 shown in Figure 12 can comprise a board management controller (BMC) block 1253, may be configured to handle miscellaneous board management functions, such as controlling the power-up sequence and continuously monitoring temperatures, voltages, and other sensor data to ensure feed handling system 1201 operates within safe parameters.

[0295] According to an embodiment of the present application, feed handling system 1201 shown in Figure 12 can comprise a storage block 1250, coupled to feed handling device 1200, may be configured to store LOB and level book built up by feed handling device 1200 if necessary.

[0296] According to an embodiment of the present application, storage block 1250 can comprise high-speed random access memory, such as DRAM, SRAM, DDR RAM or other random access solid state memory devices, e.g. DDR 4 or DDR 5. The high density of high-speed random access memory is another reason allowing feed handling system 1201 to be integrated as a PCIe form factor.

[0297] According to a preferred embodiment of the present application, storage block 1250 can comprise a Reduced-Latency DRAM (RLDRAM), such as RLDRAM 3, the latest version of RLDRAM.

[0298] According to another embodiment of the present application, it is also possible that trading strategies or other logic co-exist with feed handling system 1201 in the same chip, so the outputs made by feed handling device is forwarded to the trading strategies or other logic via internal bus in the chip.

[0299] According to yet another embodiment of the present application, it is also possible feed handling system 1201 be deployed as a standalone system, forwarding outputs made by feed handling device 1200 over network connections to multiple trading servers.

[0300] Full hardware-based feed handling device and feed handling system provided by the present application that embodied on integrated circuit have been described in details above. Another key challenge in implementing a full hardware-based feed handling device is the initialization of feed handling device, which including initialization of LOB, level book and the second table on each side for tracking top N price levels. In a HFT system, maintaining an accurate and up-to-date LOB and level book requires handling financial market data of both snapshots and real-time packets efficiently. The challenge is how to seamlessly initialize feed handling device while ensuring that real-time packets remain synchronized during the transition from snapshot-based initialization to continuous LOB and level book updating in hardware. In order to implement this seamless transition, feed handling device may need to complete the following tasks.

[0301] 1. Feed handling device must temporarily store real-time packets in a buffer when a snapshot is being processed.

[0302] 2. Feed handling device fully processes a snapshot.

[0303] 3. After the processing of a snapshot is completed, feed handling device starts to process the buffered packets, discarding those with a sequence number lower than or equal to the snapshot’s sequence number; only packet with a sequence number higher than the snapshot’s sequence number are applied.

[0304] A straightforward approach is to implement all the above tasks by a full hard-ware based feed handling device. However, this straightforward approach may encounter following limitations.

[0305] 1. Feed handling device would need significant memory resources in hardware such as FPGA / ASIC to buffer real-time packets while the snapshot being processed.

[0306] 2. Additional complex logic block has to be embodied in the same hardware such as FPGA / ASIC to handle the snapshot processing, and ensure the seamless transition.

[0307] Given the above limitations, an alternative approach is to initialize feed handling device by software first, then transit to hardware-based real-time processing. This alternative approach also introduces following limitations as well.

[0308] 1. Since a hard-ware based (e.g., FPGA / ASIC-based) feed handling device is inherently faster than software, feed handling device processes incoming real-time packets faster than software can construct the initial state of feed handling device, which creating a timing mismatch.

[0309] 2. Synchronization is another problem, by the time software completes initialization, hard-ware based feed handling device has already received newer real-time packets, making it difficult to achieve a seamless transition.

[0310] The ideal solution must ensure the financial market date remaining in sequence during the transition, and the transition must be lossless, seamless, and with minimal latency overhead.

[0311] Overall considering the above-mentioned tasks and limitations, the present application proposes a feed handling device that enables efficient initialization and transition from software-based initialization to full hardware-based (e.g., FPGA / ASIC-based) real-time processing without disrupting the sequence of financial market data feed from the exchange(s).

[0312] Figure 13 is a block diagram illustrating a feed handling device with initialization according to an embodiment of the present application. According to an embodiment of the present application, feed handling device 1300 may be embodied on integrated circuit such as FPGA or ASIC. According to a preferred embodiment, feed handling device 1300 may be embodied in a single FPGA chip due to lower latency, better performance, and smaller dimension of the feed handling device 1300.

[0313] According to an embodiment of the present application, feed handling device shown in Figure 13 can comprise multiple delay cells, each of them is coupled to a separate network connection from the exchange. For example, feed handling device 1300 can comprise delay cell 13801 and delay cell 13802, each of them is coupled to a separate network connection from exchange E.

[0314] Exchange E transmits feed E1 and feed E2 of market data through two separate network connections. Therefore, delay cell 13801 may be configured to receive feed E1 of market data from exchange E, and delay cell 13802 may be configured to receive feed E2 of market data from exchange E.

[0315] According to an embodiment of the present application, each delay cell can comprise a FIFO. For example, delay cell 13801 can comprise a FIFO, and delay cell 13802 can comprise another FIFO.

[0316] According to an embodiment of the present application, the network connections from the exchange can comprise optical connectors, such as QSFP-DD, QSFP or SFP, or electronic connections such as 10 GE copper connectors.

[0317] According to an embodiment of the present application, feed handling device 1300 shown in Figure 13 can comprise an arbitration block 1360, including two input ports, coupled to delay cell 13801 and delay cell 13802 respectively, may be configured to receive feed E1 of market data via delay cell 13801 and receive feed E2 of market data via delay cell 13802. Working principle of arbitration block 1360 is similar to arbitration block 1060 in feed handling device 1000, no need to repeat here again.

[0318] According to an embodiment of the present application, feed handling device 1300 can comprise a normalization block 1310, coupled to arbitration block 1360.

[0319] According to an embodiment of the present application, normalization block 1310 can comprise parse cell 13101, coupled to arbitration block 1360, its working principle is similar to parse cell 10101 in feed handling device 1000, no need to repeat here again.

[0320] According to an embodiment of the present application, normalization block 1310 can comprise normalization cell 13102, coupled to parse cell 13101, its working principle is similar to normalization cell 112 in feed handling device 100, no need to repeat here again.

[0321] According to an embodiment of the present application, feed handling device 1300 can comprise OBM block 1320, coupled to normalization cell 13102, its structure and working principle are similar to OBM block 120 in feed handling device 100, no need to repeat here again.

[0322] According to an embodiment of the present application, feed handling device 1300 can comprise BBM block 1330, coupled to OBM block 1320, its structure and working principle are similar to BBM block 130 in feed handling device 100, no need to repeat here again.

[0323] According to an embodiment of the present application, feed handling device 1300 can comprise output block 1340, coupled to BBM block 1330, its working principle is similar to output block 140 in feed handling device 100, no need to repeat here again.

[0324] According to an embodiment of the present application, feed handling device 1300 shown in Figure 13 can comprise a connection, such as PCIe connector, to couple to a computer-readable non-transitory storage medium embodying software 1390 that can be installed in and performed by an apparatus outside feed handling device 1300 (e.g., the user’s trading server) for processing snapshot from exchange E into incremental updates, transforming these incremental updates into normalized updates, and send these normalized updates to OBM block 1320.

[0325] According to an embodiment of the present application, arbitration block 1360 can comprise another input ports to receive packets transmitted by software 1390.

[0326] By placing delay cells between network connections from the exchanges and input ports of arbitration block and ensuring that arbitration block only to process the packets buffered in delay cells when FIFO’s fill level exceeds a certain threshold, a temporary artificial delay is introduced to feed handling device to achieve initialization and a seamless transition from software-based processing of snapshot to full hardware-based processing of real-time packets. Taking feed handling device 1300 as an example, the complete process can comprise the following steps.

[0327] 1. Feed handling device 1300 disables delay cell 13801, delay cell 13802 and two input ports of arbitration block 1360 coupled to delay cell 13801 and delay cell 13802, so arbitration block 1360 may be configured to only process packets received from software 1390 before the transition stage.

[0328] 2. Software 1390 processes a snapshot into incremental updates and transform these updates into normalized updates.

[0329] 3. Software 1390 transmits normalized updates derived from snapshot to OBM block 1320.

[0330] 4. OBM block 1320 processes normalized updates received from software 1390 to build up initial state of LOB according to its working principle previously described.

[0331] 5. BBM block 1330 receives normalized updates derived from snapshot from OBM block 1320 and build up initial state of level book and the second table on each side for tracking top N price levels according to its working principle previously described.

[0332] 6. Meanwhile, software 1390 holds real-time packets arriving in the buffer of itself during time cost by steps 2 to 5.

[0333] 7. Once initial state of feed handling device 1300 has been completed by OBM block 1320 and BBM block 1330, software 1390 starts to replay the real-time packets held in its own buffer, and drops all real-time packets with sequence numbers smaller than the snapshot being processed and only forwards packets with sequence number bigger than the snapshot’s sequence number to arbitration block 1360, until the buffer in software 1390 is cleaned (at this stage, software 1390 is the only source of real-time packets to arbitration block 1360), then software 1390 continues to receive and forwarding newly coming real-time packets.

[0334] 8. At this moment, when the buffer in software 1390 has been  cleaned and software 1390 is waiting for newly arriving real-time packets, feed handling device 1300 enables delay cell 13801, delay cell 13802 and the input ports of arbitration block 1360 coupled to delay cell 13801 and delay cell 13802 to start the transition stage. Plus, delay cell 13801 and delay cell 13802 introduce a temporary delay by only allowing real-time packets arriving to leave for arbitration block 1360 when their FIFO’s fill level is above a certain threshold, and this threshold can be set bigger than the time difference between software processing and hardware processing to financial market data.

[0335] Since hardware processes financial market data naturally faster than software, if enabling the delay cells without introducing any temporary delay, according to working principle of arbitration block, “future” packets (i.e. packets with sequence number bigger than the expected one) will be sent to arbitration block and win packet from software in the arbitration and then be forwarded to downstream blocks. In this way, a gap in packets stream will be caused.

[0336] Therefore, a temporary delay introduced to each delay cells eliminate the possibility of sending “future” packets to arbitration block in hardware side. For example, when packets queued in delay cell 13801 and delay cell 13802 start to leave for arbitration block 1360, since the temporary delay has held the packets from delay cell 13801 and delay cell 13802, software 1390 keep sending the next packet with a sequence number expected by arbitration block 1360 earlier than delay cell 13801 and delay cell 13802, which means possibility of any gap occurred in the stream of packets sent out from arbitration block 1360 to downstream blocks has been avoided.

[0337] 9. Software 1390 stops sending packets until arbitration block 1360 finds out a series of packets from delay cell 13801 or delay cell 13802 have been dropped in arbitration, which means no gap will be caused, then disables the input port coupled to software 1390 and leaves delay cells as the only sources of real-time packets. Plus, temporary delays are removed by eliminating threshold of fill level in FIFO of delay cell 13801 and delay cell 13802. From this moment on, the packets arriving in delay cell 13801 and delay cell 13802 will be processed immediately, ensuring no extra delay.

[0338] 10. Once the temporary delay introduced by delay cell 13801 and delay cell 13802 is removed, transition stage is completed.

[0339] The initialization and transition mechanism adopted by feed handling device 1300 shown in Figure 13 ensures a smooth transition from software-based snapshot processing to hardware-based real-time packets processing without data loss.

[0340] According to another embodiment of the present application, feed handling device 1300 can comprise only one delay cell shared by all input ports of arbitration block coupled to network connections from the exchange (not shown in the figure). For example, feed handling device 1300 can comprise only delay cell 13801 shared by two input ports of arbitration block 1360 for feed E1 and feed E2 from exchange E to manage an efficient transition.

[0341] In this case, still taking feed handling device 1300 as an example, in the first place, delay cell 13801 is coupled between network connection for feed E1 and first input port of arbitration block 1360, feed handling device 1300 disables delay cell 13801 and both input ports of arbitration block 1360 for feed E1 and feed E2, such that arbitration block 1360 may be configured to process only market data received from software 1390 before the transition stage. Then feed handling device 1300 may then complete the above-mentioned steps 2-7 to start the transition stage.

[0342] During the transition stage, the logic for eliminating a possible gap in real-time packet stream is similar. The only difference is that the transition is performed on port by port basis, due to only one delay cell is shared by all input ports.

[0343] This approach of sharing a single delay cell among all input ports of arbitration block for all feeds from the exchange provides a flexible and resource-efficient way to manage feed transitions across multiple input ports, ensuring a seamless transition while maintaining financial market data integrity and low latency.

[0344] According to an embodiment of the present application, the approach for initialization and a seamless transition from software-based snapshot processing to hardware-based real-time packets processing applied to feed handling device 1300 can be applied to feed handling device that supports multiple exchanges. Figure 14 is a block diagram illustrating a feed handling device with initialization according to an embodiment of the present application. According to an embodiment of the present application, feed handling device 1400 may be embodied on integrated circuit such as FPGA or ASIC. According to a preferred embodiment, feed handling device 1400 may be embodied in a single FPGA chip due to lower latency, better performance, and smaller dimension of feed handling device 1400.

[0345] In summary, if not considering initialization and relevant transition, feed handling device 1400 shown in Figure 14 has similar working principle in processing real-time financial market data to feed handling device 1100 that supports financial market data feeds from multiple exchanges. Based on this, the approach of initialization and seamless transition from software-based snapshot processing to hardware-based real-time packets processing and relevant structure described in previous embodiment of feed handling device 1300 is applicable to feed handling device 1400, including both separate delay cells and a single shared delay cell.

[0346] However, it should be noted that feed handling device 1400 has two differences from feed handling device 1300.

[0347] First, feed handling device 1400 supports financial market data feeds from multiple exchanges, for example, as shown in Figure 14, feed handling device 1400 may be configured to process market data feeds from exchange F and exchange G, feed handling device 1400 may be configured to implement the approach for initialization and relevant transition for multiple exchanges on exchange-by-exchange basis. For example, completing initialization and relevant transition for exchange F first, then real-time market data feeds from exchange F can be processed through pipeline structure of arbitration block 1461, normalization block 1411, MUX block 1470, OBM block 1420, BBM block 1430 and output block 1440. After this, feed handling device 1400 may be configured to implement the approach for initialization and relevant transition for exchange G, once completed, real-time market data feeds from exchange G can be processed through pipeline structure of arbitration block 1462, normalization block 1412, MUX block 1470, OBM block 1420, BBM block 1430 and output block 1440. So far, initialization and relevant transition for all exchanges are completed, feed handling device 1400 may be configured to continue processing real-time financial market data feeds from both exchanges with working principle similar to that described in the embodiment of feed handling device 1100, no need to repeat here again.

[0348] Second, computer-readable non-transitory storage medium embodying software 1490 that can be installed in and performed by an apparatus outside feed handling device 1400 (e.g., the user’s trading server) processes a snapshot into incremental updates, transforms these updates into normalized updates and transmits normalized updates derived from snapshot to MUX block 1470. Then, OBM block 1420 processes normalized updates received from MUX block 1470 to build up initial state of LOB according to its working principle previously described; BBM block 1430 receives normalized updates derived from snapshot from OBM block 1420 and build up initial state of level book and the second table on each side for tracking top N price levels according to its working principle previously described.

[0349] When feed handling device provided by the present application processes market data feeds from multiple exchanges, such as exchanges more than two, working principle of feed handling device 1400 for initialization and relevant transition from software-based snapshot processing to hard-ware real-time packets processing is also applicable.

[0350] In order to avoid extra memory overhead, the present application also proposes another solution, in which arbitration block is able a seamless transit from software-based snapshot processing for initialization to hardware-based real-time packets processing without requiring additional delay cell. Figure 15 is a block diagram illustrating a feed handling device with initialization according to another embodiment of the present application. According to an embodiment of the present application, feed handling device 1500 may be embodied on integrated circuit such as FPGA or ASIC. According to a preferred embodiment, feed handling device 1500 may be embodied in a single FPGA chip due to lower latency, better performance, and smaller dimension of feed handling device.

[0351] According to an embodiment of the present application, feed handling device shown in Figure 15 can comprise arbitration block 1560 that includes multiple input ports, each of which is coupled to a separate network connection from the exchange. For example, feed handling device 1500 can comprise arbitration block 1560, including two input ports, each of which is coupled to a separate network connection from exchange H.

[0352] Exchange H transmits feed H1 and feed H2 of financial market data through two separate network connections. Therefore, arbitration block 1560 may be configured to receive feed H1 of financial market data from exchange H via the first input port, and receive feed H2 of financial market data from exchange H via the second input port. Working principle of arbitration block 1560 is similar to arbitration block 1060 in feed handling device 1000, no need to repeat here again.

[0353] According to an embodiment of the present application, the network connections from the exchange can comprise optical connectors, such as QSFP-DD, QSFP or SFP, or electronic connections such as 10 GE copper connectors.

[0354] According to an embodiment of the present application, feed handling device 1500 can comprise a normalization block 1510, coupled to arbitration block 1560.

[0355] According to an embodiment of the present application, normalization block 1510 can comprise parse cell 15101, coupled to arbitration block 1560, its working principle is similar to parse cell 10101 in feed handling device 1000, no need to repeat here again.

[0356] According to an embodiment of the present application, normalization block 1510 can comprise normalization cell 15102, coupled to parse cell 15101, its working principle is similar to normalization cell 112 in feed handling device 100, no need to repeat here again.

[0357] According to an embodiment of the present application, feed handling device 1500 can comprise OBM block 1520, coupled to normalization cell 15102, its structure and working principle are similar to OBM block 120 in feed handling device 100, no need to repeat here again.

[0358] According to an embodiment of the present application, feed handling device 1500 can comprise BBM block 1530, coupled to OBM block 1520, its structure and working principle are similar to BBM block 130 in feed handling device 100, no need to repeat here again.

[0359] According to an embodiment of the present application, feed handling device 1500 can comprise output block 1540, coupled to BBM block 1530, its working principle is similar to output block 140 in feed handling device 100, no need to repeat here again.

[0360] According to an embodiment of the present application, feed handling device 1500 shown in Figure 15 can comprise a connection, such as PCIe connector, to couple to a computer-readable non-transitory storage medium embodying software 1590 that can be installed in and performed by an apparatus outside feed handling device 1500 (e.g., the user’s trading server) for processing snapshot from exchange H into incremental updates, transforming them into normalized updates and send these normalized updates to OBM block 1520.

[0361] According to an embodiment of the present application, arbitration block 1560 can comprise the third input ports to receive packets transmitted by software 1590.

[0362] Compared with feed handling device 1300 and 1400, feed handling device 1500 shown in Figure 15 doesn’t comprise any delay cell to introduce temporary delay to eliminate gap in real-time packets, but making use of natural time gap may occur when an exchange transmits financial market data feed to reach the same purpose. Taking feed handling device 1500 as an example, the complete process can comprise the following steps.

[0363] 1. Feed handling device 1500 disables two input ports of arbitration block 1560 for feed H1 and feed H2 from exchange H, so arbitration block 1560 may be configured to only process financial market data received from software 1590 before the transition stage.

[0364] 2. Software 1590 processes a snapshot into incremental updates and transforms these updates into normalized updates.

[0365] 3. Software 1590 transmits normalized updates derived from snapshot to OBM block 1520.

[0366] 4. OBM block 1520 processes normalized updates received from software 1590 to build up initial state of LOB according to its working principle previously described.

[0367] 5. BBM block 1530 receives normalized updates derived from snapshot from OBM block 1520 and build up initial state of level book and the second table on each side for tracking top N price levels according to its working principle previously described.

[0368] 6. Meanwhile, software 1590 holds the real-time packets arriving in the buffer of itself during the time cost in steps 2 to 5.

[0369] 7. Once initial state of feed handling device 1500 has been completed by OBM block 1520 and BBM block 1530, software 1590 starts to replay the real-time packets held in its own buffer, and drops all real-time packets with sequence numbers smaller than the snapshot being processed and only forwards packets with sequence number bigger than the snapshot’s sequence number to arbitration block 1560, until the buffer in software 1590 is cleaned (at this stage, software 1590 is the only source of real-time packets to arbitration block 1560), then software 1590 continues to receive and forwarding newly coming real-time packets.

[0370] 8. At this moment, when buffer in software 1590 is cleaned and software 1590 is waiting newly arriving real-time packets, feed handling device 1500 enables the first and second input ports of arbitration block 1560 to start the transition stage. Arbitration block 1560 now may be configured to work in a temporary mode, which is comparing the sequence number of packets from different sources with the expected sequence number it recorded, and drops either the one with a sequence number from “future” (it means sequence number of such packet’s is bigger than the expected sequence number) or from “past” (it means sequence number of such packet is smaller than the expected sequence number).

[0371] In order to accomplish the temporary mode, besides recording the expected sequence number, arbitration block 1560 can further comprise three counters for each of the three input ports respectively, one “future” counter, one “past” counter and one “winning” counter, that is nine counters in total; wherein “future” counter will add 1 if the packet from this input port is dropped by arbitration block 1560 due to with a sequence number bigger than the expected one, “past” counter will add 1 if the packet from this input port is dropped by arbitration block 1560 due to with a sequence number smaller than the expected one, “winning” counter will add 1 if the packet from this input port is forwarded to downstream by arbitration block 1560 due to with a sequence number matching the expected one. Noted that, at the same time point, packet from each input port will only add 1 in one out of three counters of this input port.

[0372] Since the market data received from software 1590 is originated from the CPU of the apparatus running software 1590, which is slightly slower than market data received from hardware side, which are directly fed into arbitration block 1560 via network connection. During the transition stage, packet arriving from hardware side is likely from the “future”, with a sequence number bigger than the expected one and gets dropped by arbitration block 1560 working in temporary mode. Therefore, software 1590 keeps the main source of real-time packets until a natural time gap between consecutive arriving packets occurs in feed H1 or feed H2. Typically, packets received from software 1590 are no more than tens of microseconds slower than packets received from hardware side due to PCIe and software processing overhead. In practice, the natural time gap between consecutive packets often exceeds this time difference.

[0373] Once a natural time gap occurs, packets from hardware side will have the expected sequence numbers, and no more being dropped by arbitration block 1560 working in temporary mode, but packet from software 1590 will be dropped due to coming with a sequence number smaller than the expected one, allowing arbitration block 1560 to naturally switch to hardware-based processing of real-time market data from feed H1 and feed H2. Upon a series round that “future” counters of input ports for feed H1 and feed H2 not accumulating, and “past” counter of input port for software 1590 keep accumulating, arbitration block 1560 may be configured to disable the input port for software 1590, transition stage for both feed H1 and feed H2 is completed. From this moment on, arbitration block 1560 may be configured to work in normal mode, the packets from feed H1 and feed H2 arriving in the input ports of arbitration block 1590 are processed immediately, ensuring no extra delay.

[0374] 9. Once transition stage of feed handling device 1500 is completed, arbitration block 1560 restores the working principle similar to arbitration block 1060. Noted that, during transition stage, arbitration block may be configured to work in temporary mode not letting a packets from “future” pass through, and this will be removed upon the transition stage is completed and arbitration block restores normal mode. This prevents feed handling device 1500 from hanging in case a real sequence number gap caused by packet loss or other transmission issues of exchanges in the future.

[0375] The initialization and relevant transition mechanism adopted by feed handling device 1500 shown in Figure 15 ensures a smooth transition from software-based snapshot processing to hardware-based real-time packets processing without packet loss, low latency, no additional delay cell is required to occupy memory space of feed handling device 1500, and efficiently utilizes natural time gaps in financial market data feeds for a smooth transition without artificial delays or extra buffering.

[0376] According to an embodiment of the present application, the approach of initialization and a seamless transition from software-based snapshot processing to hardware-based real-time packets processing applied to feed handling device 1500 can be applied to feed handling device that supports multiple exchanges. Figure 16 is a block diagram illustrating a feed handling device with initialization according to an embodiment of the present application. According to an embodiment of the present application, feed handling device 1600 may be embodied on integrated circuit such as FPGA or ASIC. According to a preferred embodiment, feed handling device 1600 may be embodied in a single FPGA chip due to lower latency, better performance, and smaller dimension of feed handling device 1600.

[0377] In summary, if not considering initialization and relevant transition, feed handling device 1600 shown in Figure 16 has similar working principle in processing real-time financial market data to feed handling device 1100 that supports market data feeds from multiple exchanges. Based on this, the approach of initialization and a seamless transition from software-based snapshot processing to hardware-based real-time financial market data processing and relevant structure described in previous embodiment of feed handling device 1500 is applicable to feed handling device 1600.

[0378] However, noted that, feed handling device 1600 has two differences from feed handling device 1500.

[0379] First, feed handling device 1600 supports financial market data feeds from multiple exchanges, for example, as shown in Figure 16, feed handling device 1600 may be configured to process financial market data feeds from exchange J and exchange K, and implement the approach for initialization and relevant transition for multiple exchanges on exchange by exchange basis. for example, completing initialization and relevant transition for exchange J first, then real-time financial market data feeds from exchange J can be processed through pipeline structure of arbitration block 1661, normalization block 1611, MUX block 1670, OBM block 1620, BBM block 1630 and output block 1640. After this, feed handling device 1600 may be configured to implement the approach for initialization and relevant transition for exchange K, once completed, real-time financial market data feeds from exchange K can be processed through pipeline structure of arbitration block 1662, normalization block 1612, MUX block 1670, OBM block 1620, BBM block 1630 and output block 1640. So far, initialization and relevant transition for all exchanges are completed, feed handling device 1600 may be configured to continue processing real-time financial market data feeds from both exchanges with working principle similar to that described in the embodiment of feed handling device 1100, no need to repeat here again.

[0380] Second, a computer-readable non-transitory storage medium embodying software 1690 that can be installed in and performed by an apparatus outside feed handling device 1600 (e.g., the user’s trading server) processes a snapshot into incremental updates， transform these updates into normalized updates and transmits normalized updates derived from snapshot to MUX block 1670. Then, OBM block 1620 processes normalized updates received from MUX block 1670 to build up initial state of LOB according to its working principle previously described. BBM block 1630 receives normalized updates derived from snapshot from OBM block 1620 and build up initial state of level book and the second table on each side for tracking top N price levels according to its working principle previously described.

[0381] When feed handling device provided by the present application processes market data feeds from multiple exchanges, such as exchanges more than two, working principle of feed handling device 1600 for initialization and relevant transition from software-based snapshot processing to hard-ware real-time packets processing is also applicable.

[0382] The present application provides a method for initializing a feed handling device provided by the present application that embodied on integrated circuit such as FPGA or ASIC and how to seamless transiting from software-based snapshot processing for initialization to hardware-based real-time market data processing, comprising the following steps.

[0383] Feed handling device disables multiple delay cells and multiple input ports of an arbitration block of the feed handling device that receive feeds of financial market data from an exchange.

[0384] Computer-readable non-transitory storage medium embodying software of the feed handling device processes a snapshot from the exchange into a series of incremental updates and transform them into normalized updates.

[0385] The software transmits the normalized updates derived from the snapshot to an OBM block of the feed handling device.

[0386] OBM block processes the normalized updates received from the software to build up an initial state of LOB, populates and transmits the normalized updates to BBM block of the feed handling device.

[0387] BBM block processes the normalized updates received from OBM block and build up an initial state of a level book and the second table on each side for tracking top N price levels.

[0388] The software holds real-time packets arriving in the buffer of itself during the time cost for building up all the initial states of the feed handling device.

[0389] Feed handling device transits from software-based snapshot processing to hardware-based real-time packets processing.

[0390] Wherein “feed handling device transit from software-based snapshot processing to hardware-based real-time packets processing” can comprise the following steps.

[0391] The software starts to replay the real-time packets held in its own buffer, and drops all real-time packets with a sequence numbers smaller than that of the snapshot and only forwards packets with a sequence number bigger than that of the snapshot to the arbitration block, until the buffer in the software is cleaned.

[0392] The software continues to receive and forwards newly coming real-time packets to the arbitration block.

[0393] Feed handling device enables the multiple delay cells and the multiple input ports of the arbitration block to start the transition stage on a port by port basis.

[0394] The delay cell of the input port being enabled introduces a temporary delay by only allowing real-time packets arriving to leave for the arbitration block when fill level of a FIFO in the delay cell is above a certain threshold to eliminate any possible mismatch due different latency of hardware side and software side.

[0395] The temporary delay is removed by eliminating threshold of fill level in the FIFO of the delay cell of the input port being enabled.

[0396] Or, wherein “feed handling device transits from software-based snapshot processing to hardware-based real-time packets processing” can comprise as following.

[0397] The software starts to replay the real-time packets held in its own buffer, and drops all real-time packets with a sequence numbers smaller than that of the snapshot and only forwards packets with the sequence number bigger than that of the snapshot to the arbitration block, until the buffer in the software is cleaned.

[0398] The software continues to receive and forward newly coming real-time packets to the arbitration block.

[0399] Feed handling device enables the multiple input ports of the arbitration block to start the transition stage, and feed handling device sets the arbitration block to work in a temporary mode, which is comparing the sequence number of packets from different sources with the expected sequence number it recorded, and drops the packets with the sequence number either bigger or smaller than the expected one.

[0400] The multiple input ports and the software respectively count the amount of packets from themselves that being dropped due to with a sequence number either bigger or smaller than the expected one, or being forwarded to downstream due to with a sequence number matching the expected one until a natural time gap in any of the multiple feeds of the financial market data occurs.

[0401] Upon the amount of packets from software side that being dropped due to with a sequence number bigger than the expected one has not increased for a series of rounds, the amount of packets from software side that being dropped due to with a sequence number smaller than the expected one keep increasing for a series of rounds, the feed handling device disables the arbitration block’s input port for the software.

[0402] In case the feed handling device processes financial market data from multiple exchanges, the method for initializing a feed handling device can comprise software-based snapshot processing for initializing the feed handling device and transiting to hardware-based real-time financial market data processing on an exchange by exchange basis.

[0403] In case the feed handling device processes financial market data from multiple exchanges, the method for initializing a feed handling device can further comprise the software transmits the normalized updates derived from the snapshot from each of the multiple exchanges to an MUX block of the feed handling device.

[0404] Wherein the computer-readable non-transitory storage medium embodying software of the feed handling device for processing snapshots can be installed in and performed by an apparatus outside feed handling device (e.g., the user’s trading server).

[0405] While the above-mentioned embodiments are merely for purposes of illustration and description of the present application, and not for limiting the present invention, it will be apparent to those skilled in the art that various changes and modifications may be made without departing from the scope of the present invention, accordingly, it is intended to embrace all such equivalents that fall within the scope of the present invention.

Claims

1. A feed handling device, comprising:multiple normalization blocks, each of which comprises:a parse cell, configured to receive packets of a financial market data feed from an exchange via an network connection, slice each packet transmitted by the financial market data feed into one or more raw messages, then slice each raw message into one or more incremental updates, and slice each incremental updates into different fields; anda normalization cell, coupled to the parse cell, configured to receive sliced fields and information from the parse cell and organize the sliced fields and information into normalized updates with a normalized format; wherein when the normalization cell outputs the normalized updates, they are in the same sequence as the sequence of the incremental updates arriving at the parse cell; wherein each of the normalized updates comprise a type field;a MUX Block, coupled to all the multiple normalization blocks, configured to merge the normalized updates from the multiple normalization blocks into a single sequenced stream;an OBM block, coupled to the MUX block, configured to receive normalized updates from the MUX block, identify whether each of the normalized update is an order related update or a non-order related update by the type field, process each of the order related updates to update a LOB, retrieve information from the LOB to populate any empty fields in the order related updates, and transmit each of the normalized updates to downstream block in the same sequence as they are received; wherein, the OBM block is configured to maintain a single LOB for all financial instruments traded in the multiple exchanges or a portion thereof selected by the user, and entries in the LOB do not need to be sorted in any sequence;a BBM block, coupled to the OBM block, configured to receive normalized updates from the OBM block, process each of the order related updates to update a level book that aggregates the order related update into various price levels; track top N price levels for all the financial instruments traded in the multiple exchanges or a portion thereof selected by the user, wherein N is an integer set by the user; generate data for fill consolidation service or trade summary service as required by the user; transmit each of the normalized updates to downstream block in the same sequence as they are received, and transmit top N price levels or their changes and other data required by the user to downstream block; wherein, the BBM block is configured to maintain a single level book for all financial instruments traded in the multiple exchanges or a portion thereof selected by the user, and entries in the level book do not need to be sorted in any sequence; andan output block, coupled to the BBM block, configured to receive output from the BBM block and format the output into a format adaptive to trading server running by the user, and transmit formatted output to the trading server running by the user.2.According to the feed handling device in Claim 1, wherein the OBM block further comprises:a classifier cell, coupled to the MUX block, configured to receive the normalized updates from the MUX block, identify whether each of the normalized updates arrives is an order related update or an non-order related update by the type field, and route them to appropriate downstream cells;a book updating cell, coupled to the classifier cell, configured to receive a copy of each of the order related updates from the classifier cell, and process each of the order related updates to update the LOB;a first queue cell, coupled to the classifier cell, configured to receive another copy of each of the order related updates and each of the non-order related updates from the classifier cell, and transmit all the normalized updates to downstream cell in the same sequence as they are received; anda joiner cell, coupled to both the book updating cell and the first queue cell, receive each of the order related updates and each of the non-order related updates from the first queue cell, and transmits all these updates to the BBM block in the same sequence as they are received from the MUX block; wherein for any order related update having one or more empty fields, the book updating cell is further configured to retrieve information for the one or more empty fields from the LOB and transmit the information to the joiner cell; the joiner cell is further configured to populate the one or more empty fields of the corresponding order related update with the information before transmitting the order related update to the BBM block.3.According to the feed handling device in Claim 1, wherein the BBM block further comprises:a second queue cell, coupled to the joiner cell, configured to receive each of the normalized updates from the joiner cell;a central processing cell, coupled between the second queue cell and the output block, configured to receive each of the normalized updates from the second queue cell, complete processing for each of the order related updates to update the level book accordingly, and transmit each of the normalized updates to output block in the same sequence as they are received; wherein the processing for each order related updates comprise communicating with relevant functional cells;a level book cell, coupled to the central processing cell, configured to store the level book;a top N levels cell, coupled to the central processing cell, configured to maintain two tables to track top N price levels on bid side and maintain another two tables to track top N price levels on ask side for all financial instruments traded on the multiple exchanges or a portion thereof selected by the user; wherein N is an integer set by the user for each of the financial instruments; wherein the central processing cell is further configured to process each of the order related update to update a second table on bid side or a second table on ask side, and send top N price levels to the output block whenever they are updated.4.According to the feed handling device in Claim 3, wherein a first table on bid side and a first table on ask side for financial instruments traded in the multiple exchanges or a portion thereof selected by the user stores a start address, an end address and the integer N set by the user to indicate memory space allocated to each of the financial instruments for top N price levels in the corresponding second table.5.According to the feed handling device in claim 1, wherein in case the multiple exchanges transmit their financial market data with multiple feeds for redundancy, the feed handling device further comprises multiple arbitration blocks for the multiple exchanges respectively, each of the multiple arbitration blocks is coupled to the parse cell for the same exchange; wherein, each of the multiple arbitration blocks further comprises multiple input ports to couple to the network connections for the multiple feeds respectively; each of the multiple arbitration blocks is configured to receive the packets from the multiple feeds transmitted by one exchange, merge the packets by comparing sequence numbers of incoming packets from the multiple feeds to identify and only forward the packet who arrives earlier with a sequence number that is equal to or bigger than an expected sequence number and discard the others.

6. According to the feed handling device in Claim 5, the feed handling device is embodied on FPGA or ASIC.

7. A feed handling system, comprising:multiple network connectors, configured to support network connections with multiple exchanges;a feed handling device according to any of Claim 1 to Claim 6;a storage block, coupled to the feed handling device, configured to store an LOB maintained by the feed handling device;a connector, coupled between the feed handling device and the user’s trading server;a power block, configured to provide the power supply to the feed handling system;a clock block, configured to provide the clock signal to the feed handling system; anda BMC block, configured to handle board management functions, including controlling the power-up sequence and continuously monitoring temperatures, voltages, and other sensor data.

8. A feed handling method performed by a feed handling device according to any of Claim 1 to Claim 6, comprising:receiving financial market data feeds from multiple exchanges;filtering the packets transmitted in the financial market data feeds with redundancy;parsing each packet transmitted in the feeds into one or more raw messages, then into one or more incremental updates, then into fields;organizing the fields and relevant information into normalized updates in the same sequence as the original incremental updates;merging the normalized updates corresponding to the multiple exchanges into one stream of the normalized message;maintaining a single LOB for all financial instruments traded in the multiple exchanges or a portion thereof selected by the user without sorting entries in the LOB, and pipelining the normalized updates to downstream in the same sequence as they are received;maintaining a single level book for all financial instruments traded in the multiple exchanges or a portion thereof selected by the user without sorting entries in the level book, and tracking top N price levels on each side for each financial instrument; generating necessary data for trade summary service or fill consolidation service if required by the user; andtransforming format of feed handling output into that can be supported by the user’s trading server.

9. According to the feed handling method in Claim 8, wherein maintaining a single LOB for all financial instruments traded in the multiple exchanges or a portion thereof selected by the user without sorting entries in the LOB includes processing each order related update of the normalized updates to update the LOB; wherein pipelining the normalized updates to downstream in the same sequence as they are received includes retrieving necessary information to populate any empty fields of the normalized updates.

10. According to the feed handling method in Claim 8, wherein maintaining a single level book for all financial instruments traded in the multiple exchanges or a portion thereof selected by the user without sorting entries in the level book includes processing each order related update of the normalized updates to update the level book; wherein tracking top N price levels on each side for each financial instrument includes updating top N price levels whenever the level book being updated.

Images