Patent Description:
This patent application is also related to <CIT>,<CIT>, and <CIT> as well as the following published patent applications: <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, and WO Pub.

<FIG> provides a block diagram of an exemplary trading platform which may be useful as background for understanding the invention. A general role of financial exchanges, crossing networks and electronic communications networks is to accept orders to buy/sell financial instruments, maintain sorted listings of buy/sell orders for each financial instrument, and match buyers/sellers at the same price (transact trades).

Financial exchanges, crossing networks and electronic communications networks report all of this activity on various types of financial market data feeds as described in the above-referenced <CIT>. As used herein, a "financial instrument" refers to a contract representing an equity ownership, debt, or credit, typically in relation to a corporate or governmental entity, wherein the contract is saleable.

Examples of financial instruments include stocks, bonds, options, commodities, currency traded on currency markets, etc. but would not include cash or checks in the sense of how those items are used outside the financial trading markets (i.e., the purchase of groceries at a grocery store using cash or check would not be covered by the term "financial instrument" as used herein; similarly, the withdrawal of $<NUM> in cash from an Automatic Teller Machine using a debit card would not be covered by the term "financial instrument" as used herein).

Furthermore, the term "financial market data" as used herein refers to data contained in or derived from a series of messages that individually represent a new offer to buy or sell a financial instrument, an indication of a completed sale of a financial instrument, notifications of corrections to previously-reported sales of a financial instrument, administrative messages related to such transactions, and the like. Feeds of messages which contain financial market data are available from a number of sources and exist in a variety of feed types -for example, Level <NUM> feeds and Level <NUM> feeds as discussed herein.

Dark Pools play a similar function of matching up buyers and sellers, but do not provide full visibility into the available liquidity and pricing information. Dark Pools may be operated by financial exchanges, investment banks, or other financial institutions. Dark Pools are rapidly becoming a key market center for electronic trading activity, with a substantial proportion of transactions occurring in dark pools, relative to public markets.

In order to facilitate the development of trading applications that leverage real-time data from multiple market centers (and their concomitant feeds), trading platforms typically normalize data and perform common data processing/enrichment functions in ticker plants, as described in the above-referenced <CIT> and WO Pub.

Trading strategies consume normalized market data, make decisions to place buy/sell orders, and pass those orders on to an order management system. Note that those orders may provide guidance to the order management system on where to route the order (e.g. whether or not it should be routed to a dark pool), how long the order should be exposed in the market before canceling it (if it is not executed), and other conditions governing the management of the order in the marketplace.

An Order Management System (OMS) (which can also be referred to as an Execution Management System (EMS)) is responsible for managing orders from one or more trading applications. Note that the OMS/EMS may be responsible for managing orders from multiple trading entities. These entities may be competing trading groups within the same investment bank. These entities may also be independent financial institutions that are accessing the market through a common prime services broker or trading infrastructure provider.

The function of the OMS/EMS is to enter orders into a market. Prior to entering an order into a market, the OMS may first perform a series of checks in order to deem the order "valid" for placement. These checks can include:.

It can be noted that these checks are driven by account, risk, and regulatory data accessible by the OMS, as well as a view of the current state of the markets provided via normalized market data from a ticker plant.

It can also be noted that the OMS/EMS typically is used to manage order placement into multiple markets, including dark pools. Once an order is declared to be appropriate (i.e., "valid"), one of the primary functions of the OMS/EMS is to select the destination for each incoming order. Note that the OMS/EMS may also choose to sub-divide the order into smaller orders that may be routed the same or different markets. The OMS/EMS makes routing decisions based on the current state of the markets provided via normalized market data from a ticker plant, as well as routing parameters input to the OMS/EMS. Routing parameters may be scoped on a per-account or corporate basis. These parameters may include:.

Once the OMS has made a decision of where and how to route an order, it may then attempt to optimize the order and communication channel in which it transmits orders to a given market (order entry optimization). For example, orders with a higher probability of getting filled (matched) may be placed prior to orders with a lower probability of getting filled, or orders meeting certain criteria, such as order types or specific financial instruments, may have a higher probability of being filled by utilizing one communication channel rather than another. The order entry optimization may also incorporate the current view of the market (from the normalized market data) as well the current estimate of intra-market latency for the given market.

<FIG> presents a diagram of a conventional OMS/EMS implementation known in the art, which may be useful for understanding the invention. Typically, a plurality of servers <NUM> and network infrastructure (switches, routers, etc.) are employed to host one or more instances of OMS/EMS functions that are interconnected via one or more messaging buses <NUM>, <NUM>, and <NUM>. The OMS/EMS functions are typically implemented in software components that execute on general-purpose processors (GPPs) present in the plurality of servers <NUM>. As shown in <FIG>, normalized market data from a ticker plant is distributed to OMS/EMS software components via a market data messaging bus <NUM>. Similarly an order entry messaging bus <NUM> carries incoming orders from trading strategies, order-related messages between OMS/EMS software components, outgoing orders to markets, and order responses from markets. A database access messaging bus <NUM> provides OMS/EMS software components with access to databases of entitlements, regulatory parameters, risk profiles, accounts, order routing parameters, and position blotters.

One or more order validation software components are deployed on one or more servers <NUM>. Each order validation software component requires a market data interface to the messaging bus. The interface allows the validation software component to request the necessary market data to perform validation on incoming orders. Similarly, the order validation software components listen for new incoming orders from trading strategies on the order entry bus. Note that the latency of market data delivery and the bandwidth available on the market data bus affect the quality and quantity, respectively, of data used by the order validation software component. Furthermore, the distribution of order validation software components across multiple servers <NUM> segments validation decisions. As result, the previously described validation decisions are performed on a limited view of data, which introduces risk, or validation decisions are delayed until data from disparate components can be compiled in order to build a comprehensive view of risk. Such delays may reduce or eliminate market opportunities that depend on a fast response to trading opportunities.

Orders that pass the validation checks are forwarded to one or more routing strategy software components that perform order placement into multiple markets, as previously described. Like the order validation software components, each routing strategy software component requires a market data interface to the market data messaging bus through which it receives current pricing information. The order routing software components typically require a price-aggregated view of the book for the instruments for which it is routing new orders. These book views may be cached locally in the routing strategy software components or requested via the market data interface. The latency associated with these book views directly affects the quality of the data used by the routing strategy software components to make order routing decisions. Delayed data may cause a routing strategy software component to make a decision that results in a missed trading opportunity or a trading loss. Once a routing strategy software component makes a routing decision, the order along with its handling instructions and destination market is forwarded on to the order entry bus.

Typically, output orders from the routing strategy software components are directly passed to one or more FIX engine software components that implement the order-entry interface to one or more markets. The FIX engine software components pass outgoing orders to the markets and pass incoming order responses from the markets to the order entry bus. The latency induced by another transition over a messaging bus and the FIX engine processing represents an additive contribution to the total latency of the OMS/EMS.

Optionally, an OMS/EMS may include one or more order entry optimization software components. As previously described, these software components impose a priority ordering on the orders passed on to the markets. When included in the OMS/EMS, the software components receive orders from the routing strategy software components via the order entry bus, perform their priority queuing operation, and pass orders destined for the market to the appropriate FIX engine software components via the order entry messaging bus. As with the FIX engine software components, the latency induced by another transition over a messaging bus and the order entry optimization processing represents an additive contribution to the total latency of the OMS/EMS.

Thus, distributing OMS/EMS components across multiple systems results in added complexity and latency, which introduces regulatory risk and limits the opportunity to capitalize on latency-sensitive trading opportunities. Furthermore, the overhead of inter-component communication may limit the quantity of data available to components to perform their tasks. This may introduce additional regulatory risk and may further limit trading opportunities.

As a solution to these technical problems of complexity and latency, the inventors disclose a variety of examples whereby tight integration is provided between system components to thereby dramatically improve latency and reduce communication complexity.

The present invention provides an apparatus as set out in present claim <NUM>. Further aspects of the present invention are set out in the remaining claims.

Features and advantages of the present invention will be understood by those having ordinary skill in the art upon review of the description and figures hereinafter.

<FIG> provides a block diagram of an exemplary order management engine (OME) <NUM> which may be useful for understanding the invention, and which integrates various functional components of an OMS/EMS. The integrated engine we describe herein provides significant advantages over the state-of-the-art by significantly reducing latency and complexity while expanding the breadth and increasing the quality of data that may be shared among the components. For example in an embodiment where engine components are deployed on a reconfigurable logic device, on-chip interconnects in the reconfigurable logic device have the potential to provide orders of magnitude more communication bandwidth between components hosted on the same device, as compared to components hosted on disparate servers interconnected via commodity network links. These advantages provide the OME disclosed herein with an opportunity to reduce risk and to more effectively capitalize on latency-sensitive trading opportunities.

As shown in <FIG>, the OME is comprised of a set of parallel components that each performs a subset of the OMS/EMS functionality. The primary datapath of the order management engine (OME) is organized as a feed-forward pipeline: orders flow from the mapping component <NUM> to the order validation component <NUM> to the routing strategy component <NUM> to the order entry optimization component <NUM>. This eliminates the latency and complexity overhead of general-purpose messaging buses interconnecting disparate components. Additionally, this architecture maps well to parallel processing devices such as reconfigurable logic devices (e.g., Field Programmable Gate Arrays (FGPAs)), graphics processing units (GPUs), and chip-multi-processors (CMPs). Feedback from the markets (e. g order accept/reject, order fills, latency measurements via order responses <NUM>) is also propagated to the appropriate component via dedicated interconnects which are only practical in an integrated design. Note that each of the components may exploit parallelism internally in order to maximize throughput and minimize processing latency. Subsequently, we provide examples of parallel implementations of OME components.

The OME can ingest a stream of orders <NUM> originating from one or more trading strategies from one or more trading entities. Preferably, those trading strategies are accelerated and hosted on the integrated trading platform as described herein in connection with <FIG>. Incoming orders <NUM> preferably contain the following fields: instrument key, individual account number, corporate account number, order type, order price, order size, order handling conditions. The instrument key uniquely identifies the financial instrument associated with the order. This key may be in one of various forms, including a string of alphanumeric characters assigned by the financial exchange, an index number assigned by the financial exchange, or an index number assigned by the ticker plant.

The mapping component <NUM> resolves a unique identifier for the financial instrument used by the OME to track per-instrument state. Preferably this key is an index number that allows instrument state to be directly indexed using the number. The mapping component also resolves the unique instrument identifier required for order entry into the markets. Preferably, the mapping component also resolves the instrument identifier required to retrieve the current pricing information from the market view component. As described the above-referenced and incorporated <CIT>, the mapping is preferably accomplished by using a hash table implementation to minimize the number of memory accesses to perform the mapping. Similarly, the mapping component resolves a unique identifier for the individual and corporate risk profile records.

In order to seed the order validation checks, the mapping component also initiates the retrieval of relevant validation information associated with the order from one or more of the following sources:.

Preferably, each of the caches is stored in high-speed memory directly attached to the device hosting the mapping component. Such local memory may be initialized from a centralized database during maintenance windows when trading is not occurring via the operational parameters <NUM> interface shown in <FIG>. The individual account and risk profile is retrieved by using the unique identifier mapped from the individual account number from the incoming order. The corporate account and risk profile is retrieved by using the unique identifier mapped from the corporate account number from the incoming order. The regulatory record is retrieved using the unique instrument identifier mapped from the instrument key as previously described. While the mapping component initiates the retrievals, the read results from the caches are passed to downstream components: order validation, routing strategy, and order entry optimization. In doing so, the mapping component pre-fetches the necessary records for downstream computations, thus masking the latency of the record retrieval from the caches.

Similarly, the mapping component initiates the retrieval of current pricing information for the financial instrument by passing the mapped instrument identifier to the market view component <NUM>.

The market view component can ingest normalized market data <NUM> from a logically upstream ticker plant. Examples of ticker plants that can be employed for this purpose are the ticker plant engines described in described in the above-referenced and incorporated <CIT> and WO Pub. The market view component provides a current view of the markets to other components within the OME. Typically, the view of the market is provided as regional and composite price-aggregated book views for each financial instrument such as those described in the above-referenced and incorporated WO Pub. In a preferred example, the market view component provides a current pricing record to downstream OME components that includes a snapshot of current liquidity in the form of a limited-depth price-aggregated composite book, liquidity statistics, and trade statistics, as shown in <FIG>. The depth of the composite book view may be set as a configuration parameter, or may be dynamically determined by size of the incoming order that triggered the record retrieval. In the latter case, the depth would be chosen to provide visibility into enough liquidity to fill the order on one or more venues. The liquidity statistics provide downstream components with information about the historical share of the best bid and best offer price (i.e. what percentage of the time has the best bid price been available on BATS). The trade statistics present downstream components with a pan-market summary of execution activity for the financial instrument, such as the percentage of the current daily volume that has been executed on a particular market.

In addition to ingesting normalized market data, the market view component has the ability to update those regional and composite book views based on order entry confirmation and order fill reports received from the markets. This information from the order entry interfaces of financial markets is processed by the position blotter component. The position blotter updates the view of current outstanding positions in the market and makes this view available to the market view component, as well as other OME components. Updates to the view of outstanding positions may allow the current view of the market to be updated prior to the concomitant updates being received via the upstream ticker plant that consumes the exchanges' market data feeds. In order to prevent redundant updates to the books, the market view component can maintain a cache <NUM> of updates triggered by the order entry responses. When a concomitant market data update is received, it must be omitted or adjusted by the amount of liquidity added/removed by the order entry response event.

Similar to the retrieval of necessary regulatory and account records, the retrieval of the financial instrument record from the market view component masks the latency of record retrieval for downstream components.

It should also be noted that optionally, the market view component <NUM> can itself be a ticker plant engine that ingests financial market data to produce normalized financial market data for consumption by the order validation component.

The order validation component <NUM> maintains independent input buffers for incoming orders, the regulatory and account records, and the market data records. The buffers provide a synchronization mechanism whereby the order validation component initiates its computations for a new order when all necessary record information is available. The order validation component contains a plurality of rule engines that perform a set of checks as described in the Introduction. Thus the rules engine can instantiate various rules and validate orders (or groups of orders) against those rules. Such rules may be derived from any or all of the following validation rules discussed above (although it should be understood that other validation rules may be desired by a practitioner):.

An example of a rules engine that can be employed toward this end is disclosed in the above-referenced and incorporated <CIT>. Note that the set of rule engines may leverage data parallelism (multiple copies of identical rule engines) and functional parallelism (pipeline of function-specific rule engines) to achieve the desired throughput and latency for the order validation component.

The specific set of checks is dictated by the validation information associated with the order (that was retrieved during the order mapping step). If all checks pass, the order is declared as valid and passed on to the routing strategy component. Note that the order validation component may update validation records and write them back to the appropriate record cache, e.g. The current and cumulative statistics on positions for a given account may be updated. As shown in <FIG>, rule engines within the order validation component may be organized to perform checks in parallel. The output of those parallel checks can be combined in one or more rule engines that ultimately produce a decision to accept, reject, or modify the order. Examples of checks include:.

The combinatorial rules are typically more straightforward, as a reject result from any of the individual rule checks results in a reject decision for the order. The number of independent rule engines provisioned in the order validation component can be determined by the throughput requirement for the component and an analysis of the complexity of rule checks that must be performed.

Modified and accepted orders are forwarded to the routing strategy component <NUM>, along with its concomitant records via a dedicated interconnect. This allows the routing strategy component to immediately begin processing the order. The routing strategy component determines if a valid order is to be partitioned and where the order (or each order partition) is to be routed. Similar to the order validation component, the routing strategy component utilizes a plurality of rules engines such as those described in the above-referenced and incorporated <CIT> to make these decisions (which may also employ a parallelization strategy). The decisions are driven by routing parameters contained in the individual account, corporate account, and regulatory records, as well as data from the market view component and the position blotter component. The rules implement the types of routing strategies outlined in the Introduction. Once a routing decision is completed by the rules engines, the order (or order partitions) are passed on to the order entry optimization component <NUM> with directives on where and how to enter the order (or order partitions) into the market. Note that an order may be entered into a market with a wide variety of parameters that direct the exchange (or dark pool) on how the order may be matched. The routing strategy component also updates the position blotter component to reflect a new position in the market.

The latency monitor component <NUM> utilizes data from outgoing order events <NUM> and incoming order response events <NUM> to maintain a set of statistics for each channel to each market. The latency statistics may include estimates of intra-exchange latency based on measurements of the round-trip-time (RTT) from transmitting a new order on a channel to receiving a response event (either an order accept, reject, or fill notification). The statistics may include the last measurement as well as the average, minimum, and maximum for a defined time window (e.g. a moving average). The latency statistics may also be further refined to include statics on a per-instrument/per-order-type basis for each channel. Such measurements can be performed by recording a timestamp for the transmission of an order entry event, timestamping each order entry response event, identifying the order entry event that corresponds to the response event, and then computing the difference in timestamps.

The order entry optimization component <NUM> optimizes the sequence in which orders are transmitted to a given market. Furthermore, the component may select the appropriate communication channel to the market if multiple channels are available. The order entry optimization component utilizes the directives from the routing strategy component, as well current estimates of intra-exchange latency computed for each independent channel to that market. The latency estimates for each instrument and order type combination may also be incorporated. As shown in <FIG>, the order entry optimization component <NUM> may employ various buffers to store order data, market view data, latency statistical data, individual records data, and corporate records data. The order entry optimization component first computes a vector of scores for each new order via a plurality of computation subcomponents <NUM>, each associated with a channel. Each score in the vector represents a relative priority for an available channel. The channel selection subcomponent <NUM> selects the highest score and stores the order for transmission in the queue <NUM> for the channel associated with that selected highest score. The score associated with the order is also used to determine its insertion point into the queue <NUM>. Thus, each queue <NUM> is associated with a channel and can be implemented as a priority queue that allows new entries to be inserted with a relative priority score, i.e. the order will be inserted ahead of items with a lower score.

A FIX encoder subcomponent <NUM> then services the queues <NUM> to generate the outgoing orders <NUM> in accordance with the selected channels and other optimizations.

An exemplary computation subcomponent <NUM> can score order channels as a simple weighted sum of antecedents: sum(W[i] * A[i]), where W[i] is a user specified weight, and A[i] = antecedent. Exemplary antecedents include:.

A score antecedent selection subcomponent <NUM> can be employed by the computation subcomponent <NUM> to select which data from the buffers is to be used for antecedent values.

As indicated above, the subcomponents of the order entry optimization component <NUM> shown in <FIG> can be implemented in hardware logic pipelines or other parallel processing-capable architectures to exploit parallelism internally in order to maximize throughput and minimize processing latency.

The position blotter update component <NUM> processes order entry response messages <NUM> from the various markets. The response messages notify the OME of which orders were placed, executed, cancelled, rejected, etc. The position blotter provides updates to the market view component when orders are placed so that the views of the market can be updated with less latency than receiving the update via the market data feed from the market center. Through a dedicated interconnect between the position blotter update component and the market view component, such updates can be passed with minimal overhead. Thus, when the OME <NUM> receives confirmation that an order has been placed from a destination market, the OME is able to modify its internal view of the state of the market to include the placed order. This provides the OME with a current view of the market, before the change is reported on the public market data feed. This latency advantage in the market view may then be leveraged by the OME and any trading strategies with access to such data.

The position blotter also tracks the current set of outstanding positions that the OME is managing. The component allows the order validation component and routing strategy component to incorporate a view of the outstanding positions when making validation and routing decisions.

The OME may be implemented on high performance computational platform, such as an offload engine or the like. Examples of a suitable computational platform for the OME include a reconfigurable logic device (e.g., a field programmable gate array (FPGA) or other programmable logic device (PLD)), a graphics processor unit (GPU), and a chip multiprocessors (CMP). However, it should be understood that the OME could also be deployed on one or more general purpose processors (GPPs) or other appropriately programmed processors if desired. It should also be understood that the OME may be partitioned across multiple reconfigurable logic devices (or multiple GPUs, CMPs, etc. if desired).

As used herein, the term "general-purpose processor" (or GPP) refers to a hardware device having a fixed form and whose functionality is variable, wherein this variable functionality is defined by fetching instructions and executing those instructions, of which a conventional central processing unit (CPU) is a common example. Exemplary embodiments of GPPs include an Intel Xeon processor and an AMD Opteron processor. As used herein, the term "reconfigurable logic" refers to any logic technology whose form and function can be significantly altered (i.e., reconfigured) in the field post-manufacture. This is to be contrasted with a GPP, whose function can change post-manufacture, but whose form is fixed at manufacture. Furthermore, as used herein, the term "software" refers to data processing functionality that is deployed on a GPP or other processing devices, wherein software cannot be used to change or define the form of the device on which it is loaded, while the term "firmware", as used herein, refers to data processing functionality that is deployed on reconfigurable logic or other processing devices, wherein firmware may be used to change or define the form of the device on which it is loaded.

By implementing one or more components of the OME in reconfigurable logic such as an FPGA, hardware logic will be present on the device that permits fine-grained parallelism with respect to the different operations that such components perform, thereby providing such a component with the ability to operate at hardware processing speeds that are orders of magnitude faster than would be possible through software execution on a GPP.

Further, the OME may be hosted in a dedicated system with computer communications links providing the interfaces to the normalized market data, order entry interfaces of markets, and order flow from trading strategies. In a preferred embodiment, the OME is hosted in an integrated system where the full trading platform is hosted.

<FIG> presents an exemplary block diagram of an integrated trading platform <NUM> according to the invention, that may be hosted on a single computing system. The single computing system may be a single server, appliance, "box", etc. The system uses intra-system interconnections to transfer data between the ticker plant engine(s) <NUM>, trading strategies <NUM> and/or <NUM>, and order management engine(s) <NUM>. The integrated trading platform <NUM> provides the following advantages over the state of the art (where it should be understood that this list is not exhaustive):.

The amount of general-purpose computing resources available in a single host system is fundamentally limited. This implies that pure software implementations of the trading platform or trading platform components will provide less capacity and latency performance relative to systems that leverage hardware-accelerated designs. In order to achieve a higher level of performance in a single system, trading platform components are preferably offloaded to engines that do not consume general purpose computing resources and leverage fine-grained parallelism.

Thus, as shown in <FIG>, a host system for the trading platform <NUM> comprises a software sub-system <NUM> and a hardware sub-system <NUM>, wherein the software sub-system may comprise one or more host processors and one or more associated host memories. Aspects of the trading platform such as one or more of the ticker plant engine(s) <NUM>, strategy offload engine(s) <NUM>, and OMEs <NUM> can be offloaded to the hardware sub-system for improved performance as described herein.

The ticker plant engine(s) <NUM> can normalize and present market data <NUM> from disparate feeds for presentation to consuming applications (including consuming applications that are resident in the software sub-system <NUM>). Examples of a suitable ticker plant engine <NUM> are the ticker plant engines described in the above-referenced and incorporated <CIT> and WO Pub. <CIT>, which can leverage the parallelism provided by reconfigurable logic devices to provide dramatic acceleration over conventional ticker plants. Furthermore, as shown in <FIG> and described in the above-referenced and incorporated <CIT> and <CIT>, the ticker plant engines writes normalized market data to shared system memory <NUM> (for consumption by trading strategies written in software and executing on the general purpose computing devices in the system) and to shared memory in other offload engines in the system via a peer-to-peer hardware interconnect <NUM>. The peer-to-peer hardware interconnect allows data to be transferred between offload engines without the involvement of system software. Note that the peer-to-peer hardware interconnect may be implemented by dedicated links or system interconnection technologies like PCI Express.

Writing normalized market data to shared (system) memory allows multiple trading applications to view the current state of the market by simply issuing reads to the memory locations associated with the financial instruments of interest. This reduces the latency of data delivery to the trading applications by eliminating the need to receive and parse messages to extract data fields.

An exemplary embodiment of a peer-to-peer hardware interconnect is a PCI Express bus where endpoint devices are each assigned a portion of the addressable memory space. A Base Address Register (BAR) defines the address space assigned to a given device on the bus. If device A issues a write operation to an address within the BAR space associated with device B, data can be transferred directly from device A to device B without involving system software or utilizing host memory. A wide variety of protocols may be developed with this basic capability. Multiple BARs may be employed by a device to implement control structures. For example, specific BARs may be used to maintain read and write pointers for the implementation of a ring buffer or queue for data transfers between devices.

Strategy offload engines <NUM> may also be hosted in the integrated system. Moreover, such strategy offload engines <NUM> can be resident in the hardware sub-system <NUM> as shown in <FIG>. Like the OME, strategy offload engines may receive normalized market data directly over the peer-to-peer hardware interconnect. Examples of suitable strategy offload engines <NUM> include an options pricing engine such as described in the above-referenced and incorporated <CIT>, a basket calculation engine as described in the above-referenced and incorporated <CIT>, engines for performing data cleansing and integrity checks which can employ rules engines such as those described in the above-referenced and incorporated <CIT>, etc..

Note that a hardware-to-software interconnect channel <NUM> provides for low-latency, high-bandwidth communication between software and hardware components. An example of a suitable interconnect channel in this regard is described in the above-referenced and incorporated <CIT>. This facilitates the partitioning of trading strategies across general purpose processing and reconfigurable logic resources. Thus, the strategy offload engines <NUM> can also interact with the trading strategy applications <NUM> within the software sub-system of the host through the hardware-software channel <NUM>, where a trading strategy application <NUM> can offload certain tasks to the hardware-accelerated strategy offload engine <NUM> for reduced latency processing.

The functions of a traditional OMS/EMS that are not performance-critical (e.g. are not performed on every order) may be hosted on general-purpose processing resources in the system if desired (although a practitioner may want to deploy all functions on high performance resources such as reconfigurable logic devices). These functions may include modification of routing parameters, modification of risk profiles, statistics gathering and monitoring. The software components of the OMS/EMS utilize the same hardware-to-software interconnection channel to communicate with the OME(s), update cached records, etc..

As noted above, in connection with the OME, examples of a suitable computational platform for one or more of the engines <NUM>, <NUM>, and <NUM> include a reconfigurable logic device (e.g., a field programmable gate array (FPGA) or other programmable logic device (PLD)), a graphics processor unit (GPU), and a chip multiprocessors (CMP). However, it should be understood that one or more of the other engines <NUM>, <NUM>, and <NUM> could also be deployed on one or more general purpose processors (GPPs) or other appropriately programmed processors if desired for parallel execution within the host. It should also be understood that the engines <NUM>, <NUM>, and <NUM> may be partitioned across multiple reconfigurable logic devices (or multiple GPUs, CMPs, etc. if desired).

Thus, by implementing one or more engines within the hardware sub-system <NUM> in reconfigurable logic such as an FPGA, hardware logic will be present on the platform that permits fine-grained parallelism with respect to the different operations that such engines perform, thereby providing such an engine with the ability to operate at hardware processing speeds that are orders of magnitude faster than would be possible through software execution on a GPP.

Claim 1:
An apparatus comprising:
a trading platform (<NUM>), the trading platform configured to receive and process streaming financial market data (<NUM>), the trading platform comprising:
a host system, the host system comprising a host processor and host memory;
a ticker plant engine (<NUM>), wherein the ticker plant engine is deployed on a member of the group consisting of (i) a reconfigurable logic device, (ii) a graphics processor unit, "GPU", and (iii) a chip multi-processor, "CMP";
an order management engine (<NUM>), wherein the order management engine is deployed on a member of the group consisting of (i) a reconfigurable logic device, (ii) a graphics processor unit, "GPU", and (iii) a chip multi-processor, "CMP"; and
a peer-to-peer hardware interconnect (<NUM>) configured to interconnect the ticker plant engine and the order management engine;
wherein the ticker plant engine is configured to communicate normalized financial market data to the order management engine via the peer-to-peer hardware interconnect without using the host processor and without using the host memory.