Computerized security for trading platform systems, methods, and architectures

Abstract

A system and method for processing trading orders includes a strategy matching venue configured to process strategy orders with each strategy specifying a base rate or a range of base rates. The strategy orders are matched to contrast rate orders that are compatible but may have different strategies. A single match generates a stream of executions at the maximum rate compatible with the matched order's strategy. An additional system operates to generate strategy orders from conventional algorithmic orders and adjust the algorithmic orders for selection to fill the strategy orders by the strategy matching venue.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 62 / 799,170, filed on January 31, 2019, the entire contents of which are hereby expressly incorporated by reference.

[0002] The present invention relates to the processing of trading orders in an automated trading platform.

Background Art

[0003] Institutional investors often need to place large orders in order to make investment decisions. Placing a single large order in the market can, simply based on the rules of supply and demand, have a significant impact on the market price of the security.

[0004] Therefore, large orders are split into many smaller discrete sub - orders according to an algorithmic ("algo") process. These sub - orders are easier to fill and, at least individually, have less impact on the market price of the security. As a result, the overall impact on the price by filling a large order can be reduced. The trade - off in this implementation decision is the acceptance of market risk and implementation risk resulting from the longer execution period resulting from trading in smaller orders that are filled at a slower rate.

[0005] In a conventional trading system, this type of large order is processed using a computerized trading platform. The computerized trading platform uses an algorithmic trading system that automatically slices the large order into many discrete small orders according to an explicitly selected algorithm implementation strategy. The smaller orders are sent to trading venues where they are individually matched and processed against contra-orders in each trading venue. From the perspective of the execution rate, to fill a single large order, an execution rate greater than the market liquidity rate at that time is required. The applied algorithm strategy attempts to fill the large order at an execution rate equal to the available liquidity in the market (the ratio of the available volume to the total market volume) (the ratio of the filled share to the market volume). There are various different types of algorithmic trading strategies used. At a high level, these differences are reflected in the volume rate at which they participate in the market.

[0006] As an example, an order to buy 100,000 shares of XYZ at a specified limit market price may be issued by an institutional trader via an order management system (OMS) or an execution management system (EMS). The order is delivered to a broker-dealer that implements an algorithmic trading system. Algorithmic order management periodically slices the child orders in amounts and frequencies that depend on the algorithm strategy being used and new and / or past market data. In a volume percentage (POV) strategy, the order is sliced at a specified percentage of the market volume. Thus, a 10% POV process can be specified to slice every time after market data indicates that a child order of 2,000 shares has been traded after another 20,000 shares of XYZ.

[0007] The child orders are sent to the smart order router (SOR) of the algo trading platform, which generally further splits each child order into even smaller discrete grandchild buy orders for just a few hundred shares and then sends them individually to multiple trading venues by the SOR. Next, each trading venue tries to match these small grandchild orders with contra orders at rest for execution. Conditional orders are sent to multiple trading venues and may then be cancelled after one venue has been able to fill it.

[0008] The algorithmic trading process is a major component of the current high-frequency trading-dominated market structure and a factor in the fragmentation and decline of the average trade size that characterizes traditional equity markets. Using this traditional methodology, to fill a single large order, thousands of discrete small orders need to be generated and processed. Assuming the current average trade size is 200 shares across the U.S. equity markets, the institutional algorithms would need to have 500 trades to complete an order of 100,000 shares. To achieve 500 executions, a typical algorithmic strategy issues 5,000 orders, most of which are ultimately cancelled. This geometric explosion of orders resulting from algorithmic slicing is further exacerbated by high-frequency trading market makers in market structures that reward the fastest orders and increases the processing overhead. There is also an increased risk of disrupting the entire financial data network, as reflected in the increased occurrence of flash crashes.

[0009] Since the orders on both sides are split into many discrete small orders for processing before trade matching, conventional algorithmic trading systems and execution venues cannot identify situations where large orders can be fully or partially matched with contra orders. Even if institutional investor A wants to sell a large number of shares of the same security at the same venue, time, and strategy, and B wants to buy a large number of shares of the same security at the same venue, time, and strategy, the existing trading system cannot match the parent order. Therefore, institutional investors are restricted to large trades at one price (typically handled as special orders with high commissions by brokers) or small and slow trades across a range of time, volume, price, venue, and counterparty.

[0010] The performance or quality of order execution by algorithmic trading strategies can be quantitatively measured against the benchmark price of the applied algorithmic strategy. For example, the benchmark for an order of 10,000 shares with an algorithmic execution strategy of POV10% is the volume-weighted average price (VWAP) of the next 100,000 shares traded in the market (10,000 / 100,000 = 10%).

[0011] Conventional algo trading systems and methods are inherently flawed in terms of benchmark time matching or optimization. As a result, the algo order system is designed to achieve a certain benchmark and minimize deficiencies, but it cannot fully match the benchmark. The liquidity available in different venues (orders of different quantities and resting limit orders) is continuously changing, and the SOR used in the algorithm processor for grandchild orders continuously reacts to market data from all these venues, which can cause delays. As a result, the algorithm platform is constantly trying to pursue liquidity. On average, the algo platform always performs worse than the benchmark that reflects the best price achievable based on the best liquidity available at all sites.

[0012] Furthermore, the trading venues cannot accurately match orders at the algorithm strategy level. Even in the trajectory cross-venue, it relies on the pre-volume estimation of the security to size the "trajectoried" quantity, which results in slippage through quantity prediction errors. Also, although the algorithm typically overrepresents liquidity needs in multiple venues (e.g., by issuing over-conditional orders), it cannot miss trading volumes anywhere. Therefore, due to the disadvantages of speed and latency, the queue position of the broker's implementation algorithm in the trading venue is typically lower in priority than that of high-frequency market makers who specialize in latency arbitration across venues. As a result of such other inefficiencies, the total benchmark slippage can exceed $100 billion annually in the U.S. stock market. SUMMARY OF THE INVENTION PROBLEMS TO BE SOLVED BY THE INVENTION

[0013] Such inefficiencies, constraints, and other drawbacks are addressed by a trading system architecture and method in which orders are issued with a selected strategy having a rate or range, and are matched at an implicit rate to a target implementation strategy against a contra order in a strategy matching venue. Unlike conventional venues where matching between an order and a contra order results in a single discrete quantity, price, and trade report, strategy matching is open-ended and can include unlimited streams of quantity, price, and trades respectively, according to a compatible rate for the strategy of the matched orders. The price and quantity can be based on prices and sizes that occur in a continuous market, and the stream of implementation of the matching can continue until either the party's order quantity or value range limit is exhausted, violated, or cancelled.

[0014] For example, a buyer and a seller having a trading strategy with a 10% implementation rate can be matched in a strategy matching venue and a stream of implementation that exactly matches the desired ratio, without either party knowing the other or the strategy.

[0015] A strategy order can specify a security, side, quantity, limit price, and a particular strategy. The strategy is selected from a predetermined set of strategies. Each strategy in the set has a specified rate or rate range. Each strategy can be matched to a contra order having the same strategy type, and one, some, or all of the strategies can also be matched to at least one other strategy type. Different predetermined sets of strategies can be provided for different users to use.

[0016] Strategies can be given different matching priorities, such as a priority based on an implicit liquidity rate in the execution strategy. Advantageously, arranging the trading priority order before and after the rate instead of by price better matches the rate-based execution strategy with the venue liquidity. Market participants compete for liquidity based on the rates demanded and offered, instead of competing by price and order submission speed as in conventional systems.

[0017] The system, method, and architecture can be implemented in three main parts that can interact with each other or operate independently. A strategy matching venue engine, a rate optimization system engine that operates in conjunction with an algorithmic trading platform (sometimes referred to herein as the HERO system), and a pre- or post-routing optimization system engine that operates in conjunction with an OMS / EMS system (sometimes referred to herein as the PRO system).

[0018] The strategy matching venue receives and stores strategy orders. Each strategy order has at least one assigned main strategy selected from a predetermined set of strategies. A default strategy can be assigned to non-strategy orders issued to the strategy matching venue. A marketability function can be periodically applied to the stored strategy orders to identify marketable orders. A marketable order having a rate capacity available for exchanging tradable units such as securities is considered tradable.

[0019] The strategy matching venue can select tradable orders, search for contra orders, and identify matches. The strategy matching venue identifies matches between orders based on factors that can include the tradability of the orders and the compatibility of the strategies of each order. If multiple contra orders are available for matching, the match can be prioritized based on factors that can include one or more of the contrast strategy type, order size, order source, order time, and / or other factors. A given tradable order can match multiple contra orders simultaneously.

[0020] Trades are processed for the matched order pairs with reference to external data (market data), and the execution stream is generated based on, for example, market data and the rate overlap of the strategies of the matched orders. The execution streaming can continue as long as both members of the pair are tradable.

[0021] The HERO system can operate in close association with existing algorithmic trading systems such as those used by brokers / dealers. The HERO system is integrated with the algorithmic trading system and generates strategy orders by converting algorithm orders placed in the algorithmic trading system into strategy orders for strategies supported by the strategy matching venue. Using predetermined strategy mapping rules, a specific strategy type to be applied can be selected based on the attributes of the corresponding algorithm order and based on user settings. Different users may prefer different ways of mapping algorithm order attributes to strategy types for strategy orders. One or more sets of strategy mapping rules can be provided for the same predetermined set of strategies and set of mapping rules used for any given order selected based on the attributes of the order such as the trading desk it was issued from. The strategy mapping rules can define more complex rules or can be a simple direct map from the rate specified for the algorithm order to the strategy. Here, the strategy selected for a given algorithm can change dynamically based on external data of the algorithm order itself such as market conditions and the volume of algorithm orders that may already have been filled, but is not limited to these.

[0022] The HERO system interfaces with the strategy matching venue and the algo platform and coordinates both activities to obtain the best trading results for algorithm orders. Messages are exchanged between the algorithmic trading system, the HERO system, and the strategy matching venue to coordinate the processing of strategy orders and the corresponding algorithm orders, such that when strategy order matching is available, the strategy matching functions for the corresponding algorithm order process in the price discovery market.

[0023] The PRO system operates at a higher level than the HERO system in the order processing workflow, interfaces with the Strategy Matching Venue and OMS / EMS, and coordinates activities across both to obtain the best trading results for the trading desk. Instead of acting directly on the algorithmic order platform that enables orders as done in the HERO system, the PRO system acts on the OMS or EMS used by the trading desk to place algorithmic orders and issue strategic orders to the Strategy Matching Venue. The strategic orders are generated corresponding to the algo-orders issued by the OMS / EMS and are issued to the Strategy Matching Venue. Messages are exchanged among the OMS / EMS, the PRO system, and the Strategy Matching Venue to coordinate the processing of the strategic orders and the corresponding algo-orders and, if strategic order matching is available, to enable the strategy matching to work to the advantage of the corresponding algo-orders.

[0024] The systems, methods, and architectures of the present invention have many advantages over conventional trading systems, particularly with respect to the processing of large orders. When pursuing an execution strategy, there is no need to repeat the matching process innumerable times. Since the number of matching cycles to be performed is significantly reduced, the subsequent number of child orders sent per parent order is also significantly reduced. Further, the need to send multiple sub-orders to multiple venues is eliminated. As a result, potential information leakage is limited to the participants centered on execution in the Strategy Matching Venue, and the number of third parties such as HFT market makers who can know the existence of the strategic orders is significantly reduced compared to conventional trading systems. Further, the relative slip with respect to the execution benchmark is mostly or completely eliminated, and the absolute slip with respect to arrival is significantly reduced due to this reduction in information leakage and the elimination of the structural drawbacks of inter-market and intra-market fragmentation present in conventional systems and methods.

[0025] Aspects of the invention also support conditional orders. Canceling a matched order is possible even if the order is actively functioning in the strategy matching venue and is only partially filled.

[0026] In one embodiment, an improved security trading system for implementing various aspects of the invention includes: (i) a strategy matching venue that accepts, matches, and fills strategy orders; (ii) a HERO system that operates with a broker / dealer's algo trading platform, generates strategy orders related to algo orders functioning on the algo trading platform, issues the strategy orders to the strategy matching venue, and causes the strategy orders to function preferentially over the corresponding algo orders; and (iii) a PRO system that operates with an OMS / EMS that can issue orders to a broker / dealer system using a conventional algo trading platform, wherein the PRO system generates strategy orders related to algo orders issued by the OMS / EMS, issues the strategy orders to the strategy matching venue, and causes the strategy orders to function preferentially over the corresponding algo orders, and can comprise one or a combination of such PRO systems. A conventional exchange venue can continue to provide services, for example, to orders from an algo trading platform.

[0027] In one embodiment, the strategy matching venue comprises a computerized system having suitable hardware, memory, and network access to support a desired transaction level, and the system operates according to computer software stored in computer memory. During operation, the strategy matching venue receives a plurality of strategy orders for a first tradable item and stores information regarding the strategy orders in a strategy order book maintained in computer memory. Each strategy order is from a respective source such as a HERO system compatible system, a PRO system compatible system, or any other suitable source. Each order comprises information specifying a side, a limit price, and a strategy. Each strategy is a member of a predetermined set of strategies and has a respective rate or range of rates.

[0028] A first tradable strategy order selected from the strategy orders of the strategy order book. The tradability can be determined by applying a tradability function to evaluate the attributes of each strategy order and the first market data. The strategy orders in the strategy order book have the first strategy order and respective strategies that are compatible with the strategy of the first strategy order, and are searched to find a first matching between the first contrast strategy order and the first matching that is tradable based on the tradability function applied to the first market data. The matching state of the first matching is initially unbroken (not broken). The matching state breaks when either the first strategy order or the first contrast strategy order becomes non-tradable.

[0029] While the first matching is not broken, fills for tradable items are intermittently issued at the maximum rate compatible with the respective strategies of the first strategy orderer and the first contrast strategy orderer, between the first strategy orderer and the first contrast strategy orderer, and the fill amount is a function of the maximum rate applied to the second market data related to the tradable items. Information regarding the first strategy orderer and the first contrast strategy orderer in the strategy orderer book is updated to reflect the fill amount. At least one execution message is sent to each source for the first strategy orderer and the first contrast strategy orderer, and each execution message indicates the filled amount that has been executed.

[0030] In one embodiment, in response to finding the first matching, a conditional message indicating the found matching is sent to each source for the first strategy orderer and the first contrast strategy orderer.

[0031] In one embodiment, in response to each executed fill, each execution message is sent to the source of the first strategy orderer and the source of the first contrast strategy orderer indicating the respective executed fill amount.

[0032] In one embodiment, in response to the break of the first matching, an end-of-matching conditional message is sent to at least one of each source for the first strategy orderer and the first contrast strategy orderer.

[0033] In one embodiment, a tradable item comprises a first security, the first market data comprises data indicating the best available ask price and the best available bid price for at least the first security in the market, and the second market data comprises transaction data indicating at least one reported transaction at each traded quantity and price for the first security in the market. The tradability function for each order can comprise a determination, based on the limit price for each order and the first market data, that each order is marketable and that each order has available capacity, and that the order is tradable if the order is marketable and has available capacity. Each fill quantity can be the maximum rate applied to the traded quantity of each reported transaction, and each fill price can be the price of each reported transaction or a function thereof.

[0034] In one embodiment, the marketability of a strategy order stored in a strategy order book is determined in response to receipt of new first market data. In one embodiment, each fill is performed in response to receipt of new second market item data.

[0035] In one embodiment, if multiple contra orders having compatible strategies are available to match to a strategy order, the contra orders can be prioritized according to the relative priority of the strategies. If multiple contra orders having the same priority strategy are available, the order can be prioritized based on one or more additional priority factors that can include order size, and the order has a higher priority than a threshold size that is smaller than the order, the order source, and the arrival time in the strategy matching venue.

[0036] In one embodiment, the maximum rate compatible with each strategy of the first strategy orderer and the first contrast strategy orderer is the minimum rate of the maximum rate available to the first strategy orderer and the maximum rate available to the first contrast strategy orderer.

[0037] In one embodiment, when an order pair matches, information regarding the match can be stored in one or more active stream records of the active stream table. Each record of the active stream table identifies each of the first side and the contra orderer currently in matching. A link to the appropriate active stream record can also be stored in the order record of the matching order in the order book.

[0038] In one embodiment, a strategy orderer can be made conditional. If at least one of the first order and the first contra order of the first match is conditional, conditional matching can be generated and information regarding the match is stored. A confirmation message is sent to the source of each conditional order. The filter for the tradable item is not performed until each conditional order of the match is confirmed. If not confirmed within a predetermined period, the conditional matching can be released.

[0039] The confirmation message can include a matching ID number associated with a particular matching being confirmed. The confirmation response can be matched to the relevant strategy matching based on the matching ID value included in the response. The confirmation response can include an update for each conditional strategy orderer being confirmed, or a replacement unconditional strategy orderer for each conditional strategy orderer being confirmed.

[0040] In one embodiment, the order data stored in the order book can include the available capacity of each order, and the available capacity indicates the order capacity available for that order that can be applied to subsequent matching with a contra order. In various embodiments, the order capacity can be specified with respect to the available volume rate or range of rates for each order, with respect to the available capacity, or by other metrics. When a first strategy order and a first contra strategy order match, the available capacity of each order can be reduced by the expected total amount of the share to be exchanged between the first order and the first contra order during the first matching, by the maximum volume rate compatible with the respective strategies of the first strategy order and the first contra strategy order, or by other metrics. If the available capacity of the first order remains zero or greater than the minimum threshold, the first order can be matched with an additional contra order while the first matching remains active.

[0041] In one embodiment, the strategy order can further specify alternative strategies and predetermined conditions for activating the alternative strategies. The conditions for triggering the use of an alternative strategy can be specified as the difference between the current price of the relevant security and the strike price of the strategy order.

[0042] In one embodiment, a strategy order change message can be received that specifies that each strategy amount or strike price is to be changed. The strategy order change message can specify the strategy to be used to replace the current strategy of each order.

[0043] In one embodiment, the HERO system comprises a computerized system having appropriate hardware, memory, and network access to support a desired trading level, and the system operates according to computer software stored in computer memory. The HERO system is configured to communicate with a strategy matching venue and an automated computerized algorithm trading platform connected to at least one trading venue by a network.

[0044] The algorithm trading platform operates to process a trading order that specifies tradable items, which may be securities, quantities, sides, and has associated algorithmic constraints by intermittently generating sub-orders from the trading order according to the algorithmic constraints. Each sub-order specifies a respective sub-order quantity and is issued to a point-in-time (PIT) trading venue. A PIT execution message is received, and each PIT execution message corresponds to a respective sub-order and indicates the fill quantity of the respective sub-order, where the fill quantity is less than or equal to the respective sub-order quantity.

[0045] A first strategy order corresponding to the trading order is generated, and the first strategy order specifies a respective strategy selected from a predetermined set of strategies according to the security and side of the trading order, a predetermined set of strategy mapping rules by the HERO system, and rules for at least one attribute of the trading order. A plurality of sets of predetermined strategy mapping rules can be defined and can be selected based on attributes of a particular trading order, such as the trader or trader group for which the trading order was issued.

[0046] Information regarding the first strategy order is added to a strategy order table, and the first strategy order is issued to the strategy matching venue.

[0047] When the algorithmic trading platform receives a matching detection condition message from the strategy matching venue for the first strategy order, it is controlled by the HERO system to stop generating sub-orders for the trading order corresponding to the first strategy order.

[0048] When receiving an execution message related to the first strategy order from the strategy matching venue, it designates the execution of the first order of the respective trading volume and trading price data of the first strategy order in the strategy order table, is updated to reflect the execution volume, and the execution information from the execution message is sent by the HERO system to the algorithmic trading platform.

[0049] When the algorithmic trading platform receives a matching break condition message from the strategy matching venue, it is controlled to resume issuing sub-orders for the first algorithmic trading order, and if there is at least one potential share available for the trading order, the generation of sub-orders is resumed.

[0050] In one embodiment, the available quantity information for the trading order is received from the algorithmic trading platform, and the quantity data of the strategy order table record for the first strategy order is updated based on the received available quantity information. In response to receiving the execution data from the strategy matching venue, the record data regarding the first strategy order in the strategy order table is adjusted to reflect the execution data.

[0051] In one embodiment, the first strategy order can specify the maximum number of shares available for strategy matching, or this can be determined later. The maximum number of shares available for strategy matching is the number of potential shares of the first strategy order (unexecuted shares of orders not routed to the trading venue) minus the buffer value.

[0052] In one embodiment, the first strategy order is a conditional strategy order. In response to receiving a confirmation message from the strategy matching venue for the first strategy order, a confirmed number of shares available for strategy matching related to the first strategy order is determined, and the confirmation response sends the strategy matching venue. In one embodiment, the confirmed number of shares can be the potential number of shares associated with the first algorithm order, or alternatively, the remaining number of shares associated with the first algorithm trade order. In one embodiment, the confirmed response may be an update to the first strategy order specifying the confirmed number of shares, or alternatively, a second strategy order having content specifying the confirmed number of shares and associated with the first order ID or a link to the first order ID, and a second message that cancels the first strategy order to the advantage of the second strategy order may also optionally be sent by the HERO system.

[0053] In one embodiment, in response to receiving a confirmation request by the HERO system, the HERO system sends a cancel order instruction to the algorithm trading platform requesting cancellation of unprocessed child orders related to the first algorithm order, and after receiving a cancellation confirmation message from the algorithm trading platform, can perform a confirmation response process on the strategy trading platform.

[0054] In one embodiment, the information regarding the active strategy order in the strategy order table comprises content indicating the current number of potential shares available for the first algorithm order, and the potential number of shares is updated in response to receiving order execution information regarding a trade order from the algorithm trading platform. In response to a change in the maximum number of shares available for strategy matching for the first strategy order, a message can be sent to the strategy matching venue indicating the change.

[0055] In one embodiment, the PRO system comprises a computerized system having appropriate hardware, memory, and network access to support a desired trading level, and the system operates according to computer software stored in computer memory. The PRO system is configured to communicate with a strategy matching venue and an order or execution management system. The strategy matching venue processes strategy orders for respective shares by matching a strategy order having a particular strategy with a contrast strategy order having a compatible strategy and initiating a stream of trade execution between the matched orders. The management system issues algorithmic orders to an algorithmic trading system.

[0056] The first trade order is received in the PRO system from a management system that identifies tradable items such as security, side, limit price, and algorithmic constraints. A first strategy order corresponding to the trade order is generated, and the first strategy order designates respective strategies selected from a predetermined pair of strategies according to the security and side of the trade order, a predetermined pair of strategy mapping rules, and rules in at least one attribute of the trade order. A plurality of pairs of predetermined strategy mapping rules can be defined, and a particular pair of strategy mapping rules can be selected based on attributes of a particular trade order such as the trading desk or broker from which the trade order was issued.

[0057] A conditional first strategy order having a first order ID and content that specifies tradable items, side, and limit price from the trade order and further specifies a first strategy type is generated. Information regarding the first strategy order is added to a strategy order table, and the first strategy order is issued by the PRO system to a strategy matching venue.

[0058] In response to receiving a confirmation message from the strategy matching venue for the first strategy order, the PRO system can send an order cancellation message to the management system indicating that the minimum portion of the trading order issued to the algorithmic trading platform is cancelled. Upon receiving a cancellation confirmation from the management system, the confirmed number of shares available for the first strategy order for strategy matching is determined, and a confirmation response indicating the confirmed number of shares is sent to the strategy matching venue. In one embodiment, the confirmation response may be an update to the first strategy order specifying the confirmed number of shares, or it may be a second strategy order having content specifying the confirmed number of shares and associated with the first order ID or a link to the first order ID, and a second message may optionally be sent to cancel the first strategy order to the advantage of the second strategy order.

[0059] The matching detection condition message from strategy matching indicates that the confirmed first strategy order is matched with a counter strategy order. If the matching detection condition is not received within a predetermined timeout period, a reissue message is sent to the management system indicating that the cancelled portion of the first trading order can be reissued.

[0060] Upon receiving an execution message related to the first strategy order specifying the execution of each trading volume and trading price from the strategy matching venue, the record of the first strategy order in the strategy order table is updated to reflect the execution volume, and the execution information from the execution message is sent by the PRO system to the management platform.

[0061] The received matching detection message can include an indicator of the maximum number of traded shares for the strategy order that can result from the matching. In response, the message can be sent by the PRO system to a management system having this value, and the management system can reissue an algorithm order having the number of available shares after assuming that the maximum number has been met by the strategy matching venue.

[0062] Upon receiving a matching break condition message from the strategy matching venue, the management system sends a message to the management system indicating that it can reissue the unfilled portion of the trading order to the algorithmic trading platform.

Brief Description of the Drawings

[0063] Further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, are disclosed in detail below with reference to the accompanying drawings.

[0064]

Figure 1

Figure 2A

Figure 2B

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7A

Figure 7B

Figure 8A

Figure 8B

Figure 8C

Figure 9A

Figure 9B

Figure 10A

Figure 10B

Figure 11

Figure 12A

Figure 12B

Figure 13A

Figure 13B

Figure 14A

Figure 14B

Figure 15

Figure 16A

Figure 16B

Figure 16C

Figure 16D

Figure 17

Figure 18

Figure 19

Best Mode for Carrying Out the Invention

[0065] FIG. 1 is a high-level block diagram showing a general system architecture of a conventional algorithmic trading platform (algorithmic platform) 100 used to process orders for trading securities. An algorithmic order (algorithmic order) 105 is issued from an institutional order management system (OMS) or an execution management system (EMS) 110 and sent to the algorithmic platform 100. The algorithmic order 105 specifies a side (buy or sell), quantity, and limit price. The new algorithmic order 105 is added to an algorithmic order table 120 used to track information about open algorithmic orders. When an algorithmic order in the algorithmic order table 120 is selected to be processed, the algorithmic order management 130 operates to divide the algorithmic order into a number of smaller discrete sub-orders. The sub-orders 135 are continuously "sliced" from the parent according to the specified execution algorithm. The new algorithmic order 105 can also have general instructions used by the algorithmic order management 130 to control the sub-slicing to spread the execution over time and / or over market volume.

[0066] The sub-orders 135 are processed by a smart order router ("SOR") 140 that further divides the sub-orders into even smaller discrete grandchild orders 145. The SOR 140 directs the grandchild orders 145 to a selected point-in-time (PIT) trading venue 150. Each trading venue 150 conducts point-in-time (PIT) trading, matches the received orders with contra orders, and for each match, performs a single execution of a single discrete quantity of securities exchanged at a fixed price and at a single point in time. The execution information 155 is returned from each PIT trading venue 150 to the algorithmic trading platform 100, and this is used to update the internal data associated with the grandchild, sub-, and initial orders 145, 135, 105 as appropriate.

[0067] When an order placed in the PIT trading venue 150 is conditional, when the PIT trading venue detects a matching with an order for that order, it sends an invitation to the order originator such as the SOR 140 and invites them to send a confirmed response order. When the confirmed response order 160 is received, the confirmed response order replaces the cancelled conditional order, and instead, the confirmed response order is processed.

[0068] Figure 2A is a high-level flowchart of the general operation of the conventional algorithm order management 130. Figure 2B is a high-level flowchart of the general operation of the conventional SOR 140. Referring to Figures 2A and 2B, for example, when an initial algorithm order is received to purchase N shares of security XYZ (step 202), information about the order including the initial number of shares is added to the algorithm order table (step 204). If an initial or subsequent sub-slice is required, appropriate algorithms and order parameters are applied and a new child order (e.g., for n shares) is sliced (steps 206, 208). Here, n can be much smaller than N. The child order is issued to the SOR for downstream processing (step 210), and the algorithm order table (or other appropriate dataset) is updated to indicate the potential number of shares in the original algorithm order, e.g., the number of shares that are not allocated to the issued child orders and can therefore be sliced into further child orders and sent for execution. (step 212). If potential shares remain in the algorithm order (step 214), the system slices off child orders according to the applied algorithm and continues to issue them (steps 206-212). When there are no remaining potential shares (step 214), there is no need to slice additional child orders.

[0069] Referring to FIG. 2B, when the SOR receives a child order from the algo order management (step 216), it generates grandchild orders and then issues them to the PIT trading menu for execution (steps 218, 210). Execution information from the PIT trading menu is received by the SOR (step 222), and the execution data is returned to the algo order management (step 224).

[0070] Returning to FIG. 2A, when the child order execution data is received from the SOR (step 226), the algo order management updates the information regarding the algo order in the algo order table to reflect the amount of shares exchanged in the executed transaction (step 228). If the total number of executed shares is less than the total number of shares of the algo order (e.g., less than N) (step 230), the algo order management continues to wait for additional execution data from the SOR. (step 226). If there are no remaining shares, the entire algo order is filled (step 330). Additional steps can be taken if the delivered algo order, child order, and / or grandchild order are conditional orders for each order to determine appropriately.

[0071] FIG. 3 is a high-level block diagram of an improved trading system architecture 300 that can execute strategy orders using a strategy matching platform and can be implemented and operated with a conventional algorithmic trading system.

[0072] Similar to algorithmic orders, strategy orders specify order security (or other tradable items), side (e.g., buy or sell), and limit price. Further, in contrast to conventional trading systems, strategy orders also specify a strategy type selected from a predetermined set of strategies. Each strategy order type can have a different execution rate or range of rates. Advantageously, the strategy matching system can implement trading strategies not supported by conventional algo systems, such as executing more than 100% of the amount traded in the market over a certain period.

[0073] A variety of different strategy types can be defined. Various predetermined sets of strategies can be made available for use in various situations, for trading different types of tradable items, and for use by various entities. Each institutional trader or broker-dealer can have its own customized set of unique strategy types. Each strategy type has a rate or range of rates and can be matched to itself, can be matched to one or more other strategy types of a predetermined set, and in some cases can be matched with other predetermined strategy sets. Priorities can be assigned to strategy matching. In one embodiment, the strategies can be prioritized according to the relative liquidity rate. When one strategy can be matched by two or more other strategies, the matching strategy that provides a higher rate can be given a higher priority.

[0074] A variety of different strategies can be defined, but in one embodiment, the strategies are classified into three basic classes. The first strategy class comprises strategies having a reference rate or range of reference rates of 100% or less. As further described below, the reference rate of a strategy is used, for example, in determining the execution rate of a strategy order, where the execution volume is determined from a certain rate applied to a specific record of the trading volume of the item in question. The second strategy class comprises strategies having a reference rate or range of reference rates that exceed 100%. The third strategy class is a liquidity search and comprises a non-numerical rate (or infinity) indicating that the maximum rate allowed during strategy order processing is used.

[0075] Returning to FIG. 3, the High Efficiency Rate Optimizer (HERO) system engine 310 is connected to one or more strategy matching venues 315. The HERO system operates to issue strategy orders to the strategy matching venue 315. The strategy matching venue 315 attempts to match the received strategy order with a contrast strategy order having a strategy with the same security and compatibility.

[0076] When a match is found by the strategy matching venue 315, a series of implementations for the matched order are carried out according to the compatible aspects of each strategy type for the matched order. Instead of matching discrete and independent sub-orders as done in the conventional algo trading system 100 operating in the PIT trading venue 150, the matching of the strategy matching venue 135 is open-ended and can maximize liquidity up to the maximum available for the matched strategy order. A single match can result in a continuous flow of fills based on the reference rate and the integrated trading volume, and the strategy matching is implemented so that this can be done without the need to access a continuous market. The execution price can be based on the current market price of the security reflected by the market trading data and the execution volume determined as a function of the current reference market data such as the trading strategy of the order and the trading volume of the security reflected by the market data. The flow of fills ends when the marketable liquidity between the matched strategy orders is exhausted.

[0077] As will be further described below, an algo order can have associated algorithmic constraints, such as a target rate at which the algo trading platform attempts to match. A strategy order can be generated for an algo order by selecting a strategy from a given set of strategies according to a given strategy mapping rule. Different sets of strategy mapping rules can be defined by different system users, and the particular mapping table used can be selected, for example, according to the party that issued the initial order. The predefined strategy mapping rules may be static or may be mapped to a particular strategy based on the algo order target rate. The strategy mapping rules may be dynamic, and the strategy to be mapped depends on factors such as the percentage of completed algo orders, market data inputs related to the security in question, and / or other direct or indirect factors.

[0078] FIG. 19 is an example of a matrix of a predetermined set of strategy types indicating which strategy types match which other types and priorities. In the illustrated embodiment, a low rate range strategy is defined as having a reference rate range of 5% - 15%, and a medium strategy is defined as having a reference rate range of 10% - 30%. A strategy order having a low strategy is processed in a strategy matching venue such that when the order matches, it is executed at a rate of 5% - 15% of the relevant transaction volume at an actual rate that depends on the strategy of one or more contra orders that match, as further described below. Similarly, a strategy order having a medium strategy is executed in a strategy matching venue at a rate between 10% - 30% of the relevant transaction volume. Rate strategies of 100% - 200% and 100% - 400% indicate implementation rate ranges exceeding 100%. An exact rate strategy specifies a single reference rate, such as 7%, for implementation in a strategy matching venue. Strategies can also have other ranges. The predetermined number of strategies in a strategy set can vary, and increasing the number of strategies can increase the rate granularity between various strategies. Strategies can be defined with an intentional overlap to allow overlapping strategies to cross-match with each other.

[0079] Both the low strategy and the medium strategy tolerate rates between 10% and 15%, and thus, using transactions related to the low strategy type, at least a part of the contra transactions made by the medium strategy order (implemented at a higher rate) can be satisfied without violating the specified strategy rate range of any order. Therefore, the low strategy and the medium strategy can match each other. In practice, the rate used for implementation in the strategy matching venue is the maximum rate of the overlap, which is 15% here, but in alternative embodiments, a lower rate can be used if it is considered appropriate for a particular transaction situation. Similarly, the 100% - 200% and 100% - 400% strategy types are compatible in that an order with a 100 - 400% strategy can be at least partially satisfied by an order with a 200% strategy. The liquidity search strategy matches all interest rate-based strategies and liquidity search strategies.

[0080] When a given strategy can be matched to a plurality of different compatible contra strategies, a priority can be given to the matching with the highest potential liquidity. In FIG. 19, the strategy matching priority is exemplarily shown by sequence numbers 1 - 5, where 1 indicates the highest priority. As an example, a buy order with a medium (10% - 30%) strategy is preferentially matched to a contra order with a liquidity search strategy and is matched when there is nothing available for the media strategy and when there is nothing available for the low (5% - 15%) strategy order.

[0081] When a strategy order is matched to a contra strategy order, if there is additional capacity available in the strategy order, that strategy order can be matched to another contra strategy order, and the other contra order can also have strategies that may not be compatible. For example, a strategy order specifying a strategy of 5 - 15% can be matched to a contra strategy order with an exact strategy rate of 11%. Since the strategy matching is carried out at the 11% rate, the initial strategy order has a remaining capacity of 15% - 11% = 4% (while the initial strategy matching is valid), and thus can be simultaneously matched to a second contra order with a strategy of <= 4% (or the remaining strategy capacity).

[0082] In a set of strategy matching rules, an algo order with a target trade rate X tends to be mapped to a strategy with a reference rate in the range from A to B, where A <= X <= B. However, the user does not need to specify the mapping required. Further, even within this condition, if two or more strategies have a reference rate range that includes X, different users can define their own strategy matching rules for mapping the order to different strategies. For example, the first user can specify a rule that results in an algo order specifying an algo target rate of 12% mapping to the 5% - 15% strategy, and the second user can specify a rule that results in an algo order with the same target rate of 12% mapping to the 15% - 30% strategy. The third user can specify that any algo order with a reference rate between 5% and 12.5% is mapped to the 5% - 15% strategy, while an order with a reference rate exceeding 12.5% and less than 35% is mapped to the 10% - 30% strategy.

[0083] Examples of Strategy Orders A and B having the strategy selected from the strategy of FIG. 19 are shown below for the trading volume V of the related security 10000. These examples assume that the strategy orders are marketable and each has a capacity available for a determined quantity to be exchanged. If the capacity of either order is less than the calculated amount, the lowest capacity determines the amount to be exchanged. JPEG0007701269000001.jpg93146

[0084] Operationally, the strategy matching venue 315 continues to conduct a series of matching trades. The trades use the quantity calculated from the applied reference rate and the most recent trading volume (the corresponding trading price), or use the midpoint of the current bid and offer of the block seeking liquidity for the match until the capacity of the matched pair of orders is depleted or one of the orders lacks marketability.

[0085] The HERO system 310 also communicates with an algo trading platform engine 320 configured to operate in conjunction with the HERO system (which can be referred to herein as the HERO recognition algorithm platform). The algo trading platform 320 and the HERO system 310 can all be implemented as part of an entire cell-side or buy-side broker-dealer system, and there are various ways to integrate the systems. When a qualified algo order is sent to the algo trading platform 320, the HERO system 310 generates a corresponding strategy order and issues this strategy order to the strategy matching venue 315. Although one strategy matching venue 315 is shown, there may be multiple available strategy matching venues, and the HERO system 310 may be configured to select an appropriate strategy matching venue as desired. The strategy matching venue used for a given strategy order can be defined in advance or can be dynamically selected based on various factors such as the type of tradable item being issued or other details regarding the order.

[0086] The overall processing of strategy orders by the HERO system 310 and their respective strategy matching venues 315, and the corresponding algorithmic order processing by the algo trading platform 320 and the PIT venue, occur roughly in parallel. Strategy matching for strategy orders takes precedence over the algorithmic processing of the corresponding algo orders. Messages are exchanged between the HERO system 310 and the algo trading platform 320, and the HERO system 310 instructs the algo trading platform 320 to start and stop the algorithmic processing of algo orders during the streaming of fills from strategy matching by the strategy matching venue. Messages are also exchanged to keep both the HERO system 310 and the algo trading platform 320 up-to-date regarding the state of filling their respective algo orders and corresponding strategy orders.

[0087] The total number of executed shares resulting from strategy matching may be unknown at the time when the matching is performed by the strategy matching venue 315. When the strategy matching venue 315 detects a match, it notifies the HERO system 310 of the presence of a condition message indicating the match, which in this specification is also referred to as the "stream on" condition, for the relevant strategy order. Subsequently, the HERO system 310 notifies the algo trading platform 320 of the stream on state and instructs the algo trading platform 320 to stop slicing new child orders for the corresponding algo order.

[0088] When the filter stream ends at the strategy matching venue 315, the HERO system 310 sends a matching break condition message, also called the "stream off" condition, to the associated strategy order. The HERO system 310 is also notified by the strategy matching venue 315 of the total number of filters performed during strategy matching, such as while a filter is being performed at the strategy matching venue or the total after the stream has ended. The HERO system 310 updates the internal record associated with the strategy order. It also notifies the algo trading platform 320 of the stream off state and the total number of filters (if that information has not yet been provided). The algo trading platform 320 can then update its own internal record for the corresponding algo order. If the algo order is not fully filled, the algo trading platform 320 can resume the remaining algorithmic processing, and the HERO system 310 and the strategy matching venue 315 can continue in parallel to process the corresponding strategy order.

[0089] Additional messages can also be sent as needed between the strategy matching venue 315, the HERO system 310, and the algo trading platform 320 to determine the share amount that can be used to confirm a conditional order or exchange it with a predetermined order. When the strategy order specifies the total number of shares, the strategy order update can be sent by the HERO system 310 to the strategy matching venue 315 to reflect the implementation resulting from the activities of the algo system working on the corresponding algo order.

[0090] In one embodiment, since the HERO system 310 communicates with the internal aspects of the algo trading platform 320, the HERO system module 310 can generally be integrated into the same broker-dealer system that includes the algo trading platform 320. Thus, a broker / dealer can install the HERO system into its trading system, modify its algo order management, communicate properly with the HERO system, and start and stop algo order processing as needed. Such an algo system can then advantageously pause and resume the algorithmic processing of algo orders so that, in a more efficient manner, the corresponding orders are processed in parallel with the individual order processing systems that can fulfill the corresponding orders, either in whole or in part.

[0091] The algo trading platform system can also be designed or modified to have appropriate APIs or other program hooks, and internal controls are required to cooperate with the HERO system whether the HERO system is initially unavailable or, if available, implemented as an individual system. A HERO system module with an appropriate API interface for communicating with the algo platform can be added separately. There are various ways to implement and integrate the HERO system 310 into a conventional algo trading platform 320. Specific embodiments are described below.

[0092] FIG. 4 is a high-level diagram of the architecture of the HERO system 315. One or more computer processors 405 implement computer software stored in program memory 410. The processor 405 is used for generating strategy orders based on algo orders and has access to a data memory 412 that includes one or more data repositories such as a strategy order table 415, one or more sets of strategy mapping rules, and other operational data 425.

[0093] To connect the HERO system 310 to an external system, an appropriate communication interface 430 is used. In the illustrated embodiment, a LAN 435 provides communication between the HERO system 310 and the algo trading platform 320, while a separate WAN 440 provides communication between the HERO system 310 and one or more strategy matching venues 315. The computer platform used to implement the HERO system can be one or more high-speed computers having sufficient data throughput and processing power to support the expected transaction volume. The LAN and WAN networks 435, 440 can be high-speed fiber optic data networks, or other network systems conventionally used in financial trading networks. Appropriate computer platforms are known to those skilled in the art.

[0094] The program memory 410 and the data memory 412 can be implemented, in whole or in part, by the same or different components. The memories 410, 420 can include one or more internal RAMs and firmware, local electronic data storage devices such as solid or magnetic drives, and external data storage devices provided by memories physically coupled via other data cables accessible via USB or a network. Other computer-readable media for storing software and data can also be used. The HERO system 310 can be implemented on one or more computer servers, personal computers, or other computer systems.

[0095] A separate user interface 445 can be provided, and a computing device 450 such as a PC can access the HERO system 310, and an authorized user can perform various management functions such as monitoring of HERO system performance metrics, display of order maps and transaction histories, and adjustment of system configurations. The remote device 450 can be connected locally to the HERO system 310, or can be connected via a network 455 such as an intranet or a secure VPN on the Internet to provide remote monitoring.

[0096] The HERO system 310 can be implemented as an internal computer system of the infrastructure of a given brokerage dealer system. In one embodiment, it is implemented on the same physical computer as the algo trading platform 320. The processor 405 implements both the algo and HERO system code, and the program memory 410 stores the functions of both systems. In this more tightly coupled embodiment, communication between the HERO system 310 and the software modules of the algo trading platform 320 can be implemented at a lower level using various internal APIs or other message protocols known to those skilled in the art, and a separate LAN connection may not be required.

[0097] Alternatively, the HERO system 310 can also be implemented as a stand-alone computer system such as a high-speed server with a communication interface 430 having network ports such as optical fiber ports, Ethernet, USB ports, or other data communication ports suitable for connection to the LAN 435 and WAN 440 respectively. Various programming techniques for implementing such a configuration are known to those skilled in the art.

[0098] Multiple HERO systems operating in parallel can be used with the algo trading platform 320. Load balancing and other techniques can be used to assign appropriate algo orders to the HERO systems. Similarly, a brokerage dealer with some internal algorithm order management can integrate each with a common HERO system.

[0099] Figure 5 is a high-level diagram showing the functional aspects and data communications of one embodiment of the HERO system 310 between (i) the components of the algo trading platform 320 having the HERO system 310 and the HERO system recognition algo order management 580, and (ii) the HERO system 310 and one or more respective strategy-level strategy matching venues 315. For the internal functions of one embodiment of the HERO system 310 and the inter-system communications, refer to the flowcharts of FIGS. 7 and 8 for a more detailed description.

[0100] The illustrated HERO system 310 includes a strategy order management 505 that can track strategy orders and store their details in a strategy order table 415, and is mainly related to the function of exchanging information and messages with the algo trading platform regarding algos and strategy orders. Note that the order amounts stored in the algo order table 120 and the strategy order table 415 are related to each other, but may not be the same. The HERO system may be given access to only a portion of the total quantity specified in the initial order 105 so as to be available for use in strategy orders. This difference can act as a buffer to prevent the risk of over-implementation.

[0101] The communication between the strategy order management 505 and the strategy matching venue 315 can be supported by a strategy SOR 510 that routes communications regarding strategy orders between the strategy order management 505 and one or more strategy matching venues 315, and can have the function of selecting an appropriate strategy matching venue if more than one is available. The strategy SOR 510 is shown separately from the strategy order management 505, but the functions may be combined in an integrated software program. Similarly, the functions of the strategy order management 505 may be implemented in multiple software components.

[0102] Various messages can be sent between the HERO system 310 and each respective strategy matching venue 315. These messages include a strategy order 520 sent to the strategy matching venue 315, stream on and stream off condition messages 525 received from the strategy matching venue 315, and streaming order execution data 530 from the strategy matching venue 315 regarding fills. Confirmation orders and other confirmation related messages 540 are used in the processing of conditional strategy orders. Various message protocols such as the FIX (Financial Information Exchange) protocol can be used.

[0103] Various messages can be sent between the HERO system 310 and components of the algo trading platform 320. The message protocol used depends on how the HERO system 310 and the algo trading platform 320 are integrated with each other. Those skilled in the art will be aware of various suitable message protocols.

[0104] When an algo order or algo order update is received by the algo trading platform 320, an order update message 550 can be sent to the HERO system 310. Since the algo trading platform 320 places algo orders, information regarding the order status, such as remaining order quantity updates 565, can be sent to the HERO system 310, such that the HERO system remains informed of the share numbers for the corresponding strategy orders available for strategy matching. When each respective strategy matching venue 315 sends a stream on / off condition message 525, a corresponding stream on / off condition message 560 is sent from the HERO system to the algo order management 580. Similarly, the execution data 530 received from the strategy matching venue 315 may be sent as an execution message 555, such that the algo trading platform 320 can update its internal records regarding the corresponding algo order.

[0105] When the HERO system 310 detects a new algo order or is notified, it can generate a corresponding strategy order. One way to do this, referring to FIG. 6, is by using the usage strategy mapping rule 420. The strategy mapping rule 420 can be predefined to reflect various trading selections of participating users. The mapping can be implemented using the details of any algo order available in this process. Additional data can also be referenced. For example, the supplementary order data field of the algo order 105 sent to the algo trading platform by the OMS / EMS 110 can be used to provide additional information for use by the strategy mapping rule, for example, to directly specify a particular strategy.

[0106] Different institutional OMS / EMS 110s or broker-dealers can have different selections regarding how to map algo orders based on various attributes of the strategy in a given pair of strategies. The provider of the algo trading platform 320 can define its own mapping rules for use with orders, or the user can define them. If two or more sets of rules 420 are available, the HERO system can be notified to select the appropriate set of rules or which set to use.

[0107] In addition to the static one-to-one mapping as described above, more intelligent dynamic rules can be defined to enable the selection of corresponding strategies based on information external to a specific algo order, such as current or past market data 610. In the above example of a 12% volume order, the conversion mapping can specify a match to the 10 - 30% strategy if specified market conditions exist, such as the index exceeding the 30-day average, and a match to the 5 - 15% strategy if the conditions do not exist. The HERO system can also monitor relevant market data and operate to respondently adjust the strategy for an existing strategy order. If the strategy selected for an existing strategy order is allowed to change over time, the HERO system can periodically re-evaluate the strategy for such a strategy order in the strategy order table, update the strategy as needed, and send a strategy order change message to the strategy matching venue to appropriately reflect this change.

[0108] The strategy mapping rules do not need to enable mapping to every available strategy. Certain strategies, for example, those with a benchmark rate exceeding 100%, may not be suitable for the expected set of algorithmic constraints for the algorithm orders received by the algorithmic trading platform. Such unused strategies may still be specified for the strategy orders placed in the strategy matching venue by other information sources.

[0109] In one embodiment, the HERO system 310 monitors the algo trading platform 320 to detect new algo orders and then generates corresponding strategy orders. In different embodiments, the algo trading platform 320 can also generate the corresponding strategy order at that time as part of the process to add the new algo order to the algo order table 120 and issue the strategy order to the HERO system 310.

[0110] Figures 7A and 7B are high-level flowcharts of the processing of algorithm orders by the operation and completion of the HERO system recognition algorithm order management 580. For simplicity, the functions generally address the processing of a single parent order. Various techniques for implementing functions in systems and methods for processing multiple independent orders are known to those skilled in the art.

[0111] Referring to Figure 7A, when a new algorithm order is received (step 702), the order is added to the algorithm order table 120 and also sent to the HERO system 310. If there is no stream-on condition (step 706), child slices are generated according to the specific algorithm in question and issued to the SOR 140 in a manner similar to the operation of the algorithm system 100 without the HERO system (steps 708-712). The potential share count for the algorithm order decreases. Also, data may be provided to the HERO system 315 (step 714) reflecting the change in the available potential shares for the algorithm order, which can affect the quantity available for strategy matching. The slice process continues until there are no potential shares left (step 716).

[0112] If there is a stream-on condition (step 706), the child slice process is interrupted and the algorithm order management 580 waits for a stream-off condition to occur (step 722). In one embodiment, child orders that have already been issued but not fulfilled can remain open and will eventually be fulfilled. In an alternative embodiment, when a stream-on message is received, the algorithm order management 580 can cancel some or all of the unexecuted child orders (step 718). Successfully canceled child orders decrease the potential share count and increase the share count available for strategy matching. The HERO system is notified of the success (or failure) of the cancellation and the associated change in the potential share count (step 720).

[0113] Figure 7B is a high-level function of the monitoring process thread that processes the implementation notice. When an implementation notice is received from the algorithm trading platform SOR or the HERO system 130 (step 724), the appropriate value for the corresponding order in the working algorithm order table 120 is updated (step 726). When a cancel order request is received from the HERO system 130 (step 728), the unprocessed child orders for the related algorithm order are canceled (step 730), and a cancel completion instruction is provided to, for example, the HERO system 130 (step 732). When all shares for an algorithm order are filled, or an order end condition occurs and the order is canceled (step 734), the processing of the order is completed.

[0114] Figures 8A - 8C are high-level flowcharts of the operation of one embodiment of the HERO system in processing orders. For simplicity, the functions generally target the processing of a single order, and the functions are shown as separate program engine threads A - E. The use of program threads implemented independently is not necessary, and the functions of one or more threads can be combined. Various techniques for implementing these functions in a system and method for processing multiple independent orders will be known to those skilled in the art.

[0115] Thread A801 processes a new algorithm order. A new algorithm order can be detected via a message sent by the algorithm order management 580, or via monitoring by the HERO system 310 of the algorithm order table 120, or via other data of the algorithm trading platform, etc. If a minimum order size for strategy order processing is defined, the new algorithm order size is checked (step 802). If the algorithm order is larger than a predetermined minimum size, the strategy of the algorithm order is determined using the related strategy mapping rules. A new strategy order record with the related strategy order data is added to the strategy order table (steps 804, 806).

[0116] Thread B811 determines when to issue the strategy order of the strategy order table 415 to the strategy matching venue. It is determined whether there is an available strategy order that is not on hold in the strategy matching venue, and optionally, whether other conditions are met if defined (step 812). If a strategy order is available, an appropriate strategy order is issued to the strategy matching venue via, for example, strategy SOR510 (step 814). Preferably, the HERO system 315 maintains a minimum buffer size and sends a strategy order to the strategy matching venue only when the potential share number for the strategy order exceeds the minimum buffer value. If a minimum order size is specified, a strategy order below the minimum size is no longer considered eligible.

[0117] Thread C815 provides an order update function. When a message regarding an update to an existing algo order, such as a message indicating that a portion of an algo order with a corresponding strategy order has been fulfilled, is received from algo order management 580 (or other aspects of the algo trading platform 320), the appropriate record in the strategy order table 415 for the corresponding strategy order is updated. The updated information can change the strategy selected for the corresponding strategy order as defined by the relevant strategy mapping rules 420. In such a case, the strategy specified in the strategy order table 415 is updated accordingly. If the strategy order in question is unprocessed in the strategy matching view 315, the message can also be sent to the strategy matching view to update the strategy of that order (step 818). When a data message reflecting a streaming implementation is received from the strategy matching view 315, the data in the strategy order table regarding the relevant strategy order is updated as needed. Execution data including at least an order indicator and the fulfilled amount (e.g., number of shares) is also sent to the algo order management 580 (step 822).

[0118] Thread D823 processes stream on and stream off signals. When a stream on condition message is received from the strategy matching view 315 (step 824), the stream on condition for each order is sent to the algo order management 580 (step 826). Depending on the implementation details, a signal can also be sent to instruct the algo order management 580 to cancel the unprocessed child orders of the corresponding algo order, and as a result, the potential fills from those unprocessed child orders can be made available for strategy matching (step 828). When a stream off message is received from the strategy matching view 315 (step 830), the stream off for each order is sent to the algo order management 580 (step 832). Depending on the implementation details, the stream off signal may itself be handled by the algo order management 580 as an instruction to resume a slice of new child orders for the corresponding algo order, or an additional signal may be sent to explicitly instruct the algo order management 580 to resume a slice of new child orders, thus enabling the HERO system to handle trading scenarios where a stream off for a given strategy order is received but the conditions do not guarantee resuming a slice of new child orders at that time.

[0119] Thread E833 monitors the potential shares available for a given strategy order. If a change in the available potential shares is detected as a result of a child order for the corresponding algo order being filled (step 834), the number of shares available for the strategy order for strategy matching is determined (step 836). If that number is less than a predetermined minimum number of shares for strategy matching (step 838), the strategy order can be cancelled and removed from the strategy order table 415 (step 842). If the related strategy order is unprocessed in the strategy matching view 315, a message with the updated quantity available for the strategy order can be sent to the strategy matching view 315.

[0120] Thread F843 is for processing conditional strategy orders. The conditional strategy orders issued to the strategy matching venue 315 by the HERO system 310 can include or omit the total number of shares available for the order. When the strategy matching venue detects a match, it can issue a request to the HERO system to finalize the conditional strategy order and provide a quantity value. When a finalization request for the strategy order is received (step 844), the algo order management 580 is instructed to cancel some or all of the outstanding child orders for the corresponding algo order (step 846). In response to the finalization request, after the algo order child order cancellation process is completed, the HERO system determines the available number of shares available for strategy matching based on the potential number of shares, buffer size, and other factors at that time (step 848) and can send a finalization response message to the strategy matching venue 315 (step 850). The finalization response can be in the form of, for example, an unconditional strategy order or a message. The unconditional strategy order replaces the conditional strategy, and the message instructs the strategy matching venue 315 to update the conditional strategy order aspect to unconditional and appropriately change other aspects such as the available number of shares. The strategy matching venue 315 can keep the strategy matching open until the order is finalized. If this does not occur within a specified period, such as a timeout defined in the strategy matching venue, the match is dropped. After the order is finalized, the strategy matching venue issues a stream on condition message.

[0121] Figures 9A and 9B show a sample parent algo order process and the corresponding strategy order process for selling 100,000 shares by the HERO perception algo trading platform 320 and the HERO system 310, which operate in parallel and show the propagation directions of various order-related data values between systems as the process progresses. In this example, the HERO system 310 is configured to maintain a buffer of 15K potential shares.

[0122] At time T0, before any action is taken, all 100K shares of the parent order are potential. At T1, the first 5K of the child order is sliced by the algo order management and issued to the SOR140, and the SOR is subdivided into grandchild orders issued to the trading venue 150. The number of potential shares is reduced to 95K. The parent order has 80K potential shares available for strategy matching (95K potential shares - 15k buffer value). The 80K strategy order is issued to the strategy matching venue.

[0123] At time T2, there are 5K shares for the algo child order. 2K of algo order execution is received, reducing the unprocessed value to 3K. Next, 2K of the child order is sliced and issued to the SOR140, returning the total number of issued algo child order shares to 5K and the number of potential shares to 93K. Thus, the number of shares available for strategy matching is reduced to 78K, and a strategy order update indicating the changed amount is issued to the strategy matching venue. Time T3 shows the result of a 5K algo order fill followed by a slice of 5K of the child order, a reduction in the number of potential shares, and a subsequent update of the strategy order from 78K to 73K.

[0124] At time T4, the strategy matching venue detects a match for the strategy order and the stream on condition exists. When the strategy matching venue stream is filled, information regarding the fill number is returned. In this example, a streaming fill of 30K (which may be reflected in a sequence of smaller fills) is shown. The potential share number is reduced by 30K. There is also a child order of 5K on the algo side.

[0125] At time T5, the algo system receives an execution message indicating that 4K of the outstanding 5K of the child order has been filled. The issued share number of the algo child order is currently 1K. Since the child order has already been considered, the potential share number does not change. Due to the stream on state, the issuance of new child orders by the algo trading platform 320 is paused.

[0126] At time T6, an additional streaming fill of 43K of the outstanding orders is shown and the potential share number is reduced to 15K. The total number of streamed strategy matching fills has reached 73K, which is the current size of the strategy order. The strategy matching venue closes the order and indicates a stream off condition.

[0127] Upon receiving the stream off condition, the algo trading platform 320 resumes the remaining algorithmic processing of the order. Child slices are issued and filled from time T7 to T10 when the parent order is fully filled.

[0128] Figures 10A and 10B show the processing of a sample parent algo order and corresponding strategy orders for selling 100,000 shares by the HERO recognition algo trading platform 320 and the HERO system 310, which operate in parallel and show the propagation directions of various order-related data values between systems as the process progresses. The example in Figure 10 is similar to the examples in Figures 9A - B, but instead of causing the unprocessed child orders to be filled, an algo trading platform 320 configured to cancel the unprocessed child orders in response to receiving a stream on indicator from the HERO system is used.

[0129] The operation of the system from time T0 to T3 is the same as in Figures 9A - 9B. At time T4, in response to the stream on condition, the algo trading platform 320 cancels 5K of the unprocessed child orders. The potential number of shares increases by 5K. Since more shares are now available for strategy streaming, the strategy order is updated from 73K to 78K. The remainder of the order processing continues in a similar manner to that in Figures 9A - 9B.

[0130] In some situations, the benefits provided by strategy order processing in the strategy matching venue may be desired, but a HERO system-compatible platform may not be available to brokers / dealers for receiving such orders. In a further aspect of the invention, a Pre / Post Routing Optimizer ("PRO") system can be provided for use with an OMS / EMS system that can also send orders to a conventional algo system 100. The PRO system receives initial orders at a higher level than a non-HERO algo platform 100, such as directly from a client OMS / EMS 110. The PRO system then generates the corresponding strategy orders and processes the orders in a manner similar to the HERO system by sending them to the strategy matching venue. Also, the OMS / EMS can send the original order to a conventional broker / dealer that processes it in its own algo system.

[0131] Since the PRO system is not coupled to the broker / dealer's algo system 100, the PRO system cannot tell the algo system 100 to start or stop the algorithmic processing of an algo order when a matching for the corresponding strategy order is found, as indicated by a stream on condition message. To compensate for this, the issued strategy orders are conditional. When the strategy matching view indicates that strategy matching is available for a strategy order, e.g., by sending a firm request, the PRO system can signal that the order placed in the broker / dealer's algo system should be cancelled and then the corresponding strategy order should be affirmed. After the strategy matching view indicates that strategy matching has ended, e.g., by a stream off condition message or an indication that the affirmation was not successful, the PRO system can inform that a new order will be sent from the OMS / EMS 1100 to the broker / dealer's algo system 100 for any remainder of the original order. Information is exchanged between various platform components as the algo order and strategy order are processed to track the progress of order execution and ensure that order execution does not exceed the total order size.

[0132] FIG. 11 is a high-level block diagram of the system architecture of one embodiment of a trading platform having an order management and execution management system (OMS / EMS) 1100 with a PRO system engine 1110 coupled to a trading order management 1115. The OMS / EMS 1100 can receive orders issued by portfolio management 1120 via a trading desk 1125. The OMS / EMS 1100 communicates with a broker / dealer that uses a conventional algorithmic trading system 100 that issues orders to a conventional exchange venue 150. In the conventional exchange venue 150, orders are filled against matching contra-orders issued by other conventional brokers / dealers and other market participants such as HFT firms. The OMS / EMS 1100 also communicates with one or more strategy matching venues 315 that can issue strategy orders from the PRO system, and these strategy orders can be generated based on the initial orders. If multiple strategy matching venues 315 are available, the PRO system can be configured to select an appropriate strategy matching venue as desired. The strategy matching venue used can be predefined or can be dynamically selected based on various factors such as the type of security or other details about the order. The strategy matching venue 315 can also receive strategy orders from other HERO system-compatible brokers / dealers 300, other PRO systems operating in conjunction with other OMS / EMS systems 1100', and any other suitable order sources.

[0133] FIGS. 12A and 12B are high-level diagrams showing the functional aspects of one embodiment of the PRO system 1110, as well as the communication between (i) the PRO system engine 1100 and the strategy matching venue 315, and (ii) the PRO system and the PRO system-aware trading order management 1115 in the OMS / EMS system 1100. The internal functions of the PRO system 310 and the embodiments of the inter-system communication will be discussed in more detail with respect to the flowcharts of FIGS. 13A and 13B.

[0134] The trading order management 1115 communicates with one or more brokers / dealers using the broker-dealer interface 1120 and using the conventional as well as the HERO system compliant algorithm trading engine 100. Messages that can be sent and received include issuing a new algorithm order 1125 to the broker / dealer's algo trading platform 100, receiving messages related to the execution 1130 of the placed algo order 1125, and issuing a request 1135 for the algo trading platform 100 to cancel or appropriately modify an existing order. The OMS / EMS work order table 1105 is used for the OMS / EMS 1100 to track unprocessed orders.

[0135] PRO 1110 includes a strategy order management 1140, a strategy SOR 1145, and a strategy order table 1150 for maintaining data regarding the current strategy order. In an embodiment where one or more of the algo trading platforms available to the OMS / EMS 1100 are HERO system capable, the OMS / EMS can indicate whether an order has been sent to such an algo trading platform, and the PRO system is configured to act only on algo orders sent to non-HERO recognized algo trading platforms.

[0136] From the perspective of the strategy matching view 315, the PRO system 1110 and the HERO system 310 can appear the same and can have the same type of message exchange. Similar to the HERO system 310, the PRO system 1110 and the strategy matching view 315 exchange messages related to strategy orders including placing new conditional or unconditional strategy orders, receiving stream on and stream off condition messages, receiving strategy order execution data, and confirming conditional orders.

[0137] Strategy SOR1145 operates to route communications regarding strategy orders between strategy order management 1140 and one or more strategy matching venues 315, and can also include the function of selecting an appropriate strategy matching venue when two or more are available. Strategy SOR1145 is shown separately from strategy order management 1140, but the functions may be combined in an integrated software program. Similarly, the functions of strategy order management 1140 may be implemented in multiple software components.

[0138] Orders received by OMS / EMS1100 may be conventional orders intended to be processed by a conventional algorithmic trading system, with or without a specified trading strategy. If no strategy is specified, corresponding strategy orders can be generated via a set of strategy mapping rules 155 in the same way as described above for the HERO system. This function can be implemented in the PRO system.

[0139] During operation, messages regarding new strategy orders and strategy order updates, as well as remaining quantity updates for existing algo orders, can be sent from OMS / EMS1100 to PRO system 1110. Messages related to stream ON and stream OFF conditions and strategy order streaming implementation can be sent from PRO system 1110 to OMS / EMS1100. Additionally, messages related to the cancellation or re-routing of algo orders and strategy orders can be exchanged between PRO system 1110 and OMS / EMS1100.

[0140] The implementation of the PRO system 1110 can be provided in a conventional computing system that operates independently of the computer system used to implement the OMS / EMS 1100. Referring to FIG. 12B, in one embodiment, the PRO system hardware can be similar to the hardware of the independently implemented HERO system, but is connected to the OMS / EMS 1100 instead of the broker / dealer's algo trading platform 320. One or more computer processors 1160 implement computer software stored in the program memory 1165. The processor 1160 accesses a data memory 1170 that includes one or more data repositories such as a strategy order table 1150, one or more pairs of strategy mapping rules 1155 used to generate strategy orders based on algorithmic orders, and other operational data 1175.

[0141] A suitable communication interface 1180 is used to connect the PRO system 1110 to an external system. In the illustrated embodiment, a local area network provides communication between the PRO system 1110 and the OMS / EMS 1100, and another WAN provides communication between the HERO system 310 and one or more strategy matching venues 315.

[0142] The computer platform used to implement the HERO system can be one or more high-speed computers having sufficient data throughput and processing power to support the expected transaction volume. The LAN and WAN networks can be high-speed fiber optic data networks or other network systems conventionally used in financial trading networks. Suitable computer platforms are known to those skilled in the art.

[0143] The program memory 1165 and the data memory 1170 may be implemented in whole or in part within the same or different components. The memories 1156, 1170 can include one or more internal RAMs and firmware, local electronic data storage devices such as solid or magnetic drives, and external data storage devices provided by memories physically coupled via other data cables accessible via USB or network. Other computer-readable media for storing software and data can also be used. The PRO system 1110 can be implemented within one or more computer servers, personal computers, or other computer systems.

[0144] To enable a computing device 1190 such as a PC to access the PRO system 1110, another user interface 1185 can be provided, which allows authorized users to perform various administrative functions such as monitoring system performance metrics, viewing order maps and transaction histories, and adjusting system configurations. The remote device 1190 can be locally connected to the PRO system or connected via a network such as an intranet or a secure VPN on the Internet to provide remote monitoring.

[0145] The PRO system 1110 can be implemented as an internal computer system within the OMS / EMS broker-dealer system 1100, and may perhaps be implemented on the same physical computer as the trade order management 1115, in which case no additional network connection between the PRO system 1110 and other components within the OMS / EMS 1100 may be required. The OMS / EMS can be designed or modified to have appropriate APIs or other program hooks, and internal controls are required to operate with the PRO system whether the PRO system is initially unavailable or is available but implemented as a separate system. Next, a PRO system module with an API interface suitable for communication with the EMS / OMS can be separately added. There are various ways to implement the PRO system 1110 and integrate it with the EMS / OMS system 1100.

[0146] Figures 13A and 13B are high-level flowcharts showing modes of operation of an embodiment of the PRO system engine in a processing order. For simplicity, the functions generally target the processing of a single order. Various techniques for implementing these functions in systems and methods for processing multiple independent orders will be known to those skilled in the art.

[0147] Referring to FIGS. 13A and 13B, when a new algo order is received from the OMS / EMS 100 (step 1305), a corresponding strategy order is generated (after applying appropriate strategy mapping rules if necessary) and added to the strategy order table 1150. If the strategy order quantity exceeds a minimum value, and if specified, for the strategy matching to be used (step 1312), the corresponding strategy order is issued as a conditional order to the strategy matching venue 315 (step 1314). It is assumed that the initially received order exceeds the minimum value, although this may not be guaranteed.

[0148] When an algo order is processed, an execution update message is generated and sent to the PRO system. These executions affect the quantities available to the corresponding strategy order. In response to the receipt of such a message, the PRO system updates the available quantity reflected in the corresponding strategy order in the strategy order table 1150. The update message may also be sent to the relevant strategy matching venue. If the quantity available for a strategy order falls below the minimum value, the PRO system can send an order cancellation message to the relevant strategy matching venue 315 (step 1316).

[0149] After the issuance of a conditional strategy order, as long as the strategy order remains open, the PRO system will wait to receive a confirmation request from the strategy matching venue (step 1318). When the strategy matching venue 315 detects a potential match for the conditional strategy order, it sends a confirmation request to the PRO system. Upon receiving the confirmation request, the PRO system sends a message to the trading order management 1115 instructing it to cancel the corresponding algo order (if any) sent to the broker / dealer (step 1320). After the algo order is successfully cancelled, the trading order management 1115 sends a message confirming the success of the cancellation. The message can also indicate the maximum number of shares available for strategy matching, and the amount should be less than or equal to the total of the unexecuted portion of the original order. (PRO may also or instead be configured to issue a query to the OMS / EMS 1100 requesting information about a specific algo order, such as the number of shares filled.) After the cancellation confirmation and quantity data are received by the PRO system (step 1322), an appropriate confirmation message for the strategy order is sent to the strategy matching venue 315 (step 1324).

[0150] Even if a conditional order is confirmed, the conditions can change in the strategy matching venue 315 so that potential matching can no longer solidify. For example, the selected contrast strategy order may be conditional but not confirmed within the timeout period. If the PRO system does not receive a stream-on indicator for the order within the applicable timeout period (step 1326), the confirmed order is presumed not to be filled. The strategy matching venue 315 may be configured to send the issuer a notification of the confirmed conditional strategy order indicating that the matching has failed. Receiving such a message by the PRO system can be treated the same as a timeout condition while waiting for a stream-on message. (A similar function can be implemented in the HERO system.)

[0151] After the timeout (step 1326), the OMS / EMS is notified that it can reissue the algo order (cancelled considering the confirmation request from the strategy matching venue 315) to the appropriate broker / dealer. The PRO system can also send a message to the strategy matching venue 315 explicitly cancelling the previously confirmed order. The strategy order remains on hold in the PRO system. If the quantity available for the order exceeds the minimum value (step 1312), another conditional order can be issued and the process can continue.

[0152] When strategy order matching occurs in the strategy matching venue, the strategy matching venue can return the matching rate (which can only be a portion of the benchmark rate available for the specified strategy). In addition, or instead, the strategy matching venue can determine the total fill amount resulting from the matching, or at least the maximum amount of the resulting fill, based on the rate used for strategy matching and the maximum available amount of the order matched. If this information is available, it can be included as part of the stream on message. After the PRO system has finalized a conditional strategy order and timely receives a stream on, and the stream on message indicates the fill amount expected from that matching or provides data from which that information can be derived, the PRO system can calculate the amount of the strategy order remaining after strategy matching streaming is complete. If the strategy matching does not fulfill the maximum amount available for the strategy order in question, the effort to fulfill the remaining algo side orders can proceed without competing with the strategy order fill. In such a case, the PRO system can notify the OMS / EMS to issue an algo order that determines the difference between the maximum amount available for the strategy order and the actual or maximum amount expected to be filled in the strategy matching venue (steps 1330, 1332).

[0153] Subsequently, after the stream on, an execution message for the strategy order is received in the PRO system from the strategy matching venue (step 1334). The execution data is sent by the PRO system to the OMS / EMS (step 1336), and this data can be used to update its internal records to reflect the fills that occurred. This continues until a stream off message for the strategy order is received (step 1338). Next, the OMS / EMS is instructed to reissue the cancelled algo orders to the broker / dealer to determine the remaining unfilled order amount. (step 1340).

[0154] Figures 14A and 14B show a high-level functional block diagram of a particular embodiment of a strategy matching venue 1400 for processing strategy orders for tradable items such as securities. The strategy matching venue 1400 is connected to an order placement and routing platform 1410 that can include a strategy SOR, a legacy SOR, and any other source of suitable orders such as directly placed strategy orders originating from, for example, a brokerage gateway, as used in a HERO system or a PRO system. Communication with the order router 1410 can be supported via a suitable network connection. In one embodiment, messages are exchanged using the FIX protocol. Strategy order-related messages, stream on and off condition messages, confirmation commands, and other communications can be sent through this interface. Minor extensions to the FIX protocol may be required to support features such as stream on / off messages and new strategy order types, such as defining new FIX message values.

[0155] The Strategy Matching Venue 1400 includes a software engine intended to process strategy orders. In one embodiment, the Strategy Matching Venue 1400 is configured to also process non-strategy orders. Received non-strategy orders can be sent to a Strategy Order Generator Engine 1430 that converts the non-strategy orders into strategy orders. A set of one or more default strategies 1435 is provided and can be selected according to a set of predetermined rules. Strategy selection can depend on the non-strategy order and / or the content of its source or other data. One broker / dealer can define a liquidity search as the default strategy for any non-strategy order it sends while different brokers / dealers request different strategies. It is also possible to use a more complex system within the HERO System 315 to select strategies as described above. Strategy order conversion is shown as part of the Strategy Matching Venue 1400, but a Strategy Selection Engine that uses a predetermined strategy mapping rule can be implemented separately from the Strategy Matching Venue 1400.

[0156] The Strategy Matching Venue 1400 receives market data such as bid / ask quotes and trades from an appropriate Security Information Processor (SIP) 1415, etc. Two or more data sources can be available for use within the Strategy Matching Venue 1400 from alternative market (or non-market) data sources 1425, etc. Strategy order execution data is output from the Strategy Matching Venue 1400 and can be returned to the SIP 1415 in a conventional manner, such as via a Trade Reporting Facility (TRF) 1420. The execution report is returned to an appropriate order router 1410 via an I / O handler 1405. Different mechanisms for reporting execution to the market can be utilized depending on the tradable item in question.

[0157] The strategy matching function in the strategy matching venue 1400 is implemented in software that can be organized as a set of software engines. The I / O handler 1405 processes input and output messages and updates data records related to incoming orders. The SIP handler 1445 receives input market and other data, and sends the first market data that can be the NBBO price to the price handler 1450, and sends the second market data that can be an individual market execution notice for the item being traded to the trading handler 1455, etc., to send relevant data to the appropriate internal engine. In one embodiment, the price handler 1450 examines the input data and determines whether the pending strategy order is marketable and thus actionable. The trading handler 1455 processes input SIP data related to market transactions, such as the quantity of the security being traded, so that the information is available for use by the trading processor 1465. The matching engine 1460 identifies eligible matches from among the pending strategy orders. The trading processor 1465 is a streaming engine that generates trades for the matched strategy orders.

[0158] Referring to FIG. 14B, the strategy matching venue 1400 can be implemented on a computer system such as a suitable server connected to one or more processors 1470 and a storage device 1440, which can include an internal RAM and firmware, a local electronic data storage device such as a solid state or magnetic drive, and an external data storage device provided by a memory physically coupled via a USB or other data cable accessible through a network. The program memory 1472 is used to store the operational computer software implemented by the processor. The data memory 1474 is used to store various operational data books / tables, buffers, rules, and other short-term and long-term storage data used during the operation of the system. A suitable interface is provided for communicating with external systems. For example, the order interface module 1480 can be used to communicate with various order routers or other order sources 1410 via the order network 1482. The market data interface module 1484 can be used to access various sources of market data 1415, 1425 via the market data network 1486 and retrieve market data used during order processing. The trade reporting interface module 1488 can be used to provide execution information to the trade reporting facility 1420 via a suitable reporting network 1490.

[0159] The physical computer processors and overall computer platform used for the strategy matching venue 1400 can be one or more high-speed computers having sufficient processing capacity, data throughput, and network bandwidth to support the expected transaction volume. Suitable computer platforms are known to those skilled in the art. Although three networks 1482, 1486, 1490 are shown separately, one or more of them may be the same network. For example, the three networks 1482, 1486, 1490 can all be a common high-speed data network that supports data communication between devices using, for example, the FIX protocol.

[0160] Figure 15 shows some of the various types of information stored within the strategy matching venue 1400 and used during the processing of strategy orders. One particular arrangement of the data structure is shown. Not all of the illustrated data fields are required or used in any particular embodiment, and additional data may also be stored. Other methods known to those skilled in the art may be used to organize the data used by the strategy matching venue, and the specific names used for reference purposes may be changed. Various data tables and objects may be stored in the memory storage area 1440, which may be composed of various types of storage devices such as local RAM, solid state drives, cloud storage devices, etc.

[0161] In the data arrangement of Figure 15, three primary data arrays (data tables, database objects, or otherwise organized and referenced within the storage device) are provided and appropriately stored within the memory 1440 of the strategy matching venue 1400.

[0162] All orders 1502 are used to store information regarding the active strategy order placed in the strategy matching venue 1400. Each order record has a unique order ID and stores strategy order information having a symbol, side, and bid / ask price. A conditional flag indicates whether the order is conditional. The order quantity specifies the number of shares (or other tradable items) in the order available for strategy matching. The strategy type field stores the strategy used for that order. Over time, the available share quantity changes as the strategy order is processed or updated.

[0163] Additional fields can be provided to store the original order quantity, the quantity already executed, and the remaining quantity available for subsequent strategy matching. Not all of these quantity fields are required, and some data attributes may be easily computable from other data related to the order. However, providing these fields can simplify later processing.

[0164] The marketability flag indicates whether the market conditions related to the order are such that the order is marketable. For example, if the order is to purchase a security, and the current trading price of that security is greater than the order's limit price, the order is not marketable. Other marketability factors may also be identified and considered in relation to the order. The fact that an order is marketable does not mean that there is a counterorder available for matching at that time.

[0165] A stream is an array of data within the entire order book and is used to indicate the stream or streams (if any) to which each order pertains. A large order may be matched, for example, to two smaller orders that result in two trading streams.

[0166] The available capacity in a particular order record indicates the available rate for each order that can be applied to subsequent matching with counterorders.

[0167] Orders can be defined such that the strategies applied to them can be dynamically changed in response to changes in market conditions for conditional alternative strategies. In certain embodiments, the order provides a way to specify that the strategy should be changed when an attribute of the order, such as a limit price, exceeds a specified limit for the current market price of the security in question. For example, a 5 - 15% strategic buy order can have a normal limit price of $15.75 and a limit price of $15.65. If the offering price of the security exceeds the limit price, the offering is non - marketable. If the current offering is between the two values, the order is marketable and a 5 - 15% strategy is used. If the offering price is below the limit price, the order strategy can be changed to a different strategy, such as a liquidity search, or a user - specified second strategy for the order. If a limit price is provided but no second strategy is specified, a default strategy, such as a liquidity search, can be used. The strategy adjustment can be made when the order is examined to determine whether it is marketable. A flag can be provided to indicate whether this feature is enabled for a given order. Alternatively, the limit price can be set to zero by default, and a non - zero value indicates that the feature is available. This or similar conditional strategy features can be implemented as an alternative to the implementation in the strategy matching venue 1400, in the HERO or PRO systems, or for example in a first conditional strategy change process implemented in the HERO or PRO systems and in a second conditional strategy process implemented within the strategy matching venue 1400.

[0168] The criteria for selecting an appropriate secondary strategy may be the same as the strategy mapping rules used to initially select a strategy, such as the strategy mapping rules used by the HERO system, the PRO system, or may be different, conditional strategy mapping rules, or may be included in the strategy matching venue 1400 for processing received non-strategy orders. As an example, an algo purchase order can be mapped to Strategy C. If dynamic strategy selection is available and can be used, the second strategy can be selected to be Strategy B with the next highest priority and a transition threshold set at a limit price lower than that specified in the order, such as 0.5% or 1% lower. This information can also, or alternatively, be specified within an appropriate set of mapping rules.

[0169] Instead of, or in addition to, including a second strategy within the strategy order itself, the issuer of the strategy order, such as the HERO system or the PRO system, can monitor market conditions and detect when a strategy shift for a particular order may be required. In response, an existing strategy order can be cancelled and replaced with an alternative order with a new strategy. Alternatively, an order update message can be sent to the strategy matching venue specifying the new strategy, and in response, the strategy matching venue can, accordingly, update its internal record for that order and, as appropriate, interrupt or change an existing match.

[0170] All order tables 1502 can also store information about strategy orders that are no longer active, such as completed orders or canceled orders, for at least a limited period. The order status attribute can specify the order status. For example, "active", "canceled", "completed". All orders over a given period can be retained in the table. At the end of the trading period, all canceled or completed orders can be stored in the transaction history table, and the remaining active orders existing at the end of the trading session can be automatically canceled.

[0171] The arrival time can be used to store a timestamp indicating when each order was received at the strategy matching venue 1400.

[0172] The active stream 1504 is used to store information regarding currently active order matching. Each record in the active stream can include data associating the first order with one or more contra-orders currently being matched. To enable easy lookups for matching of buy or sell orders, the table or data structure is double-indexed, once for buy orders and once for sell orders. Additional data can also be indexed. For example, the matched orders can be indexed by security at the time of issue to facilitate identification of active matching for a given security. In a particular embodiment, each entry associates the first order with one matched contra-order. If the first order is matched with multiple contra-orders simultaneously, there are multiple entries for the first order. A status field can also be included to indicate whether the stream is active (unbroken) or has ended. Information regarding ended streams can be retained within the active stream for a period and / or archived, for example, for historical analysis and auditing purposes.

[0173] The unprocessed reference transaction table 1506 is used to temporarily store market transactions from the transaction handler 1455 that have not yet been processed by the transaction processor streaming engine 1465. When the trade processor processes a market transaction from this table, it can remove it from the table and archive it.

[0174] Figures 16A - 16 D are, respectively, high - level flowcharts of the basic functions provided by the embodiments of the I / O handler 1405, the transaction handler 1455, and the market handler 1450.

[0175] Referring to FIG. 16A, when an input order message is received by the I / O handler 1405 (step 1602), it is checked to see if a strategy is specified (step 1604). If no strategy exists, one is selected, for example, by using the strategy order generator engine 1430 (steps 1606, 1608). In the case of a received message that includes an update to a new or existing order, the all - order table 1502 is updated, as necessary, to add the new order or changed data stored for the existing order (steps 1602, 1604, 1610). When the I / O handler receives an output message for the client, such as a stream on / off condition message, an execution message, or a confirmation request (step 1612), the message is formatted as necessary and then sent to the specified recipient, for example, via the FIX interface.

[0176] ​Referring to FIG. 16B, the transaction handler 1455 is used as an intermediary for the transaction data used by the transaction processor 1465 when determining the streaming execution volume and / or timing. If other types of market data or non-market data are required by the transaction processor 1465, it can also serve as an intermediary for that data. When a SIP update such as market transaction data is received by the transaction handler 1455 (step 1616), a check is made to determine whether the transaction processor 1645 is busy (step 1620). If it is not busy, the SIP update is sent to the transaction processor (step 1622). If the transaction processor 1645 is busy, the SIP update is added to the unprocessed reference transaction buffer 1506 (step 1624).

[0177] In the embodiment of FIG. 16C, the exchange handler 1450 processes stock market data to determine the marketability of orders for the securities in the full order book 1502. For example, when a new exchange price for security X is received from an NBBO security feed or other source, the orders in the full order book for that security are examined to compare the best available ask / bid price of the received exchange price with the limit price of each order. (Steps 1628, 1630) Next, a determination is made as to whether the order is marketable and about the marketability flag for the appropriately set order considering the current exchange price (step 1632). This process is repeated until all relevant orders are checked.

[0178] If a strategy order that is part of an active stream is switched from a marketable one to a non-marketable one, the order is no longer eligible for matching. When a transition from a marketable one to a non-marketable one occurs, the market handler 1450 can check the active stream data for that order. If the order participates in one or more streams, a notification can be issued to break the matching of that order and stop the transaction. (Step 1636). The order may be non-marketable for a short temporary period and then quickly regain marketability, so the matching is temporarily saved (but not operated for implementation purposes), and the matching can only be broken if the order is non-marketable for longer than a specified period.

[0179] In an alternative embodiment, the marketability of an order for a tradable item may be defined by a marketability function specified based on first market data, which may include market bid / ask values or other information. FIG. 16D is a high-level flowchart for such a more general implementation of the market handler 1450. The market handler 1450 receives data related to the marketability of one or more orders, which can be received from one or more sources (Step 1626’). For each order in the entire order book whose marketability depends on the newly received data, the marketability function for that order is applied, and accordingly, a marketability flag is set (Steps 1628’ - 1634’). If an order transitions from a marketable one to a non-marketable one, a notification can also be sent to break the existing matching (Step 1636’).

[0180] Enabling the use of common marketability features in an automated trading system provides traders with additional flexibility to control whether additional orders are executed. Marketability features are likely to rely on bid / ask data for the tradable item in question, but alternatively, marketability features based on additional data and / or alternative data can be used. This can be appropriate to support trading of non-traditional tradable items and / or as an additional way to conditionally change trading strategies. In certain embodiments, the function of setting the marketability flag of an order (thus preventing new matching) may be different from the marketability function applied when determining to break an existing match. The match-breaking marketability function can be state-based (as opposed to stateless) and can be based on previous activity or the lack thereof. For example, the system can track how long or how much has been traded or how much the price has moved while no execution has occurred when determining whether to break an existing match.

[0181] Additions to the FIX protocol may be required to enable additional marketability conditions to be specified or to enable alternative channels to be used to provide that data (and possibly the entire order data) depending on the overall trading environment in which the strategy matching venue 1400 is operating.

[0182] FIG. 17 is a high-level flowchart of an embodiment of a matching engine 1460 implementing a strategy matching process. The matching process may be performed continuously, periodically, or intermittently.

[0183] When the matching process is started, for example, from the entire order book, Strategy Order A to be worked on is selected. The selected Strategy Order A must be marketable and have available capacity to support matching (e.g., be tradable) (step 1702). There may be multiple orders for a given security and side that meet these criteria for selecting Strategy Order A. Various methods can be used when ranking the selection orders. The orders can be ranked by order size, marketability, cost, or other factors, or a combination of two or more factors. Different ranking selections can be provided for orders from different sources. A priority field can be provided within the order to enable the order issuer to specify the selection priority factors among orders from at least the same first trader. Large orders exceeding a threshold size, such as 100,000 shares, can be given a higher priority than smaller orders and can then be further prioritized, for example, according to when they were placed. Various other factors can also be used, such as whether the order is new, or the order has previously been matched but is not currently being matched, and whether the order is an active match.

[0184] The matching process can also filter the order by degree for consideration using other criteria. In one embodiment, the input order can indicate a selection for a broker or other source identifier or a particular subset of order characteristics. All orders can be stored in a common full order book, but another instance of the order matching process can be applied, and each instance considers orders placed only by the specified source. Orders from different sources can be prioritized using different methodologies, which can be selected from a predetermined set of provided methodologies or ranking functions, such as when an account with a strategy matching view is established. Indexing of available liquidity and factorization of other dimensions advantageously enable a uniquely customized order priority book and liquidity search.

[0185] After a tradable strategy order A is selected to function, the full order book is searched to identify a strategy order B for the same security of A that is on the opposite side, is tradable, and has a strategy type compatible with the strategy type of strategy order A (step 1704). Often, there may be multiple potential contra orders B available for selection. Various prioritization schemes can be implemented to select a particular order B. As described above, different priorities can be given to the strategy types. If multiple potential contra order matchings are available, they can be ranked based on the priority of the strategy type, with higher priority strategies (such as those providing greater liquidity) coming first. Referring to FIG. 19, an order A with a strategy type of 10% - 30% is preferentially matched with an available order B having a strategy of seeking liquidity, and if there is no available order A for the 10% - 30% strategy and no available order B for the 5% - 15% strategy, it is preferentially matched.

[0186] If there are multiple possible contra-orders with the same highest strategy type priority, one or more additional prioritization methods can be implemented. Orders can be ranked by size and time. The orders to which the prioritization criteria apply can vary according to preferences or design choices. For example, orders can be prioritized first according to order size and then by strategy type, or vice versa. Other factors as described above regarding the selection of Order A can also be used. Different prioritization schemes are available and may be selected based on other predetermined criteria.

[0187] In certain embodiments, if multiple potential contra-order matchings with the same strategy are available, the matching engine can use a sequence of prioritization factors to select an order from that strategy bucket, and the sequence of prioritization factors can include, in order of highest to lowest priority, order target strategy, order attribute preference, dormant order placement institution, original order quantity of the order, order arrival time, and remaining order quantity (in the case of new orders and conditional orders only).

[0188] In a more specific embodiment, the matching engine can select a matching order from among the orders within the same strategy bucket according to one or more of the options listed below from highest priority to lowest priority: 1. Liquidity search selection: If one or more search selections are specified in the input order, those selections are prioritized. 2. Institution / Broker / Dealer: For matching, orders from the same institution or broker / dealer are given priority. The institution or broker / dealer can disable this option to avoid "self-crossing". 3. Desk: When an input order specifies a particular desk or broker, the order is paired so as to match only with orders that are compatible with the same desk and / or broker. For example, an approved broker list, or a particular broker IOI. 4. Original Order Size Bucket: Orders with an original order size larger than a threshold such as 25K are prioritized over smaller orders. 5. Arrival Time: Time priority is the final factor in determining a match. If two orders (e.g., 500K and 125K or 20K and 15K respectively) are in the same bucket, priority is given to the order that arrived earlier within the pair.

[0189] The prioritized selection of a contra order can continue as long as Order A has available capacity for additional contra matching.

[0190] Returning to Figure 17, if there is no available contra order B to match with the selected Order A and there are additional orders in the entire order book to be checked (step 1708), the next tradable Order A is selected using an appropriate prioritization method (step 1720), and the process continues until all relevant orders have been checked.

[0191] When a matching control order B is identified, the order is checked to see if it is conditional (step 1722). If the order is not conditional, the matching of order A and order B is stored in the active stream table (1726). Each of orders A and B has its respective rate capacity based on the selected strategy and other strategies that match it. For this matching, the maximum rate that can be satisfied is the smaller of the available rate capacities of A and B. The available capacities of orders A and B are decreased by this amount (step 1728). Thereafter, a stream on message can be sent as a trigger to the sources of orders A and B (step 1730). For liquidity search orders, the matching does not affect the rate. However, the matching can result in the maximum potential transaction quantity (such as the lesser of the total quantity available to order A and the total quantity available to order B). This amount can be used to determine at least the minimum amount for liquidity search orders that remain available for use in strategy matching with other contra orders. If both order A and order B have liquidity search strategies, the matching will result in a subsequent block trade being carried out for the lesser quantity of the total quantities available to order A and order B. The matching can be carried out at a determined price such as the midprice based on the current NBBO, and since neither order in the pair has rate constraints, there is no need to participate in the streaming execution process implemented in the transaction processor streaming engine 1465. Alternatively, LS-to-LS matching can be processed by the transaction processor streaming engine 1465 along with other matchings.

[0192] Advantageously, the matching logic maximizes the liquidity flow rate. If an order has the capacity to receive a higher rate (or the liquidity search order leaves an additional amount), it is more eligible for matching. A large-capacity order A can be matched simultaneously with a plurality of orders B, B', B'', etc. having smaller capacities, and the strategies of the orders B, B', B'', etc. in multiple matching situations do not have to be the same.

[0193] If a stream-on message of order A is sent following the matching with order B, and order A matches with a second order B' while the matching with order B is still active, there is no need to send an additional stream-on message. Similarly, a stream-off message for order A does not have to be sent until all active matchings with A are completed.

[0194] If additional information is included in the stream-on message, such as the expected rate of matching and the maximum quantity that can be filled during that matching, a stream-on message can be sent for each matching. The stream-off message can be sent optionally when the matching breaks, even if there are other matchings. The receiving HERO system or PRO system can independently track the stream-on and stream-off messages for a given strategic order, such as by referring to the matching ID included in the stream-on and stream-off messages.

[0195] If each received stream-on message for a strategy order can be paired with a subsequent stream-off message, there is no active matching for that strategy order. Alternatively, or further, a strategy matching venue can have two types of stream-off messages that differ, for example, by the value of a message matching remaining flag. The set value of the matching remaining flag indicates that there is at least one remaining discontinuous matching for each strategy order. If a stream-off message is received but there are still active strategies for that strategy order, the stream-off message may be considered not used by the receiving HERO system or PRO system to simply trigger, as information, a notification to the algo trading platform to resume algorithm processing, or a notification to the OMS / EMS to reissue the algo order (for any remaining amount).

[0196] Returning to FIG. 17, if one or both of the selected order A and the matching contra order B are conditional orders (step 1722), an order confirmation process is started for the conditional order (step 1732). As described above, this can involve sending a confirmation request for the conditional order and including switching the matched conditional order to an unconditional replacement order that has been confirmed. While waiting for the order to be confirmed, the process of searching for additional matches can continue (step 1708).

[0197] For each match or each conditional match, a respective match ID can be assigned. The confirmation request message can include the match ID value of the conditional match at the time of issuance, and the returned confirmed order response can include the associated match ID value. The presence of the match ID value in the order sent to the strategy matching venue can be used to determine whether the match is a confirmation of an existing conditional order or instead a confirmed unconditional order.

[0198] If one or more conditional orders are not confirmed within the specified timeout period (step 1736), the matching is released (step 1740). If both orders are conditional but only one is confirmed, a notification indicating that the conditional matching has failed can be sent to the source of the confirmed order. If the conditional order matching is successfully confirmed (step 1738), the process continues in the same way as for unconditional matching (step 1726).

[0199] The strategic order can also be provided with an "expiration period" specifier. If the expiration period is exceeded and the strategic order is still active, it can be cancelled and rolled back.

[0200] FIG. 18 is a high-level flowchart of an embodiment of the transaction processor 1465. The transaction processor 1465 operates based on market transaction data provided by the transaction handler 1455, and the transaction cycle can be started upon receipt of new transaction data or when the transaction data is buffered. When receiving transaction data for a given security X at a volume V (specifying the volume) and a price P (step 1802), a check is made to see if there is an active stream order for security X (step 1804). If not, no further action needs to be taken for that data point.

[0201] If there is one or more active streams, for example, if there is an active matching between order A and contra-order B for security X, those streams are processed (step 1804). For the selected stream, a check is made to determine whether price P is compatible with the limit values specified for the matched pairs of order A and order B within that stream (step 1806). If there is no compatibility in price, no additional action is taken for that stream (step 1808). If more streams are available (step 1810), the next active stream for security X is selected and processed (step 1812).

[0202] If price P is compatible with the limit values of the matched order pairs of one or more active streams (where order A can match order B and can also match order B', B'', etc.), the execution of that pair is generated (step 1816). In one embodiment, the execution is based on the quantity of security X and the maximum strategy base that conforms to the strategy of the matched orders. The streaming quantity is the product of the last trading volume V and the quantity strategy standard percentage, and is created at the last trading price. If the calculated streaming quantity exceeds the available base for one of the orders in the pair, the quantity to be exchanged is the lowest available base. If one of the orders has a liquidity search strategy, the highest available percentage of the capacity for the strategy of the other order is applied. If both orders in the pair are seeking liquidity, the block exchange can be made in an amount equal to the lowest available quantity capacity of the two orders (in the case of a match between two liquidity search orders, execution can be performed at the time of matching without waiting for the matched pair to be addressed in the trading processing loop).

[0203] Streaming exchanges may be conducted in a single transaction or divided into several smaller transactions. Additionally, multiple market transactions can be combined into a single strategic matching fill. The fill is implemented using conventional techniques, and the implementation data is reported, for example, to the appropriate trade reporting facility 1420.

[0204] In a more specific embodiment, for price reference streaming matching, the system can continuously process SIP trade feeds and generate a fill for each order in the matching as follows for all reference trades for the matched orders. 1. Calculate the Cross Qty based on the strategy of each order in the matching quantity and residual quantity (e.g., if both strategies are 100% - 200%, the cross quantity is the smaller of twice the quantity of the reference trade and the minimum of the remaining quantities on both sides of the matching). 2. Calculate the CrossPrice based on the reference trade price and applicable price setting rules. 3. Generate the implementation of crossQty@crossPrice for each order in the matching (reducing the remaining quantity for each order) and send a fixed implementation report to each order. 4. Generate a report to the TRF including all other relevant details (e.g., related MPID, risk - free principal, and other trade modification factors) and a clearing report to DTCC. 5. If this implementation completes an order (i.e., remaining quantity = 0), call the completed order function, as a result, a stream - off message is sent and other relevant housekeeping is performed. Orders with remaining quantity continue to be processed by the matching system for subsequent matching and filling.

[0205] Structural advantages inherent in implementation in the reference market, and universal segmentation applied in the strategic matching view protect investors, but to further protect against leakage of implementation information, protections such as anti-gaming features can be added. One way to do this is to introduce random factors into the transactions. These can include, for example, randomizing the matching rate when the stream is two-way, changing the stream rate intra-stream, randomly rounding up or down the stream volume when referring to odd lots, periodic bunching of reports, and randomizing trade reports.

[0206] Returning to Figure 18, after the exchange is completed, a determination is made as to whether one or both of the orders of the active stream pair have filled the available capacity (step 1820). If filled, no further trades are available for that pair and the matching is broken (step 1822). Order completion housekeeping tasks can also be performed, as a result of which the other streams of that order may end. If additional capacity remains, after receiving additional relevant trade data regarding the security in question, the matching continues and further exchanges can be made.

[0207] If an additional active stream of the paired orders is available for security X (step 1810), the next stream is selected and processed in the same way (step 1812). After all active streams for security X have been processed, no further action regarding these trades by the trade processor is required until another item of trade data for security X is received.

[0208] In summary, once a match is established, the execution stream flows from the seller to the buyer based on the match strategy type. The match establishment and break conditions are designed to minimize breaks to the established match. In one embodiment, the match / stream ends only if the match becomes non - marketable based on a marketability test to which one or both orders are applied, or if one or both orders are completed (e.g., the remaining quantity becomes zero, or one or both orders are cancelled). In embodiments that prioritize blocking trades over streaming fills, one of the matching orders is a liquidity search, and the match can also be broken if a new, larger liquidity search contra - side matching order arrives.

[0209] As described above, if one of the matches becomes non - marketable, the match can be broken. An order can lose marketability and regain marketability immediately. Instead of breaking the match immediately, the match can be interrupted, and the buffer period given before the match is interrupted can be interrupted to preserve the pairing. If the order regains marketability during the buffer period, the match is re - activated. Various conditions can be set to determine when to break the interrupted match.

[0210] In certain embodiments, one or more of the following conditions are implemented: (a) if the order remains non - marketable for longer than a specified timeout period, (b) if more than a specified market volume, such as 50K, is traded in the security of the matched orders before both of the matched orders regain marketability again, and (c) if the market price (e.g., as specified in NBBO market data) moves beyond a specified price delta at the base point and exceeds the limit price by a certain amount, the match is broken.

[0211] The strategy matching and streaming implementation method is flexible and can be applied to implement an asymmetric trading strategy. As shown in FIG. 16D, the marketability function of an order can be defined based on any desired data available in the strategy matching venue. This can provide more control when the orders actually match. Similarly, in addition to or instead of the current quantity of the security being exchanged, a special strategy with an execution quantity function can be defined based on factors. Thereby, the strategy matching venue can support trading of other tradable items A such as commodities or synthetic securities based on criteria other than simply the current price and quantity of commodity A.

[0212] As described above, various extensions to the FIX protocol can be made to support the features of the present invention. Similar features can be implemented with other protocols used for communication between various components of the present invention. For example, a series of additional FIX partitions can be defined to support strategy trading and related functions and management.

[0213] FIGS. 7A, 7B, 8A - C, 13A, and 13B are high - level flowcharts of the operation of embodiments of the HERO recognition algorithm trading platform 320, the HERO system 315, and the PRO system 1110, focusing on the functionality used to process a single parent order. Various ways of implementing this functionality to support the processing of multiple orders simultaneously will be known to those skilled in the art. The functions shown herein can be implemented continuously, periodically, or in response to software events or other signals. As in the prior art, various orders have unique order IDs, and appropriate order IDs are included in the messages transmitted between the system and software elements to associate those messages with their respective orders. Various other conventional bookkeeping and function management characteristics can also be used.

[0214] The various functions disclosed in the flowchart are shown as separate program threads. A multi-threaded program can be used, but it is not essential, and the software implementing such functions can be programmed in various ways, as is known to those skilled in the art. Similarly, certain functions disclosed as occurring sequentially may instead be implemented in another thread operating in parallel. For example, the transaction processor 1465 can cycle through the active associated streams when new transaction data is received. This type of sequential function can also be implemented in parallel threads, where each thread processes one or more active streams and / or each processing stream for different security in response to the receipt of transaction data for its security.

[0215] The system has been described as being applicable to a system and method for trading securities such as stocks, index stocks, etc., but the strategy matching system can also be applied to the processing or ordering of other tradable items by referring to the relevant market data of these tradable items. The first market data is used to determine whether a given strategy order is marketable, and the second market data is used to determine the timing and volume of streaming trades.

[0216] In a further embodiment, strategy matching can support matching with only partial rate matching. In such a case, there may still be additional fee capacity available for an order, even considering the matching stream provided by the strategy matching venue. In such a case, the algo processing system can be further controlled to slice the order using modified algorithmic constraints considering the strategy order rate matching, such that the algorithmic processing attempts to match the differential rate not covered by the strategy matching venue.

[0217] Various aspects, embodiments, and examples of the present invention have been disclosed and described herein. Those skilled in the art can make modifications, additions, and changes without departing from the spirit and scope of the present invention as defined in the appended claims.

Claims

1. A system for analyzing and processing an order of a tradable item received from an electronic trading network, wherein the system comprises a memory having stored computer instructions, and a processor connected to the memory for executing the computer instructions, the memory having a stored strategy order book, the strategy order book comprising records of a plurality of strategy orders for tradable items, each strategy order having each side, price limit, quantity, rate strategy, and source, the system being configured to receive a stream of market data for the item, the market data comprising an instance of trade data indicating reported third - party trades of the item for each trading volume and price, and an instance of bid and ask for the item including the best available bid and the best available ask, the computer instructions configuring the processor (a) code for determining whether a specified strategy order is tradable with respect to the received market data, (b) code for selecting a tradable strategy order from the strategy order book, (c) code for matching a selected strategy order to a specific contrast strategy order, the first contrast strategy order being tradable and having each strategy compatible with the strategy of the selected strategy order, the matched selected strategy order and the specific contrast strategy order forming each match having an unbroken initial state, information about each match being stored in the memory, and code for the rate strategies of the two orders being compatible when there is at least one overlapping rate value that satisfies the rate strategies of the selected strategy order and the specific contrast strategy order, (d) code for evaluating the matching state of the matches stored in the memory, the code for breaking each match between each strategy order and each contrast strategy order when any of the strategy orders is not tradable (e) code to select, as a selected rate for matching at the maximum rate that satisfies the rate strategy of each of the strategy orders and the rate strategy of each of the contrast strategy orders of each of the matchings; (f) code for processing each matching in memory, wherein each matching (i) responds to receipt of an instance of new trade data in the stream of market data, intermittently issues a fill of the tradable item between each strategy order and each contrast strategy order in each matching, the amount of the fill being a function of the selected rate of each matching adapted to the trade amount of the item in each new trade data, and since new trade data is received while each matching is not disrupted, each matching results in multiple fills between the strategy orders of each matching, (ii) sends at least one execution message to each source of each strategy order and each source of each first contrast strategy order, each execution message indicating at least one fill amount; a system comprising the code. **Claim 2** The system according to claim 1, wherein the computer instruction further comprises code for receiving a new strategy order and adding a record of the new strategy order to the strategy order book. **Claim 3** The computer instruction receives a new non-strategy order, selects each strategy for the non-strategy order, and further comprises code for adding the new non-strategy order having each strategy to the strategy order book. The system according to claim 2. **Claim 4** The system according to claim 1, wherein the computer instruction further comprises code for sending a matching detection condition message to each source of each of the matched orders in response to a matching of each strategy order and each contrast strategy order. **Claim 5** The system according to claim 4, wherein the computer instruction further comprises code for sending a matching end condition message to at least one of the source of the strategy order in each matching and the source of the contrast strategy order in each matching in response to a break in each matching.

6. The code for determining when a particular strategy order is tradable comprises code for determining the marketability of each strategy order in the strategy order book for the new instance of market data in response to receipt of the new instance of market data, wherein each strategy order is tradable if it is marketable and has available capacity for participating in fill trading, according to the system of claim 1.

7. The marketability of each strategy order is determined based on the limit price of each strategy order compared to at least one of the current ask price and the current bid price, according to the system of claim 6.

8. The price of each fill is the reported trade price in each instance of the new trade data, according to the system of claim 1.

9. For a first rate strategy in a first rate range between R1 and R2 and a second rate strategy in a second rate range between R3 and R4, where the first rate range and the second rate range overlap, and the maximum rate compatible with the first rate strategy and the second rate strategy is the maximum rate in the overlap between the first rate range and the second rate range, according to the system of claim 1.

10. For a first rate strategy having a first rate range between R1 and R2 (R2 > R1) and a second rate strategy for rate liquidity search, the maximum rate compatible with each strategy is R2, according to the system of claim 1.

11. The order for matching a selected strategy order to a particular counter-strategy order further comprises code for sending a confirmation message to each source of each conditional order in response to at least one of each matched strategy order and counter-strategy order being conditional, and waiting for each conditional order to be confirmed, wherein the code for processing each match in memory does not operate to process each match if there are unconfirmed conditional orders, according to the system of claim 1.

12. The record of the strategy order book for each strategy order comprises the size of the available capacity for each strategy order. ​ The code for matching a selected strategy order to a specific contrast order further comprises code for reducing the available capacity of each of the strategy orders and each of the contrast strategy orders by an amount that depends on the maximum rate that satisfies the rate strategy of each of the strategy orders and the rate strategy of each of the contrast strategy orders, in response to detecting each matching between each strategy order and each contrast strategy order. Each strategy order having a first strategy and matching a first contrast strategy order can be simultaneously matched to a second contrast strategy order having each rate strategy compatible with the rate strategy of the first strategy order and having the reduced available capacity of the first strategy order. The system according to claim 1, wherein the code for processing each matching in the memory operates to process the second matching until the second matching breaks.

13. The computer instruction further comprises code for selecting the specific contrast strategy order from a plurality of eligible contrast strategy orders according to at least one predetermined matching priority criterion, according to the system of claim 1.

14. The system according to claim 13, wherein the predetermined matching priority criterion comprises strategy fluidity.

15. The system according to claim 14, wherein the predetermined matching priority criterion further comprises one or more of order source, order desk, original order size, and order arrival time, and the priority order selection specified for each strategy order.

16. The computer instruction further comprises code for changing the strategy of each strategy order in the strategy order book to an alternative strategy in response to receiving a change strategy message for each of the strategy orders, according to the system of claim 1.

17. The computer instruction further comprises code for detecting a strategy change condition and evaluating market data received for a strategy change rule to change the strategy of each strategy order in the strategy order book to an alternative strategy in response to detecting the strategy change condition, according to the system of claim 1.

18. The computer instruction further comprises code for selecting a strategy for use with the non-strategic order in response to receipt of the non-strategic order, and adding the non-strategic order having the selected strategy to the strategic order book, wherein the non-strategic order is converted into a strategic order, the system according to claim 1.

19. The code for selecting a tradable strategic order from the strategic order book configures the processor to select the strategic order from a plurality of selectable orders based on at least one predetermined selection priority criterion, the system according to claim 1.

20. The at least one predetermined selection priority criterion comprises at least one of order size, order marketability, order cost, order age, and order matching status, the system according to claim 19.

21. The computer instruction further comprises code for issuing a fill between the maximum amount available for each strategic order having a liquidity search strategy and each contrast strategic order having a liquidity search strategy in response to matching of each strategic order having a liquidity search strategy with each contrast strategic order having a liquidity search strategy, wherein the fill has the lesser of (i) the maximum total amount available for each strategic order and (ii) the maximum total amount available for the contrast strategic order, the system according to claim 1.

22. A method for analyzing and processing orders from an electronic trading network, The method is implemented on a computer having a memory and storage, and the method Receiving a plurality of strategic orders for tradable items, each strategic order having each source, each side, limit price, quantity, and rate strategy specified, and the plurality of strategic orders comprising a first strategic order for the tradable item and a plurality of strategic order contras for the one strategic order; Storing information about the received strategic orders in a strategic order book held in the computer memory; Receiving a stream of market data for the item, the instance of the reference trade data indicating the third party reported for the item in each trading volume and amount and the bid and ask data for each item; Determining whether the designated strategy order is tradable with respect to the received market data; Selecting a first tradable strategy order from the strategy order book; Matching the first strategy order to a first counter strategy order, the first counter strategy order being tradable, having each strategy compatible with the strategy of the first strategy order, the matched first strategy order and the first counter strategy order forming a first match in an unbroken initial state, and when there is at least one overlapping rate value satisfying the rate strategies of the first strategy order and the first counter strategy order, the rate strategies of the two orders being compatible and the match between the first strategy order and the first counter strategy order being initially unbroken; Selecting, as the selected rate, the maximum rate satisfying the rate strategy of the first strategy order and the rate strategy of the first counter strategy order; After the step of matching the first strategy order to the first counter strategy order, receiving a plurality of instances of new trade data in the stream of market data; In response to receiving an instance of new trade data in the stream of market data, intermittently issuing a fill for the tradable item between the first strategy order and the first counter strategy order, the amount of the fill being a function of the selected rate adapted to the trade volume of the item in each new trade data, and since new reference trade data is received while the match between the first strategy order and the first counter strategy order is unbroken, the match between the first strategy order and the first counter strategy order resulting in a plurality of separate fills; Evaluating the matching status between the first strategy order and the first contrast strategy order, and breaking the first match if either the first strategy order or the contrast strategy order is not tradable; A method comprising: transmitting at least one execution message to the source of the first strategy order and the source of the first contrast strategy order, each execution message indicating at least one fill quantity.

23. The method according to claim 22, further comprising transmitting a matching detection message to the source of the first strategy order and the source of the first contrast strategy order in response to the formation of the first match.

24. The step of transmitting at least one execution message comprises transmitting each execution message to the source of the first strategy order and the source of the first contrast strategy order after each fill between the first strategy order and the first contrast strategy order, and each execution message designates the quantity of each fill. The method according to claim 22.

25. The method according to claim 22, further comprising transmitting a matching end message to at least one of the source of the first strategy order and the source of the first contrast strategy order in response to the break of the first match.

26. The step of issuing each fill of the items between the first strategy order and the first contrast strategy order is performed in response to the reception of each instance of new trade data. The method according to claim 22.

27. The rate strategy of the first strategy order is not the same as the rate strategy of the first contrast strategy order. The method according to claim 22.

28. The rate strategy of the first strategy order has a first rate range between R1 and R2, the rate strategy of the first contrast strategy order has a second rate range between R3 and R4, and the first rate range overlaps with the second rate range. The maximum rate that satisfies the rate strategy of the first strategy orderer and the rate strategy of the first contrast orderer is the maximum rate in the overlap between the first rate range and the second range. The method according to claim 27.

29. The strategy of the first strategy orderer has a first rate range between R1 and R2 (R2 > R1), the strategy of the second strategy orderer has a liquidity search rate, and the maximum rate of the rate strategy of the first strategy orderer and the rate strategy of the first contrast strategy orderer is R2. The method according to claim 27.

30. The first contrast strategy orderer is selected from a set of available matching contrast strategy orderers prioritized by the rate strategy liquidity. The method according to claim 22.

31. The first contrast strategy orderer is selected from a set of available matching contrast strategy orderers that are prioritized based on at least one predetermined matching priority criterion. The method according to claim 22.

32. The at least one predetermined matching priority criterion comprises one or more of order source, order desk, original order size, and order arrival time, and the prioritized selection specified by the first strategy orderer. The method according to claim 31.

33. Responding to the first contrast strategy orderer being a conditional order; Sending a confirmation message to each source of the first contrast strategy orderer; Waiting for the first contrast strategy orderer to be confirmed. The method further comprises, During the step of intermittently issuing a fill of the tradable item between the first strategy orderer and the first contrast strategy orderer, the first fill of the item between the first strategy orderer and the first contrast strategy orderer is not performed until the first contrast strategy orderer is confirmed. The method according to claim 22.

34. The information of each strategy orderer in the strategy orderer book comprises a measure of the available capacity of each strategy orderer. The method comprises In response to the matching of the first strategy order to the first contrast strategy order, reducing the available capacity of the first strategy order by an amount depending on the maximum rate of the matching between the first strategy order and the first contrast strategy order; Detecting a matching between the first strategy order and a second contrast strategy order in the strategy order book, wherein the second contrast strategy order is tradable and each strategy rate range having the reduced available capacity of the first strategy order overlaps with the strategy rate range of the first strategy order provided; When the first strategy order or the second contrast strategy order becomes non-tradable, breaking the matching between the first strategy order and the second contrast strategy order; The method according to claim 22, further comprising processing the second matching between the first strategy order and the second contrast strategy order until the matching between the first strategy order and the second contrast strategy order breaks.

35. The method according to claim 22, further comprising, in response to receiving a change strategy message of each strategy order, changing each strategy of each strategy order in the strategy order book to an alternative strategy.

36. Evaluating market data against a strategy change rule to detect a strategy change condition; The method according to claim 22, further comprising, in response to detecting the strategy change condition, changing each strategy of the strategy order in the strategy order book to an alternative strategy.

37. Receiving a non-strategy order of a first tradable item; Selecting a strategy to be used in the non-strategy order; Adding the non-strategy order having the selected strategy to the strategy order book, The non-strategy order is converted into a strategy order, the method according to claim 22.

38. The tradable item comprises a first security, the first market data comprises data indicating the best available ask price and the best available bid price in the market for at least the first security, and the second market data comprises trade data indicating at least one reported trade of the first security at each traded quantity and each traded price, the method according to claim 22.

Images